Bug#1077579: liblld-18: liblld does not contain any runtime libraries
Package: liblld-18 Version: 1:18.1.8-7 Severity: normal X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, the package only contains object archives, which should be provided by liblld-18-dev. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-23-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages liblld-18 depends on: ii libllvm18 1:18.1.8-1 liblld-18 recommends no packages. liblld-18 suggests no packages.
Bug#1072908: libc++-18-dev: install c++20 module definitions
Sorry, I just figured out they are installed, at `/usr/lib/llvm-18/share/libc++/v1` (did assume they would end up in /usr/share for some reason). Bug is invalid Norbert
Bug#1072908: libc++-18-dev: install c++20 module definitions
Sorry, I just figured out they are installed, at `/usr/lib/llvm-18/share/libc++/v1` (did assume they would end up in /usr/share for some reason). Bug is invalid Norbert
Bug#1052009: Provide compiler-rt builtins for windows/mingw-64
So, this went rather smooth. just had to copy over stuff from wasm. The patch builds the compiler-rt libraries for windows. in short, there will be 2 new files in libclang-rt-18-dev: /usr/lib/llvm-18/lib/clang/18/lib/windows/libclang_rt.builtins-i386.a /usr/lib/llvm-18/lib/clang/18/lib/windows/libclang_rt.builtins-x86_64.a The result is that, aslong as mingw-w64-x86-64-dev is installed, this will work: clang -rtlib=compiler-rt -target x86_64-w64-mingw test.cpp Notably, I hard-coded those archs, windows support would make sense for aarch64 and armv7 aswell. I am unsure how the policy is, when to build which target architecture, clang/llvm wont care. maybe place all windows builtins into an libclang-rt-18-dev-w64 package for all architectures? regards, Norbert Am Di., 30. Apr. 2024 um 22:14 Uhr schrieb Norbert Lange : > > Am So., 28. Apr. 2024 um 18:17 Uhr schrieb Sylvestre Ledru > : > > > > Hello > > > > > > Le 16/09/2023 à 00:29, Norbert Lange a écrit : > > > Package: libclang-rt-16-dev > > > Version: 1:16.0.6-3 > > > Severity: wishlist > > > X-Debbugs-Cc: nolang...@gmail.com > > > > > > Adding the compiler-rt library for windows / mingw-64 would allow ease > > > building > > > mingw-64 tools, > > > the builtins seem to be pretty universal for any windows target. > > > > > > There is a project providing a full mingw toolchain for reference: > > > https://github.com/mstorsjo/llvm-mingw > > > > > > I am able to create the builtins just with the mingw-w64-common package > > > and > > > debians llvm/clang like this: > > > > Sorry but I am not a windows user (or interested by this space), could > > you please provide a MR to implement this? > > I am not windows user (or interested by this space) but I am forced to build > for it and I prefer still staying away from that OS as much as possible. > > The package is a a bit of a monster though, both in complexity as well > as build-time. > Any tips for hacking around? > > Ill try to look at 'build-wasm/compiler-rt-%'. > > I am meant to use STAGE2 binaries? Are those the final ones? > > Given that clang is a native crosscompiler, I guess it makes sense providing > the mingw builtins as "all" package like libclang-rt-18-dev-wasm32? > > Ill see if I find time for that next week. > > Regards, Norbert diff -burN debian.orig/control debian/control --- debian.orig/control 2024-04-04 07:52:43.0 +0200 +++ debian/control 2024-06-17 14:40:56.331727789 +0200 @@ -29,6 +29,7 @@ llvm-spirv-18 [amd64 arm64 armhf i386 ppc64 ppc64el riscv64 s390x] | hello [amd64 arm64 armhf i386 ppc64 ppc64el riscv64 s390x] , spirv-tools [linux-any] | hello [linux-any], wasi-libc | hello, +mingw-w64-common [amd64 arm64 armhf i386], libcurl4-openssl-dev | libcurl-dev , libgrpc++-dev [amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] , protobuf-compiler-grpc [amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] , diff -burN debian.orig/rules debian/rules --- debian.orig/rules 2024-05-19 09:27:15.0 +0200 +++ debian/rules 2024-06-17 14:45:48.531063108 +0200 @@ -938,6 +938,38 @@ STAGE_2_WASM_CFLAGS := $(filter-out -march=% -mfpu=% -fcf-protection% -mbranch-protection%, $(STAGE_2_CFLAGS)) STAGE_2_WASM_CXXFLAGS := $(filter-out -march=% -mfpu=% -fcf-protection% -mbranch-protection%, $(STAGE_2_CXXFLAGS)) +build-mingw/compiler-rt-%: cpu = $(@:build-mingw/compiler-rt-%=%) +build-mingw/compiler-rt-%: + @echo "Building compiler-rt for $(cpu)-w64-windows-gnu" + @echo "Using cmake: $(CMAKE_BIN)" + mkdir -p "$@" + $(CMAKE_BIN) -B "$@" -S compiler-rt/lib/builtins/ \ + -G Ninja \ + $(SCCACHE_CMAKE) \ + -DCMAKE_SYSTEM_NAME=Windows \ + -DCMAKE_SYSROOT=/usr/share/mingw-w64 \ + -DCMAKE_C_COMPILER_TARGET=$(cpu)-w64-windows-gnu \ + -DCMAKE_CXX_COMPILER_TARGET=$(cpu)-w64-windows-gnu \ + -DCMAKE_ASM_COMPILER_TARGET=$(cpu)-w64-windows-gnu \ + -DCMAKE_C_COMPILER=$(STAGE_2_BIN_DIR)/clang \ + -DCMAKE_CXX_COMPILER=$(STAGE_2_BIN_DIR)/clang++ \ + -DCMAKE_C_FLAGS="$(opt_flags)" \ + -DCMAKE_CXX_FLAGS="$(opt_flags)" \ + -DCMAKE_SHARED_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \ + -DCMAKE_MODULE_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \ + -DCMAKE_EXE_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \ + -DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-$(LLVM_VERSION)/lib/clang/$(LLVM_VERSION) \ + -DCMAKE_INSTALL_DATADIR=lib \ + -DCMAKE_INSTALL_INCLUDEDIR=include \ + -DLLVM_CMAKE_DIR=$(STAGE_2_BIN_DIR)/../ \ + -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON \ + -DCOMPILER_RT_USE_BUILTINS_LIBRARY=ON \ + -DCOMPILER_RT_EXCLUDE_ATO
Bug#1072908: libc++-18-dev: install c++20 module definitions
Package: libc++-18-dev Version: 1:18.1.6-1 Severity: wishlist X-Debbugs-Cc: nolang...@gmail.com Please install the datafiles necessary to use `import std;', the flag would be -DLIBCXX_INSTALL_MODULES=ON . -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc++-18-dev depends on: ii libc++1-181:18.1.6-1 ii libc++abi-18-dev 1:18.1.6-1 ii libunwind-18-dev 1:18.1.6-1 libc++-18-dev recommends no packages. libc++-18-dev suggests no packages. -- no debconf information
Bug#1072379: clang-scan-deps tool is required for C++20 modules
Package: clang Version: 1:18.0-59~exp1 Severity: normal X-Debbugs-Cc: nolang...@gmail.com clang-scan-deps should be part of the basic compiler toolchain, given that C++20 Module support is standardized and finally starting to be usable. It should be available in the clang package as /usr/bin/clang-scan-deps. For ex. CMake recently added support for C++20 modules, needing clang-scan-deps as part of the basic compiler toolchain. [1] - https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html -- System Information: Debian Release: 12.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clang depends on: ii clang-18 1:18.1.6-1 clang recommends no packages. clang suggests no packages. -- no debconf information
Bug#1071210: libc++abi1-18:amd64: libc++abi probably should not use libunwind, seqfaults with pthread_cancel
Found some discussion, kinda reinforcing my assumption: https://reviews.llvm.org/D106703 ie. you should only ever have one of the unwinder libraries on one system, the other should be not there or a symlink.
Bug#1071210: libc++abi1-18:amd64: libc++abi probably should not use libunwind, seqfaults with pthread_cancel
Found some discussion, kinda reinforcing my assumption: https://reviews.llvm.org/D106703 ie. you should only ever have one of the unwinder libraries on one system, the other should be not there or a symlink.
Bug#1071210: libc++abi1-18:amd64: libc++abi probably should not use libunwind, seqfaults with pthread_cancel
Package: libc++abi1-18
Version: 1:18.1.2-1
Severity: normal
X-Debbugs-Cc: nolang...@gmail.com
Dear Maintainer,
I am obsorving reproducible crashes when compiling using libc++,
it seems that the cause is mixing unwinding from libgcc_s
with libunwind.
I also ofen observe debugging sessions just closing down, which
I havent narrowed down but they seem to be the same cause.
There is an upstream issue [1], it seems its reproducible on
many clang/debian versions. Yet it is fine on Fedora, the obvious
difference is that libc++abi is not linked against libunwind there
To reproduce, compile with: clang++ -stdlib=libc++ test_cancel.cpp
```
#include
#include
extern "C" int main()
{
std::thread systhr([]() {
std::this_thread::sleep_for(std::chrono::seconds(1)); });
std::this_thread::sleep_for(std::chrono::seconds(1));
pthread_cancel(systhr.native_handle());
systhr.join();
return 0;
}
```
Running the produced executable will end in an SEGFAULT, with the following
trace:
```
#0 0x in ?? ()
#1 0x7f70fc3b1baa in unw_get_proc_info () at
build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libunwind/src/libunwind.cpp:188
#2 0x7f70fc3b588c in _Unwind_GetLanguageSpecificData () at
build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libunwind/src/UnwindLevel1.c:478
#3 0x7f70fc3a001d in scan_eh_tab () at
build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libcxxabi/src/cxa_personality.cpp:617
#4 __gxx_personality_v0 () at
build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libcxxabi/src/cxa_personality.cpp:947
#5 0x7f70fc28fab6 in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0x7f70fc092d30, context=context@entry=0x7f70fc091650,
frames_p=frames_p@entry=0x7f70fc091558) at
../../../src/libgcc/unwind.inc:183
#6 0x7f70fc2901b0 in _Unwind_ForcedUnwind (exc=0x7f70fc092d30,
stop=0x7f70fc1272c0 , stop_argument=)
at ../../../src/libgcc/unwind.inc:218
#7 0x7f70fc127440 in __GI___pthread_unwind (buf=) at
./nptl/unwind.c:130
#8 0x7f70fc11d73b in __do_cancel () at ../sysdeps/nptl/pthreadP.h:282
#9 sigcancel_handler (sig=32, si=0x7f70fc0918f0, ctx=) at
./nptl/pthread_cancel.c:65
#10 sigcancel_handler (sig=, si=0x7f70fc0918f0, ctx=) at ./nptl/pthread_cancel.c:32
#11
#12 0x7f70fc165485 in __GI___clock_nanosleep (clock_id=clock_id@entry=0,
flags=flags@entry=0, req=0x7f70fc091db8, rem=0x7f70fc091db8)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
#13 0x7f70fc169d93 in __GI___nanosleep (req=, rem=) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#14 0x7f70fc41df9b in __libcpp_thread_sleep_for () at
build-llvm/tools/clang/stage2-bins/include/c++/v1/__threading_support:411
#15 sleep_for () at
build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libcxx/src/thread.cpp:108
#16 0x55bf7ab29a5e in void std::__1::this_thread::sleep_for >(std::__1::chrono::duration > const&) ()
#17 0x55bf7ab297fd in main::$_0::operator()() const ()
#18 0x55bf7ab29795 in decltype ((static_cast({parm#1}))())
std::__1::__invoke(main::$_0&&) ()
#19 0x55bf7ab29775 in void
std::__1::__thread_execute >,
main::$_0>(std::__1::tuple >, main::$_0>&,
std::__1::__tuple_indices<>) ()
#20 0x55bf7ab29532 in void*
std::__1::__thread_proxy >, main::$_0> >(void*) ()
#21 0x7f70fc11f134 in start_thread (arg=) at
./nptl/pthread_create.c:442
#22 0x7f70fc19f7dc in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```
[1] - https://github.com/llvm/llvm-project/issues/90041
Regards, Norbert
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libc++abi1-18:amd64 depends on:
ii libc6 2.36-9+deb12u7
ii libunwind-18 1:18.1.2-1
libc++abi1-18:amd64 recommends no packages.
libc++abi1-18:amd64 suggests no packages.
-- no debconf information
Bug#1052009: Provide compiler-rt builtins for windows/mingw-64
Am So., 28. Apr. 2024 um 18:17 Uhr schrieb Sylvestre Ledru : > > Hello > > > Le 16/09/2023 à 00:29, Norbert Lange a écrit : > > Package: libclang-rt-16-dev > > Version: 1:16.0.6-3 > > Severity: wishlist > > X-Debbugs-Cc: nolang...@gmail.com > > > > Adding the compiler-rt library for windows / mingw-64 would allow ease > > building > > mingw-64 tools, > > the builtins seem to be pretty universal for any windows target. > > > > There is a project providing a full mingw toolchain for reference: > > https://github.com/mstorsjo/llvm-mingw > > > > I am able to create the builtins just with the mingw-w64-common package and > > debians llvm/clang like this: > > Sorry but I am not a windows user (or interested by this space), could > you please provide a MR to implement this? I am not windows user (or interested by this space) but I am forced to build for it and I prefer still staying away from that OS as much as possible. The package is a a bit of a monster though, both in complexity as well as build-time. Any tips for hacking around? Ill try to look at 'build-wasm/compiler-rt-%'. I am meant to use STAGE2 binaries? Are those the final ones? Given that clang is a native crosscompiler, I guess it makes sense providing the mingw builtins as "all" package like libclang-rt-18-dev-wasm32? Ill see if I find time for that next week. Regards, Norbert
Bug#1056126: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#1056126: fixed in llvm-toolchain-17 1:17.0.6-1)
4446 devel optional > llvm-toolchain-17_17.0.6-1_amd64.buildinfo > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmVnEiAACgkQfmUo2nUv > G+HK6BAAkqLRSXlBOqLp2znV9xP2LYnybsIZE78/sWYK+l70dGQ9aAEYU7JW9Ql5 > DtzUZzBKrluYaxnkoFepTIsxDcvjfq3LHEGIqs5v5IfcMVTDAHBRFdV3mPAcYna9 > mp3ulK7kk192sVHBnh7dBX6S/DqxYfMZFJxQMUKAsczCU8eOevglW6C1CFF/CgC0 > FWGZK3E8x1qj6EeubJlscUSktQUf4QUpQJcR7JXMaxsUV6ioESU47J9v1Sd9UcBn > /kkaMX+Ax/L5czL8Qk7v/I86idw+geLA3WPST7a9Od+nZIs5yiPbZbbW3NvMg0D3 > mfSwPMB5ZedgH91U4iALYwLbGyC+x7ESz6Ep6AUhMj1YNL49FSBGXfESPERc5zkW > 2J6jw8tsLU+X7wKVr4H8GXuULEK1IeluQyzFApV2066ENK7ZUBT+hYOJrZOiKHpe > qUsyjwFcH8wVuMZn/dk1U488a5zaH6iDnkFGQV2nuJNoYxPMt1szAJ2PuQ7CTSax > m+zNwtzt17599oIGvYXRfOnN57KTW6b6j1w5YtRIpkvzRnGoHt9DQkXjLEXyDL6r > 6/spFlxl3HtIn3SWw19tooF8V3gOUzCR0cCjGNag2lB16oERXyK6vVREak+GDh9h > RabSEk4crwCAJcQGSN1qMSs5IXWxcDyQekQqkU/AQei6ab86THA= > =2XHW > -END PGP SIGNATURE- > > > -- Forwarded message -- > From: Norbert Lange > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Fri, 17 Nov 2023 12:28:46 +0100 > Subject: libclang1-17: libclang-17.so.1 uses wrong SONAME > Package: libclang1-17 > Version: 1:17.0.5-1 > Severity: normal > X-Debbugs-Cc: nolang...@gmail.com > > Dear Maintainer, > > libclang-17.so.1 specifies the wrong SONAME, > namely the full revision like for example: > 'libclang-17.so.17.0.5' > > It should be 'libclang-17.so.1'. > > Otherwise users of the library like doxygen will > need to be rebuilt for every patch release. > > > > -- System Information: > Debian Release: 12.2 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libclang1-17 depends on: > ii libc6 2.36-9+deb12u3 > ii libgcc-s1 12.2.0-14 > ii libllvm17 1:17.0.5-1 > ii libstdc++6 12.2.0-14 > > libclang1-17 recommends no packages. > > libclang1-17 suggests no packages. > > -- no debconf information
Bug#1056126: libclang1-17: libclang-17.so.1 uses wrong SONAME
Package: libclang1-17 Version: 1:17.0.5-1 Severity: normal X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, libclang-17.so.1 specifies the wrong SONAME, namely the full revision like for example: 'libclang-17.so.17.0.5' It should be 'libclang-17.so.1'. Otherwise users of the library like doxygen will need to be rebuilt for every patch release. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libclang1-17 depends on: ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libllvm17 1:17.0.5-1 ii libstdc++6 12.2.0-14 libclang1-17 recommends no packages. libclang1-17 suggests no packages. -- no debconf information
Bug#911189: gpgme-json packaging
On Mon, 16 Jan 2023 02:01:37 +0100 =?ISO-8859-1?Q?=C1ngel?= wrote: > I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1 > and it works fine. > I would however name the new package gpgme-json, not libgpgme-bin > > The package is only providing gpgme-json(1). If it is going to ship > more binaries in the future, it can always be replaced. If someone is > told they need gpgme-json the expected package name is 'gpgme-json', > not libgpgme-bin. Plus, that lib prefix is even more confusing. > > Even the description (“This package contains the gpgme-json binary to > access GPGME...”) seem to ask for that name. > > That is the only nitpick I have. It "just works". :-) > > The debian/changelog would need updating, and rebased on top of gpgme > 1.18 (bookworm/sid) from the current 1.14. How about just playing the binary into a package name "gpgme", like Fedora does https://packages.fedoraproject.org/pkgs/gpgme/gpgme/fedora-rawhide.html#files
Bug#1039490: lldb-16: lldb should not depend on llvm-dev
Am Mo., 26. Juni 2023 um 21:02 Uhr schrieb Sylvestre Ledru : > > Hello > > > > > Dear Maintainer, > > > > lldb pulls in alot development headers, static libraries which it should > > noot require during runtime. > > I believe this is a simple mistake, but if not then the dependent stuff > > should > > be partitioned out from the huge llvm-dev package. > > Thanks. I wonder if I had a reason for doing it or not :p Seems to be in pretty much all llvm versions on debian, so lldb pulling in 380MB llvm internal stuff can be called a historical feature by now. I am using a hacked together package that omits llvm-dev as dependency, havent found an issue yet. Unrelated, but lldb-vscode https://github.com/llvm/llvm-project/tree/main/lldb/tools/lldb-vscode would need the package.json file. Dont see how installation for vscode could be automated, but having the file say in /usr/lib/llvm-16/share/lldb would help. regards, Norbert
Bug#1039490: lldb-16: lldb should not depend on llvm-dev
Package: lldb-16 Version: 1:16.0.6-1 Severity: normal X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, lldb pulls in alot development headers, static libraries which it should noot require during runtime. I believe this is a simple mistake, but if not then the dependent stuff should be partitioned out from the huge llvm-dev package. -- System Information: Debian Release: 12.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lldb-16 depends on: ii libc62.36-9 ii libclang-cpp16 1:16.0.6-1 ii libedit2 3.1-20221030-2 ii libgcc-s112.2.0-14 ii liblldb-16 1:16.0.6-1 ii libllvm161:16.0.6-1 ii libncurses6 6.4-4 ii libstdc++6 12.2.0-14 ii libtinfo66.4-4 ii libxml2 2.9.14+dfsg-1.2 ii llvm-16-dev 1:16.0.6-1 ii python3-lldb-16 1:16.0.6-1 ii zlib1g 1:1.2.13.dfsg-1 lldb-16 recommends no packages. lldb-16 suggests no packages. -- no debconf information
Bug#1036901: provide the erofsfuse binary as package
Package: erofs-utils
Version: 1.6-1
Severity: normal
Tags: patch
X-Debbugs-Cc: nolang...@gmail.com
Hello,
this tool is quite usefull, but it should be its own package.
I added a patch implementing this
-- System Information:
Debian Release: 12.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages erofs-utils depends on:
ii libc62.36-9
ii liblz4-1 1.9.4-1
ii liblzma5 5.4.1-0.2
ii libselinux1 3.4-1+b5
ii libuuid1 2.38.1-5+b1
erofs-utils recommends no packages.
erofs-utils suggests no packages.
-- no debconf information
diff -burN erofs-utils_1.6-1.debian.orig/debian/control
erofs-utils_1.6-1.debian/debian/control
--- erofs-utils_1.6-1.debian.orig/debian/control2023-03-11
17:00:00.0 +0100
+++ erofs-utils_1.6-1.debian/debian/control 2023-03-11 17:00:00.0
+0100
@@ -4,6 +4,7 @@
Build-Depends:
debhelper-compat (= 10),
pkg-config,
+ libfuse-dev,
liblz4-dev,
liblzma-dev,
libselinux1-dev,
@@ -27,3 +28,21 @@
which improves storage density, keeps relatively higher
compression ratios, which is more useful to achieve high
performance for embedded devices with limited memory.
+
+Package: erofsfuse
+Architecture: linux-any
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: FUSE Mount Utility for EROFS File System
+ EROFS (Enhanced Read-Only File System) is a lightweight
+ read-only file system with modern designs (eg. page-sized
+ blocks, inline xattrs/data, etc.) for scenarios which need
+ high-performance read-only requirements, e.g. Android OS
+ for smartphones and LIVECDs.
+ .
+ It also provides fixed-sized output compression support,
+ which improves storage density, keeps relatively higher
+ compression ratios, which is more useful to achieve high
+ performance for embedded devices with limited memory.
+ .
+ This package contains a utility to mount EROFS images
+ using FUSE.
diff -burN erofs-utils_1.6-1.debian.orig/debian/erofsfuse.install
erofs-utils_1.6-1.debian/debian/erofsfuse.install
--- erofs-utils_1.6-1.debian.orig/debian/erofsfuse.install 1970-01-01
01:00:00.0 +0100
+++ erofs-utils_1.6-1.debian/debian/erofsfuse.install 2023-03-11
17:00:00.0 +0100
@@ -0,0 +1,2 @@
+usr/bin/erofsfuse
+usr/share/man/man1/erofsfuse.1
diff -burN erofs-utils_1.6-1.debian.orig/debian/erofs-utils.install
erofs-utils_1.6-1.debian/debian/erofs-utils.install
--- erofs-utils_1.6-1.debian.orig/debian/erofs-utils.install1970-01-01
01:00:00.0 +0100
+++ erofs-utils_1.6-1.debian/debian/erofs-utils.install 2023-03-11
17:00:00.0 +0100
@@ -0,0 +1,2 @@
+usr/bin/*.erofs
+usr/share/man/man1/*.erofs.1
diff -burN erofs-utils_1.6-1.debian.orig/debian/rules
erofs-utils_1.6-1.debian/debian/rules
--- erofs-utils_1.6-1.debian.orig/debian/rules 2023-03-11 17:00:00.0
+0100
+++ erofs-utils_1.6-1.debian/debian/rules 2023-03-11 17:00:00.0
+0100
@@ -6,8 +6,6 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
-SKIP_FUSE2FS=yes
-
COMMON_CONF_FLAGS = --with-uuid --with-selinux --enable-lzma \
${EXTRA_CONF_FLAGS}
Bug#1036623: libclang-common-16-dev: missing LLVM_VERSION_FULL in include path
Package: libclang-common-16-dev Version: 1:16.0.4-1~exp1 Followup-For: Bug #1036623 X-Debbugs-Cc: nolang...@gmail.com Both symlinks are broken: /usr/lib/clang/16/include /usr/lib/clang/16/lib (I did not see any adverse effects yet) -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libclang-common-16-dev depends on: ii libllvm16 1:16.0.4-1~exp1 Versions of packages libclang-common-16-dev recommends: ii libclang-rt-16-dev 1:16.0.4-1~exp1 libclang-common-16-dev suggests no packages. -- no debconf information
Bug#1031489: NVIDIA 340.108 driver gives Segmentation fault at launch all Qt software
Package: libnvidia-legacy-340xx-glcore Version: 340.108-18 Followup-For: Bug #1031489 X-Debbugs-Cc: nolang...@gmail.com I can confirm this is still an issue, but debian might be at fault here. I will use wireshark as an example: # wireshark This will segfault with this stacktrace: #0 0x in ?? () No symbol table info available. #1 0x7f95fda01252 in ?? () from /lib/x86_64-linux-gnu/libnvidia- tls.so.340.108 No symbol table info available. #2 0x7f95ffacb81d in QThread::start(QThread::Priority) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 0x7f95ffacb81d is a call to pthread_create What likely happens is that the library needs to be loaded first LD_PRELOAD=libpthread.so.0 wireshark -> voila, no crash anymore What needs to happen is that libnvidia-tls.so.340.108 should depend on libpthread.so.0. I fixed up my version with the patchelf tool: patchelf --add-needed libpthread.so.0 /lib/x86_64-linux-gnu/libnvidia- tls.so.340.108 This took care of the issue for me. This should be feasible to fix in debian. -- Package-specific info: uname -a: Linux lano-work 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux /proc/version: Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 12.2.0 (Debian 12.2.0-14) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [NVS 300] [10de:10d8] (rev a2) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation GT218 [NVS 300] [10de:0862] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 May 23 14:58 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 May 23 14:58 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 May 23 14:58 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 May 23 14:58 pci-:01:00.0-card -> ../card0 video:x:44:lano Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/legacy-340xx link currently points to /usr/lib/nvidia/legacy-340xx link nvidia is /usr/lib/nvidia/nvidia slave nvidia--20-nvidia-legacy-340xx.conf is /etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf slave nvidia--libEGL.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 slave nvidia--libGL.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 slave nvidia--libglx.so is /usr/lib/nvidia/libglx.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1 slave nvidia--monitoring.conf is /usr/share/nvidia/monitoring.conf slave nvidia--nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump slave nvidia--nvidia-drm-outputclass.conf is /etc/nvidia/nvidia-drm-outputclass.conf slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf slave nvidia--nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so /usr/lib/nvidia/legacy-340xx - priority 340 slave nvidia--20-nvidia-legacy-340xx.conf: /etc/nvidia/legacy-340xx/20-nvidia-legacy-340xx.conf slave nvidia--libEGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.1 slave nvidia--libGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libGL.so.1 slave nvidia--libglx.so: /usr/lib/nvidia/legacy-340xx/libglx.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libnvidia-ml.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libvdpau_nvidia.so.1 slave nvidia--monitoring.conf: /usr/lib/nvidia/legacy-340xx/monitoring.conf slave nvidia--nvidia-blacklists-nouveau.conf: /etc/nvidia/nvidia-legacy-340xx-340.108/nvidia-blacklists-nouveau.conf slave nvidia--nvidia-bug-report.sh: /usr/lib/nvidia/legacy-340xx/nvidia-bug-report.sh slave nvidia--nvidia-debugdump: /usr/lib/nvidia/legacy-340xx/nvidia-debugdump slave nvidia--nvidia-drm-outputclass.conf: /etc/nvidia/legacy-340xx/nvidia-drm-outputclass.conf slave nvidia--nvidia-load.conf: /etc/nvidia/nvidia-legacy-340xx-340.108/nvidia-lo
Bug#1033484: mutter assert and kills the session on displaying popups (multiple apps liek nautilus)
Package: mutter Version: 43.3-5 Severity: grave X-Debbugs-Cc: nolang...@gmail.com Right clicking in Nautilus will bring down the Desktop Session immediatly (as well as in multiple other Application). This behaviour started with 43.2-? and is still appearing with 43.3-5, the only way I can use my system is downgrading to 43.0-2 and puttin libmutter-11-0 mutter on hold. It sounds identical to this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/2563 I have this behaviour on 2 systems, AMD with Opensource drivers and one with a really old Nvidia Card and "legacy" closed driver. Wayland / X11 rerspective - the only common thing seems to be 2 attached Monitors. Log from the crash: Mar 25 23:35:14 debian-xyz gnome-shell[2817]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed Mar 25 23:35:14 debian-xyz systemd[1]: Starting systemd-hostnamed.service - Hostname Service... Mar 25 23:35:14 debian-xyz systemd[1]: Started systemd-hostnamed.service - Hostname Service. Mar 25 23:35:15 debian-xyz gnome-shell[2817]: Buggy client caused popup to be placed outside of parent window Mar 25 23:35:16 debian-xyz gnome-shell[2817]: ** Mar 25 23:35:16 debian-xyz gnome-shell[2817]: libmutter:ERROR:../src/wayland/meta-wayland- popup.c:233:meta_wayland_popup_grab_get_top_popup: assertion failed: (!wl_list_empty (&grab->all_popups)) Mar 25 23:35:16 debian-xyz gnome-shell[2817]: Bail out! libmutter:ERROR:../src/wayland/meta-wayland- popup.c:233:meta_wayland_popup_grab_get_top_popup: assertion failed: (!wl_list_empty (&grab->all_popups)) Mar 25 23:35:16 debian-xyz gnome-shell[2817]: == Stack trace for context 0x55e7f6e26ad0 == Mar 25 23:35:16 debian-xyz gnome-shell[4415]: (EE) failed to read Wayland events: Broken pipe -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mutter depends on: ii adwaita-icon-theme43-1 ii gnome-settings-daemon-common 43.0-4 ii gsettings-desktop-schemas 43.0-1 ii libc6 2.36-8 ii libgles2 1.6.0-1 ii libglib2.0-0 2.74.6-1 hi libmutter-11-043.0-2 ii libwayland-client01.21.0-1 ii libx11-6 2:1.8.4-2 ii libxcomposite11:0.4.5-1 ii mutter-common 43.3-5 ii zenity3.44.0-1 mutter recommends no packages. Versions of packages mutter suggests: ii gnome-control-center 1:43.4.1-1 ii xdg-user-dirs 0.18-1 -- no debconf information
Bug#1030302: netavark: doesnt find aardvark-dns because of wrong default path
Package: netavark Version: 1.4.0-2 Severity: important X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, The netavark source has the path "/usr/libexec/podman/aardvark-dns" fixed in main.rs. Debian installs that binary in /usr/lib/podman/aardvark-dns instead. This will result in container dns not working and log entries like podman[180046]: [INFO netavark::commands::setup] dns disabled because aardvark-dns path does not exists -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages netavark depends on: ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 netavark recommends no packages. netavark suggests no packages. -- no debconf information
Bug#1020540: Any chance of getting this in before the freeze?
Hello Reinhard, podman been in testing for a while, can you find the time to apply the patch now? Regards, Norbert
Bug#998627:
On Fri, 20 Jan 2023, 06:52 Salvatore Bonaccorso, wrote: > Hi Norbert, > > On Thu, Jan 19, 2023 at 11:44:47PM +0100, Norbert Lange wrote: > > It's been ages, why isn't this enabled by now? How should this driver > > mature when no one can test it (without going through the hassle if > > compiling the Kernel). > > Thanks for asking back. NTFS3 driver is still not in astate making it > confident it's wise to enable it for a stable release. > > > https://lore.kernel.org/ntfs3/784f82c4-de71-b8c3-afd6-468869a36...@paragon-software.com/T/#me2324a967514564949f7ebcf3f9a5965f66921bf > is an example (it took from august to now, until the fix landed in > mainline). > > I think thus the arguments from https://bugs.debian.org/998627#75 > still holds. > > Regards, > Salvatore Hello Salvatore, AFAIK kernels receive a ton of patches in distros, Backported and what not. Is it not possible to atleast build the module but either blacklist it or offer it in a separate package? If it's in a sorry state, then that would direct the complaints to the module, not to the configuration. Thanks for the quick response. Norbert
Bug#998627:
It's been ages, why isn't this enabled by now? How should this driver mature when no one can test it (without going through the hassle if compiling the Kernel).
Bug#1020540: podman-remote should be built and offered as seperate package
Am Mo., 14. Nov. 2022 um 14:46 Uhr schrieb Reinhard Tartler : > > > > On Thu, Sep 22, 2022 at 7:00 PM Norbert Lange wrote: >> >> Package: podman >> Version: 4.2.1-0.1 >> Severity: minor >> Tags: patch >> X-Debbugs-Cc: nolang...@gmail.com >> >> Hello, >> >> I am aware of #1000521, I dont see it as resolved. >> >> The problem is that you can run podman as service, and clients >> can connect on for ex. an exposed unix socket. >> >> Practical example is: >> >> - run rootless podman providing an unix socker >> - run an container jenkins/inbound-agent container >> binding that socket >> - provide a binary that takes the same arguments as docker >> while using the socket >> >> Now the issue is, that you have to install podman and its many >> dependencies in the jenkins/inbound-agent container. >> >> Way better would be to use one of the simple remote-only clients, >> this is a single file without any dependencies >> (run ldd on both). >> >> docker provides the docker-ce-cli package, podman the podman-remote >> binary. >> >> Debian should offer the package as independent package, >> so client/server can be updated together. >> Then containers can get a bind-mount to the host's >> /usr/bin/podman-remote binary. > > > Thank you for your patch. I plan on integrating it soon. > > I haven't merged it yet as it would require another round through the NEW > queue, and I'd really like to get 4.3.1 into unstable first. Once we have > 4.3.1 in testing, I'd like to upload your patch, as processing times through > NEW is unpredictable, and I'd like to avoid having other updates to podman > stuck for weeks or months. Thats fine, my provisional build will work till then. I ended up using a statically built podman-remote, as some of the containers did not have a compatible libc. (nabbed from https://github.com/mgoltzsche/podman-static/blob/master/Dockerfile-remote) so a podman-remote-static package would be a good idea regards Norbert
Bug#1020540: podman-remote should be built and offered as seperate package
Package: podman
Version: 4.2.1-0.1
Severity: minor
Tags: patch
X-Debbugs-Cc: nolang...@gmail.com
Hello,
I am aware of #1000521, I dont see it as resolved.
The problem is that you can run podman as service, and clients
can connect on for ex. an exposed unix socket.
Practical example is:
- run rootless podman providing an unix socker
- run an container jenkins/inbound-agent container
binding that socket
- provide a binary that takes the same arguments as docker
while using the socket
Now the issue is, that you have to install podman and its many
dependencies in the jenkins/inbound-agent container.
Way better would be to use one of the simple remote-only clients,
this is a single file without any dependencies
(run ldd on both).
docker provides the docker-ce-cli package, podman the podman-remote
binary.
Debian should offer the package as independent package,
so client/server can be updated together.
Then containers can get a bind-mount to the host's
/usr/bin/podman-remote binary.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.1.3+ds1-1
ii crun 1.5+dfsg-1+b1
ii golang-github-containers-common 0.49.1+ds1-1
ii libc62.34-7
ii libdevmapper1.02.1 2:1.02.185-1
ii libgpgme11 1.17.1-4.1
ii libseccomp2 2.5.4-1+b1
Versions of packages podman recommends:
pn buildah
pn catatonit | tini | dumb-init
ii dbus-user-session 1.14.0-2
pn fuse-overlayfs
ii slirp4netns 1.2.0-1
ii uidmap1:4.11.1+dfsg1-2
Versions of packages podman suggests:
ii containers-storage 1.42.0+ds1-1
pn docker-compose
ii iptables1.8.8-1
-- no debconf information
diff -burN a/debian/control b/debian/control
--- a/debian/control2022-08-19 09:43:54.0 +0200
+++ b/debian/control2022-08-19 09:43:54.0 +0200
@@ -131,6 +131,32 @@
.
Podman is a daemon-less alternative to Docker.
+Package: podman-remote
+Architecture: any
+Built-Using: ${misc:Built-Using}
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: engine to run OCI-based containers in Pods
+ Podman is an engine for running OCI-based containers in Pods.
+ Podman provides a CLI interface for managing Pods, Containers, and
+ Container Images.
+ .
+ At a high level, the scope of libpod and podman is the following:
+ * Support multiple image formats including the OCI and Docker image
+formats.
+ * Support for multiple means to download images including trust & image
+verification.
+ * Container image management (managing image layers, overlay filesystems,
+etc).
+ * Full management of container lifecycle.
+ * Support for pods to manage groups of containers together.
+ * Resource isolation of containers and pods.
+ * Support for a Docker-compatible CLI interface through Podman.
+ .
+ Podman is a daemon-less alternative to Docker.
+ .
+ This package installs a smaller executable being only a
+ frontend to control a remote podman instance.
+
Package: golang-github-containers-libpod-dev
Architecture: all
Depends: ${misc:Depends},
diff -burN a/debian/podman.install b/debian/podman.install
--- a/debian/podman.install 2022-08-19 09:43:54.0 +0200
+++ b/debian/podman.install 2022-08-19 09:43:54.0 +0200
@@ -1,5 +1,4 @@
completions/zsh/_podman /usr/share/zsh/vendor-completions
-completions/zsh/_podman-remote /usr/share/zsh/vendor-completions
cni/87-podman-bridge.conflist /etc/cni/net.d/
debian/etc/containers/libpod.conf /etc/containers/
diff -burN a/debian/podman-remote.install b/debian/podman-remote.install
--- a/debian/podman-remote.install 1970-01-01 01:00:00.0 +0100
+++ b/debian/podman-remote.install 2022-08-19 09:43:54.0 +0200
@@ -0,0 +1,3 @@
+completions/zsh/_podman-remote /usr/share/zsh/vendor-completions
+
+usr/bin/podman-remote
diff -burN a/debian/podman-remote.manpages b/debian/podman-remote.manpages
--- a/debian/podman-remote.manpages 1970-01-01 01:00:00.0 +0100
+++ b/debian/podman-remote.manpages 2022-08-19 09:43:54.0 +0200
@@ -0,0 +1 @@
+docs/build/man/podman-remote*.1
diff -burN a/debian/rules b/debian/rules
--- a/debian/rules 2022-08-19 09:43:54.0 +0200
+++ b/debian/rules 2022-09-23 00:38:15.821251178 +0200
@@ -36,6 +36,7 @@
## https://podman.io/getting-started/installation#build-tags
BUILDTAGS := apparmor,ostree,seccomp,
Bug#1016163: llvm package misses llvm-addr2line symlink
Package: llvm Version: 1:14.0-55~exp2 Severity: normal X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, The package misses the llvm-addr2line -> llvm-addr2line-14 symlink. When the binutils are not installed, no tool for various "symbolizer" scripts is available under the normal name, this will also be used as fallback with buildsystems like CMake -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages llvm depends on: ii llvm-14 1:14.0.5-1 ii llvm-runtime 1:14.0-55~exp2 llvm recommends no packages. llvm suggests no packages. -- no debconf information
Bug#1014581: systemd-boot: kernel hook schould use conforming name
Package: systemd-boot
Version: 251.2-7
Severity: normal
X-Debbugs-Cc: nolang...@gmail.com
Dear Maintainer,
The kernel hook in /etc/kernel/{post,pre}inst.d should
be named correctly, to quote the kernel-handbook [1]:
> hook scripts for boot loaders must be named using
the prefix zz- and no other packages may use this prefix
so zz-systemd-boot whould be correct.
[1] - https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd-boot depends on:
ii libc6 2.33-7
ii libsystemd-shared 251.2-7
ii systemd-boot-efi 251.2-7
Versions of packages systemd-boot recommends:
pn efibootmgr
systemd-boot suggests no packages.
-- no debconf information
Bug#1014167: linux-image-5.18.0-0.bpo.1-cloud-amd64: cloud kernels should enable the F2FS filesystem
Package: src:linux Version: 5.18.2-1~bpo11+1 Severity: normal X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, I am trying to use the cloud variant kernel to quickly spin up a VM and run packaging jobs, including some filesystem images for embedded systems. Unfortunately f2fs is not available, this is a modern and popular filesystem, and would be my first choice. I dont see why it is not available as module in the cloud variants, potentially could be "builtin" as compression that would allow the VM images themself using F2FS (without initrd and modules). Sparse images (debian OS) using F2FS with compression are 60% the size compared with using ext4. Regards, Norbert Lange -- Package-specific info: ** Version: Linux version 5.18.0-0.bpo.1-cloud-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PREEMPT_DYNAMIC Debian 5.18.2-1~bpo11+1 (2022-06-14) ** Command line: initrd=\hipase_virtual\5.18.0-0.bpo.1-cloud-amd64\initrd console=tty0 console=ttyS0 root=PARTUUID=39b31ce0-33fb-42a8-9e4f-bd2adef2d810 ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: QEMU product_name: Standard PC (Q35 + ICH9, 2009) product_version: pc-q35-7.0 chassis_vendor: QEMU chassis_version: pc-q35-7.0 bios_vendor: EFI Development Kit II / OVMF bios_version: 0.0.0 ** Loaded modules: nls_ascii nls_cp437 vfat fat zstd zstd_compress zram zsmalloc nft_nat evdev serio_raw virtio_net efi_pstore net_failover virtio_console failover qemu_fw_cfg button nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse configfs efivarfs ip_tables x_tables autofs4 virtio_rng rng_core virtio_pci virtio virtio_pci_legacy_dev virtio_pci_modern_dev virtio_ring ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- BAR=0 offset= size= Capabilities: [70] Vendor Specific Information: VirtIO: Notify BAR=4 offset=3000 size=1000 multiplier=0004 Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg BAR=4 offset=2000 size=1000 Capabilities: [50] Vendor Specific Information: VirtIO: ISR BAR=4 offset=1000 size=1000 Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg BAR=4 offset= size=1000 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:06.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] Subsystem: Red Hat, Inc. Virtio network device [1af4:0001] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- BAR=0 offset= size= Capabilities: [70] Vendor Specific Information: VirtIO: Notify BAR=4 offset=3000 size=1000 multiplier=0004 Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg BAR=4 offset=2000 size=1000 Capabilities: [50] Vendor Specific Information: VirtIO: ISR BAR=4 offset=1000 size=1000 Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg BAR=4 offset= size=1000 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:07.0 Communication controller [0780]: Red Hat, Inc. Virtio console [1af4:1003] Subsystem: Red Hat, Inc. Virtio console [1af4:0003] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- BAR=0 offset= size= Capabilities: [70] Vendor Specific Information: VirtIO: Notify BAR=4 offset=3000 size=1000 multiplier=0004 Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg BAR=4 offset=2000 size=1000 Capabilities: [50] Vendor Specific Information: VirtIO: ISR BAR=4 offset=1000 size=1000 Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg BAR=4 offset= size=1000 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interfac
Bug#1010629: libc++-14-dev: provide memorysanitizer enabled variants of libc++ and libc++-abi
Package: libc++-14-dev
Version: 1:14.0.0-2
Severity: wishlist
X-Debbugs-Cc: nolang...@gmail.com
Dear Maintainer,
the MemorySanitizer basically requires all used libraries (outside of libc)
to be recompiled.
Given that a C++ library is needed for any C++ Application, providing
libc++ and libc++-abi would be very welcome.
Unfortunatly the llvm-toolchain package is rather complex, so it
is too much for me to figure out a solution.
The idea is that a separate package would install the instrumented
libraries into a subdirectory like
/usr/lib/x86_64-linux-gnu/msan/libc++{.so,.a}
/usr/lib/x86_64-linux-gnu/msan/libc++abi{.so,.a}
[1] - https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libc++-14-dev depends on:
ii libc++1-141:14.0.0-2
ii libunwind-14-dev 1:14.0.0-2
libc++-14-dev recommends no packages.
libc++-14-dev suggests no packages.
-- no debconf information
Bug#995810: libc++-13-dev: cant link without libuwind.so, should depend on that package
Package: libc++-13-dev
Version: 1:13.0.0-2
Severity: normal
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Hello,
if you install just clang and libc++-dev,
then a library is missing for linking
Test:
int main() {}' | /usr/bin/clang++ -stdlib=libc++ -stdlib=libc++ -fuse-ld=lld
-x c -
The solution should be to depend on libunwind-13-dev
Norbert
Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc++-13-dev depends on:
ii libc++1-13 1:13.0.0-2
libc++-13-dev recommends no packages.
libc++-13-dev suggests no packages.
-- no debconf information
Bug#986279: gnome-shell: Gnome completely hangs, allows no input after opening archive with file-roller
Package: gnome-shell Version: 3.38.4-1 Severity: important X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, I experience a very serious issue with the Gnome Desktop, when triggered: - Apps continue to run - The systemlog is swamped with entries - No input is procecessed, no Powerbutton, not switching to VT, nothing works. The way I can reproduce it almost always is by opening archives with file-roller. I dont know why I now get this issue, I noticed a recent glib2.0 upgrade to 2.66.8-1 which happened arond the same time. but downgrading to the older 2.66.7-2 version did not help. # Entry from /var/log/apt/history.log Start-Date: 2021-03-30 10:28:59 Commandline: apt-get dist-upgrade Upgrade: libglib2.0-bin:amd64 (2.66.7-2, 2.66.8-1), libglib2.0-data:amd64 (2.66.7-2, 2.66.8-1), libglib2.0-0:amd64 (2.66.7-2, 2.66.8-1), libglib2.0-0:i386 (2.66.7-2, 2.66.8-1) End-Date: 2021-03-30 10:29:01 # Part from syslog (will try to attach full file) Apr 02 10:52:06 systemd[1336]: Finished Cleanup of User's Temporary Files and Directories. Apr 02 10:53:16 gnome-shell[1490]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. Apr 02 10:53:16 gnome-shell[1490]: The offending signal was app-state-changed on ShellAppSystem 0x556db98ef8d0. Apr 02 10:53:16 gnome-shell[1490]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked. Apr 02 10:53:16 gnome-shell[1490]: == Stack trace for context 0x556db960b1a0 == Apr 02 10:53:16 gnome-shell[1490]: == Stack trace for context 0x556db960b1a0 == Apr 02 10:53:16 gnome-shell[1490]: == Stack trace for context 0x556db960b1a0 == Apr 02 10:53:16 gnome-shell[1490]: == Stack trace for context 0x556db960b1a0 == Apr 02 10:53:16 gnome-shell[1490]: The offending signal was app-state-changed on ShellAppSystem 0x556db98ef8d0. Only workaround for me currently is uninstalling file-roller. I am using Wayland with 2 monitors with different resolution and DPI (so Im kinda used to random issues). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii evolution-data-server3.38.3-1 ii gir1.2-accountsservice-1.0 0.6.55-3 ii gir1.2-atspi-2.0 2.38.0-2 ii gir1.2-freedesktop 1.66.1-1+b1 ii gir1.2-gcr-3 3.38.1-2 ii gir1.2-gdesktopenums-3.0 3.38.0-2 ii gir1.2-gdm-1.0 3.38.2.1-1 ii gir1.2-geoclue-2.0 2.5.7-3 ii gir1.2-glib-2.0 1.66.1-1+b1 ii gir1.2-gnomebluetooth-1.03.34.3-2 ii gir1.2-gnomedesktop-3.0 3.38.4-1 ii gir1.2-gstreamer-1.0 1.18.3-1 ii gir1.2-gtk-3.0 3.24.24-3 ii gir1.2-gweather-3.0 3.36.1-2 ii gir1.2-ibus-1.0 1.5.23-2 ii gir1.2-mutter-7 3.38.4-1 ii gir1.2-nm-1.01.30.0-1 ii gir1.2-nma-1.0 1.8.30-1 ii gir1.2-pango-1.0 1.46.2-3 ii gir1.2-polkit-1.00.105-30 ii gir1.2-rsvg-2.0 2.50.3+dfsg-1 ii gir1.2-soup-2.4 2.72.0-2 ii gir1.2-upowerglib-1.00.99.11-2 ii gjs 1.66.2-1 ii gnome-backgrounds3.38.0-1 ii gnome-settings-daemon3.38.1-3 ii gnome-shell-common 3.38.4-1 ii gsettings-desktop-schemas3.38.0-2 ii gstreamer1.0-pipewire0.3.19-4 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-10 ii libcairo21.16.0-5 ii libecal
Bug#981757: gnome-core: ensure heic images are supported out of the box
Package: gnome-core Severity: wishlist X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, Since 2019 some smartphone and camera vendors support HEIC images, and already set this format as default. In debian testing (/bullseye) support of that image-format is lacking. - EyeOfGnome needs heif-gdk-pixbuf to decode pictures - An extra heif-thumbnailer is needed. Some related discussion is in Bug#981538. Those formats will only get more popular, and finding the relation HEIC -> HEIF and the necessary packages involved is not obvious. For a good desktop experience, good out of the box support would be welcome. Kind regards, Norbert -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-core depends on: ii adwaita-icon-theme3.38.0-1 ii at-spi2-core 2.38.0-2 ii baobab3.38.0-1 pn caribou ii chromium 87.0.4280.88-0.4 ii dconf-cli 0.38.0-1 ii dconf-gsettings-backend 0.38.0-1 ii eog 3.38.1-1 ii evince3.38.0-3 ii evolution-data-server 3.38.3-1 ii fonts-cantarell 0.111-3 ii gdm3 3.38.2.1-1 ii gedit 3.38.1-1 ii gkbd-capplet 3.26.1-1 ii glib-networking 2.66.0-2 ii gnome-backgrounds 3.38.0-1 ii gnome-bluetooth 3.34.3-2 ii gnome-calculator 3.38.2-1 ii gnome-characters 3.34.0-1 pn gnome-contacts ii gnome-control-center 1:3.38.3-1 ii gnome-disk-utility3.38.1-1 ii gnome-font-viewer 3.34.0-2+b1 ii gnome-keyring 3.36.0-1 ii gnome-logs3.36.0-2 ii gnome-menus 3.36.0-1 ii gnome-online-accounts 3.38.0-3 pn gnome-online-miners ii gnome-session 3.38.0-3 ii gnome-settings-daemon 3.38.1-3 ii gnome-shell 3.38.3-1 ii gnome-shell-extensions3.38.2-1 pn gnome-software pn gnome-sushi ii gnome-system-monitor 3.38.0-1 ii gnome-terminal3.38.2-1 ii gnome-themes-extra3.28-1 pn gnome-user-docs ii gnome-user-share 3.34.0-2 ii gsettings-desktop-schemas 3.38.0-2 pn gstreamer1.0-packagekit ii gstreamer1.0-plugins-base 1.18.3-dmo1 ii gstreamer1.0-plugins-good 1.18.3-dmo1 ii gstreamer1.0-pulseaudio 1.18.3-dmo1 ii gvfs-backends 1.46.2-1 pn gvfs-fuse ii libatk-adaptor2.38.0-1 ii libcanberra-pulse 0.30-7 ii libglib2.0-bin2.66.4-1 ii libpam-gnome-keyring 3.36.0-1 ii libproxy1-plugin-gsettings0.4.17-1 ii libproxy1-plugin-webkit 0.4.17-1 ii librsvg2-common 2.50.3+dfsg-1 ii nautilus 3.38.2-1 ii pulseaudio14.1-1 ii pulseaudio-module-bluetooth 14.1-1 ii sound-theme-freedesktop 0.8-2 ii system-config-printer-common 1.5.14-1 ii system-config-printer-udev1.5.14-1 pn totem ii tracker 2.3.6-2 ii yelp 3.38.2-1 ii zenity3.32.0-6 Versions of packages gnome-core recommends: ii libproxy1-plugin-networkmanager 0.4.17-1 pn network-manager-gnome Versions of packages gnome-core suggests: pn gnome
Bug#981538: libgdk-pixbuf2.0-bin: supported mimetypes are not extended with additional gdk-pixbuf loader
Am Mo., 1. Feb. 2021 um 11:27 Uhr schrieb Simon McVittie : > > On Mon, 01 Feb 2021 at 10:48:07 +0100, Norbert Lange wrote: > > Am Mo., 1. Feb. 2021 um 10:37 Uhr schrieb Simon McVittie : > > > libheif maintainers: if heif-thumbnailer is considered safe for use, > > > then I think heif-gdk-pixbuf should probably have a Recommends (or > > > even Depends?) on heif-thumbnailer, to meet user expectations around > > > thumbnailing. If it's a Depends, then heif-thumbnailer should probably > > > become Multi-Arch: foreign, so that it does not prevent heif-gdk-pixbuf > > > from being Multi-Arch: same. > > > > Should I open an issue for that package, or on some gnome package? > > No need, I've reassigned your bug report to heif-gdk-pixbuf already. > > > heif/heic is getting common, would be nice to have support "out of the box" > > Today is the first time I've heard of this image format, so I don't think > it's necessarily key functionality for a desktop environment right now. > However, if you disagree, the place to request this would be a separate > wishlist bug report against one of the desktop metapackages (such as > "gnome"). Getting pics in this format from my sons kindergarden. Several Apple and Samsung phones (and I think cameras) use it by default since a couple years. I am more concerned about the state of support in the Linux world ;) Yeah, I am considering doing that. Thanks for helping, Norbert.
Bug#981538: libgdk-pixbuf2.0-bin: supported mimetypes are not extended with additional gdk-pixbuf loader
Am Mo., 1. Feb. 2021 um 10:37 Uhr schrieb Simon McVittie : > > Control: reassign -1 heif-gdk-pixbuf 1.10.0-2 > Control: retitle -1 heif-gdk-pixbuf: should have Recommends on > heif-thumbnailer? > > On Mon, 01 Feb 2021 at 09:19:58 +0100, Norbert Lange wrote: > > I was not getting thumbnails for heic/heif files. > > > > I would expect that installing the heif-gdk-pixbuf should > > be enough to enable support, but it needed editing the file > > /usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer, > > and adding the image/heif Mimetype. > > > > Naturally this change will be lost everytime this package > > will be upgraded. > > I don't think this is really something that the gdk-pixbuf package can or > should solve on its own. The thumbnailer files in /usr/share/thumbnailers > are static, not dynamic, and gdk-pixbuf-thumbnailer.thumbnailer is > only designed to describe the formats that are supported by the base > gdk-pixbuf library. > > One way it can be solved in packages that extend gdk-pixbuf would be for > them to have a Suggests, Recommends or Depends on libgdk-pixbuf2.0-bin, and > install a /usr/share/thumbnailers/foo-gdk-pixbuf.thumbnailer > that runs the same gdk-pixbuf-thumbnailer command, but has MimeType set > according to the MIME types for which this package adds support. > That's a direct equivalent of what happens in the librsvg2-common package, > also from GNOME, to add SVG support to gdk-pixbuf, which suggests that it > is the upstream-supported approach to getting more MIME types thumbnailed > via gdk-pixbuf. > > However, in the particular case of libheif it seems that this is > unnecessary, because there is also a heif-thumbnailer package that > provides its own, more specific thumbnailing code (extracting a thumbnail > from metadata if available, rather than loading the entire HEIF image just > to scale it down). I would recommend installing that if you are interested > in HEIF files. > > Authors of gdk-pixbuf plugins and .thumbnailer files should be aware that > file managers like Nautilus will trigger thumbnailing for downloaded files > (for example in ~/Downloads), and some web browsers will download files > into ~/Downloads without prompting under some circumstances (a "drive-by > download"). Combining these two factors means that a thumbnailer adds > significant attack surface to the system, so authors of gdk-pixbuf plugins > should not provide a corresponding .thumbnailer file for formats whose > decoder is not written defensively, with maliciously-crafted image files > in mind. Nautilus and libgnome-desktop attempt to mitigate any exploitable > bugs in thumbnailers by running them in a restricted sandbox environment, > but I don't think all consumers of the .thumbnailer mechanism do this. > > As a result, even if it was straightforward to implement, I think it would > be inappropriate for gdk-pixbuf to automatically provide thumbnailing > services for unknown gdk-pixbuf plugins: the authors of plugins that > are believed to be robust against maliciously-crafted image files need to > take action to opt-in to participating in the thumbnailing mechanism, and > take responsibility for the consequences. Ok, thanks for the Explanation. > > libheif maintainers: if heif-thumbnailer is considered safe for use, > then I think heif-gdk-pixbuf should probably have a Recommends (or > even Depends?) on heif-thumbnailer, to meet user expectations around > thumbnailing. If it's a Depends, then heif-thumbnailer should probably > become Multi-Arch: foreign, so that it does not prevent heif-gdk-pixbuf > from being Multi-Arch: same. Should I open an issue for that package, or on some gnome package? heif/heic is getting common, would be nice to have support "out of the box" Norbert
Bug#981538: libgdk-pixbuf2.0-bin: supported mimetypes are not extended with additional gdk-pixbuf loader
Package: libgdk-pixbuf2.0-bin Version: 2.42.2+dfsg-1 Severity: normal X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, I was not getting thumbnails for heic/heif files. I would expect that installing the heif-gdk-pixbuf should be enough to enable support, but it needed editing the file /usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer, and adding the image/heif Mimetype. Naturally this change will be lost everytime this package will be upgraded. I'd like a clean solution for this issue. Norbert -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgdk-pixbuf2.0-bin depends on: ii libc62.31-9 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 libgdk-pixbuf2.0-bin recommends no packages. libgdk-pixbuf2.0-bin suggests no packages. -- no debconf information
Bug#980068: cmake: Please update to version 3.19.3 before bullseye freeze
Package: cmake Version: 3.18.4-1+b1 Severity: wishlist X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, CMake 3.19.3 is currently the latest version, with it comes a rather usefull "presets" feature. Please update to the latest version so it can be included in Bullseye. Regards, Norbert -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cmake depends on: ii cmake-data3.18.4-1 ii libarchive13 3.4.3-2 ii libc6 2.31-9 ii libcurl4 7.74.0-1 ii libexpat1 2.2.10-1 ii libgcc-s1 10.2.1-3 ii libjsoncpp24 1.9.4-4 ii librhash0 1.4.1-1 ii libstdc++610.2.1-3 ii libuv11.40.0-1 ii procps2:3.3.16-5 ii zlib1g1:1.2.11.dfsg-2 Versions of packages cmake recommends: ii gcc 4:10.2.0-1 ii make 4.3-4 Versions of packages cmake suggests: pn cmake-doc ii ninja-build 1.10.1-1 -- no debconf information
Bug#973463: gnome-shell: needs Gst library installed
Am So., 1. Nov. 2020 um 11:44 Uhr schrieb Simon McVittie : > > On Sat, 31 Oct 2020 at 01:05:51 +0100, Norbert Lange wrote: > > Since a recent update I get this message in the log: > > > > JS ERROR: Error: Requiring Gst, version none: Typelib file for namespace > > 'Gst' (any version) not found > > @resource:///org/gnome/Shell/Screencast/js/screencastService.js:6:33 > > @resource:///org/gnome/Shell/Screencast/js/main.js:4:31 > > start@resource:///org/gnome/gjs/modules/script/package.js:206:5 > > @/usr/share/gnome-shell/org.gnome.Shell.Screencast:1:17 > > Does the Shell work normally, other than this warning? > > (I *think* it will work normally without this service, except that > screencasting, screen-recording, remote desktop won't work.) I guess so. Currently I am trying to track down issues that hand the login/desktop at bootup or after suspend, so I dont have a stable system to test. > > > I was able to fix this issue by installing gir1.2-clutter-gst-3.0, > > this should be a dependecy of the package. > > Please could you try removing that package, and installing > gir1.2-gstreamer-1.0? I think gir1.2-gstreamer-1.0 is the one you actually > need to avoid this error message, and gir1.2-clutter-gst-3.0 just works > around the issue by depending on it. You are correct here. > Most GNOME users will have both of those as a result of packages like > totem depending on them, so this will only happen in practice on systems > that have GNOME Shell but don't have most of the rest of GNOME, which > is presumably a description of your system. Yep, dont see why I have to carry packages around that I don't use ;) Norbert
Bug#803265: bluetooth.service: sap-server: Operation not permitted (1)
On Fri, 10 Feb 2017 11:09:43 +0100 Laurent Bonnaud wrote: > Hi, > > according to this: > > > https://raspberrypi.stackexchange.com/questions/40839/sap-error-on-bluetooth-service-status > > the error messages about SAP can be avoided by starting bluetoothd with the > "--noplugin=sap" option. > > Since SAP is probably of little use in Debian and since it does not work > anyway, how about disabling it by default? > > -- > Laurent. This repeatedly bites me, now the path changed from /usr/lib/bluetooth/bluetoothd to /usr/libexec/bluetooth/bluetoothd, causing the override to be invalid. Please figure out why this is an issue, if you can get it to work with debian, and if not disable it. Norbert
Bug#973463: gnome-shell: needs Gst library installed
Package: gnome-shell-common Version: 3.38.1-1 Severity: important X-Debbugs-Cc: nolang...@gmail.com Dear Maintainer, Since a recent update I get this message in the log: JS ERROR: Error: Requiring Gst, version none: Typelib file for namespace 'Gst' (any version) not found @resource:///org/gnome/Shell/Screencast/js/screencastService.js:6:33 @resource:///org/gnome/Shell/Screencast/js/main.js:4:31 start@resource:///org/gnome/gjs/modules/script/package.js:206:5 @/usr/share/gnome-shell/org.gnome.Shell.Screencast:1:17 I was able to fix this issue by installing gir1.2-clutter-gst-3.0, this should be a dependecy of the package. (Found this while looking for the reasons for some hangs, not sure if this is related or if it causes any harm) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 gnome-shell-common recommends no packages. gnome-shell-common suggests no packages. -- no debconf information
Bug#955469: initramfs-tools-core: Enable zstandard support
Am Fr., 31. Juli 2020 um 16:48 Uhr schrieb Sedat Dilek : > > Just FYI: > > Version 10 was now accepted in . > > Let's hope this will get into upcoming Linux v5.9. > > - Sedat - > > [1] https://github.com/terrelln/linux/commits/zstd-v10 > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/boot Thanks, I updated the patch, and made a merge request there: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests Norbert
Bug#959876: fakeroot: fstatat fails if pathname is empty
Package: fakeroot Version: 1.24-1 Severity: important Tags: patch Hello, testing a yet-to-be released version of systemd-tmpfiles under fakeroot. fakeroot is masking out flags like AT_EMPTY_PATH which would be necessary, so the calls will fail. systemd PR: https://github.com/systemd/systemd/pull/15718 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fakeroot depends on: ii libc62.30-4 ii libfakeroot 1.24-1 fakeroot recommends no packages. fakeroot suggests no packages. -- no debconf information --- a/libfakeroot.c +++ b/libfakeroot.c @@ -886,7 +886,7 @@ /* If AT_SYMLINK_NOFOLLOW is set in the fchownat call it should be when we stat it. */ INT_STRUCT_STAT st; - r=INT_NEXT_FSTATAT(dir_fd, path, &st, (flags & AT_SYMLINK_NOFOLLOW)); + r=INT_NEXT_FSTATAT(dir_fd, path, &st, (flags & (AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH | AT_NO_AUTOMOUNT))); if(r) return(r); @@ -1023,7 +1023,7 @@ /* If AT_SYMLINK_NOFOLLOW is set in the fchownat call it should be when we stat it. */ - r=INT_NEXT_FSTATAT(dir_fd, path, &st, flags & AT_SYMLINK_NOFOLLOW); + r=INT_NEXT_FSTATAT(dir_fd, path, &st, flags & (AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH | AT_NO_AUTOMOUNT)); if(r) return(r);
Bug#955469: initramfs-tools-core: Enable zstandard support
Am Mittwoch, 29. April 2020 schrieb Ben Hutchings : > On Tue, 2020-04-28 at 04:43 +0100, Ben Hutchings wrote: > > On Wed, 01 Apr 2020 09:05:22 +0200 Norbert Lange > wrote: > > > Package: initramfs-tools-core > > > Version: 0.136 > > > Severity: wishlist > > > Tags: patch > > > > > > Hello, > > > > > > there are Kernelpatches for zstandard initramfs support > > > available for several years, and will hopefully accepted > > > upstream soon. > > > > If the kernel doesn't yet support it, I'm not sure what the point of > > supporting it in initramfs-tools is. > [...] > > I see that the kernel support for this has been submitted recently, > though it's not clear which maintainer is being asked to apply the > patches. It's been submitted multiple times over the years, I don't know the lkml workings, and apparently the author of these changes is missing some detail too. Could you kindky point to what's missing? Sending the pull request directly (not cc) to a maintainer? I use initramfs-tools (unmkinitramfs in particular) for zstd compressed initrds since years. The point would be that Debian is a nice distro for any kind of development, including homebrewn kernels for pet project. And that zstd is hopefully getting enabled for initrd/kernel in the near future. It's not like this is an entirely new format. Norbert
Bug#955469: initramfs-tools-core: Enable zstandard support
Package: initramfs-tools-core
Version: 0.136
Severity: wishlist
Tags: patch
Hello,
there are Kernelpatches for zstandard initramfs support
available for several years, and will hopefully accepted
upstream soon.
Please enable support for this compression.
The patch should be simple enough, I chosen to try zstd
as first decompressor because it supports a whole
range of formats on debian.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages initramfs-tools-core depends on:
ii coreutils8.30-3+b1
ii cpio 2.13+dfsg-2
ii e2fsprogs1.45.6-1
ii klibc-utils 2.0.7-1
ii kmod 27-2
ii logsave 1.45.6-1
ii udev 244.3-1
Versions of packages initramfs-tools-core recommends:
ii busybox 1:1.30.1-4
ii pigz 2.4-1+b1
Versions of packages initramfs-tools-core suggests:
ii bash-completion 1:2.10-1
-- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed [not included]
-- no debconf information
diff -burN initramfs-tools.org/conf/initramfs.conf
initramfs-tools/conf/initramfs.conf
--- initramfs-tools.org/conf/initramfs.conf 2019-02-06 00:55:47.0
+0100
+++ initramfs-tools/conf/initramfs.conf 2020-03-31 18:38:48.558687968 +0200
@@ -38,7 +38,7 @@
KEYMAP=n
#
-# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]
+# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | zstd | xz ]
#
COMPRESS=gzip
diff -burN initramfs-tools.org/mkinitramfs initramfs-tools/mkinitramfs
--- initramfs-tools.org/mkinitramfs 2020-01-18 19:36:00.0 +0100
+++ initramfs-tools/mkinitramfs 2020-03-31 18:31:31.046107765 +0200
@@ -185,6 +185,7 @@
fi
;;
lz4) compress="lz4 -9 -l" ;;
+zstd) compress="zstd -19" ;;
xz)compress="xz --check=crc32"
# If we're not doing a reproducible build, enable multithreading
test -z "${SOURCE_DATE_EPOCH}" && compress="$compress --threads=0"
diff -burN initramfs-tools.org/unmkinitramfs initramfs-tools/unmkinitramfs
--- initramfs-tools.org/unmkinitramfs 2019-07-31 16:25:58.0 +0200
+++ initramfs-tools/unmkinitramfs 2020-03-31 18:36:36.821308275 +0200
@@ -29,7 +29,9 @@
dir="$2"
shift 2
- if gzip -t "$archive" >/dev/null 2>&1 ; then
+ if zstd -q -c -t "$archive" >/dev/null 2>&1 ; then
+ zstd -q -c -d "$archive"
+ elif gzip -t "$archive" >/dev/null 2>&1 ; then
gzip -c -d "$archive"
elif xzcat -t "$archive" >/dev/null 2>&1 ; then
xzcat "$archive"
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
Thanks, I guess I can always work around by setting the QT_QPA_PLATFORM variable. And Ill be a bit ignorant and say that In my opinion, the testing flavor would be a good testbed to find and iron out remaining issue. In case of wireshark, I haven't found issues with menus (so far), while the app running inadvertently under X11 causes issues (wrong scaling, bad text). So you might get bug reports based on those upstream issue either way ;) Norbert
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
Package: libqt5core5a Version: 5.12.5+dfsg-9 Severity: normal Dear Maintainer, Runnin any QT Application on Gnome will blacklist Wayland. You see the explicit message when starting an application from the terminal. % wireshark Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. (for me this is really annoying as I have a HiDPI and a normal Monitor, X11 doesnt allow different scaling). Fedora considers QT 5.12+ ready to enable this by default, see the two used pathes under [1], Section "Scope". I'd hope debian could follow here, and use those patches in testing. [1] - https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqt5core5a depends on: ii libc6 2.30-2 ii libdouble-conversion3 3.1.5-5 ii libgcc-s1 10-20200312-2 ii libglib2.0-0 2.64.1-1 ii libicu63 63.2-3 ii libpcre2-16-0 10.34-7 ii libstdc++6 10-20200312-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libqt5core5a recommends: ii qttranslations5-l10n 5.12.5-1 Versions of packages libqt5core5a suggests: ii libthai0 0.1.28-3 -- no debconf information
Bug#952590: kmod: Please enable zlib support
Thats atleast an argument, but looking at my bog-standard initramfs, libz is already there alongside libzstd, liblzma, liblz4, liblzo2. If you care for a small initramfs, thats a battle debian lost long ago, nothing additional will get pulled in. Curiously, I want to build a small initramfs, with busybox modprobe. This one supports zlib (only), and debians default depmod is the one thing standing in the way of building that (without alot hackery). So, this is a clear case where it practically wont cost you anything to enable zlib support. Am Mi., 26. Feb. 2020 um 15:41 Uhr schrieb Marco d'Itri : > > On Feb 26, Norbert Lange wrote: > > > Whats the problem with kmod supporting both? Its not like this has any > > real disadvantage, > Other than pulling more dependencies in the initramfs. > > -- > ciao, > Marco
Bug#952592: kmod: Please enable zlib support
Package: kmod Version: 27-1 Severity: wishlist Tags: patch Hello, I would ask you to enable zlib support, I use debian for various builds, cross-building a kernel + gzipped modules would need a depmod that can handle those modules. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kmod depends on: ii libc6 2.29-10 ii libkmod2 27-1 ii liblzma5 5.2.4-1+b1 ii libssl1.1 1.1.1d-2 ii lsb-base 11.1.0 kmod recommends no packages. kmod suggests no packages. -- no debconf information diff -burN debian.org/control debian/control --- debian.org/control 2020-02-19 02:56:07.0 +0100 +++ debian/control 2020-02-19 04:56:30.0 +0100 @@ -3,7 +3,7 @@ Priority: important Maintainer: Marco d'Itri Build-Depends: debhelper-compat (= 12), liblzma-dev, libssl-dev, xsltproc, - autoconf, automake, libtool, gtk-doc-tools + autoconf, automake, libtool, gtk-doc-tools, zlib1g-dev Standards-Version: 4.4.0.1 Rules-Requires-Root: no Vcs-Git: https://salsa.debian.org/md/kmod.git diff -burN debian.org/rules debian/rules --- debian.org/rules2020-02-19 04:53:30.0 +0100 +++ debian/rules2020-02-19 04:56:30.0 +0100 @@ -19,6 +19,7 @@ dpkg-buildflags --export=configure || true) \ --enable-gtk-doc \ --with-openssl \ + --with-zlib \ --with-xz \ --enable-debug CONFFLAGS_udeb = $(CONFFLAGS) \
Bug#952590: kmod: Please enable zlib support
Package: kmod Version: 27-1 Severity: wishlist Tags: patch Hello, I would ask you to enable zlib support, I use debian for various builds, cross-building a kernel + gzipped modules would need a depmod that can handle those modules. The change is reasonably simple diff -burN debian.org/control debian/control --- debian.org/control 2020-02-19 02:56:07.0 +0100 +++ debian/control 2020-02-19 04:56:30.0 +0100 @@ -3,7 +3,7 @@ Priority: important Maintainer: Marco d'Itri Build-Depends: debhelper-compat (= 12), liblzma-dev, libssl-dev, xsltproc, - autoconf, automake, libtool, gtk-doc-tools + autoconf, automake, libtool, gtk-doc-tools, zlib1g-dev Standards-Version: 4.4.0.1 Rules-Requires-Root: no Vcs-Git: https://salsa.debian.org/md/kmod.git diff -burN debian.org/rules debian/rules --- debian.org/rules2020-02-19 04:53:30.0 +0100 +++ debian/rules2020-02-19 04:56:30.0 +0100 @@ -19,6 +19,7 @@ dpkg-buildflags --export=configure || true) \ --enable-gtk-doc \ --with-openssl \ + --with-zlib \ --with-xz \ --enable-debug CONFFLAGS_udeb = $(CONFFLAGS) \ -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kmod depends on: ii libc6 2.29-10 ii libkmod2 27-1 ii liblzma5 5.2.4-1+b1 ii libssl1.1 1.1.1d-2 ii lsb-base 11.1.0 kmod recommends no packages. kmod suggests no packages. -- no debconf information
Bug#945427: doxygen: improve rules to pick llvm version from the control file
Package: doxygen Version: 1.8.16-0.1 Severity: wishlist Dear Maintainer, I am glad this package finally found a maintainer, I cooked up my own versions meanwhile. To make changing llvm versions (and supported archs), this code would pick it up form the cntrols file: llvm_ver = $(shell sed -n 's/.*\bllvm-\([^[:space:]]*\)-dev.*/\1/p' debian/control) clang_archs = $(shell sed -n 's/.*\bllvm-[^[:space:]]*-dev[[:space:]]*\[\(.*\)\].*/\1/p' debian/control) export LLVM_DIR = /usr/lib/llvm-$(llvm_ver)/lib/cmake/llvm/ export Clang_DIR = /usr/lib/llvm-$(llvm_ver)/lib/cmake/clang/ Norbert -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages doxygen depends on: ii libc62.29-3 ii libclang1-8 1:8.0.1-4 ii libgcc1 1:9.2.1-19 ii libllvm8 1:8.0.1-4 ii libstdc++6 9.2.1-19 ii libxapian30 1.4.12-1 ii zlib1g 1:1.2.11.dfsg-1+b1 doxygen recommends no packages. Versions of packages doxygen suggests: pn doxygen-doc pn doxygen-gui pn doxygen-latex ii graphviz 2.42.2-3 -- no debconf information
Bug#926178: grub2 efi boot installs grub.cfg file that seems to be ignored (just stays at prompt)
I don't know how I initially got there, but I kept the old version's .deb archived around when I first encountered the issue, and installed them with dpkg -i afterwards. And whether shim-signed is installed or not makes no difference, it just affects the defaults grub is using. I always have to make sure "--no-uefi-secure-boot" is used (which is implicitly set if shim-signed is not installed AFAIK). Am Mo., 10. Juni 2019 um 02:51 Uhr schrieb Steve McIntyre : > > Hi Norbert, > > On Sat, May 11, 2019 at 12:00:41PM +0200, Norbert Lange wrote: > >I got newer versions to work by adding the "--no-uefi-secure-boot" switch, > >so apparently uefi-secure-boot is not working for me. > > > >older versions might have defaulted to not using it, > >or I did not have the shim packages installed. > > I'm curious how you got here. Did you install with Recommends > disabled? There's a Recommends: chain from grub-efi-amd64-bin to > grub-efi-amd64-signed to shim-signed which should cause shim-signed to > be installed. > > Does installing shim-signed fix your problem? > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > You raise the blade, you make the change... You re-arrange me 'til I'm sane... >
Bug#926178: grub2 efi boot installs grub.cfg file that seems to be ignored (just stays at prompt)
I got newer versions to work by adding the "--no-uefi-secure-boot" switch, so apparently uefi-secure-boot is not working for me. older versions might have defaulted to not using it, or I did not have the shim packages installed.
Bug#926178: grub2 efi boot installs grub.cfg file that seems to be ignored (just stays at prompt)
Package: grub2 Version: 2.02+dfsg1-16 Severity: important Hello, setting up some new systems I ran into the issue that newer versions of grub-install will place multiple files into /boot/efi/EFI. One among them is 'grub.cfg' which tried to set 'root' by searching for the UUID, then loading the real boot/grub/grub.cfg. It appears to me, that is file is never used, as grub just drops to the prompt without any notification. The older version 2.02+dfsg1-4 is installing a single file, and boots correctly. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages grub2 depends on: ii grub-common 2.02+dfsg1-16 pn grub-pc grub2 recommends no packages. grub2 suggests no packages.
Bug#922655: systemd: some user units are not enabled according to the vendor presets
Package: systemd Version: 240-5 Severity: normal Dear Maintainer, I tried adding a user-specific file to ~/.config/user-tmpfiles.d/chromium-cache.conf, expecting this to be used when logging in. The user systemd-tmpfiles-setup is disabled by default (couple weeks old buster installation). I was able to remedy the issue with executing "systemctl --user preset-all", but this normally should not be required. There are further differnces in enabled units. The distro defaults are these: # ls /usr/lib/systemd/user/*.wants /usr/lib/systemd/user/graphical-session-pre.target.wants: ssh-agent.service /usr/lib/systemd/user/sockets.target.wants: dbus.socket dirmngr.socket gpg-agent-browser.socket gpg-agent-extra.socket gpg-agent.socket gpg-agent-ssh.socket pulseaudio.socket The user config after preset-all is this: # ls ~/.config/systemd/user/*.wants /home/noppl/.config/systemd/user/basic.target.wants: systemd-tmpfiles-setup.service /home/noppl/.config/systemd/user/default.target.wants: pulseaudio.service rygel.service /home/noppl/.config/systemd/user/sockets.target.wants: dirmngr.socket gpg-agent-browser.socket gpg-agent-extra.socket gpg-agent.socket gpg-agent-ssh.socket pulseaudio.socket /home/noppl/.config/systemd/user/timers.target.wants: systemd-tmpfiles-clean.timer Kind regards, Norbert -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.52-3+b1 ii libapparmor1 2.13.2-7 ii libaudit11:2.8.4-2 ii libblkid12.33.1-0.1 ii libc62.28-6 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.0.6-1 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.6-2 ii libgpg-error01.35-1 ii libidn11 1.33-2.2 ii libip4tc01.8.2-3 ii libkmod2 25-2 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.1.8-4 ii libseccomp2 2.3.3-3 ii libselinux1 2.8-1+b1 ii libsystemd0 240-5 ii mount2.33.1-0.1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus1.12.12-1 ii libpam-systemd 240-5 Versions of packages systemd suggests: ii policykit-10.105-25 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.133 ii udev 240-5 -- no debconf information
Bug#918984: Still issues with busters dependencies
Hello, there still seem to be issues, as far as I understand fuse3 replaces fuse, but the libs are co-installable? Several packages will be uninstalled or have a weird state after installing fuse3 and removing fuse. eg.: gvfs-fuse ntfs-3g depends on fuse. exfat-fuse depends on fuse. Probably a dependency problem on their part, but are there any mechanisms in place to fix up all the packages depending on fuse?
Bug#920949: i965-va-driver: i965_drv_video.so cant be loaded if wayland is installed
Package: i965-va-driver Severity: important Tags: upstream Dear Maintainer, the vaapi acceleration is unusable for me, this is very likely cause by the upstream bug [1]. The i965-va-driver package is version 2.2.0+dfsg1-2 (reportbug seems to have problem if both 32 and 64 bit is versions are installed). The bug is not solved in the current release, so upgrade to 2.3.0 and additional unreleased commit(s) would be necessary. Please get this in buster. [1] - https://github.com/intel/intel-vaapi-driver/issues/419 [2] - https://github.com/intel/intel-vaapi-driver/commit/f139dafa59172d40543f2ec469a035d3de9fdc6a -- Output from vainfo $ vainfo libva info: VA-API version 1.3.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_2 error: failed to resolve wl_drm_interface(): /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0: undefined symbol: wl_drm_interface libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#856255:
Can we have a statement why this patch is not added? The lack of it kills using low power CPUs (and debian) for youtube et all. Arch and Fedora both have a separate package called "chromium-vaapi", maybe this would be acceptable in debian aswell?
Bug#916400: closed by Laszlo Boszormenyi (GCS) (Bug#916400: fixed in squashfs-tools 1:4.3-10)
Thanks, I am curious though, why you don't just use a recent upstream commit? There are are 72 commits since 4.3 and that would cut down on the patches needed. Am Di., 15. Jan. 2019 um 21:51 Uhr schrieb Debian Bug Tracking System : > > This is an automatic notification regarding your Bug report > which was filed against the squashfs-tools package: > > #916400: squashfs-tools: please use more recent code that supports zstd > > It has been closed by Laszlo Boszormenyi (GCS) . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Laszlo Boszormenyi (GCS) > by > replying to this email. > > > -- > 916400: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916400 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Laszlo Boszormenyi > To: 916400-cl...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 15 Jan 2019 20:47:33 + > Subject: Bug#916400: fixed in squashfs-tools 1:4.3-10 > Source: squashfs-tools > Source-Version: 1:4.3-10 > > We believe that the bug you reported is fixed in the latest version of > squashfs-tools, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 916...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Laszlo Boszormenyi (GCS) (supplier of updated > squashfs-tools package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Tue, 15 Jan 2019 18:12:19 + > Source: squashfs-tools > Binary: squashfs-tools > Architecture: source > Version: 1:4.3-10 > Distribution: unstable > Urgency: medium > Maintainer: Laszlo Boszormenyi (GCS) > Changed-By: Laszlo Boszormenyi (GCS) > Description: > squashfs-tools - Tool to create and append to squashfs filesystems > Closes: 916400 919207 > Changes: > squashfs-tools (1:4.3-10) unstable; urgency=medium > . >* Backport upstream Zstandard support (closes: #916400). > . >[ Alexander Couzens ] >* Remove frag_deflator_thread (closes: #919207). > Checksums-Sha1: > 6a22fe71dadcfc8c3b1e3ff2081d6501ba350457 1879 squashfs-tools_4.3-10.dsc > a48caff1ef195cb1380626f7c7ece59d7e60d464 27036 > squashfs-tools_4.3-10.debian.tar.xz > a8f6f768ba656b2291c55477d9f788cc10df27b0 6941 > squashfs-tools_4.3-10_amd64.buildinfo > Checksums-Sha256: > b8451847553bafeab3b145474a1e61268ceae333f87c1f2a127cf7647a1c9fd2 1879 > squashfs-tools_4.3-10.dsc > a7496805599a2a461282354896873061681e79213e3396e9bc44832932634f38 27036 > squashfs-tools_4.3-10.debian.tar.xz > 00c3382790baa6710665aa0e22a3b95061d21c2b5013a77084631271837a4227 6941 > squashfs-tools_4.3-10_amd64.buildinfo > Files: > b134b21eed5fc107a5917c181bc8b41b 1879 kernel optional > squashfs-tools_4.3-10.dsc > e38939964b76ee39337ec2766c60a1ec 27036 kernel optional > squashfs-tools_4.3-10.debian.tar.xz > ff3860dc5c4d0318da3bdfba6603b5ac 6941 kernel optional > squashfs-tools_4.3-10_amd64.buildinfo > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEfYh9yLp7u6e4NeO63OMQ54ZMyL8FAlw+OdMACgkQ3OMQ54ZM > yL/bOhAAih+KVF2ITvnMxw9I45J/4KLguj2aAwQuCVcpUrpjY7qlAASLLrmw64L2 > qQCWdOhTMBDj7utzUJE1AK8WbyLUNAox1dYKKuW6V5jVuT/1uwtIcKg0YYfdRxul > c7PU68QaxZQ0OiAyikNhrEBW33qWybzqj8okjIvNo3buKJ166LRSkCAjeaH+DsqN > 5mu0q7YAvAVx0rBh2o9WOZmaCWkwK3gVCVe18Y8uvWHZmC1YfehKIpnZy9hduIGn > uIR4aBtO+zVc2Cr5J9ptBX3mzDqyJxdFPVkC/w1+0U1+WnTKZAfOtgrqfu9m+fPo > Y/aF/Ojqs4DZeKl0EYvvQu2T/AF6/bTJELs+HDM1r0Edqej65SxvL4PktyXopzjn > yvl/g7Hg799Dgoy0+yv1yNnxDX30jT8CGj2jiXbcXXPSNX0OWIyBhZN8fBbZ6ODL > 1qwvQOvg2wXanIWBtU2Xh3fzQWbYFFQzQHN6QFHtXy1LxSFN5Ug5LixAWFZfi5vq > F1B2a5drsCfijQ5THkIh9dZM0tJk4vM1pzqEnPg/VdGIsUiQ4TNbzBu10Wwa4JyE > RFOHpYQfxaKfA13vhWRQoWtWciEG9XTWdc8xYLCnd8xpP4oeM2MYkUlTGtawjEu/ > GftnZas61NeXHtpxQmq3hIhBF/Uqgayho72d18bcziZrg5wYya0= > =N5a3 > -END PGP SIGNATURE- > > > -- Forwarded message -- > From: Norbert Lange > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Fri, 14 Dec 2018 00:23:07 +0100 > Subject: squashfs-tools: please use more recent code that supports zstd > Package: squashfs-tools > Ver
Bug#916400: squashfs-tools: please use more recent code that supports zstd
Package: squashfs-tools Version: 1:4.3-6 Severity: normal Dear Maintainer, since kernel 4.14, squashfs supports zstandard while there is no tool to create those images. I would ask you to update to a version that supports zstd before buster ends up in the freeze. Newer versions are at https://github.com/plougher/squashfs-tools, you probably know put the debian package homepage still points to sourceforge kind regards, Norbert -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages squashfs-tools depends on: ii libc6 2.27-8 ii liblz4-1 1.8.2-1 ii liblzma5 5.2.2-1.3 ii liblzo2-2 2.10-0.1 ii libzstd1 1.3.5+dfsg-1 ii zlib1g 1:1.2.11.dfsg-1 squashfs-tools recommends no packages. squashfs-tools suggests no packages. -- no debconf information
Bug#900440: clang-6.0: clang cmake config files are installed to the wrong folder and have invalid path
Package: clang-6.0
Version: 1:6.0-3+b1
Severity: important
Dear Maintainer,
I was trying to compile doxygen doxygen-1.8.14 with libclang support,
the clang config for cmake is unusable.
First issue:
the paths in are relative to the cmake files and thus not correct if
placed in a differnt directory
copying/moving the files to the correct directory fixes this:
cp /usr/share/llvm-6.0/cmake/. /usr/lib/llvm-6.0/lib/cmake/clang -r
Second issue:
The file ClangTargets-relwithdebinfo.cmake paints the clang binary
at /usr/lib/llvm-6.0/bin/clang-6.0, this file does not exist.
editing the path to /usr/lib/llvm-6.0/bin/clang fixes this
A minimal CMakeLists.txt is following to reproduce this issue,
maybe a good idea to add such a test to the package
cmake_minimum_required(VERSION 2.8.12)
project(testllvm)
find_package(LLVM CONFIG REQUIRED)
find_package(Clang CONFIG REQUIRED)
if(NOT LLVM_VERSION STREQUAL Clang_VERSION)
#message(FATAL_ERROR "LLVM ${LLVM_VERSION} not matching to Clang
${Clang_VERSION}")
endif()
# rconfigure me with `cmake -DClang_DIR=/usr/lib/llvm-6.0/lib/cmake/clang`
PATHTOTHISDIR
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages clang-6.0 depends on:
ii binutils 2.30-20
ii libc62.27-3
ii libc6-dev2.27-3
ii libclang-common-6.0-dev 1:6.0-3+b1
ii libclang1-6.01:6.0-3+b1
ii libgcc-7-dev 7.3.0-19
ii libgcc1 1:8.1.0-3
ii libjsoncpp1 1.7.4-3
ii libllvm6.0 1:6.0-3+b1
ii libobjc-7-dev7.3.0-19
ii libstdc++-7-dev 7.3.0-19
ii libstdc++6 8.1.0-3
Versions of packages clang-6.0 recommends:
pn libomp-dev
ii llvm-6.0-dev 1:6.0-3+b1
ii python2.7.15~rc1-1
Versions of packages clang-6.0 suggests:
pn clang-6.0-doc
pn gnustep
pn gnustep-devel
-- no debconf information
Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable
2018-04-07 23:28 GMT+02:00 Olly Betts : > Control: severity -1 normal > > On Sat, Apr 07, 2018 at 05:30:19PM +0300, Adrian Bunk wrote: >> On Fri, Apr 06, 2018 at 11:53:39PM -0400, Scott Talbert wrote: >> > On Sat, 7 Apr 2018, Norbert Lange wrote: >> > >> > > it appears that the files are installed in a subdirectory, >> > > potentially to avoid confligs with previous versions? >> > > result is that >> > > >> > > import wx fails with >> > > >> > > ImportError: No module named wx >> > > >> > > I havent found a way to configure the installation >> > >> > The purpose of the python-wxgtk4.0 package is primarily for application >> > developers to use in porting their applications to wxPython 4.0 (Phoenix). >> > There isn't much of a reason otherwise to use the Python 2 version of >> > wxPython 4.0. Instead, you should use python3-wxgtk4.0 with which you can >> > 'import wx'. >> > >> > If you really would like to use the Python 2 version, you can do: >> > >> > PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg >> > python >> > import wx > > This doesn't appear to be documented in the package, which it really > should be (probably a brief explanation in the package description, and > more detail in README.Debian). The package name alone would imply it serves the same purpose as python3-wxgtk4.0, python-wxgtk3.0. which is providing the wx module > > Maybe it's also worth including a trival wrapper script to set > PYTHONPATH suitably and then exec python. > >> Is there a good reason why you are making it harder than necessary to >> use python-wxgtk4.0 ? > > Because wxPython 3.0 already exists for Python 2 as module "wx". But > wxPython 3.0 doesn't support Python 3 and never will, so there's no > other claimant for module "wx" for Python 3. > > wxPython 4.0 is pretty much a from-the-ground-up rebuild and isn't > completely compatible with wxPython 3.0, so switching "import wx" to use > that for Python 2 would not work out well. its not entirely incompatible either, as right now I only get deprecation warnings on code that was written for wxPython 3.0. > > And a lot of packages use wxPython 3.0, so wxPython 4.0 for Python 2 > really needs to be co-installable with wxPython 3.0. And a few packages like scapy still don't work with Python 3. Its forcing Python3 vs. forcing wxPython 4.0. > > Installing the module as "wx4" or something isn't helpful as that > doesn't match what upstream does, nor how it's packaged for Python 3. i agree that this is not viable. > > The only reason Scott created this package is to help people maintaining > a wxPython application who want to migrate it to wxPython 4.0 - that > involves both porting it from Python 2 to Python 3 and from wxPython 3.0 > to wxPython 4.0. Rather than having to do both together, with this > package you can port to Python 2 + wxPython 4.0 as an intermediate step. this also makes it hard to drop wxPython 3.0, as right now there is a need to run such apps on current systems. > > So I'd say the bug here is really that this isn't clear from the current > packages. > >> Python 2 is fully supported by Debian during the lifetime of buster, >> and there are various reasons why many users are stuck with Python 2 >> for some more time. > > There are, but people sticking with Python 2 are really unlikely to want > to use wxPython 4.0. Sticking to Python2 is not the reason, no. The argument would be to use wxPython 4.0, and have it painlessly run on current systems and with packages that aren't yet ported to python3. without wxPython 4.0 on python2, you have to stick to wxPython 3.0, and either bet on upwards compatibility or test on both libraries. Personally I would prefer a mutual-exlusive installation or an update-alternatives scheme as sym-linking the wx folder did work for me. Norbert
Bug#895083: python-wxgtk4.0: module wx is not usable
Package: python-wxgtk4.0 Version: 4.0.1+dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, it appears that the files are installed in a subdirectory, potentially to avoid confligs with previous versions? result is that import wx fails with ImportError: No module named wx I havent found a way to configure the installation Regards, Norbert Lange -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-wxgtk4.0 depends on: ii libc6 2.27-3 ii libgcc1 1:8-20180321-1 ii libpython2.7 2.7.14-7 ii libstdc++68-20180321-1 ii libwxbase3.0-0v5 3.0.4+dfsg-3 ii libwxgtk3.0-gtk3-0v5 3.0.4+dfsg-3 ii python2.7.14-4 ii python-sip4.19.8+dfsg-1 ii python-six1.11.0-2 python-wxgtk4.0 recommends no packages. Versions of packages python-wxgtk4.0 suggests: pn wx3.0-doc -- no debconf information
Bug#883410: linux-image-4.14.0-1-amd64: Enable zstd support for SquashFS in 4.14
I second this wish, and would further ask to enable CONFIG_SQUASHFS_FILE_DIRECT, as this will improve performance. The "downside" would be that with a bottleneck removed, more IO can then mean more CPU Resources are used by the kernel (though I don't see that a downside, just means some threads using IO are finished earlier, performance still is up). see https://lkml.org/lkml/2017/9/22/814
Bug#890514: clang-tidy-6.0: missing dependency: run-clang-tidy-6.0.py needs python-yaml
Package: clang-tidy-6.0 Version: 1:6.0~+rc2-1 Severity: normal Dear Maintainer, the run-clang-tidy-6.0.py script requires the Python yaml library. python-yaml needs to be installed, but I think debian policy would recommend using python3-yaml (needs the shebang adjusted) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clang-tidy-6.0 depends on: ii libc6 2.26-6 ii libgcc1 1:8-20180207-2 ii libllvm6.0 1:6.0~+rc2-1 ii libstdc++6 8-20180207-2 ii python 2.7.14-4 clang-tidy-6.0 recommends no packages. clang-tidy-6.0 suggests no packages. -- no debconf information
Bug#879703: gcc-7: static development libraries miss debug information
Package: gcc-7 Version: 7.2.0-11 Severity: wishlist Dear Maintainer, the static libraries, most importantly libstdc++, miss debug informations. This is not ideal, and the debuginfo should be available for developers by default. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-7 depends on: ii binutils 2.29.1-5 ii cpp-7 7.2.0-11 ii gcc-7-base7.2.0-11 ii libc6 2.24-17 ii libcc1-0 7.2.0-11 ii libgcc-7-dev 7.2.0-11 ii libgcc1 1:7.2.0-11 ii libgmp10 2:6.1.2+dfsg-1.1 ii libisl15 0.18-1 ii libmpc3 1.0.3-2 ii libmpfr4 3.1.6-1 ii libstdc++67.2.0-11 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-7 recommends: ii libc6-dev 2.24-17 Versions of packages gcc-7 suggests: pn gcc-7-doc pn gcc-7-locales ii gcc-7-multilib7.2.0-11 pn libasan4-dbg pn libatomic1-dbg pn libcilkrts5-dbg ii libgcc1-dbg 1:7.2.0-11 pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libmpx2-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan0-dbg -- no debconf information
Bug#853010: FWD: Re: build depends, maintainer interest for package OpenOCD
Hello, did you try asking on debian-de...@lists.debian.org? This package seems orphaned, but usually its up to the maintainer to declare this. I am going to need a newer openocd build sometime and would like to know whether this is going to be maintained. Kind regards, Norbert On Tue, 21 Feb 2017 21:53:13 +0100 Geert Stappers wrote: > > The e-mail that I wrote yesterday went to the wrong bugreport. > > This time it should go the intented bugreport. > And it has a better "From: " address > > > - Forwarded message from Geert Stappers - > > Date: Mon, 20 Feb 2017 17:59:07 +0100 > From: Geert Stappers > To: 853...@bugs.debian.org, lu...@debian.org, u...@debian.org > Subject: Re: build depends, maintainer interest for package OpenOCD > User-Agent: Mutt/1.5.21 (2010-09-15) > > On Sat, Jan 28, 2017 at 10:24:57PM +0100, Geert Stappers wrote: > > Package: openocd > > Tags: patch > > > > --- a/debian/control > > +++ b/debian/control > > > That removes 'autotools-dev', there is still 'autotools-dev, autoconf,'. > > And 'libftdi-dev' is now on separate line. > > > > > > Also is this bugreport to show my interrest in co-maintaining > > the Debian OpenOCD package. > > > > Yes, I still want to work on packaging openocd. > > But how think the current maintainers about that? > > That is why Uwe and Luca are also in the To: field. > > > Groeten > Geert Stappers > DD, Maintainer of package urjtag > -- > Leven en laten leven > > > > - End forwarded message - > > Groeten > Geert Stappers > -- > Leven en laten leven > >
Bug#861830: open-vm-tools-desktop: drag-and-drop cache never gets cleaned up
Package: open-vm-tools-desktop Version: 2:10.1.5-5055683-4 Severity: wishlist Dear Maintainer, Copied files will end up in the ~/.cache/vmware folder, and will remain there forever. I am aware that there are inherent problems to figure out which ones are still required, but there could be some events where the content could (and IMHO should) be deleted. *) On shutdown or startup (would need to iterate through all users) *) local X11-logon of a user *) local X11-logoff of a user *) start/stop of the vmware-user daemon On any of these events it would be safe to delete the drag-and-drop cache, I would say deleting the cache aftert stopping the user daemon would be best, that way the cache gets removed if the package gets uninstalled as well -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages open-vm-tools-desktop depends on: ii fuse 2.9.7-1 ii libatk1.0-0 2.22.0-1 ii libatkmm-1.6-1v5 2.24.2-2 ii libc62.24-10 ii libcairo21.14.8-1 ii libcairomm-1.0-1v5 1.12.0-1+b1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.1 ii libgcc1 1:6.3.0-14 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libglibmm-2.4-1v52.50.0-1 ii libgtk2.0-0 2.24.31-2 ii libgtkmm-2.4-1v5 1:2.24.5-1 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpangomm-1.4-1v5 2.40.1-3 ii libsigc++-2.0-0v52.10.0-1 ii libsm6 2:1.2.2-1+b3 ii libstdc++6 6.3.0-14 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii open-vm-tools2:10.1.5-5055683-4 Versions of packages open-vm-tools-desktop recommends: ii xauth 1:1.0.9-1+b2 pn xserver-xorg-input-vmmouse ii xserver-xorg-video-vmware 1:13.2.1-1+b1 Versions of packages open-vm-tools-desktop suggests: ii xdg-utils 1.1.1-1 -- no debconf information
Bug#860875: open-vm-tools-desktop: run-vmblock\x2dfuse.mount fails to start during boot
Package: open-vm-tools-desktop Version: 2:10.1.5-5055683-3 Severity: important Dear Maintainer, The automatic start of run-vmblock\x2dfuse.mount fails during boot, but the service can be later startet manually (at which point its too late for the vmware user daemon). I attached the relevant log, its pretty much the first entry in the logs, maybe some dependencies are missing? pr 21 09:26:05 debianvmlano2499797408 systemd-journald[263]: Journal started Apr 21 09:26:05 debianvmlano2499797408 systemd-journald[263]: Runtime journal (/run/log/journal/773554e11c0448e786a32287dd578ecc) is 8.0M, max 79.8M, 71.8M free. Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: run-vmblock\x2dfuse.mount: Mount process exited, code=exited status=1 Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Failed to mount VMware vmblock fuse mount. Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: run-vmblock\x2dfuse.mount: Unit entered failed state. Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Started Load Kernel Modules. Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Started Create Static Device Nodes in /dev. Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Started Load/Save Random Seed. Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Starting udev Kernel Device Manager... Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Starting Apply Kernel Variables... Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Starting Flush Journal to Persistent Storage... Apr 21 09:26:05 debianvmlano2499797408 systemd[1]: Starting pNFS block layout mapping daemon... -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages open-vm-tools-desktop depends on: ii libatk1.0-0 2.22.0-1 ii libatkmm-1.6-1v5 2.24.2-2 ii libc62.24-9 ii libcairo21.14.8-1 ii libcairomm-1.0-1v5 1.12.0-1+b1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.1 ii libgcc1 1:6.3.0-12 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libglibmm-2.4-1v52.50.0-1 ii libgtk2.0-0 2.24.31-2 ii libgtkmm-2.4-1v5 1:2.24.5-1 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.40.4-1 ii libpangocairo-1.0-0 1.40.4-1 ii libpangoft2-1.0-01.40.4-1 ii libpangomm-1.4-1v5 2.40.1-3 ii libsigc++-2.0-0v52.10.0-1 ii libsm6 2:1.2.2-1+b3 ii libstdc++6 6.3.0-12 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii open-vm-tools2:10.1.5-5055683-3 Versions of packages open-vm-tools-desktop recommends: ii fuse2.9.7-1 pn open-vm-tools-dkms ii xauth 1:1.0.9-1+b2 pn xserver-xorg-input-vmmouse ii xserver-xorg-video-vmware 1:13.2.1-1+b1 Versions of packages open-vm-tools-desktop suggests: ii xdg-utils 1.1.1-1 -- no debconf information
Bug#856333: bear can not be used for multiarch tools
Hello, there is a patch upstream [1] for the CMake files, its also included as debian patch until the next release. I hopefully addressed all your concerns, and verified the package is lintian-clean, the code is available at [2], broken up into multiple commits The buildflags for CMake are set in a way so that they work with older debhelper versions [3], this is for easing backports to Wheezy and Jessie (which are still used at my workplace). I had to lookup some details on the debian policies, and I thing its now compliant regarding breaks and the "circular dependency" between bear and bear-lib should ensure that all "lib" are uninstalled with bear. Can you send this package through a debian buildserver (experimental?), so that the various architectures are easily available? Kind Regards, Norbert Lange [1] - https://github.com/rizsotto/Bear/commit/5aba709f15fcef8bda3c4db3b4751c0076a274e6 [2] - https://github.com/nolange/bear-debpackage [3] - https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake 2017-03-02 23:25 GMT+01:00 Norbert Lange : > Hello Sebastian, > > think of this patch more of a proof of concept, I am not fluent with > all the requirements and conventions of the deb packages, especially > the logic behind the "breaks". > >>> + python:any, >>> + python3:any, >> >> Why? > > Is it required that python is the same arch? > I built the package with 'dpkg-buildpackage -a i386' for 32bit (or > atleast I tried to), and this is a hinderance for cross-compiling. > Sure this is not related to the reported bug, so fell free to ignore > it. > >> Why not something like libear? > > cause (to me atleast) a package called libear is by convention a > library that ends up in the system path, together with shlibs and all > this automagical stuff. bear-lib is a private component of bear. > >> This should go upstream. > > Yeah, working on it. > > Any other of your points: I din`t knew better > > Kind regards, > Norbert Lange > > 2017-03-02 10:40 GMT+01:00 Sebastian Ramacher : >> Hi Norbert, >> >> thank you for the patch. See some comments below. >> >> Cheers >> >> On 2017-02-28 00:57:41, Norbert Lange wrote: >>> Package: bear >>> Version: 2.2.1-1 >>> Severity: normal >>> Tags: patch >>> >>> Dear Maintainer, >>> >>> bear is preloading the libear.so library with an absolute path, >>> this requires that the architecture (32/64 bit) is matched >>> and known in advance. >>> >>> This leads to several issues: >>> >>> 1. the package is not multiarch capable, thus >>> there cant be libear.so for multiple archs installed >>> 2. the default path is fixed for one architecture >>> 3. starting a build under bear, using both 32 and 64 bit >>> tools will need someting different that a fixed path >>> >>> I am attaching a path to fix these issue, by splitting the library >>> in its own package, and using a variable in the default path >>> >>> Kind Regards, >>> Norbert Lange >>> >>> -- System Information: >>> Debian Release: 9.0 >>> APT prefers testing >>> APT policy: (200, 'testing') >>> Architecture: amd64 (x86_64) >>> Foreign Architectures: i386, armhf, arm64 >>> >>> Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) >>> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) >>> Shell: /bin/sh linked to /bin/dash >>> Init: systemd (via /run/systemd/system) >>> >>> Versions of packages bear depends on: >>> ii bear-lib 2.2.1-1 >>> pn python3:any >>> >>> bear recommends no packages. >>> >>> bear suggests no packages. >>> >>> -- no debconf information >> >>> diff -burN debian.orig/bear.install debian/bear.install >>> --- debian.orig/bear.install 1970-01-01 01:00:00.0 +0100 >>> +++ debian/bear.install 2017-02-28 00:01:36.0 +0100 >>> @@ -0,0 +1,2 @@ >>> +/usr/bin >>> +/usr/share/man >>> diff -burN debian.orig/bear-lib.install debian/bear-lib.install >>> --- debian.orig/bear-lib.install 1970-01-01 01:00:00.0 +0100 >>> +++ debian/bear-lib.install 2017-02-27 23:59:12.0 +0100 >>> @@ -0,0 +1 @@ >>> +/usr/lib >>> diff -burN debian.orig/changelog debian/changelog >>> --- debian.orig/changelog 2016-10-19 19:01:50.0 +0200 >>> +++ debian/changelog 2017-02-28 00:40:58.0 +0100 >>> @@
Bug#856333: bear can not be used for multiarch tools
Hello Sebastian,
think of this patch more of a proof of concept, I am not fluent with
all the requirements and conventions of the deb packages, especially
the logic behind the "breaks".
>> + python:any,
>> + python3:any,
>
> Why?
Is it required that python is the same arch?
I built the package with 'dpkg-buildpackage -a i386' for 32bit (or
atleast I tried to), and this is a hinderance for cross-compiling.
Sure this is not related to the reported bug, so fell free to ignore
it.
> Why not something like libear?
cause (to me atleast) a package called libear is by convention a
library that ends up in the system path, together with shlibs and all
this automagical stuff. bear-lib is a private component of bear.
> This should go upstream.
Yeah, working on it.
Any other of your points: I din`t knew better
Kind regards,
Norbert Lange
2017-03-02 10:40 GMT+01:00 Sebastian Ramacher :
> Hi Norbert,
>
> thank you for the patch. See some comments below.
>
> Cheers
>
> On 2017-02-28 00:57:41, Norbert Lange wrote:
>> Package: bear
>> Version: 2.2.1-1
>> Severity: normal
>> Tags: patch
>>
>> Dear Maintainer,
>>
>> bear is preloading the libear.so library with an absolute path,
>> this requires that the architecture (32/64 bit) is matched
>> and known in advance.
>>
>> This leads to several issues:
>>
>> 1. the package is not multiarch capable, thus
>> there cant be libear.so for multiple archs installed
>> 2. the default path is fixed for one architecture
>> 3. starting a build under bear, using both 32 and 64 bit
>> tools will need someting different that a fixed path
>>
>> I am attaching a path to fix these issue, by splitting the library
>> in its own package, and using a variable in the default path
>>
>> Kind Regards,
>> Norbert Lange
>>
>> -- System Information:
>> Debian Release: 9.0
>> APT prefers testing
>> APT policy: (200, 'testing')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386, armhf, arm64
>>
>> Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
>> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages bear depends on:
>> ii bear-lib 2.2.1-1
>> pn python3:any
>>
>> bear recommends no packages.
>>
>> bear suggests no packages.
>>
>> -- no debconf information
>
>> diff -burN debian.orig/bear.install debian/bear.install
>> --- debian.orig/bear.install 1970-01-01 01:00:00.0 +0100
>> +++ debian/bear.install 2017-02-28 00:01:36.0 +0100
>> @@ -0,0 +1,2 @@
>> +/usr/bin
>> +/usr/share/man
>> diff -burN debian.orig/bear-lib.install debian/bear-lib.install
>> --- debian.orig/bear-lib.install 1970-01-01 01:00:00.0 +0100
>> +++ debian/bear-lib.install 2017-02-27 23:59:12.0 +0100
>> @@ -0,0 +1 @@
>> +/usr/lib
>> diff -burN debian.orig/changelog debian/changelog
>> --- debian.orig/changelog 2016-10-19 19:01:50.0 +0200
>> +++ debian/changelog 2017-02-28 00:40:58.0 +0100
>> @@ -1,3 +1,11 @@
>> +bear (2.2.1-1~nmu) unstable; urgency=medium
>> +
>> + * split library from main python script
>> + * make default libear.so path configurable in the CMake files
>> + * adjust the default libear.so path to use the ${LIB} Variable
>> +
>> + -- Norbert Lange Tue, 28 Feb 2017 00:40:58 +0100
>> +
>> bear (2.2.1-1) unstable; urgency=medium
>>
>>* New upstream release.
>> diff -burN debian.orig/control debian/control
>> --- debian.orig/control 2016-10-19 18:58:44.0 +0200
>> +++ debian/control2017-02-28 00:36:05.0 +0100
>> @@ -5,8 +5,8 @@
>> Build-Depends:
>> debhelper (>= 10),
>> cmake,
>> - python,
>> - python3,
>> + python:any,
>> + python3:any,
>
> Why?
>
>> scons,
>> libqt4-dev,
>> dh-python
>> @@ -16,9 +16,9 @@
>> Vcs-Git: https://anonscm.debian.org/git/collab-maint/bear.git
>>
>> Package: bear
>> -Architecture: any
>> +Architecture: all
>> Depends:
>> - ${shlibs:Depends},
>> + bear-lib (>= ${source:Version}), bear-lib (<<
>> ${source:Upstream-Version}.0~)
>
> Missing comma at the end.
>
>> ${misc:Depends},
>> ${python3:Depends}
>> Description: generate compilation database for Clang tooling
>> @@ -29,3 +29,19 @@
>> cmake supports the generation of JSON com
Bug#856333: bear can not be used for multiarch tools
Package: bear
Version: 2.2.1-1
Severity: normal
Tags: patch
Dear Maintainer,
bear is preloading the libear.so library with an absolute path,
this requires that the architecture (32/64 bit) is matched
and known in advance.
This leads to several issues:
1. the package is not multiarch capable, thus
there cant be libear.so for multiple archs installed
2. the default path is fixed for one architecture
3. starting a build under bear, using both 32 and 64 bit
tools will need someting different that a fixed path
I am attaching a path to fix these issue, by splitting the library
in its own package, and using a variable in the default path
Kind Regards,
Norbert Lange
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bear depends on:
ii bear-lib 2.2.1-1
pn python3:any
bear recommends no packages.
bear suggests no packages.
-- no debconf information
diff -burN debian.orig/bear.install debian/bear.install
--- debian.orig/bear.install1970-01-01 01:00:00.0 +0100
+++ debian/bear.install 2017-02-28 00:01:36.0 +0100
@@ -0,0 +1,2 @@
+/usr/bin
+/usr/share/man
diff -burN debian.orig/bear-lib.install debian/bear-lib.install
--- debian.orig/bear-lib.install1970-01-01 01:00:00.0 +0100
+++ debian/bear-lib.install 2017-02-27 23:59:12.0 +0100
@@ -0,0 +1 @@
+/usr/lib
diff -burN debian.orig/changelog debian/changelog
--- debian.orig/changelog 2016-10-19 19:01:50.0 +0200
+++ debian/changelog2017-02-28 00:40:58.0 +0100
@@ -1,3 +1,11 @@
+bear (2.2.1-1~nmu) unstable; urgency=medium
+
+ * split library from main python script
+ * make default libear.so path configurable in the CMake files
+ * adjust the default libear.so path to use the ${LIB} Variable
+
+ -- Norbert Lange Tue, 28 Feb 2017 00:40:58 +0100
+
bear (2.2.1-1) unstable; urgency=medium
* New upstream release.
diff -burN debian.orig/control debian/control
--- debian.orig/control 2016-10-19 18:58:44.0 +0200
+++ debian/control 2017-02-28 00:36:05.0 +0100
@@ -5,8 +5,8 @@
Build-Depends:
debhelper (>= 10),
cmake,
- python,
- python3,
+ python:any,
+ python3:any,
scons,
libqt4-dev,
dh-python
@@ -16,9 +16,9 @@
Vcs-Git: https://anonscm.debian.org/git/collab-maint/bear.git
Package: bear
-Architecture: any
+Architecture: all
Depends:
- ${shlibs:Depends},
+ bear-lib (>= ${source:Version}), bear-lib (<< ${source:Upstream-Version}.0~)
${misc:Depends},
${python3:Depends}
Description: generate compilation database for Clang tooling
@@ -29,3 +29,19 @@
cmake supports the generation of JSON compilation databases out of the box.
For any other build system that does not support this, Bear can be used
instead to intercept the invocation of the compiler.
+
+Package: bear-lib
+Architecture: any
+Multi-Arch: same
+Depends:
+ ${shlibs:Depends}
+Description: generate compilation database for Clang tooling
+ Bear records the flags passed to the compiler for each translation unit and
+ stores them in a JSON file. This file can be used by Clang's tooling interface
+ and programs like clang-check to process a translation unit.
+ .
+ cmake supports the generation of JSON compilation databases out of the box.
+ For any other build system that does not support this, Bear can be used
+ instead to intercept the invocation of the compiler.
+ .
+ This is the required library for wrapping system calls
diff -burN debian.orig/patches/make_default_preload_configurable.diff
debian/patches/make_default_preload_configurable.diff
--- debian.orig/patches/make_default_preload_configurable.diff 1970-01-01
01:00:00.0 +0100
+++ debian/patches/make_default_preload_configurable.diff 2017-02-28
00:19:16.0 +0100
@@ -0,0 +1,15 @@
+Description: Allow configuring the default preload library path
+ Add the responsible variable to CMake's cache
+ .
+
+--- bear-2.2.1.orig/CMakeLists.txt
bear-2.2.1/CMakeLists.txt
+@@ -39,7 +39,7 @@ if (NOT CMAKE_BUILD_TYPE)
+ endif()
+
+ set(EAR_LIB_FILE
${CMAKE_SHARED_LIBRARY_PREFIX}ear${CMAKE_SHARED_LIBRARY_SUFFIX})
+-set(DEFAULT_PRELOAD_FILE ${CMAKE_INSTALL_FULL_LIBDIR}/${EAR_LIB_FILE})
++set(DEFAULT_PRELOAD_FILE ${CMAKE_INSTALL_FULL_LIBDIR}/${EAR_LIB_FILE} CACHE
STRING "Default preload library path")
+
+ add_subdirectory(libear)
+ add_subdirectory(bear)
diff -burN debian.orig/patches/series debian/patches/series
--- debian.orig/patches/series 2015-08-08 17:13:48.0 +0200
+++ debian/patches/series 2017-02-28 00:17:16.0 +0100
@@ -1,2 +1,3 @@
use-python3.patch
remove-rpath.patch
+make_default_preload_configurable.diff
Bug#855834: linuxptp: default startup argument "-i eth0" should be removed
Package: linuxptp Version: 1.8-1 Severity: normal Dear Maintainer, a default installation of debian stretch will not use eth0 as ethernet device name anymore, also see [1]. using this as commandline argument when starting this service is troublesome, as it can`t be undone. The documention claims you can use an empty port section, to override the but I am not sure how this should be done, as that will just result in an error. I had to edit the systemd unit file to get the service starting. I would recommend removing the argument, and add a section for the device in the configuration file. can be a placeholder like [eth0], I would not know of a good default name that would fit most systems. Kind regards, Norbert Lange [1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linuxptp depends on: ii init-system-helpers 1.47 ii libc62.24-9 linuxptp recommends no packages. linuxptp suggests no packages. -- no debconf information
Bug#855336: make hangs when synchronizing output and redirecting to null
Hi, I opened up a report for docker: https://github.com/docker/docker/issues/31182 I ran lslocks as root and with several flags, I could not get a more detailed output. For completeness, here is a (reduced) correct report with a blocked make: make11052 POSIX0B WRITE* 0 0 0 /dev/null dockerd 15312 OFDLCK READ 0 0 0 /dev... I still think that make should behave better then to block indefinitely, and should be able to cleanly exit on a term signal (not the case if using multiple jobs, seems to end just one of the blocked threads) 2017-02-18 20:33 GMT+01:00 James Cowgill : > Hi, > > On 18/02/17 08:27, Norbert Lange wrote: >> Hi, >> >> sorry for messing up years. >> lslocks only showed makes locking /dev/null, but it appears to be that >> the culprit is a running dockerd daemon. > > lslocks shouldn't be showing make holding a lock in /dev/null because it > does so for a very short period of time. It's also not in the list you > posted below. > >> I dont understand why, but with the service disabled a blocked make >> will suddenly continue. > > Both make and docker are locking the same file. Only one will be able to > obtain it and the other will probably hang (or fail in another way). > >> to install the service: >> echo > /etc/apt/sources.list.d/docker.list 'deb [arch=amd64] >> https://apt.dockerproject.org/repo/ debian-stretch main' >> apt-get update; apt-get install docker-engine >> >> For completeness, the lslocks output: >> $ lslocks >> COMMAND PID TYPE SIZE MODE M STARTEND PATH > [...] >> dockerd 3732 OFDLCKREAD 0 0 0 /dev... > > You may need to run lslocks as root to get the rest of this path. > Assuming this is a lock on /dev/null, then this is probably a bug in > docker rather than make. No-one should be holding long lived locks on > "global" files like that. > >> dockerd 3732 FLOCK 128K WRITE 0 0 0 >> /var/lib/docker/volumes/metadata.db > > Thanks, > James >
Bug#855336: make hangs when synchronizing output and redirecting to null
Hi, sorry for messing up years. lslocks only showed makes locking /dev/null, but it appears to be that the culprit is a running dockerd daemon. I dont understand why, but with the service disabled a blocked make will suddenly continue. to install the service: echo > /etc/apt/sources.list.d/docker.list 'deb [arch=amd64] https://apt.dockerproject.org/repo/ debian-stretch main' apt-get update; apt-get install docker-engine For completeness, the lslocks output: $ lslocks COMMAND PID TYPE SIZE MODE M STARTEND PATH zeitgeist-fts1685 POSIX 15.2M READ 0 1073741826 1073742335 /home/noppl/.local/share/zeitgeist/activity.sqlite zeitgeist-fts1685 POSIX32K READ 0128128 /home/noppl/.local/share/zeitgeist/activity.sqlite-shm chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/data_reduction_proxy_leveldb/LOCK chromium 1872 POSIX 16.7M WRITE 0 1073741824 1073742335 /home/noppl/.config/chromium/Default/History atd 742 POSIX 4B WRITE 0 0 0 /run/atd.pid tracker-store1609 POSIX 256.5M READ 0 1073741826 1073742335 /home/noppl/.cache/tracker/meta.db tracker-store1609 POSIX32K READ 0128128 /home/noppl/.cache/tracker/meta.db-shm zeitgeist-datah 1593 POSIX 15.2M READ 0 1073741826 1073742335 /home/noppl/.local/share/zeitgeist/activity.sqlite zeitgeist-datah 1593 POSIX32K READ 0128128 /home/noppl/.local/share/zeitgeist/activity.sqlite-shm chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/Service Worker/Database/LOCK chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/Session Storage/LOCK libvirtd 955 POSIX 3B WRITE 0 0 0 /run/libvirtd.pid chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/GCM Store/LOCK zeitgeist-fts1685 OFDLCK 0B WRITE 0 0 0 /home/noppl/.local/share/zeitgeist/fts.index/flintlock chromium 1872 POSIX 352K WRITE 0 1073741824 1073742335 /home/noppl/.config/chromium/Default/Web Data chromium 1872 POSIX 3.6M WRITE 0 1073741824 1073742335 /home/noppl/.config/chromium/Default/Sync Data/SyncData.sqlite3 cron 728 FLOCK 4B WRITE 0 0 0 /run/crond.pid chromium 1872 POSIX 124K WRITE 0 1073741824 1073742335 /home/noppl/.config/chromium/Default/Login Data chromium 1872 POSIX 13.6M READ 0 1073741826 1073742335 /home/noppl/.config/chromium/Default/Favicons chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/Extension State/LOCK chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/File System/041/t/Paths/LOCK rpcbind 689 FLOCK 0B WRITE 0 0 0 /run/rpcbind.lock zeitgeist-daemo 1651 POSIX 15.2M READ 0 1073741826 1073742335 /home/noppl/.local/share/zeitgeist/activity.sqlite zeitgeist-daemo 1651 POSIX32K READ 0128128 /home/noppl/.local/share/zeitgeist/activity.sqlite-shm chromium 1872 POSIX 0B WRITE 0 0 0 /home/noppl/.config/chromium/Default/File System/Origins/LOCK chromium 1872 POSIX 736K WRITE 0 1073741824 1073742335 /home/noppl/.config/chromium/Default/Shortcuts dockerd 3732 OFDLCKREAD 0 0 0 /dev... dockerd 3732 FLOCK 128K WRITE 0 0 0 /var/lib/docker/volumes/metadata.db 2017-02-18 1:34 GMT+01:00 James Cowgill : > Hi, > > On 17/02/17 18:08, Norbert Lange wrote: >> Hello, >> >> Tried reproducing it at work (where it first happened on a build server). >> On my PC at home with 4 cores / 12 thread the bug reproduces always >> On a 6 core / 12 threads Xeon Server the bug reproduces always >> On my work PC with 4 cores / 4 threads running in a VMware Instance it >> doesnt reproduce. >> All running Debian Stretch with current updates. >> >> Maybe you want to add infos about your system? >> From the sample of 3: Hyperthreading or >= 8 threads or runnin on bare >> metal instead of in a VM could provoke the bug. > > Originally the system I tried it on has 8 cores (can't remember number > of threads), but I tried it on machines with 2 cores and one with 16 and > it worked on all of them. I don't think the number of cores is relevant > here. > >> Further make 4.1 was uploaded to Debian Stretch on 16h january, the >> issue appeared on 19th january on the server. >> So disregard what I said about this not being an upstream issue - its >> actually quite possible. > > Have you muddled years up here? 4.1 was uploade
Bug#847652: nvidia-kernel-dkms fails to compile for rt-kernel 4.8.0-1-rt
On Tue, 13 Dec 2016 17:59:31 + Luca Boccassi wrote: > Control: tags -1 upstream > > On Sat, 2016-12-10 at 12:40 +0100, Andreas Beckmann wrote: > > On 2016-12-10 12:16, Luca Boccassi wrote: > > > Didn't even know Nvidia driver supported running on the RT kernel. > > > > IIRC this wasn't supported long ago. Maybe things have changed. I never > > tried it myself. > > At least the kernel modules always built without issues against the -rt > > kernels so far. > > > > > Is this a regression, or is it the first time you are trying this? > > > > This is a regression introduced in 370. > > > > > > Andreas > > This is a problem in the kernel code, see this patch: > > https://patchwork.kernel.org/patch/9395795/ > > I don't think there's anything we can do unless that patch is merged in > the kernel. > > Kind regards, > Luca Boccassi This is still a problem with 4.9, any chance of pushing this patch in the kernel before stretch is released? Kind regards, Norbert
Bug#855336: make hangs when synchronizing output and redirecting to null
Hello, Tried reproducing it at work (where it first happened on a build server). On my PC at home with 4 cores / 12 thread the bug reproduces always On a 6 core / 12 threads Xeon Server the bug reproduces always On my work PC with 4 cores / 4 threads running in a VMware Instance it doesnt reproduce. All running Debian Stretch with current updates. Maybe you want to add infos about your system? >From the sample of 3: Hyperthreading or >= 8 threads or runnin on bare metal instead of in a VM could provoke the bug. Further make 4.1 was uploaded to Debian Stretch on 16h january, the issue appeared on 19th january on the server. So disregard what I said about this not being an upstream issue - its actually quite possible. Heres a dump via attached gdb (step wont do anything so it seems that the thread is blocked): (gdb) thread apply all bt Thread 1 (process 12177): #0 0x7f476c156962 in do_fcntl (fd=1, cmd=7, arg=0x5595eae95ea0) at ../sysdeps/unix/sysv/linux/fcntl.c:31 #1 0x7f476c156a29 in __GI___libc_fcntl (fd=, cmd=) at ../sysdeps/unix/sysv/linux/fcntl.c:71 #2 0x5595eac795a7 in output_dump () #3 0x5595eac753b1 in reap_children () #4 0x5595eac76224 in new_job () #5 0x5595eac81a7d in ?? () #6 0x5595eac8035e in ?? () #7 0x5595eac80b3e in ?? () #8 0x5595eac81d9f in update_goal_chain () #9 0x5595eac67719 in main () further it has a few file handles open (apart from the 3 basic ones): one pipe two temp files which don't exist anymore I`ll have to compile make with debuginfo if you need more (gonna take a few days) Kind Regards. Norbert 2017-02-17 15:24 GMT+01:00 James Cowgill : > Hi, > > On 16/02/17 21:52, Norbert Lange wrote: >> Package: make >> Version: 4.1-9 >> Severity: important >> >> Dear Maintainer, >> >> running the attached Makefile will hang the process, >> if multiple jobs are used then the process wont respond to a >> TERM and has to be killed. >> >> The very same issue is observed with make-guile. >> >> I believe this to not be an upstream bug, since I observed this >> only a couple weeks ago after an upgrade. >> Unfortunatly I can`t pinpoint a date or version. > > I cannot reproduce this bug. > > Also, make has not been updated in testing for almost a year so if it > only started happening recently, something else probably caused it. > > Running 'make -d -O' (although this may be difficult if the bug requires > redirection to /dev/null) or the output or running make inside gdb and > finding where it hangs might help in diagnosing this. > > Thanks, > James > >
Bug#855336: make hangs when synchronizing output and redirecting to null
Package: make Version: 4.1-9 Severity: important Dear Maintainer, running the attached Makefile will hang the process, if multiple jobs are used then the process wont respond to a TERM and has to be killed. The very same issue is observed with make-guile. I believe this to not be an upstream bug, since I observed this only a couple weeks ago after an upgrade. Unfortunatly I can`t pinpoint a date or version. Kind Regards, Norbert cat >Makefile <<'EOF' # run with # # rm -rf subdir # make -O >/dev/null # # add -j2, then you can' t even terminate it FILE := a b all: $(addprefix subdir/,$(FILE)) $(addprefix subdir/,$(FILE)): echo "$@" mkdir -p $(dir $@); touch $@ EOF -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages make depends on: ii libc6 2.24-9 make recommends no packages. Versions of packages make suggests: pn make-doc -- no debconf information
Bug#854965: clang-4.0: Pulls 64-bit libs on i386 system
Hi, there are a couple of libraries which pull in those depencies, ands its probably a bad idea to use them at all. Those could/should be moved to own packages, similar to the "multilib"s with gcc. I proposed some new package layout in Bug #841923, but I am not sure how this would work on the buildserver, every arch would generate its static libraries in a arch=all package with a prefix and you could pick libraries for any arch you like this way (even for baremetal builds). but then the control files would be different for each build and the source archive... I think the simplest and best fix for now would be to just kill the depencies, eg (for AMD64): dh_shlibdeps -Xlibclang_rt.asan-i686.so -Xlibclang_rt.asan-i386.so (would need some fitting wildcards for the files) You will have to install the fitting libc *anyway* for a 32bit build, whether you use these libs or not, so I dont see a big problem with skipping those deps. Kind Regards, Norbert 2017-02-12 21:22 GMT+01:00 Sylvestre Ledru : > severity 854965 normal > thanks > > Le 12/02/2017 à 20:34, Robert Luberda a écrit : >> Sylvestre Ledru pisze: >>> Why do you consider that as serious? >> The Debian Policy in section 3.5 says "Every package must specify the >> dependency information about other packages that are required for the >> first to work correctly." It can be that the sentence is more about >> depending on needed packages rather than about not depending on >> unnecessary ones, but honestly I would still consider too wide >> dependencies as a serious bug. However feel free lower the severity if >> you disagree. > yeah, I just did. This doesn't cause any severe issues. > >> Anyway in my opinion the 64-bit libraries are not needed for clang to >> work correctly on i386. I can see that the libclang-common-dev package >> started providing some x86_64 libs, and dpkg-shlibdeps added dependences >> that were necessary for those libs; but I am really in doubt if clang >> will ever use those libs in normal usage, so maybe there is some >> packaging error somewhere? However if this was intentional for any >> reason, it would be great if you could consider making the dev package >> Multi-Arch:same instead to get rid of those strange 64-bit libs dependences. > I think it was introduced in 3.9-5 to fix bug #841923. I guess 3.9 is > also impacted > > Don't hesitate to propose a patch to implement Multi-Arch:same. > I won't have the time to implement it soon. > > S >
Bug#847945: googletest: Makefiles contain wrong path to sources
Package: googletest Version: 1.8.0-3 Severity: important Dear Maintainer, The included Makefile is unusable, as it contains the path of the older version of the package. Supposedly you want to build the library for your project you would do somthing similar to: mkdir /tmp/a; cd /tmp/a make -f /usr/src/googletest/googletest/make/Makefile and then use the resulting static library. To make this work the Makefile has to be fixed, for gtest: --- Makefile.old2016-12-12 15:52:40.162911855 +0100 +++ Makefile2016-12-12 15:55:33.826848718 +0100 @@ -14,10 +14,10 @@ # Points to the root of Google Test, relative to where this file is. # Remember to tweak this if you move this file. -GTEST_DIR = /usr/src/gtest +GTEST_DIR = $(dir $(lastword $(MAKEFILE_LIST))).. # Where to find user code. -USER_DIR = ../samples +USER_DIR = $(dir $(lastword $(MAKEFILE_LIST)))/../samples # Flags passed to the preprocessor. # Set Google Test's header directory as a system directory, such that for gmock: --- Makefile.old2016-12-12 16:07:12.568180908 +0100 +++ Makefile2016-12-12 16:08:51.682651003 +0100 @@ -17,14 +17,14 @@ # Points to the root of Google Test, relative to where this file is. # Remember to tweak this if you move this file, or if you want to use # a copy of Google Test at a different location. -GTEST_DIR = ../../googletest +GTEST_DIR = $(dir $(lastword $(MAKEFILE_LIST)))../../googletest # Points to the root of Google Mock, relative to where this file is. # Remember to tweak this if you move this file. -GMOCK_DIR = .. +GMOCK_DIR = $(dir $(lastword $(MAKEFILE_LIST))).. # Where to find user code. -USER_DIR = ../test +USER_DIR = $(dir $(lastword $(MAKEFILE_LIST)))../test # Flags passed to the preprocessor. # Set Google Test and Google Mock's header directories as system -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages googletest depends on: pn python:any googletest recommends no packages. googletest suggests no packages. -- no debconf information
Bug#846324: googletest: Split the gmock binary from the rest
Package: googletest Version: 1.8.0-3 Severity: wishlist Dear Maintainer, please split up googletest into a source/header only package and a separate package for the binary (only gmock_gen). Reasons would be to get rid of the python dependency and the ability to make the includes and sources - which are enough for alot of use cases - available as a package for all achitectures. probably the package for the gmock_gen tool could be for all architectures aswell? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages googletest depends on: pn python:any googletest recommends no packages. googletest suggests no packages. -- no debconf information
Bug#844093: clang-3.9: clang needs library LLVMgold.so from llvm-dev
Hmm, llvm-runtime is not a dependency either, still placing the
library in a -dev package with alot of headers
is not optimal?
I also worked a bit on the test script, with an installed llvm-3.9-dev
and the fixed efficiency sanitzier I get this output:
(just starnge taht the builtins get linked twice?)
$ sh testclang.sh clang-3.9 -v
Feature Table:
** System ** March -m64
--rtlib=compiler-rt : exec
libclang_rt.builtins-x86_64.a libclang_rt.builtins-x86_64.a
-fuse-ld=gold : exec
-fsanitize=safe-stack : exec libclang_rt.safestack-x86_64.a
-fprofile-instr-generate: exec libclang_rt.profile-x86_64.a
-fsanitize-coverage=edge: exec
libclang_rt.ubsan_standalone-x86_64.a
libclang_rt.ubsan_standalone-x86_64.a.syms
-fsanitize=undefined: exec
libclang_rt.ubsan_standalone-x86_64.a
libclang_rt.ubsan_standalone-x86_64.a.syms
-fsanitize=address : exec libclang_rt.asan-x86_64.a
libclang_rt.asan-x86_64.a.syms
-shared-libasan -fsanitize=address : exec
libclang_rt.asan-x86_64.so libclang_rt.asan-preinit-x86_64.a
-fsanitize=cfi -flto -fuse-ld=gold -fvisibility=hidden: exec
-fsanitize=leak : exec libclang_rt.lsan-x86_64.a
-fsanitize=thread : exec libclang_rt.tsan-x86_64.a
libclang_rt.tsan-x86_64.a.syms
-fsanitize=memory : exec libclang_rt.msan-x86_64.a
libclang_rt.msan-x86_64.a.syms
-fsanitize=dataflow : exec
libclang_rt.dfsan-x86_64.a libclang_rt.dfsan-x86_64.a.syms
-fsanitize=efficiency-working-set : exec libclang_rt.esan-x86_64.a
libclang_rt.esan-x86_64.a.syms
** System ** March -m32
--rtlib=compiler-rt : exec
libclang_rt.builtins-i386.a libclang_rt.builtins-i386.a
-fuse-ld=gold : exec
-fsanitize=safe-stack : exec libclang_rt.safestack-i386.a
-fprofile-instr-generate: exec libclang_rt.profile-i386.a
-fsanitize-coverage=edge: exec libclang_rt.ubsan_standalone-i386.a
-fsanitize=undefined: exec libclang_rt.ubsan_standalone-i386.a
-fsanitize=address : exec libclang_rt.asan-i386.a
-shared-libasan -fsanitize=address : exec libclang_rt.asan-i386.so
libclang_rt.asan-preinit-i386.a
-fsanitize=cfi -flto -fuse-ld=gold -fvisibility=hidden: exec
-fsanitize=leak : unsupported option
'-fsanitize=leak' for target 'i386-pc-linux-gnu'
-fsanitize=thread : unsupported option
'-fsanitize=thread' for target 'i386-pc-linux-gnu'
-fsanitize=memory : unsupported option
'-fsanitize=memory' for target 'i386-pc-linux-gnu'
-fsanitize=dataflow : unsupported option
'-fsanitize=dataflow' for target 'i386-pc-linux-gnu'
-fsanitize=efficiency-working-set : unsupported option
'-fsanitize=efficiency-working-set' for target 'i386-pc-linux-gnu'
Kind regards,
Norbert
On Sat, 12 Nov 2016 12:48:47 +0100 Norbert Lange wrote:
> Package: clang-3.9
> Version: 1:3.9-5
> Severity: normal
>
> Dear Maintainer,
>
> Some options require the gold linker and its plugin interface,
> this library is however residing in the llvm-dev package - which is not a
> dependency of clang
>
> To reproduce, uninstall llvm-3.9-dev and run:
> echo 'int main() {}' >test.c
> clang-3.9 -fuse-ld=gold test.c
>
> Please move this library out of the llvm-dev package, I think llvm-runtime
> would be correct?
>
> -- System Information:
> Debian Release: stretch/sid
> APT prefers testing
> APT policy: (200, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf, arm64
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages clang-3.9 depends on:
> ii binutils 2.27-9+b1
> ii libc62.24-5
> ii libc6-dev2.24-5
> ii libclang-common-3.9-dev 1:3.9-5
> ii libclang1-3.91:3.9-5
> ii libgcc-6-dev 6.2.0-10
> ii libgcc1 1:6.2.0-10
> ii libjsoncpp1 1.7.4-3
> ii libllvm3.9 1:3.9-5
> ii libobjc-6-dev6.2.0-10
> ii libstdc++-6-dev 6.2.0-10
> ii libstdc++6 6.2.0-10
>
> Versions of packages clang-3.9 recommends:
> ii llvm-3.9-dev 1:3.9-5
> ii python2.7.11-2
>
> Versions of packages clang-3.9 suggests:
> pn clang-3.9-doc
> pn gnustep
> pn gnustep-devel
>
> -- no debconf information
>
>
testclang.sh
Description: Bourne shell script
Bug#844093: clang-3.9: clang needs library LLVMgold.so from llvm-dev
Package: clang-3.9
Version: 1:3.9-5
Severity: normal
Dear Maintainer,
Some options require the gold linker and its plugin interface,
this library is however residing in the llvm-dev package - which is not a
dependency of clang
To reproduce, uninstall llvm-3.9-dev and run:
echo 'int main() {}' >test.c
clang-3.9 -fuse-ld=gold test.c
Please move this library out of the llvm-dev package, I think llvm-runtime
would be correct?
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages clang-3.9 depends on:
ii binutils 2.27-9+b1
ii libc62.24-5
ii libc6-dev2.24-5
ii libclang-common-3.9-dev 1:3.9-5
ii libclang1-3.91:3.9-5
ii libgcc-6-dev 6.2.0-10
ii libgcc1 1:6.2.0-10
ii libjsoncpp1 1.7.4-3
ii libllvm3.9 1:3.9-5
ii libobjc-6-dev6.2.0-10
ii libstdc++-6-dev 6.2.0-10
ii libstdc++6 6.2.0-10
Versions of packages clang-3.9 recommends:
ii llvm-3.9-dev 1:3.9-5
ii python2.7.11-2
Versions of packages clang-3.9 suggests:
pn clang-3.9-doc
pn gnustep
pn gnustep-devel
-- no debconf information
Bug#844092: libclang-common-3.9-dev: efficiency sanitizer segfaults
Package: libclang-common-3.9-dev Version: 1:3.9-5 Severity: normal Tags: patch Dear Maintainer, The efficiency sanitizer segfaults immediatly on debian sid. This is due a change in glibc. Will attach a patch shortly -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libclang-common-3.9-dev depends on: ii libc6 2.24-5 ii libgcc1 1:6.2.0-10 ii libllvm3.9 1:3.9-5 ii libstdc++6 6.2.0-10 ii libtinfo5 6.0+20160917-1 ii zlib1g 1:1.2.8.dfsg-2+b3 libclang-common-3.9-dev recommends no packages. libclang-common-3.9-dev suggests no packages. -- no debconf information esan-patch_3.9.tar.gz Description: application/gzip
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
Hello, seems like the "efficiency sanitizer" needs a patch aswell. Luckily this is only for 3.9 as 3.8 doesnt even have this sanitizer. Building now, I don`t expect any problems. esan-patch_3.9.tar.gz Description: GNU Zip compressed data
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
Hi, I first searched the related patches, then tested them on 3.9. I wrote the message without trying them on 3.8, I did not know if the first patch is required. Why didn't you run 'quilt push -a' before committing them? 😁 Am 11.11.2016 5:07 nachm. schrieb "Sylvestre Ledru" : > Yeah, my bad. Why did you included the third patch btw? > > thanks again > > > Le 11/11/2016 à 17:02, Norbert Lange a écrit : > >> Hi, you messed up the order, look in the series file from the attachment. >> You only need those two patches (in this order), third is already >> included in 3.8.1: >> >> upstream-msan-prevent-initialization-failure.diff >> upstream-asan-msan-fix-reallocation-logic.diff >> >> if you want you can refresh them with quilt, but they apply cleanly >> for me (with some other linenumbers) >> >> 2016-11-11 16:23 GMT+01:00 Sylvestre Ledru : >> >>> I could apply upstream-msan-prevent-initialization-failure.diff to 3.8 >>> but >>> not the two others, could you share yours? >>> Thanks >>> S >>> >>> >>> Le 11/11/2016 à 09:52, Norbert Lange a écrit : >>> >>>> The same 2 patches also apply to toolchain 3.8.1-15 (with some >>>> offsets), but I haven`t testing building it >>>> >>>> 2016-11-11 1:25 GMT+01:00 Norbert Lange : >>>> >>>>> BTW. make check-sanitizer would have likely found this issue, might >>>>> want to enable it? >>>>> I believe it knows which sanitizers should work >>>>> >>>>> 2016-11-11 0:46 GMT+01:00 Norbert Lange : >>>>> >>>>>> Tags: patch >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I got it working, seems that from the 3 related patched, one is >>>>>> already >>>>>> applied. >>>>>> The attached archive is the 3 patches and a edited "series" file, >>>>>> it should be painless for you to integrate it into the debian/patches >>>>>> directory for 3.9 >>>>>> >>>>>> I did not try with 3.8 yet (possibly more difficult), building llvm >>>>>> takes quite a while. >>>>>> >>>>>> Kind Regards, >>>>>> Norbert >>>>>> >>>>>> 2016-11-09 11:04 GMT+01:00 Norbert Lange : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> researched a bit further and the same compiled programm will run fine >>>>>>> on debian jessie. >>>>>>> I tracked it down to being caused by a newer glibc version [1][2], >>>>>>> apparently during loading of shared libs, glibc can now allocate >>>>>>> memory which messes up sanitzers (mostly in more subtile ways than >>>>>>> the >>>>>>> memory sanitizer). >>>>>>> >>>>>>> The result is, that if stretch will ship with the current glibc, >>>>>>> clang >>>>>>> and gcc (I dont think its patched there either), then the sanitizers >>>>>>> won`t be usable. >>>>>>> 1) revert the fix in glibc. Would have the advantage that "sanitized" >>>>>>> binaries compiled from current and older clang/gcc versions will work >>>>>>> 2) adopt the fixed from upstream [3][4] (possibly more) into clang >>>>>>> (and possibly gcc). >>>>>>> or maybe both? >>>>>>> >>>>>>> Kind Regards, >>>>>>> Norbert >>>>>>> >>>>>>> PS. shouldn`t the testsuite catch these bugs? >>>>>>> >>>>>>> [1] >>>>>>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1ce >>>>>>> de1952d7d4411a3cafd25dd8593dab9f >>>>>>> [2] https://llvm.org/bugs/show_bug.cgi?id=27310 >>>>>>> [3] >>>>>>> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1 >>>>>>> 078fc7c7da287984a7ba4563390589 >>>>>>> [4] >>>>>>> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a >>>>>>> 6f90b0370a86535cbde6738d0ccf67 >>>>>>> >>>>>>> 2016-10-31 21:43 GMT+01:00 Norbert Lange : >>>>>>> >>
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
Hi, you messed up the order, look in the series file from the attachment.
You only need those two patches (in this order), third is already
included in 3.8.1:
upstream-msan-prevent-initialization-failure.diff
upstream-asan-msan-fix-reallocation-logic.diff
if you want you can refresh them with quilt, but they apply cleanly
for me (with some other linenumbers)
2016-11-11 16:23 GMT+01:00 Sylvestre Ledru :
> I could apply upstream-msan-prevent-initialization-failure.diff to 3.8 but
> not the two others, could you share yours?
> Thanks
> S
>
>
> Le 11/11/2016 à 09:52, Norbert Lange a écrit :
>>
>> The same 2 patches also apply to toolchain 3.8.1-15 (with some
>> offsets), but I haven`t testing building it
>>
>> 2016-11-11 1:25 GMT+01:00 Norbert Lange :
>>>
>>> BTW. make check-sanitizer would have likely found this issue, might
>>> want to enable it?
>>> I believe it knows which sanitizers should work
>>>
>>> 2016-11-11 0:46 GMT+01:00 Norbert Lange :
>>>>
>>>> Tags: patch
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I got it working, seems that from the 3 related patched, one is already
>>>> applied.
>>>> The attached archive is the 3 patches and a edited "series" file,
>>>> it should be painless for you to integrate it into the debian/patches
>>>> directory for 3.9
>>>>
>>>> I did not try with 3.8 yet (possibly more difficult), building llvm
>>>> takes quite a while.
>>>>
>>>> Kind Regards,
>>>> Norbert
>>>>
>>>> 2016-11-09 11:04 GMT+01:00 Norbert Lange :
>>>>>
>>>>> Hi,
>>>>>
>>>>> researched a bit further and the same compiled programm will run fine
>>>>> on debian jessie.
>>>>> I tracked it down to being caused by a newer glibc version [1][2],
>>>>> apparently during loading of shared libs, glibc can now allocate
>>>>> memory which messes up sanitzers (mostly in more subtile ways than the
>>>>> memory sanitizer).
>>>>>
>>>>> The result is, that if stretch will ship with the current glibc, clang
>>>>> and gcc (I dont think its patched there either), then the sanitizers
>>>>> won`t be usable.
>>>>> 1) revert the fix in glibc. Would have the advantage that "sanitized"
>>>>> binaries compiled from current and older clang/gcc versions will work
>>>>> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
>>>>> (and possibly gcc).
>>>>> or maybe both?
>>>>>
>>>>> Kind Regards,
>>>>> Norbert
>>>>>
>>>>> PS. shouldn`t the testsuite catch these bugs?
>>>>>
>>>>> [1]
>>>>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
>>>>> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
>>>>> [3]
>>>>> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
>>>>> [4]
>>>>> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>>>>>
>>>>> 2016-10-31 21:43 GMT+01:00 Norbert Lange :
>>>>>>
>>>>>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru
>>>>>> wrote:
>>>>>>>
>>>>>>> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
>>>>>>>>
>>>>>>>> Package: clang-3.9
>>>>>>>> Version: 1:3.9-2
>>>>>>>> Severity: normal
>>>>>>>>
>>>>>>>> Dear Maintainer,
>>>>>>>>
>>>>>>>> The memory sanitizer is unusable as it segfaults during
>>>>>>>> initialization.
>>>>>>>> To reproduce:
>>>>>>>> echo 'int main() { return 0; }' >/tmp/test.c
>>>>>>>> clang -fsanitize=memory -o test test.c
>>>>>>>
>>>>>>> can you try with clang-3.9 instead?
>>>>>>
>>>>>> Same thing, output:
>>>>>>
>>>>>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>>>>>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>>>>>> Target: x86_64-pc-linux-gnu
>>>>>> Thread model: posix
>>&
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
The same 2 patches also apply to toolchain 3.8.1-15 (with some
offsets), but I haven`t testing building it
2016-11-11 1:25 GMT+01:00 Norbert Lange :
> BTW. make check-sanitizer would have likely found this issue, might
> want to enable it?
> I believe it knows which sanitizers should work
>
> 2016-11-11 0:46 GMT+01:00 Norbert Lange :
>> Tags: patch
>>
>>
>> Hi,
>>
>> I got it working, seems that from the 3 related patched, one is already
>> applied.
>> The attached archive is the 3 patches and a edited "series" file,
>> it should be painless for you to integrate it into the debian/patches
>> directory for 3.9
>>
>> I did not try with 3.8 yet (possibly more difficult), building llvm
>> takes quite a while.
>>
>> Kind Regards,
>> Norbert
>>
>> 2016-11-09 11:04 GMT+01:00 Norbert Lange :
>>> Hi,
>>>
>>> researched a bit further and the same compiled programm will run fine
>>> on debian jessie.
>>> I tracked it down to being caused by a newer glibc version [1][2],
>>> apparently during loading of shared libs, glibc can now allocate
>>> memory which messes up sanitzers (mostly in more subtile ways than the
>>> memory sanitizer).
>>>
>>> The result is, that if stretch will ship with the current glibc, clang
>>> and gcc (I dont think its patched there either), then the sanitizers
>>> won`t be usable.
>>> 1) revert the fix in glibc. Would have the advantage that "sanitized"
>>> binaries compiled from current and older clang/gcc versions will work
>>> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
>>> (and possibly gcc).
>>> or maybe both?
>>>
>>> Kind Regards,
>>> Norbert
>>>
>>> PS. shouldn`t the testsuite catch these bugs?
>>>
>>> [1]
>>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
>>> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
>>> [3]
>>> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
>>> [4]
>>> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>>>
>>> 2016-10-31 21:43 GMT+01:00 Norbert Lange :
>>>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru
>>>> wrote:
>>>>> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
>>>>> > Package: clang-3.9
>>>>> > Version: 1:3.9-2
>>>>> > Severity: normal
>>>>> >
>>>>> > Dear Maintainer,
>>>>> >
>>>>> > The memory sanitizer is unusable as it segfaults during initialization.
>>>>> > To reproduce:
>>>>> > echo 'int main() { return 0; }' >/tmp/test.c
>>>>> > clang -fsanitize=memory -o test test.c
>>>>> can you try with clang-3.9 instead?
>>>>
>>>> Same thing, output:
>>>>
>>>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>>>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>>>> Target: x86_64-pc-linux-gnu
>>>> Thread model: posix
>>>> InstalledDir: /usr/bin
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>>>> Found candidate GCC installation:
>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>>>> Found candidate GCC installation:
>>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
>>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
>>>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>>> Candidate multilib: .;@m64
>>>> Candidate multilib: 32;@m32
>>>> Candidate multilib: x32;@mx32
>>>> Selected multilib: .;@m64
>>>> "/usr/lib/llvm-3.9/bin/clang" -cc1 -tr
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
BTW. make check-sanitizer would have likely found this issue, might
want to enable it?
I believe it knows which sanitizers should work
2016-11-11 0:46 GMT+01:00 Norbert Lange :
> Tags: patch
>
>
> Hi,
>
> I got it working, seems that from the 3 related patched, one is already
> applied.
> The attached archive is the 3 patches and a edited "series" file,
> it should be painless for you to integrate it into the debian/patches
> directory for 3.9
>
> I did not try with 3.8 yet (possibly more difficult), building llvm
> takes quite a while.
>
> Kind Regards,
> Norbert
>
> 2016-11-09 11:04 GMT+01:00 Norbert Lange :
>> Hi,
>>
>> researched a bit further and the same compiled programm will run fine
>> on debian jessie.
>> I tracked it down to being caused by a newer glibc version [1][2],
>> apparently during loading of shared libs, glibc can now allocate
>> memory which messes up sanitzers (mostly in more subtile ways than the
>> memory sanitizer).
>>
>> The result is, that if stretch will ship with the current glibc, clang
>> and gcc (I dont think its patched there either), then the sanitizers
>> won`t be usable.
>> 1) revert the fix in glibc. Would have the advantage that "sanitized"
>> binaries compiled from current and older clang/gcc versions will work
>> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
>> (and possibly gcc).
>> or maybe both?
>>
>> Kind Regards,
>> Norbert
>>
>> PS. shouldn`t the testsuite catch these bugs?
>>
>> [1]
>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
>> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
>> [3]
>> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
>> [4]
>> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>>
>> 2016-10-31 21:43 GMT+01:00 Norbert Lange :
>>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru
>>> wrote:
>>>> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
>>>> > Package: clang-3.9
>>>> > Version: 1:3.9-2
>>>> > Severity: normal
>>>> >
>>>> > Dear Maintainer,
>>>> >
>>>> > The memory sanitizer is unusable as it segfaults during initialization.
>>>> > To reproduce:
>>>> > echo 'int main() { return 0; }' >/tmp/test.c
>>>> > clang -fsanitize=memory -o test test.c
>>>> can you try with clang-3.9 instead?
>>>
>>> Same thing, output:
>>>
>>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>>> Target: x86_64-pc-linux-gnu
>>> Thread model: posix
>>> InstalledDir: /usr/bin
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
>>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
>>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>>> Candidate multilib: .;@m64
>>> Candidate multilib: 32;@m32
>>> Candidate multilib: x32;@mx32
>>> Selected multilib: .;@m64
>>> "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
>>> -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>>> -discard-value-names -main-file-name test.c -mrelocation-model static
>>> -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
>>> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
>>> x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
>>> /usr/local/include -internal-isystem
>>> /usr/lib/llvm-3.9/bi
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
Tags: patch
Hi,
I got it working, seems that from the 3 related patched, one is already applied.
The attached archive is the 3 patches and a edited "series" file,
it should be painless for you to integrate it into the debian/patches
directory for 3.9
I did not try with 3.8 yet (possibly more difficult), building llvm
takes quite a while.
Kind Regards,
Norbert
2016-11-09 11:04 GMT+01:00 Norbert Lange :
> Hi,
>
> researched a bit further and the same compiled programm will run fine
> on debian jessie.
> I tracked it down to being caused by a newer glibc version [1][2],
> apparently during loading of shared libs, glibc can now allocate
> memory which messes up sanitzers (mostly in more subtile ways than the
> memory sanitizer).
>
> The result is, that if stretch will ship with the current glibc, clang
> and gcc (I dont think its patched there either), then the sanitizers
> won`t be usable.
> 1) revert the fix in glibc. Would have the advantage that "sanitized"
> binaries compiled from current and older clang/gcc versions will work
> 2) adopt the fixed from upstream [3][4] (possibly more) into clang
> (and possibly gcc).
> or maybe both?
>
> Kind Regards,
> Norbert
>
> PS. shouldn`t the testsuite catch these bugs?
>
> [1]
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f
> [2] https://llvm.org/bugs/show_bug.cgi?id=27310
> [3]
> https://github.com/llvm-mirror/compiler-rt/commit/827ea206c1078fc7c7da287984a7ba4563390589
> [4]
> https://github.com/llvm-mirror/compiler-rt/commit/570ee9dd7a6f90b0370a86535cbde6738d0ccf67
>
> 2016-10-31 21:43 GMT+01:00 Norbert Lange :
>> On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru
>> wrote:
>>> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
>>> > Package: clang-3.9
>>> > Version: 1:3.9-2
>>> > Severity: normal
>>> >
>>> > Dear Maintainer,
>>> >
>>> > The memory sanitizer is unusable as it segfaults during initialization.
>>> > To reproduce:
>>> > echo 'int main() { return 0; }' >/tmp/test.c
>>> > clang -fsanitize=memory -o test test.c
>>> can you try with clang-3.9 instead?
>>
>> Same thing, output:
>>
>> $ clang-3.9 -fsanitize=memory -o test test.c -v
>> clang version 3.9.0-2 (tags/RELEASE_390/final)
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>> InstalledDir: /usr/bin
>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
>> Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
>> Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
>> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
>> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
>> Candidate multilib: .;@m64
>> Candidate multilib: 32;@m32
>> Candidate multilib: x32;@mx32
>> Selected multilib: .;@m64
>> "/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
>> -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
>> -discard-value-names -main-file-name test.c -mrelocation-model static
>> -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
>> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
>> x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
>> /usr/local/include -internal-isystem
>> /usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
>> -internal-externc-isystem /usr/include/x86_64-linux-gnu
>> -internal-externc-isystem /include -internal-externc-isystem
>> /usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
>> -fmessage-length 135 -fsanitize=memory
>> -fsanitize-blacklist=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/msan_blacklist.txt
>> -fno-assume-sane-operator-new -fobjc-runtime=gcc
>> -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-2d4d2c.o -x
>> c test.c
>> clang -cc1 version 3.9.0 based upon LLVM 3.9.0
Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries
Hi, Looking at gcc-6, this is what the depency looks like there: g++-multilib [amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel mipsn32 mipsn32el powerpc ppc64 s390 s390x sparc sparc64 x32] I also found out how to use the libclang_rt.asan-*.so binaries, they are used via the option "-shared-libasan -fsanitize=address". The problem is, that the compiled programs won`t find this library (unless I adjust the LD library path to countain the private libraries of this package). There are some more "cons" with using it: https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso I really think it would be a good idea to exclude those libraries from dh_shlibdeps (like in pathv2) (but keep them in the package), If someone wants to use them, he will have to care that those get loaded correctly. Even better would be a separate package (only for the shared libs) I did not find the time to write down a scheme for the packages. I will outline it here: clang-compilerrt-common (all): contains the headers, empty directories symlinks. clang-compilerrt-dev (any): contains binary, arch specific tools. depends on clang-compilerrt-common, clang-compilerrt-dev-, libclang-compilerrt- clang-compilerrt-dev-[linux_x86_64 | kfreebsd_x86_64 | linux_i386 | linux_aarch64 | linux_armhf | ...] (all): contain the static libs (*.a *.a.syms). every host-build generates only the fitting native files. libclang-compilerrt-[linux_x86_64 | kfreebsd_x86_64 | linux_i386 | linux_aarch64 | linux_armhf | ...] (all): contains the shared libs every host-build generates only the fitting native files. dh_shlibdeps is overridden to either remove all dependecies, or use the correct multiarch suffix. That means you can easisly install the rt libraries for another system and crosscompile. if you run on amd64 and install clang-compilerrt-dev-linux_i386 you will be able to crosscompile for i386. Further, the current amd64 build (3.8-14) has the libraries for i386, splitting up the libraries the above way would allow to build them on their native environment just once, and also just easily add other archs which cant be cross-compiled as easily (x32, non-linux, etc...) The important thing here is that, you can compile for other architectures anyway, but if you want to link a simple programm (for linux) on another arch you will need to install the fitting g++-multilib or a fitting linker anyway. Installing clang-compilerrt-dev- and/or libclang-compilerrt- is an additional step, but you can assume that the user already can link for this - It it either allready covered if he can compile with g++ or he already installed a fitting toolchain and libraries. Because of this, and the reason that you cant use those shared libraries *alone*, I think removing the depencies would be best. For easy installation (also dealing with the 32bit dependencies) of x64/x86 clang maybe a new clang-multilib package would be the best way, pulling in even those dependencies: clang-multiarch (amd64): depends on: clang, g++-multiarch, clang-compilerrt-dev-linux_x86_64, clang-compilerrt-dev-linux_i386, libclang-compilerrt-dev-linux_x86x86_64, libclang-compilerrt-linux_i386 Kind Regards, Norbert 2016-11-06 16:29 GMT+01:00 Sylvestre Ledru : > I did it and I am rebuilding > > > Le 6 nov. 2016 3:40 PM, "Sylvestre Ledru" a écrit : >> >> I guess limiting the declaration of this package in the build dep should >> be enough >> >> S >> >> Le 06/11/2016 à 13:34, Sylvestre Ledru a écrit : >>> >>> Looks lile g++-multilib is not available on many archs >>> >>> https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8 >>> >>> could you have a look? >>> >>> Thanks >>> >>> S >>> >>> >>> >>> Le 01/11/2016 à 21:24, Sylvestre Ledru a écrit : >>>> >>>> Le 01/11/2016 à 19:56, Norbert Lange a écrit : >>>>> >>>>> Hi, >>>>> >>>>> we absolutely should do this. I believe we have some communication >>>>> problems, because I brought this up multiple times. >>>> >>>> Probably me, sorry :/ >>>>> >>>>> I am not sure how to solve it, I can think of multiple ways. But it >>>>> would help if you just apply this path as it is, and let it build for >>>>> the ~10 architectures. Can you do this somehow, maybe just keep it in >>>>> experimental? >>>> >>>> I don't think this is reasonable leave it as it. >>>> I would like to see this changes in 3.8 and this will impact too much >>>> Debian. >>>> >>>> So, we should find a proper solution. >>>> However, I "only" saw the i386 files, not a
Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries
> I don't think this is reasonable leave it as it. > I would like to see this changes in 3.8 and this will impact too much > Debian. I am not saying to leave it, but to do the bigger change in smaller steps. You seem to miss, that not only the amd64 package will change, but any host architecture will aswell. I cant test anything but amd64, and we might mess thing up for the rest of them, possibly without noticing ** Example, of what I believe will happen (only for arm64. mips64, ppc64, sparc64? likewise): * Now: arm64 package contains: /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a.syms armhf package contains: /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms armel package contains (would contain on a jessie backport, just my guess): /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms * After adding the g++-multilib dependency: arm64 package contains: /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a.syms /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms armhf package contains: /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms armel package contains (would contain on a jessie backport, just my guess): /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a /usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms ** this will affect packaging, and all this is just a GUESS now. We would know ALOT better what we need to do if we let the build server run once. If we start moving around files, we might miss some, or break the build. > $ debdiff /tmp/libclang-common-3.8-dev_3.8.1-12_amd64.deb > libclang-common-3.8-dev_3.8.1-13_amd64.deb As said, amd64 is just one architecture, I am talking about all of them. > You are talking about libclang_rt.asan-i386.so and libclang_rt.asan-i686.so, > right? These are the ones that add the new lib32* dependencies, and the ones that are troublesome for dh_shlibdeps What would you say, if for now we just remove the dependencies to the lib32* libraries? You would have to adjust the filter depending on the architecture (thats exactly what I dont know to figure out easily for other archs). eg.: dh_shlibdeps -l/buildllvm/llvm-toolchain-3.9-3.9/debian/tmp//usr/lib/llvm-3.9/lib/ -Xlibclang_rt.asan-i686.so -Xlibclang_rt.asan-i386.so I added a patchv2 for just this. To me this makes alot of sense anyway since you dont strictly depend on the host toolchain C/C++ libraries. For example I am using clang with custom toolchains in the /opt directory and the C/C++ libraries are picked up from there. They might make sense as recommendations. For splitting the archives, I`d like to write down a scheme, but this will take a few days. The patchv2 should result in the same dependencies as before, but still have the multilibs included. Works correctly on amd64 and should compile on all others, some other archs might end up with additional dependencies (32/64bit C/C++libs) like the previous patch - which we can fix by expanding the table of extensions (MULTILIB_EXTS). Kind Regards, Norbert PS.: an older patch for splitting up the libs is attached by Bug #829441. But I think a different approach would be better 2016-11-01 21:24 GMT+01:00 Sylvestre Ledru : > Le 01/11/2016 à 19:56, Norbert Lange a écrit : >> >> Hi, >> >> we absolutely should do this. I believe we have some communication >> problems, because I brought this up multiple times. > > Probably me, sorry :/ >> >> I am not sure how to solve it, I can think of multiple ways. But it >> would help if you just apply this path as it is, and let it build for >> the ~10 architectures. Can you do this somehow, maybe just keep it in >> experimental? > > I don't think this is reasonable leave it as it. > I would like to see this changes in 3.8 and this will impact too much > Debian. > > So, we should find a proper solution. > However, I "onl
Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries
Hi, we absolutely should do this. I believe we have some communication problems, because I brought this up multiple times. I am not sure how to solve it, I can think of multiple ways. But it would help if you just apply this path as it is, and let it build for the ~10 architectures. Can you do this somehow, maybe just keep it in experimental? First, it helps if we know we start with a working build (on all platforms) before modifying it, and which libraries would normally be built. Then I would like to be able to make a list of libraries for all architectures, since I believe this will differ alot. Also (I brought this up before): I dont know if the shared sanitizer libraries are actually used anywhere. The static libraries dont make problems, so if we can drop the shared ones then this is one problem solved. 2016-11-01 19:33 GMT+01:00 Sylvestre Ledru : > I wonder if we should not move the new files into a dedicated packages. > > When installing this package, it is installing new packages (lib32gcc1, > lib32stdc++6 and libc6-i386) [1] > This would increase the installation size quite consequently for a specific > case. > > What do you think? > > Thanks > S > > > [1] > Unpacking libclang-common-3.8-dev (1:3.8.1-13) over (1:3.8.1-13) ... > dpkg: dependency problems prevent configuration of libclang-common-3.8-dev: > libclang-common-3.8-dev depends on lib32gcc1 (>= 1:3.3); however: > Package lib32gcc1 is not installed. > libclang-common-3.8-dev depends on lib32stdc++6 (>= 4.1.1); however: > Package lib32stdc++6 is not installed. > libclang-common-3.8-dev depends on libc6-i386 (>= 2.2.4); however: > Package libc6-i386 is not installed. > > > Le 01/11/2016 à 16:31, Norbert Lange a écrit : > > Hi, > > first, I think this was an issue on my docker installation, it builds > fine without that option natively. so try without this option > secondly - yes its discouraged, just as adding libs from different > architectures in one archive, lint has some more complaints on the > llvm packages. I`d still prefer getting the libs compiled for now, > testing if it generally compiles on the supported architectures. > Ideally we will split the packages later, but Id prefer getting an > overview on how to do it (what gets built on other archs), an a > working solution right now. > > I also added a new version of the script. > Run it with 'sh testclang.sh clang-3.9 -v', will give you a table at > the end describing the state of the options (compiles, links or > executes) and the linked clang libs. > > Kind Regards, > Norbert > > On Tue, 1 Nov 2016 16:18:57 +0100 Sylvestre Ledru > wrote: > > Hello, > > Thanks for your patch. However, I don't really like the > --ignore-missing-info option (especially as the doc says > "Usage of this option is discouraged") > Any other option? > > Cheers, > Sylvesre > > > > Le 01/11/2016 à 00:56, Lange Norbert a écrit : > > Hello, > > I don`t know if the docker installation got messed up (different so versions > than on my native system), but the dh_shlibdeps step won`t find the correct > packages for some 32bit libraries. > In case some packages wont build, those errors could be ignored. > > > diff -burN debian.org/control debian/control > --- debian.org/control 2016-10-31 23:33:26.307560672 +0100 > +++ debian/control 2016-10-31 23:36:29.861497749 +0100 > @@ -7,7 +7,7 @@ > cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= > 3.0.9), > lsb-release, patchutils, diffstat, xz-utils, python-dev, > libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev, > -libjsoncpp-dev, > +libjsoncpp-dev, g++-multilib, > lcov, procps, help2man, dh-ocaml, zlib1g-dev > Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, > libllvm-3.5-ocaml-dev, > libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev > diff -burN debian.org/rules debian/rules > --- debian.org/rules 2016-10-31 23:33:26.307560672 +0100 > +++ debian/rules 2016-11-01 00:48:08.022283769 +0100 > @@ -400,7 +400,7 @@ > > > override_dh_shlibdeps: > - > LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ > dh_shlibdeps > + dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- > --ignore-missing-info > > override_dh_installman: > dh_installman > > > Von: Lange Norbert > Gesendet: Montag, 31. Oktober 2016 23:58 > An: Sylvestre Ledru; 841...@bugs.debian.org > Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib > binaries > > Hi, > > patch is attached. I tested a clean docker installation of debian-testing, > adding this
Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries
Hi, first, I think this was an issue on my docker installation, it builds fine without that option natively. so try without this option secondly - yes its discouraged, just as adding libs from different architectures in one archive, lint has some more complaints on the llvm packages. I`d still prefer getting the libs compiled for now, testing if it generally compiles on the supported architectures. Ideally we will split the packages later, but Id prefer getting an overview on how to do it (what gets built on other archs), an a working solution right now. I also added a new version of the script. Run it with 'sh testclang.sh clang-3.9 -v', will give you a table at the end describing the state of the options (compiles, links or executes) and the linked clang libs. Kind Regards, Norbert On Tue, 1 Nov 2016 16:18:57 +0100 Sylvestre Ledru wrote: > > Hello, > > Thanks for your patch. However, I don't really like the > --ignore-missing-info option (especially as the doc says > "Usage of this option is discouraged") > Any other option? > > Cheers, > Sylvesre > > > > Le 01/11/2016 à 00:56, Lange Norbert a écrit : > > Hello, > > > > I don`t know if the docker installation got messed up (different so > > versions than on my native system), but the dh_shlibdeps step won`t find > > the correct packages for some 32bit libraries. > > In case some packages wont build, those errors could be ignored. > > > > > > diff -burN debian.org/control debian/control > > --- debian.org/control 2016-10-31 23:33:26.307560672 +0100 > > +++ debian/control 2016-10-31 23:36:29.861497749 +0100 > > @@ -7,7 +7,7 @@ > > cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= > > 3.0.9), > > lsb-release, patchutils, diffstat, xz-utils, python-dev, > > libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev, > > -libjsoncpp-dev, > > +libjsoncpp-dev, g++-multilib, > > lcov, procps, help2man, dh-ocaml, zlib1g-dev > > Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, > > libllvm-3.5-ocaml-dev, > > libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev > > diff -burN debian.org/rules debian/rules > > --- debian.org/rules 2016-10-31 23:33:26.307560672 +0100 > > +++ debian/rules 2016-11-01 00:48:08.022283769 +0100 > > @@ -400,7 +400,7 @@ > > > > > > override_dh_shlibdeps: > > - > > LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ > > dh_shlibdeps > > + dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- > > --ignore-missing-info > > > > override_dh_installman: > > dh_installman > > > > > > Von: Lange Norbert > > Gesendet: Montag, 31. Oktober 2016 23:58 > > An: Sylvestre Ledru; 841...@bugs.debian.org > > Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib > > binaries > > > > Hi, > > > > patch is attached. I tested a clean docker installation of debian-testing, > > adding this dependency generates the additional libraries. > > Having those built once via the debian build machinery should give us an > > idea which subtypes are supported, and wether it crashes and burns an some > > systems (looking at gcc-6 source package theres alot arch.dependend > > libraries there) > > > > I`ll think of some scriptable tests too, but this will have to smart enough > > to figure out the expected variants for all supported hosts (ie the > > suported "multilib" flags). > > > > Kind regards, > > Norbert testclang.sh Description: Bourne shell script
Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries
Hi, I attached a script for an exhaustive run of arguments, with the aim to link all existing libraries from this package once. As you will see, there are alot failure, most of which arent a problem of the packaging. We would need to figure out which features should work. So far this should be: * everything on amd64 * rtlib and address- / undefined-sanitizer on x86 * rtlib on x32 Usage is for ex.: sh testclang.sh clang-3.9 or (adds -v option everywhere so you see the linked libs): sh testclang.sh clang-3.9 -v Some points * if being a full replacement for gcc is the aim, x32 should be supported too (-sanitizer=undefined) * I don`t know how the i686 libraries are picked up, I thouhgt --march=i686 would do the trick, but it still uses the i386 variants. maybe need to set clang to a i686 toolchain like '--gcc-toolchain=/usr/lib/gcc/i686-linux-gnu/6' ? * Also it seems, that sanitizers always are linked statically, even if eg. asan has a shared library aswell. * memory sanitizer (Bug #842642) and efficiency sanitizer segfault on the simple test. (the later is still WIP, but maybe it would be best to not build/include it for now?) Maybe you can bring the discussion upstream, for what should be supported, and wether some libs are`nt used at all Kind regards, Norbert On Tue, 1 Nov 2016 08:25:08 +0100 Sylvestre Ledru wrote: > Hello > > Thanks for the patch. How do I test this change from the user perspective? > > Thanks > Sylvestre > > Le 1 nov. 2016 00:56, "Lange Norbert" a écrit : > > > Hello, > > > > I don`t know if the docker installation got messed up (different so > > versions than on my native system), but the dh_shlibdeps step won`t find > > the correct packages for some 32bit libraries. > > In case some packages wont build, those errors could be ignored. > > > > > > diff -burN debian.org/control debian/control > > --- debian.org/control 2016-10-31 23:33:26.307560672 +0100 > > +++ debian/control 2016-10-31 23:36:29.861497749 +0100 > > @@ -7,7 +7,7 @@ > > cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= > > 3.0.9), > > lsb-release, patchutils, diffstat, xz-utils, python-dev, > > libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev, > > -libjsoncpp-dev, > > +libjsoncpp-dev, g++-multilib, > > lcov, procps, help2man, dh-ocaml, zlib1g-dev > > Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, > > libllvm-3.5-ocaml-dev, > >libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev > > diff -burN debian.org/rules debian/rules > > --- debian.org/rules2016-10-31 23:33:26.307560672 +0100 > > +++ debian/rules2016-11-01 00:48:08.022283769 +0100 > > @@ -400,7 +400,7 @@ > > > > > > override_dh_shlibdeps: > > - > > LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ > > dh_shlibdeps > > + dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- > > --ignore-missing-info > > > > override_dh_installman: > > dh_installman > > > > > > Von: Lange Norbert > > Gesendet: Montag, 31. Oktober 2016 23:58 > > An: Sylvestre Ledru; 841...@bugs.debian.org > > Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib > > binaries > > > > Hi, > > > > patch is attached. I tested a clean docker installation of debian-testing, > > adding this dependency generates the additional libraries. > > Having those built once via the debian build machinery should give us an > > idea which subtypes are supported, and wether it crashes and burns an some > > systems (looking at gcc-6 source package theres alot arch.dependend testclang.sh Description: Bourne shell script
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
On Mon, 31 Oct 2016 08:38:21 +0100 Sylvestre Ledru wrote:
> Le 31/10/2016 à 00:39, Norbert Lange a écrit :
> > Package: clang-3.9
> > Version: 1:3.9-2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > The memory sanitizer is unusable as it segfaults during initialization.
> > To reproduce:
> > echo 'int main() { return 0; }' >/tmp/test.c
> > clang -fsanitize=memory -o test test.c
> can you try with clang-3.9 instead?
Same thing, output:
$ clang-3.9 -fsanitize=memory -o test test.c -v
clang version 3.9.0-2 (tags/RELEASE_390/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.2.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
"/usr/lib/llvm-3.9/bin/clang" -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name test.c -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem
/usr/include -fdebug-compilation-dir /tmp -ferror-limit 19
-fmessage-length 135 -fsanitize=memory
-fsanitize-blacklist=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/msan_blacklist.txt
-fno-assume-sane-operator-new -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-2d4d2c.o -x
c test.c
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target
x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
"/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu/crt1.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu/crti.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/crtbegin.o
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../..
-L/usr/lib/llvm-3.9/bin/../lib -L/lib -L/usr/lib -whole-archive
/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.msan-x86_64.a
-no-whole-archive
--dynamic-list=/usr/lib/llvm-3.9/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.msan-x86_64.a.syms
/tmp/test-2d4d2c.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/crtend.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.2.0/../../../x86_64-linux-gnu/crtn.o
Bug#842642: clang-3.9: memory sanitizer segfaults immediately
Package: clang-3.9
Version: 1:3.9-2
Severity: normal
Dear Maintainer,
The memory sanitizer is unusable as it segfaults during initialization.
To reproduce:
echo 'int main() { return 0; }' >/tmp/test.c
clang -fsanitize=memory -o test test.c
./test
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages clang-3.9 depends on:
ii binutils 2.27-9+b1
ii libc62.24-5
ii libc6-dev2.24-5
ii libclang-common-3.9-dev 1:3.9-2
ii libclang1-3.91:3.9-2
ii libgcc-6-dev 6.2.0-9
ii libgcc1 1:6.2.0-9
ii libjsoncpp1 1.7.4-3
ii libllvm3.9 1:3.9-2
ii libobjc-6-dev6.2.0-9
ii libstdc++-6-dev 6.2.0-9
ii libstdc++6 6.2.0-9
Versions of packages clang-3.9 recommends:
pn llvm-3.9-dev
ii python2.7.11-2
Versions of packages clang-3.9 suggests:
pn clang-3.9-doc
pn gnustep
pn gnustep-devel
-- no debconf information
Bug#841923: libclang-common-3.9-dev: missing multilib binaries
Package: libclang-common-3.9-dev Version: 1:3.9-2 Severity: important Dear Maintainer, On plattforms such as amd64, the libraries necessary to build for other architectures (i386 in this case) are missing. A local build of the package will however result in those libraries beeing built and packaged, so I believe that the build-depencies for creating the libraries are missing (g++multilib?) and the lvvm build will just silently skip over the libraries it can`t build (this bug is going back to atleast llvm 3.7) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libclang-common-3.9-dev depends on: ii libc6 2.24-5 ii libgcc1 1:6.2.0-6 ii libllvm3.9 1:3.9-2 ii libstdc++6 6.2.0-6 ii libtinfo5 6.0+20160917-1 ii zlib1g 1:1.2.8.dfsg-2+b1 libclang-common-3.9-dev recommends no packages. libclang-common-3.9-dev suggests no packages. -- no debconf information
Bug#832753: coreutils: stdbuf is not usable for multiarch tools (eg. i386 on amd64)
I think you are making this more complicated than it needs to be.
First, if we start asking how often is it needed... I doubt often, but
I never ever needed stdbuf before and now it doesnt work for 100% of
my needs.
A bugreport shouldnt be the place to discuss this, but its a
limitation of a tool that IMHO isnt necessary.
To your solution:
LD_PRELOAD_{32,64} is not an option since its not supported on debian
(Jessie atleast). A elegant soluton would be to drop the path and
install the libraries to
the correct multilib locations:
/usr/lib/i386-linux-gnu/libstdbuf.so
/usr/lib/x86_64-linux-gnu/libstdbuf.so
This would naturally extend to further architectures (x32?, even
cross-emulation one day?)
Also I wouldnt even bother with even cross-compiling.
Just split the library to its own "libstdbuf" package, and add this as
dependency for coreutils.
Then change the stdbuf tool to set LD_PRELOAD=libstdbuf.so
Installing coreutils will only install the native (64bit) library,
after installing libstdbuf:i386 (or x32) the tool will
automatically pick the right dll for all architectures.
coreutils:amd64
/usr/lib/i386-linux-gnu/libstdbuf.so (libstdbuf:i386)
/usr/lib/x86_64-linux-gnu/libstdbuf.so (libstdbuf:amd64)
Doesnt sound like a big deal to me, and this is pretty much a packaging thing.
Doubt you need to change a single bit in autotools.
2016-07-28 16:53 GMT+02:00 Pádraig Brady :
> On 28/07/16 15:20, Norbert Lange wrote:
>> Package: coreutils
>> Version: 8.25-2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I am trying to use stdbuf tool on a 32bit Binary, this will result
>> in a failure:
>>
>> ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/coreutils/libstdbuf.so' from
>> LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>
>> To make this work seemlessly,
>> LD_PRELOAD would need to be used with the plain library libstdbuf.so
>> and the library would need to be installed in the proper locations
>> for 64 and 32bit.
>>
>> Likely this would mean using a seperate binary package for the library to
>> allow co-installing both?
>
> Notes on this upstream at http://bugs.gnu.org/8960
>
> Stuff I noted previously...
>
> You can't install coreutils 32 bit and 64 bit together,
> so to support this the libs would need to be separated out to a separate
> package.
> I.E. one would have a coreutils package that depended on
> coreutils-lib.i686 and coreutils-lib.x86_64, which would
> install to /usr/lib{,64}/coreutils/libstbuf.so respectively.
> Then you would have the flexibility to set both LD_PRELOAD_{32,64}
>
> Currently we don't support separate (per arch) libs because of:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e23f1795
> So we'd have to revert that essentially as automake
> is too restrictive here and may support the orig var in newer versions?
>
> We might also have to adjust setting of PKGLIBEXECDIR at build time?
>
> Is this complexity worth it? How often does 64 bit coreutils
> need to control buffering for 32 bit programs?
> We've not been asked for that flexibility at present.
>
Bug#832753: coreutils: stdbuf is not usable for multiarch tools (eg. i386 on amd64)
Package: coreutils Version: 8.25-2 Severity: normal Dear Maintainer, I am trying to use stdbuf tool on a 32bit Binary, this will result in a failure: ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/coreutils/libstdbuf.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. To make this work seemlessly, LD_PRELOAD would need to be used with the plain library libstdbuf.so and the library would need to be installed in the proper locations for 64 and 32bit. Likely this would mean using a seperate binary package for the library to allow co-installing both? -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages coreutils depends on: ii libacl12.2.52-2 ii libattr1 1:2.4.47-2 ii libc6 2.19-18+deb8u4 ii libselinux12.3-2 ii multiarch-support 2.19-18+deb8u4 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#829441: Package cant be installed for multiple archs (eg. amd64 and i386)
Package: libclang-common-3.8-dev
Version: 1:3.8.1-2
Hello,
this is a continuation of Bug Report 771380 (since I dont think it
will be fixed back there).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771380
The issue is that you can only install 1 architecture version of the
libraries, producing an i386 executable with sanitizer or rt library
would need the i386 version installed - this is not possible, atleast
nor as long the amd64 version is installed.
The solution is to split up the architecture-dependend files into a
own package and set the multiarch flags correctly.
I did a patch to demonstrate this, I am sure you might find better names.
Thus, installing clang with the i386 libraries could be done simpy by:
apt-get install clang-3.8 libclang-common-3.8-dev:i386
Kind Regards,
Norbert
diff -burN oldfiles/control newfiles/control
--- oldfiles/control 2016-06-30 14:52:42.0 +0200
+++ newfiles/control 2016-07-02 23:47:15.050271000 +0200
@@ -141,9 +141,10 @@
Package: libclang-common-3.8-dev
Architecture: any
+Multi-Arch: same
Section: libdevel
-Depends: ${shlibs:Depends}, ${misc:Depends}, libllvm3.8 (= ${binary:Version})
-Description: clang library - Common development package
+Depends: ${shlibs:Depends}, ${misc:Depends}, libllvm3.8 (= ${binary:Version}), libclang-headers-3.8-dev (= ${binary:Version})
+Description: clang library - Common development libraries
Clang project is a C, C++, Objective C and Objective C++ front-end
for the LLVM compiler. Its goal is to offer a replacement to the GNU Compiler
Collection (GCC).
@@ -152,9 +153,24 @@
well as the upcoming C++14 standard, and some parts of the fledgling C++1z
standard, and is considered a production-quality C++ compiler.
.
- This package contains the clang generic headers and some libraries
+ This package contains the static clang target libraries
(profiling, etc).
+Package: libclang-headers-3.8-dev
+Architecture: all
+Multi-Arch: foreign
+Section: libdevel
+Depends: ${shlibs:Depends}, ${misc:Depends}, libllvm3.8 (= ${binary:Version})
+Description: clang library - Common development headers
+ Clang project is a C, C++, Objective C and Objective C++ front-end
+ for the LLVM compiler. Its goal is to offer a replacement to the GNU Compiler
+ Collection (GCC).
+ .
+ Clang fully implements all published ISO C++ standards including C++11, as
+ well as the upcoming C++14 standard, and some parts of the fledgling C++1z
+ standard, and is considered a production-quality C++ compiler.
+ .
+ This package contains the clang generic headers
Package: python-clang-3.8
Section: python
diff -burN oldfiles/libclang-common-X.Y-dev.install.in newfiles/libclang-common-X.Y-dev.install.in
--- oldfiles/libclang-common-X.Y-dev.install.in 2016-03-04 17:55:18.0 +0100
+++ newfiles/libclang-common-X.Y-dev.install.in 2016-07-02 23:23:33.0 +0200
@@ -1,7 +1,7 @@
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include
+#usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include
usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/lib
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/*.txt
+#usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/*.txt
#usr/lib/clang/@LLVM_VERSION_FULL@/lib /usr/lib/clang/@LLVM_VERSION@/
#usr/lib/clang/@LLVM_VERSION_FULL@/include/ /usr/include/clang/@LLVM_VERSION@/
diff -burN oldfiles/libclang-common-X.Y-dev.links.in newfiles/libclang-common-X.Y-dev.links.in
--- oldfiles/libclang-common-X.Y-dev.links.in 2016-03-04 17:55:18.0 +0100
+++ newfiles/libclang-common-X.Y-dev.links.in 1970-01-01 01:00:00.0 +0100
@@ -1,7 +0,0 @@
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include usr/include/clang/@LLVM_VERSION@/include
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include usr/lib/clang/@LLVM_VERSION@/include
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/lib usr/lib/clang/@LLVM_VERSION@/lib
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include usr/include/clang/@LLVM_VERSION_FULL@/include
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include usr/lib/clang/@LLVM_VERSION_FULL@/include
-usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/lib usr/lib/clang/@LLVM_VERSION_FULL@/lib
-
diff -burN oldfiles/libclang-headers-X.Y-dev.install.in newfiles/libclang-headers-X.Y-dev.install.in
--- oldfiles/libclang-headers-X.Y-dev.install.in 1970-01-01 01:00:00.0 +0100
+++ newfiles/libclang-headers-X.Y-dev.install.in 2016-07-03 01:26:04.901696000 +0200
@@ -0,0 +1,7 @@
+usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/include
+
+#usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/lib
+usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/*.txt
+
+#usr/lib/clang/@LLVM_VERSION_FULL@/lib /usr/lib/clang/@LLVM_VERSION@/
+#usr/lib/clang/@LLVM_VERSION_FULL@/include/ /usr/include/clang/@LLVM_VERSION@/
diff -burN oldfiles/libclang-headers-
Bug#807174: u-boot-tools: Please provide the dumpbin binary
Yes, thats fine. Took me a while to find the correct git branch ;) Thanks, Norbert 2015-12-10 8:50 GMT+01:00 Vagrant Cascadian : > Control: tags 807174 pending > > On 2015-12-06, Norbert Lange wrote: >> please provide the dumpbin binary with the package. >> its a usefull companion to the mkimage tool, for our case >> we could grab usefull information embedded within a binary >> with a script. > > I've included the dumpimage command in the package in git. Hopefully > that will do what you were looking for. > > > live well, > vagrant
