Bug#1003168: qemu-user-static: fails to run lyx user directory configuation
Control: tag -1 + moreinfo Ok. This one, just like the other bug of this theme (#999421), seems to be fixed in current qemu (7.1) in bookworm. At least I can't reproduce it anymore, and our reproducer (lyx install) succeeds now. Andreas, can you verify it is fixed for you? From the previous info, it looks like some wrong syscall emulation has been fixed since. Thanks, /mjt
Bug#999421: qemu-user-static: lli-13/arm64 causes segfault on amd64 host
Control: tag -1 + moreinfo So, it looks like this issue has been fixed now with current qemu 7.1 (and with current clang from unstable, 13.0.1-9). Andreas, can you verify it is fixed for you please? Thanks! /mjt
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
On 03/12/22 12:48 pm, Shengjing Zhu wrote: On Sat, Dec 3, 2022 at 2:00 AM Pirate Praveen wrote: [...] src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2: cannot find package "github.com/cespare/xxhash/v2" in any of: /<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2 (vendor tree) /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from $GOROOT) /<>/_build/src/github.com/cespare/xxhash/v2 (from $GOPATH even though golang-github-cespare-xxhash-dev is installed. I think the import path and binary package name should be bumped to match go.mod: module github.com/cespare/xxhash/v2 so binary package should be golang-github-cespare-xxhash-v2-dev. Though I'm not 100% sure about the XS-Go-Import-Path as I think it should match without a change there. No. The Go compiler can find it automatically. Please see the detail at https://lists.debian.org/debian-go/2020/06/msg9.html I think you may have done some non-standard magic in your package. I just vendored some dependencies till protobuf 1.5 vs 1.3 settle down. So from a vendored module, it is not able to find this module. I don't think this is cause. For example, golang-k8s-klog is also a v2 module, and it doesn't have v2 in XS-Go-Import-Path. But packages which have vendor library which uses that v2 path, can be built successfully. For example, https://sources.debian.org/src/containerd/1.6.9~ds1-1/vendor/k8s.io/client-go/rest/request.go/#L48 You can reproduce this issue with https://salsa.debian.org/ruby-team/gitlab/ (after uncommenting the manual v2 in rules). https://people.debian.org/~praveen/staging/ has newer build depends (gitaly and gitlab-labkit) OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1025362: libapache2-mod-authn-sasl FTCBFS: fails running apache2
Source: libapache2-mod-authn-sasl Version: 1.2-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs libapache2-mod-authn-sasl fails to cross build from source, because it gets a host architecture apache2-bin and thus fails running it. It also cannot be marked Multi-Arch: foreign due to loadable module support. As such, the dependency should likely be :native. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru libapache2-mod-authn-sasl-1.2/debian/changelog libapache2-mod-authn-sasl-1.2/debian/changelog --- libapache2-mod-authn-sasl-1.2/debian/changelog 2013-06-15 16:49:57.0 +0200 +++ libapache2-mod-authn-sasl-1.2/debian/changelog 2022-12-02 15:33:19.0 +0100 @@ -1,3 +1,10 @@ +libapache2-mod-authn-sasl (1.2-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Depend on a native apache2-bin. (Closes: #-1) + + -- Helmut Grohne Fri, 02 Dec 2022 15:33:19 +0100 + libapache2-mod-authn-sasl (1.2-2) unstable; urgency=low * Preparing Apache2.4 transition (Closes: #666840). diff --minimal -Nru libapache2-mod-authn-sasl-1.2/debian/control libapache2-mod-authn-sasl-1.2/debian/control --- libapache2-mod-authn-sasl-1.2/debian/control2013-06-15 17:20:31.0 +0200 +++ libapache2-mod-authn-sasl-1.2/debian/control2022-12-02 15:33:18.0 +0100 @@ -4,7 +4,7 @@ Maintainer: Ulises Vitulli Uploaders: Rene Mayorga Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 7), autotools-dev, apache2-dev, - libsasl2-dev, libtool, apache2-bin + libsasl2-dev, libtool, apache2-bin:native Standards-Version: 3.9.4 Homepage: http://mod-authn-sasl.sourceforge.net/
Bug#1025361: netavark FTCBFS: can't find crate for `core`
Source: netavark
Version: 1.0.3-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
netavark fails to cross build from source. A build ends with:
| Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=cfg_if
CARGO_MANIFEST_DIR=/<>/debian/cargo_registry/cfg-if-1.0.0
CARGO_PKG_AUTHORS='Alex Crichton '
CARGO_PKG_DESCRIPTION='A macro to ergonomically define an item depending on a
large number of #[cfg]
| parameters. Structured like an if-else chain, the first matching branch is the
| item that gets emitted.
| ' CARGO_PKG_HOMEPAGE='https://github.com/alexcrichton/cfg-if'
CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE=''
CARGO_PKG_NAME=cfg-if
CARGO_PKG_REPOSITORY='https://github.com/alexcrichton/cfg-if'
CARGO_PKG_VERSION=1.0.0 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=0
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE=''
LD_LIBRARY_PATH='/<>/target/release/deps:/usr/lib' rustc
--crate-name cfg_if --edition=2018
/<>/debian/cargo_registry/cfg-if-1.0.0/src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat
--crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C
embed-bitcode=no -C metadata=df2022695625b25e -C
extra-filename=-df2022695625b25e --out-dir
/<>/target/armv7-unknown-linux-gnueabihf/release/deps --target
armv7-unknown-linux-gnueabihf -L
dependency=/<>/target/armv7-unknown-linux-gnueabihf/release/deps
-L dependency=/<>/target/release/deps --cap-lints warn -C
debuginfo=2 --cap-lints warn -C linker=arm-linux-gnueabihf-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix
/<>=/usr/share/cargo/registry/netavark-1.0.3 --remap-path-prefix
/<>/debian/cargo_registry=/usr/share/cargo/registry`
| error[E0463]: can't find crate for `core`
| |
| = note: the `armv7-unknown-linux-gnueabihf` target may not be installed
| = help: consider downloading the target with `rustup target add
armv7-unknown-linux-gnueabihf`
|
| error[E0463]: can't find crate for `compiler_builtins`
|
| For more information about this error, try `rustc --explain E0463`.
| error: could not compile `cfg-if` due to 2 previous errors
|
| Caused by:
| process didn't exit successfully: `CARGO=/usr/bin/cargo
CARGO_CRATE_NAME=cfg_if
CARGO_MANIFEST_DIR=/<>/debian/cargo_registry/cfg-if-1.0.0
CARGO_PKG_AUTHORS='Alex Crichton '
CARGO_PKG_DESCRIPTION='A macro to ergonomically define an item depending on a
large number of #[cfg]
| parameters. Structured like an if-else chain, the first matching branch is
the
| item that gets emitted.
| ' CARGO_PKG_HOMEPAGE='https://github.com/alexcrichton/cfg-if'
CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE=''
CARGO_PKG_NAME=cfg-if
CARGO_PKG_REPOSITORY='https://github.com/alexcrichton/cfg-if'
CARGO_PKG_VERSION=1.0.0 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=0
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE=''
LD_LIBRARY_PATH='/<>/target/release/deps:/usr/lib' rustc
--crate-name cfg_if --edition=2018
/<>/debian/cargo_registry/cfg-if-1.0.0/src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat
--crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C
embed-bitcode=no -C metadata=df2022695625b25e -C
extra-filename=-df2022695625b25e --out-dir
/<>/target/armv7-unknown-linux-gnueabihf/release/deps --target
armv7-unknown-linux-gnueabihf -L
dependency=/<>/target/armv7-unknown-linux-gnueabihf/release/deps
-L dependency=/<>/target/release/deps --cap-lints warn -C
debuginfo=2 --cap-lints warn -C linker=arm-linux-gnueabihf-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix
/<>=/usr/share/cargo/registry/netavark-1.0.3 --remap-path-prefix
/<>/debian/cargo_registry=/usr/share/cargo/registry` (exit status:
1)
| error: failed to compile `netavark v1.0.3 (/<>)`, intermediate
artifacts can be found at `/<>/target`
| Traceback (most recent call last):
| File "/usr/share/cargo/bin/cargo", line 241, in
| sys.exit(main(*sys.argv[1:]))
| File "/usr/share/cargo/bin/cargo", line 231, in main
| return install(os.getenv("DESTDIR", ""),
| File "/usr/share/cargo/bin/cargo", line 134, in install
| logrun(["env", "RUST_BACKTRACE=1",
| File "/usr/share/cargo/bin/cargo", line 76, in logrun
| return subprocess.run(*args, **kwargs)
| File "/usr/lib/python3.10/subprocess.py", line 526, in run
| raise CalledProcessError(retcode, process.args,
| subprocess.CalledProcessError: Command '['env', 'RUST_BACKTRACE=1',
'CARGO_TARGET_DIR=/<>/target', '/usr/bin/cargo',
'-Zavoid-dev-deps', 'install', '--verbose', '--verbose', '-j1', '--target',
'armv7-unknown-linux-gnueabihf', '--path', '/<>', '--root',
'debian/netavark/usr']' returned non-zero exit status 101.
| dh_auto_install: error: env DESTDIR=debian/netavark
/usr/share/cargo/bin/cargo install returned exit code 1
| make: *** [debian/rules:8: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
I looked into this and wondered why
Bug#1025360: guetzli FTCBFS: hard codes the build architecture pkg-config
Source: guetzli Version: 1.0.1-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs guetzli fails to cross build from source, because it hard codes the build architecture pkg-config and thus fails locating libpng. I'm attaching a patch for your convenience. Helmut --- guetzli-1.0.1.orig/guetzli.make +++ guetzli-1.0.1/guetzli.make @@ -10,6 +10,8 @@ .PHONY: clean prebuild prelink +PKG_CONFIG ?= pkg-config + ifeq ($(config),release) RESCOMP = windres TARGETDIR = bin/Release @@ -19,12 +21,12 @@ INCLUDES += -I. -Ithird_party/butteraugli FORCE_INCLUDE += ALL_CPPFLAGS += $(CPPFLAGS) -MMD -MP $(DEFINES) $(INCLUDES) - ALL_CFLAGS += $(CFLAGS) $(ALL_CPPFLAGS) -O3 -g `pkg-config --cflags libpng` - ALL_CXXFLAGS += $(CXXFLAGS) $(ALL_CPPFLAGS) -O3 -g -std=c++11 `pkg-config --cflags libpng` + ALL_CFLAGS += $(CFLAGS) $(ALL_CPPFLAGS) -O3 -g `$(PKG_CONFIG) --cflags libpng` + ALL_CXXFLAGS += $(CXXFLAGS) $(ALL_CPPFLAGS) -O3 -g -std=c++11 `$(PKG_CONFIG) --cflags libpng` ALL_RESFLAGS += $(RESFLAGS) $(DEFINES) $(INCLUDES) LIBS += LDDEPS += - ALL_LDFLAGS += $(LDFLAGS) `pkg-config --libs libpng` + ALL_LDFLAGS += $(LDFLAGS) `$(PKG_CONFIG) --libs libpng` LINKCMD = $(CXX) -o "$@" $(OBJECTS) $(RESOURCES) $(ALL_LDFLAGS) $(LIBS) define PREBUILDCMDS endef @@ -46,12 +48,12 @@ INCLUDES += -I. -Ithird_party/butteraugli FORCE_INCLUDE += ALL_CPPFLAGS += $(CPPFLAGS) -MMD -MP $(DEFINES) $(INCLUDES) - ALL_CFLAGS += $(CFLAGS) $(ALL_CPPFLAGS) -g `pkg-config --cflags libpng` - ALL_CXXFLAGS += $(CXXFLAGS) $(ALL_CPPFLAGS) -g -std=c++11 `pkg-config --cflags libpng` + ALL_CFLAGS += $(CFLAGS) $(ALL_CPPFLAGS) -g `$(PKG_CONFIG) --cflags libpng` + ALL_CXXFLAGS += $(CXXFLAGS) $(ALL_CPPFLAGS) -g -std=c++11 `$(PKG_CONFIG) --cflags libpng` ALL_RESFLAGS += $(RESFLAGS) $(DEFINES) $(INCLUDES) LIBS += LDDEPS += - ALL_LDFLAGS += $(LDFLAGS) `pkg-config --libs libpng` + ALL_LDFLAGS += $(LDFLAGS) `$(PKG_CONFIG) --libs libpng` LINKCMD = $(CXX) -o "$@" $(OBJECTS) $(RESOURCES) $(ALL_LDFLAGS) $(LIBS) define PREBUILDCMDS endef @@ -210,4 +212,4 @@ -include $(OBJECTS:%.o=%.d) ifneq (,$(PCH)) -include $(OBJDIR)/$(notdir $(PCH)).d -endif \ No newline at end of file +endif
Bug#1025359: grandorgue FTCBFS: needs to build build tools separately
Source: grandorgue Version: 3.9.1-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs grandorgue fails to cross build from source. The upstream documentation describes special steps needed for cross compilation, but the packaging does not implement them. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru grandorgue-3.9.1/debian/changelog grandorgue-3.9.1/debian/changelog --- grandorgue-3.9.1/debian/changelog 2022-11-20 22:28:05.0 +0100 +++ grandorgue-3.9.1/debian/changelog 2022-12-02 07:17:13.0 +0100 @@ -1,3 +1,10 @@ +grandorgue (3.9.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Build build tools natively. (Closes: #-1) + + -- Helmut Grohne Fri, 02 Dec 2022 07:17:13 +0100 + grandorgue (3.9.1-1) unstable; urgency=medium * New upstream version 3.9.1 diff --minimal -Nru grandorgue-3.9.1/debian/clean grandorgue-3.9.1/debian/clean --- grandorgue-3.9.1/debian/clean 1970-01-01 01:00:00.0 +0100 +++ grandorgue-3.9.1/debian/clean 2022-12-02 07:17:09.0 +0100 @@ -0,0 +1 @@ +build-tools diff --minimal -Nru grandorgue-3.9.1/debian/rules grandorgue-3.9.1/debian/rules --- grandorgue-3.9.1/debian/rules 2022-04-17 20:37:16.0 +0200 +++ grandorgue-3.9.1/debian/rules 2022-12-02 07:17:13.0 +0100 @@ -4,4 +4,8 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- -DUSE_INTERNAL_RTAUDIO=OFF -DUSE_INTERNAL_PORTAUDIO=OFF -DUSE_INTERNAL_ZITACONVOLVER=OFF -DBUILD_VERSION=debian +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) + dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure --builddirectory=build-tools --sourcedirectory=src/build + dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build --builddirectory=build-tools --sourcedirectory=src/build +endif + dh_auto_configure -- -DUSE_INTERNAL_RTAUDIO=OFF -DUSE_INTERNAL_PORTAUDIO=OFF -DUSE_INTERNAL_ZITACONVOLVER=OFF -DBUILD_VERSION=debian $(if $(filter $(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,-DIMPORT_EXECUTABLES=$(CURDIR)/build-tools/ImportExecutables.cmake)
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
On Sat, Dec 3, 2022 at 2:00 AM Pirate Praveen wrote: [...] > >> src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2: > >> cannot find package "github.com/cespare/xxhash/v2" in any of: > >> > >> > >> /<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2 > >> (vendor tree) > >> /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from > >> $GOROOT) > >> /<>/_build/src/github.com/cespare/xxhash/v2 > >> (from > >> $GOPATH > >> > >> even though golang-github-cespare-xxhash-dev is installed. > >> > >> I think the import path and binary package name should be bumped to > >> match go.mod: > >> module github.com/cespare/xxhash/v2 > >> > >> so binary package should be golang-github-cespare-xxhash-v2-dev. > >> Though > >> I'm not 100% sure about the XS-Go-Import-Path as I think it should > >> match without a change there. > > > > No. The Go compiler can find it automatically. Please see the detail > > at > > > > https://lists.debian.org/debian-go/2020/06/msg9.html > > > > I think you may have done some non-standard magic in your package. > > > > I just vendored some dependencies till protobuf 1.5 vs 1.3 settle down. > So from a vendored module, it is not able to find this module. > I don't think this is cause. For example, golang-k8s-klog is also a v2 module, and it doesn't have v2 in XS-Go-Import-Path. But packages which have vendor library which uses that v2 path, can be built successfully. For example, https://sources.debian.org/src/containerd/1.6.9~ds1-1/vendor/k8s.io/client-go/rest/request.go/#L48 -- Shengjing Zhu
Bug#1004275: php upgrade apache2: After upgrade php install apache2 and i have intalled lighttpd
Control: close -1 Hi, this is the usual - pay attention what you are doing. And uninstall `php` and `phpX.Y` packages. The apt dependency solver doesn’t know that you are using lighttpd and it picks the first alternative to fulfill the dependency for the above. If you install just the package for the SAPI you are using it’s going to be fine. Ondřej -- Ondřej Surý (He/Him) > On 2. 12. 2022, at 22:42, Hendrik Jäger wrote: > > Control: tags -1 moreinfo > Control: reassign php > > Hi > > Thank you for your report. > >> On Mon, 24 Jan 2022 01:33:24 +0100 wrote: >> After apt update & upgrade a new php update appear but the upgrade also >> installed apache2. > > Can you provide a log of your commands and outputs? > Which php package(s) were updated from which version to which version? > >> I am running lighttpd server and apache2 it's not neccesary on my system. > > Makes sense. Which version of lighthttpd is installed? > > I’m reassigning this package to php, exclusively, because I don’t think any > change in the apache2 package(s) can fix the issue. > > Cheers > > henk >
Bug#1025358: src:python-xarray: fails to migrate to testing for too long: autopkgtest regression
Source: python-xarray Version: 2022.06.0-7 Severity: serious Control: close -1 2022.11.0-2 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:python-xarray has been trying to migrate for 61 days [2]. Hence, I am filing this bug. One of the recent version of your package caused its autopkgtest to fail everywhere. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=python-xarray OpenPGP_signature Description: OpenPGP digital signature
Bug#1025357: src:jbigkit: fails to migrate to testing for too long: autopkgtest regression
Source: jbigkit Version: 2.1-3.1 Severity: serious Control: close -1 2.1-6 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1023710 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:jbigkit has been trying to migrate for 61 days [2]. Hence, I am filing this bug. The new version of your package caused an autopkgtest regression which I reported in bug 1023710. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=jbigkit OpenPGP_signature Description: OpenPGP digital signature
Bug#1025324: libc6: Xserver with nouveau not workiing.
Hi all, Also hit by this problem (intel i5 box). Noticed that Xorg log showing the error is very similar to what is seen in #1025312 [libgl1-mesa-dri: multiple packages FTBFS and have autopkgtest regressions running test programs under Xvfb] Regards, -- Agustin
Bug#1025259: Bug#1025196: zfp: (autopkgtest) needs update for python3.11: No module named 'zfpy'
Il 02/12/22 09:59, Jochen Sprickerhof ha scritto: Control: tags -1 + patch Hi Antonio, * Antonio Valentino [2022-12-02 07:56]: We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of zfp fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: pass fail python3-defaults from testing 3.10.6-3 zfp from testing 1.0.0-3 all others from testing from testing [...] the problem is due to the fact that out d/rules only build builds the Python extension for the default python version (3.10 currently). IMHO the solution is configure/build twice with cmake in order to have the Python extension for all the supported Python versions. If it is OK for you, I plan to work on it during the weekend. If you have an better solution or can point me to a package that faced the same issue please let me know. pybuild has support for this, I've attached a patch. Note that There is no need to pass -DCMAKE_BUILD_TYPE=RelWithDebInfo to cmake as debhelper does the right thing already. Thanks Jochen -- Antonio Valentino
Bug#1017881: ITA: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes
Hello, On Fri 02 Dec 2022 at 06:10PM -08, Stefan Kangas wrote: > I'm still working on it. I have run into a boring problem where my > packages are building correctly, but no longer being signed for some > reason. I think I accidentally broke something related to cowbuilder, > or something like that. As soon as I can fix it, I will upload the new > package to mentors.d.n. I only sponsor out of git, I don't need any .dscs :) So, it's ready? -- Sean Whitton signature.asc Description: PGP signature
Bug#1025356: reportbug: leaves tempfiles around
Package: reportbug Version: 7.10.3+deb11u1 Severity: minor X-Debbugs-Cc: t...@mirbsd.de reportbug leaves 0-length files around in /var/tmp/ (the persistent temporary file storage), which needs not be. Incidentally, it also leaves copies of the sent reports around, but in /tmp/ which may be on a ramdisc and which, iff leaving around at all, I’d have expected on /var/tmp/ instead (especially during composition time, i.e. before sending). Might want to move that. -- Package-specific info: ** Environment settings: EDITOR="/usr/bin/sensible-editor" VISUAL="/usr/bin/jupp" DEBEMAIL="Thorsten Glaser " INTERFACE="text" ** /home/tglase/.reportbugrc: reportbug_version "7.10.3+deb11u1" mode advanced ui text no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages reportbug depends on: ii apt2.2.4 ii python33.9.2-3 ii python3-reportbug 7.10.3+deb11u1 ii sensible-utils 0.0.14 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils ii debsums 3.0.2 pn dlocate pn emacs-bin-common ii file1:5.39-3 ii gnupg 2.2.27-2+deb11u2 ii postfix [mail-transport-agent] 3.5.13-0+deb11u1 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.2.4 ii file 1:5.39-3 ii python33.9.2-3 ii python3-apt2.2.1 ii python3-debian 0.1.39 ii python3-debianbts 3.1.0 ii python3-requests 2.25.1+dfsg-2 ii sensible-utils 0.0.14 python3-reportbug suggests no packages. -- no debconf information
Bug#1025355: lintian: check for non-breaking-space chars in name part of Maintainer/Uploaders fields
Package: lintian
Severity: wishlist
The name part of the Maintainer field for the emacs-cmake-mode package
currently contains non-breaking-space characters instead of spaces.
This has been reported against emacs-cmake-mode as bug report #1025354.
This is unlikely to break any Debian package infrastructure, but it
does mean that naive validation of the Maintainer field will error,
for example the DDPO cron job Maintainer check regex uses spaces
and generates a warning mail when the regex does not match.
The Maintainer field and each item of the Uploaders field should be
checked in both source and binary Debian packages.
Please add a check to prevent this from happening in future.
$ apt-cache showsrc emacs-cmake-mode | sed -n 's/Maintainer: //p' | sort -u
| tee /dev/stderr | tr -d -- '-@<>.a-zA-Z ' | xargs -d '\n' unicode --brief
Debian Emacsen team
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
$ apt-cache show elpa-cmake-mode | sed -n 's/Maintainer: //p' | sort -u |
tee /dev/stderr | tr -d -- '-@<>.a-zA-Z ' | xargs -d '\n' unicode --brief
Debian Emacsen team
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
$ /srv/qa.debian.org/data/cronjobs/ddpo
/srv/qa.debian.org/ftp/debian/dists/unstable/main/source/Sources.xz:0:
syntax error in emacs-cmake-mode Maintainer: Debian Emacsen team
at ../extract_archive.pl line 101.
/srv/qa.debian.org/ftp/debian/dists/testing/main/source/Sources.xz:0: syntax
error in emacs-cmake-mode Maintainer: Debian Emacsen team
at ../extract_archive.pl line 101.
$ grep warn.*error /srv/qa.debian.org/data/ddpo/extract_archive.pl
$pkgdata{$package}->{maintainer} =~ /(.+) <(.+)>/ or warn
"$fname:$.: syntax error in $package Maintainer:
$pkgdata{$package}->{maintainer}";
$uploader =~ /(.+) <(.+)>/ or warn "$fname:$.:
syntax error in $package Uploaders: $uploader";
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#1025354: emacs-cmake-mode: non-breaking-space chars in name part of Maintainer field
Source: emacs-cmake-mode
Version: 3.25.0+ds-2
Severity: important
The name part of the Maintainer field for the emacs-cmake-mode package
currently contains non-breaking-space characters instead of spaces.
This is unlikely to break any Debian package infrastructure, but it
does mean that naive validation of the Maintainer field will error,
for example the DDPO cron job Maintainer check regex uses spaces
and generates a warning mail when the regex does not match.
Please fix the space characters so QA folks no longer get cron mail.
$ apt-cache showsrc emacs-cmake-mode | sed -n 's/Maintainer: //p' | sort -u |
tee /dev/stderr | tr -d -- '-@<>.a-zA-Z ' | xargs -d '\n' unicode --brief
Debian Emacsen team
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
$ apt-cache show elpa-cmake-mode | sed -n 's/Maintainer: //p' | sort -u | tee
/dev/stderr | tr -d -- '-@<>.a-zA-Z ' | xargs -d '\n' unicode --brief
Debian Emacsen team
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
$ /srv/qa.debian.org/data/cronjobs/ddpo
/srv/qa.debian.org/ftp/debian/dists/unstable/main/source/Sources.xz:0: syntax
error in emacs-cmake-mode Maintainer: Debian Emacsen team
at ../extract_archive.pl line 101.
/srv/qa.debian.org/ftp/debian/dists/testing/main/source/Sources.xz:0: syntax
error in emacs-cmake-mode Maintainer: Debian Emacsen team
at ../extract_archive.pl line 101.
$ grep warn.*error /srv/qa.debian.org/data/ddpo/extract_archive.pl
$pkgdata{$package}->{maintainer} =~ /(.+) <(.+)>/ or warn "$fname:$.:
syntax error in $package Maintainer: $pkgdata{$package}->{maintainer}";
$uploader =~ /(.+) <(.+)>/ or warn "$fname:$.: syntax
error in $package Uploaders: $uploader";
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#1025353: remmina: new upstream version
Package: remmina Version: 1.4.27+dfsg-2 Severity: wishlist Hey. 1.4.28 seems to be out, which also contains a number of nice fixes for usage of VNC with UNIX sockets. Thanks, Chris.
Bug#1017881: ITA: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes
Hello Sean, Sean Whitton writes: > On Sat 15 Oct 2022 at 05:36PM GMT, Stefan Kangas wrote: > >> Thanks for your work on the unclutter-xfixes package. I intend to adopt >> it, and work on getting the new upstream release into bookworm. >> >> You will be able to track my progress at: >> https://salsa.debian.org/skangas/unclutter-xfixes > > May I ask if you'll be ready with this one soon? The freeze is coming. Thanks for reaching out. I'm still working on it. I have run into a boring problem where my packages are building correctly, but no longer being signed for some reason. I think I accidentally broke something related to cowbuilder, or something like that. As soon as I can fix it, I will upload the new package to mentors.d.n. I'm aware of the freeze and should be ready well in advance. Thanks.
Bug#1025352: grub2: Unable to present non-ASCII character
Package: grub2
Version: 2.06-5
Severity: normal
X-Debbugs-Cc: ybx...@gmail.com
Dear Maintainer,
After the update, the grub can only present the ASCII character which means the
frame and the arrow keys cannot be presented and was replaced by ?. I tried to
edit the grub.cfg to change the location of the unicode.pf2 but still get the
same error. It happens on all of my three computers.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sdb1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/sdc1 /home ext4 rw,relatime 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1
--hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1
a5479fa5-b6b1-4a84-ac35-c5a9a06f9598
else
search --no-floppy --fs-uuid --set=root a5479fa5-b6b1-4a84-ac35-c5a9a06f9598
fi
font="/boot/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=zh_CN
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1
--hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1
a5479fa5-b6b1-4a84-ac35-c5a9a06f9598
else
search --no-floppy --fs-uuid --set=root a5479fa5-b6b1-4a84-ac35-c5a9a06f9598
fi
insmod png
if background_image /usr/share/desktop-base/homeworld-theme/grub/grub-4x3.png;
then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-a5479fa5-b6b1-4a84-ac35-c5a9a06f9598' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1
--hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1
a5479fa5-b6b1-4a84-ac35-c5a9a06f9598
else
search --no-floppy --fs-uuid --set=root
a5479fa5-b6b1-4a84-ac35-c5a9a06f9598
fi
echo'Loading Linux 6.0.0-5-amd64 ...'
linux /boot/vmlinuz-6.0.0-5-amd64
root=UUID=a5479fa5-b6b1-4a84-ac35-c5a9a06f9598 ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-6.0.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-a5479fa5-b6b1-4a84-ac35-c5a9a06f9598' {
menuentry 'Debian GNU/Linux, with Linux 6.0.0-5-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-6.0.0-5-amd64-advanced-a5479fa5-b6b1-4a84-ac35-c5a9a06f9598' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio;
fi
insmod part_gpt
Bug#1025351: ITP: aws-crt-python -- Python 3 bindings for the AWS Common Runtime
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-de...@lists.debian.org, debian-cl...@lists.debian.org * Package name: aws-crt-python Version : 0.15.3 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-crt-python * License : Apache 2.0 Programming Lang: Python and C Description : Python 3 bindings for the AWS Common Runtime aws-crt-python contains python interfaces for common low-level functionality used when interfacing with Amazon Web Services service endpoints. It provides socket handling, the HTTP client implementation, authentication, logging, and error handling. The package is initially being prepared in order to support upgrading the awscli package to version 2.x, which introduces it as a dependency. It will be maintained by the cloud team. In the future, the C components in this package may be split into standalone packages that can be used independently of the python bindings if needed. For now the focus is on python. noah
Bug#1005902: xmms2: do not release with bookworm
There is release 0.9.1 of 2022-05-02 at https://github.com/xmms2/xmms2-devel/releases/tag/0.9.1 . Rather than throwing it out, please consider upgrading xmms2 packaging to 0.9.1 instead. Thank you! Best, Sebastian
Bug#1025213: Extra info
I tried to install gnome-shell-common gnome-shell and gnome-shell-extension-prefs 43.0.2. This did not succeed because of failing login (protocol)? Then I compiled source gnome-shell 43.0.2 and installed at /usr/local... I verified the version with gnome-shell --version. This downgrade did not change anything. So gnome-shell itself is not the problem. Subframes seem to be rendered OK, but old, already deleted subframes are repeatedly shown. Do not know how to investigate further. Upstream??
Bug#1025350: qt6ct: changing font has no effect
Package: qt6ct Version: 0.7-2 Severity: normal X-Debbugs-Cc: tsuyo...@yumegakanau.org I use GNOME. I was trying out qtcreater. I do not regularly use any Qt applications. The font size in qtcreator's interface is too small for me. I read that qt6ct can be used to configure the font size, if you are not using KDE. So I installed it and ran it, went to the font dialog in qt6ct, and set the fonts to what I want. However, this has no effect on qtcreator's interface font size. Incidentally, it also appears to have no effect on qt6ct's interface font size. When I rerun qt6ct, the font that I selected is still there, so it is getting saved. I also tried the "Create fonts.conf" button in qt6ct. This did change the fonts in the qtcreator (and qt6ct) interface. But it only made the same too-small fonts look pixellated. I was, luckily, able to revert this by using the "Remove fonts.conf" button. -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt6ct depends on: ii libc6 2.36-6 ii libgcc-s1 12.2.0-9 ii libqt6core6 [qt6-base-abi] 6.3.1+dfsg-10+b1 ii libqt6gui6 6.3.1+dfsg-10+b1 ii libqt6svg6 6.3.1-2 ii libqt6widgets6 6.3.1+dfsg-10+b1 ii libstdc++6 12.2.0-9 ii qt6-qpa-plugins 6.3.1+dfsg-10+b1 qt6ct recommends no packages. qt6ct suggests no packages. -- no debconf information
Bug#1025349: gdm3: should define the display-manager alias for start dependencies
Package: gdm3 Version: 43.0-1 Severity: normal Hello, If gdm happens to manage to start quicker than console-setup, console-setup's setupcon call will fail. So we need a dependency between the two, to make console-setup start "Before" display managers. This can be set with Before=display-manager.service since display managers usually set this alias. But gdm3 apparently explicitly removes this with the debian/patches/92_systemd_unit.patch patch: * Don't install the display-manager.service alias, which is managed jointly by all Debian display managers via a debconf question but I don't think that's the point of the display-manager.service alias? At any rate, we need a proper way to make console-setup get started before display managers (and I don't think making console-setup explicit a list of display managers is a proper way to do it :) ) Samuel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 22.08.8-1+b1 ii adduser 3.129 ii cdebconf [debconf-2.0]0.265 ii cinnamon [x-window-manager] 5.4.12-2 ii cinnamon-session [x-session-manager] 5.6.0-1 ii dbus [default-dbus-system-bus]1.14.4-1 ii dbus-bin 1.14.4-1 ii dbus-broker [dbus-system-bus] 32-1+b1 ii dbus-daemon 1.14.4-1 ii dconf-cli 0.40.0-3 ii dconf-gsettings-backend 0.40.0-3 ii debconf [debconf-2.0] 1.5.79 ii eterm [x-terminal-emulator] 0.9.6-6.1 ii fvwm [x-window-manager] 1:2.7.0-1 ii fvwm3 [x-window-manager] 1.0.5+ds-2 ii gir1.2-gdm-1.043.0-1 ii gnome-session [x-session-manager] 43.0-1 ii gnome-session-bin 43.0-1 ii gnome-session-common 43.0-1 ii gnome-settings-daemon 43.0-3 ii gnome-shell 43.1-2 ii gnome-terminal [x-terminal-emulator] 3.46.2-1 ii gsettings-desktop-schemas 43.0-1 ii icewm [x-window-manager] 3.1.0-1 ii konsole [x-terminal-emulator] 4:22.08.1-1 ii libaccountsservice0 22.08.8-1+b1 ii libaudit1 1:3.0.7-1.1+b2 ii libc6 2.36-5 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libgdm1 43.0-1 ii libglib2.0-0 2.74.1-2 ii libglib2.0-bin2.74.1-2 ii libgtk-3-03.24.35-1 ii libgudev-1.0-0237-2 ii libkeyutils1 1.6.3-1 ii libpam-modules1.5.2-5 ii libpam-runtime1.5.2-5 ii libpam-systemd [logind] 252.1-1 ii libpam0g 1.5.2-5 ii librsvg2-common 2.54.5+dfsg-1 ii libselinux1 3.4-1+b3 ii libsystemd0 252.1-1 ii libx11-6 2:1.8.1-2 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.5 ii lxsession [x-session-manager] 0.5.5-2+b1 ii lxterminal [x-terminal-emulator] 0.4.0-2 ii marco [x-window-manager] 1.26.1-1 ii mate-session-manager [x-session-manager] 1.26.0-1 ii mate-terminal [x-terminal-emulator] 1.26.0-1 ii metacity [x-window-manager] 1:3.46.0-1 ii mlterm [x-terminal-emulator] 3.9.0-1+b1 ii muffin [x-window-manager] 5.4.7-1 ii mutter [x-window-manager] 43.0-2 ii olwm [x-window-manager]
Bug#1025347: [iwd] hidden network connection failures without rebooting things
Quoting Lyndon Brown (2022-12-03 00:14:00) > Continuing... With a reboot having fixed the issue starting the iwd > service, I was still not connected to wifi, so I opened gnome's wifi > settings. It was now giving me a list of access points again, and mine > was listed, but connecting failed every time I tried to select it. > > I then deleted and recreated the access point (a hidden type as > previously mentioned), having remembered having needed to do this last > time I tried iwd. This made no difference. > > I then toggled wifi on/off and immediately it tried auto-connecting and > was successful. > > WTH, why was that necessary. Sounds like this (from https://wiki.debian.org/NetworkManager/iwd ): > IWD itself is considered stable [...], however the NetworkManager > backend is considered in an experimental state I.e. you might experience an issue with _NetworkManager_ (not IWD). See also the Known Issues section of that wiki page. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1025345: [iwd] service would not start after installation until after restart
Quoting Lyndon Brown (2022-12-02 23:04:55) > Having done this I opened up gnome wifi settings and was faced with an > empty access point list and a spinning activity indicator. > > The problem turned out to be that the iwd service was failing to start. > Trying to get it started with a manual `systemctl start` command > failed. Toggling wifi on/off made no difference. I couldn't see any > indication of what was wrong in dmesg or journalctl, so I tried a > reboot. The iwd service started successfully upon rebooting. > > Is it expected that switching over to iwd like this can't work without > a reboot, or is there a bug? It is not surprising to me that switching from one wifi daemon to another may not go smooth. I don't consider that a bug in either of them. I recommend (instead of filing as a speculative bugreport which is not really actionable) that you try use and improve on this wikie page: https://wiki.debian.org/NetworkManager/iwd - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1025348: RFP: nvtop -- Interactive NVIDIA and AMD GPU process monitor.
Package: nvtop Severity: wishlist This program allows you to monitor your GPU processes, temperatures, power consumption, and average fan speed. Can this package please be built to support AMD and Intel GPUs, as well? So far, it only seems to support Nvidia GPUs. Thank you. Upstream: https://github.com/Syllo/nvtop
Bug#1025297: thunderbird segfault with 22.3
Hi, I'm also encountering issues with 22.3.0-1 with thunderbird. The application doesn't start - here's GDB backtrace: #0 _dl_close (_map=0x0) at ./elf/dl-close.c:795 #1 0x77b6de9a in __GI__dl_catch_exception (exception=exception@entry=0x7fff9a70, operate=, args=) at ./elf/dl-error-skeleton.c:208 #2 0x77b6df4f in __GI__dl_catch_error (objname=0x7fff9ac8, errstring=0x7fff9ad0, mallocedp=0x7fff9ac7, operate=, args=) at ./elf/dl-error-skeleton.c:227 #3 0x77aa3dc7 in _dlerror_run (operate=, args=) at ./dlfcn/dlerror.c:138 #4 0x77aa3b26 in __dlclose (handle=) at ./dlfcn/dlclose.c:31 #5 0x7fffe3ae7f44 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #6 0x7fffe3ae7190 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #7 0x7fffe30aa179 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #8 0x7fffe36b5156 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #9 0x7fffe36b50c4 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #10 0x7fffe30ac0bc in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #11 0x7fffe30b44b5 in () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #12 0x7fffedd31eae in () at /lib/x86_64-linux-gnu/libgbm.so.1 #13 0x7fffedd32360 in () at /lib/x86_64-linux-gnu/libgbm.so.1 #14 0x7fffedd3264b in () at /lib/x86_64-linux-gnu/libgbm.so.1 #15 0x7fffedd3074c in () at /lib/x86_64-linux-gnu/libgbm.so.1 #16 0x7fffedd30884 in gbm_create_device () at /lib/x86_64-linux-gnu/libgbm.so.1 #17 0x70d48f9a in mozilla::widget::nsGbmLib::CreateDevice(int) (fd=3) at ./widget/gtk/DMABufLibWrapper.h:66 #18 0x70d48d4f in mozilla::widget::nsDMABufDevice::Configure(nsTSubstring&) (this=0x756e3880 , aFailureId=...) at ./widget/gtk/DMABufLibWrapper.cpp:255 #19 0x7fffef1f3bc0 in gfxPlatformGtk::InitDmabufConfig() (this=) at ./gfx/thebes/gfxPlatformGtk.cpp:221 #20 0x7fffef1f35c4 in gfxPlatformGtk::gfxPlatformGtk() (this=0x7fffea00e580) at ./gfx/thebes/gfxPlatformGtk.cpp:113 #21 0x7fffef1eb9a2 in gfxPlatform::Init() () at ./gfx/thebes/gfxPlatform.cpp:895 #22 0x7fffef1eafd0 in gfxPlatform::GetPlatform() () at ./gfx/thebes/gfxPlatform.cpp:467 Downgrading to 22.2.4 fixes the issue. I'm using the proprietary nvidia driver, on another machine without a nvidia card, 22.3 works fine. Let me know if you need something else. Thanks
Bug#924685: package ready for upload
Control: tags -1 +pending On 2022-12-02 16:31:07, Moritz Mühlenhoff wrote: > Hi Antoine, > >> At your convenience, please review the changes I've done on the package, >> and let me know when I can upload it. > > Thanks so much for moving this forward! It looks great to me, please > upload at your convenience. > >> PS: and I think you should get rid of the debian/ branches on your end >> so there's no ambiguity about where the package is maintained. > > Ack, I'll sort this out within the Wikimedia folks involved. I think > all future uploads will > land in Debian first (will add myself to uploaders when the next > release comes out). Uploaded, it should land in NEW soon. Thanks! -- The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.- Friedrich Nietzsche
Bug#1025347: [iwd] hidden network connection failures without rebooting things
package: iwd version: 2.0-1 I reported the first issue I encountered trying to switch to iwd v2.0 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025345 (iwd service not starting after installation). Continuing... With a reboot having fixed the issue starting the iwd service, I was still not connected to wifi, so I opened gnome's wifi settings. It was now giving me a list of access points again, and mine was listed, but connecting failed every time I tried to select it. I then deleted and recreated the access point (a hidden type as previously mentioned), having remembered having needed to do this last time I tried iwd. This made no difference. I then toggled wifi on/off and immediately it tried auto-connecting and was successful. WTH, why was that necessary. It then worked just fine for the next X number of hours until I shut down my laptop for the night. The router remained on. Coming back to it today, router still on, I turned on my laptop, and no auto-connected wifi. I went into gnome wifi settings and selected the access point, but it failed to connect, over and over. I tried toggling wifi on/off like before, but no difference. It just outright refused to connect. I then turned off and restarted the router. Laptop still refused to connect. I then rebooted the laptop, and then it worked. WTH. This is reminiscent of my troubles last time. I'd hoped that they'd have fixed this by now. :/ Btw, I'm now using an Intel wifi module. At some point in the past I'd had a different brand's, but I can't remember which of the two I was using the last time I tried iwd. The following is a chunk of journalctl output from when the laptop was refusing to connect today: Dec 02 19:02:28 debian1 kernel: iwlwifi :3a:00.0: Not associated and the session protection is over already... Dec 02 19:02:28 debian1 kernel: wlan0: Connection to AP 8c: lost Dec 02 19:02:28 debian1 kernel: wlan0: send auth to 8c: (try 2/3) Dec 02 19:02:29 debian1 kernel: iwlwifi :3a:00.0: Not associated and the session protection is over already... Dec 02 19:02:29 debian1 kernel: wlan0: Connection to AP 8c: lost Dec 02 19:02:29 debian1 kernel: wlan0: send auth to 8c: (try 3/3) Dec 02 19:02:30 debian1 kernel: iwlwifi :3a:00.0: Not associated and the session protection is over already... Dec 02 19:02:30 debian1 kernel: wlan0: Connection to AP 8c: lost Dec 02 19:02:30 debian1 kernel: wlan0: authentication with 8c: timed out Dec 02 19:02:30 debian1 iwd[818]: connect event timed out, reason=2 Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7101] device (wlan0): Activation: (wifi) Network.Connect failed: GDBus.Error:net.connman.iwd.Failed: Operation failed Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7107] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed') Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7121] manager: NetworkManager state is now CONNECTED_LOCAL Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7133] device (wlan0): Activation: failed for connection '' Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7136] device (wlan0): new IWD device state is disconnected Dec 02 19:02:30 debian1 NetworkManager[815]: [1670007750.7149] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Dec 02 19:02:38 debian1 sudo[2919]:: TTY=pts/0 ; PWD=/home/ ; USER=root ; COMMAND=/usr/bin/journalctl -n100 Dec 02 19:02:38 debian1 sudo[2919]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000) Dec 02 19:05:01 debian1 CRON[2939]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0) Dec 02 19:05:01 debian1 CRON[2940]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 02 19:05:01 debian1 CRON[2939]: pam_unix(cron:session): session closed for user root Dec 02 19:07:42 debian1 sudo[2919]: pam_unix(sudo:session): session closed for user root Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5780] device (wlan0): Activation: starting connection '' () Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5781] audit: op="connection-activate" uuid="" name="" pid=2800 uid=1000 result="> Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5782] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5785] manager: NetworkManager state is now CONNECTING Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5787] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Dec 02 19:07:45 debian1 NetworkManager[815]: [1670008065.5860] device (wlan0): new IWD device state is connecting Dec 02 19:07:45 debian1 kernel: wlan0: authenticate with 8c: Dec 02 19:07:45 debian1 kernel: wlan0: bad VHT capabilities, disabling VHT Dec 02 19:07:45 debian1 kernel: wlan0: Invalid HE
Bug#1025346: ITP: calamares-settings-mobian -- Calamares branding and configuration for Mobian
Package: wnpp Severity: wishlist Owner: undef X-Debbugs-Cc: debian-de...@lists.debian.org, undef * Package name: calamares-settings-mobian Version : 0.2.4 Upstream Author : Mobian-team * URL : https://salsa.debian.org/Mobian-team/calamares-settings-mobian * License : GPL3+ Programming Lang: sh Description : Calamares branding and configuration for Mobian This package contains the branding, configuration and scripts required to boot to calamares and install Mobian on a small, touch screen only device. This package will be maintained inside the Mobian team.
Bug#1022540: build-essential: please add riscv64 support
Hello! If there isn't any specific blocker, I would like to get into a state where I don't have to hack our CI with the following Ubuntu injection: ``` apt-get install -y gcc-riscv64-linux-gnu g++-riscv64-linux-gnu wget http://mirrors.kernel.org/ubuntu/pool/universe/b/build-essential/crossbuild-essential-riscv64_12.8ubuntu1.1_all.deb dpkg -i crossbuild-essential-riscv64_12.8ubuntu1.1_all.deb ``` Thank you for your work on crossbuild! David -- David Heidelberg Consultant Software Engineer
Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
On 2022-12-01 01 h 52, Stuart Prescott wrote: Hi Scott On 01/12/2022 15:16, Scott Kitterman wrote: On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote: Hi Scott, On 01/12/2022 02:16, Scott Kitterman wrote: Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep, leading to false positives. Scott K I contemplated filing a similar the other day but in writing it up, I realised that lintian was correct. Policy requires that the 'clean' target be functional with only the Build-Depends (and Build-Conflicts) satisfied, and pybuild + the build-backend dependencies are involved in the cleaning step. Not always. At least with the package I ran into this on, clean works fine without them. Yes indeed... - the most obvious case where that works is where 'clean' is explicit in d/rules - it would also be possible for it to work in situations where dh-python is (redundantly?) listed in B-D (not B-D-I), since the pyproject plugin's 'clean' operation has no dependency on `build`, `installer`, and the backend. However, this for this second case: - it might result in pybuild picking a different plugin through lack of dependencies like `tomli`. That might just work... but also feels slightly terrifying. - there's not _currently_ any backend-specific cleaning code, but perhaps there should be, which would then need the deps to be in B-D? (Is that in the spec somewhere?) I guess the main thing to be careful of in any rewording of this explanation is that for the most common case of using "%:\n\tdh --buildsystem pybuild", dh-python (or pybuild-plugin-pyproject) is needed in B-D not B-D-I to be policy-compliant. cheers Stuart I've proposed a fix here: https://salsa.debian.org/lintian/lintian/-/merge_requests/426 It's not precise enough to flag packages that would declare everything as a Build-Depends-Indep though. This would be much more complex and I feel this situation is overall pretty rare. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1025324: libc6: Xserver with nouveau not workiing.
El 2/12/22 a las 20:13, Aurelien Jarno escribió: Hi: Can you please give more details, especially which previous version of libc6 were you using? Also can you please try to downgrade your system to this version to confirm that the issue is linked to libc6? I think I know what it is. Although it jumps in libc6, as far as I can see it's a glx libraries issue (from the new version). I had 2.36.5 before. But I see it's not the problem. I rule it out entirely as libc6. I have tested it. I will look and do another way to report this bug. Unless it's libc6, because I've already ruled it out (tried and tested). I'll do it with more time, but as I said before, I'm using the generic graphics card driver. I will solve it. -- Enviando desde Mozilla Thunderbird. OpenPGP_signature Description: OpenPGP digital signature
Bug#1000627: apache2: missing dependency setting
Control: tags -1 upstream Hi On Fri, 3 Jun 2022 23:53:50 +0200 Michael Biebl wrote: > I'd like to refer to https://systemd.io/NETWORK_ONLINE/ as well. > Especially to "Should network-online.target be used?" which suggest > better and more robust options then using network-online.target AFAICT there is an upstream bugreport for implementing IP_FREEBIND: https://bz.apache.org/bugzilla/show_bug.cgi?id=58725 This seems to have already been implemented, at least in 2.5/trunk: https://httpd.apache.org/docs/trunk/mod/mpm_common.html#listen Since this bug only occurs when the user specifies an IP address to listen on, our default config is not affected AFAIU. So the easiest way to fix this bug is to wait and maybe add a comment before the default 'Listen' directives to add the freebind option when changing the 'Listen' to a specific IP address. This can only be done once we package a release containing that option, though. In the meantime the only workaround seems to be to wait for the network-online.target but since this is not necessary for the stock config, I don’t really want to do that.
Bug#1025345: [iwd] service would not start after installation until after restart
package: iwd version: 2.0-1 I thought I'd give iwd another go with the newly released version 2.0. It's been quite some time since I last tried it, having previously encountered issues relating to my hidden network that resulted in switching back to wpa_spplicant. My network is still hidden, which I may change at some point, but it is what it is for now. FYI I have a WPA2-based ISP supplied router. So last night, after the v2.0 update hit upstable, I made the switch by: 1) Installing iwd (plus a few updates) 2) Creating the /etc/NetworkManager/conf.d/iwd.conf file with the following contents: [device] wifi.backend=iwd 3) Disabling wpa_supplicant, initially with `sudo systemctl mask wpa_supplicant` following some old notes, before undoing this and doing the following instead: sudo systemctl stop NetworkManager sudo systemctl disable --now wpa_supplicant sudo systemctl restart NetworkManager Having done this I opened up gnome wifi settings and was faced with an empty access point list and a spinning activity indicator. The problem turned out to be that the iwd service was failing to start. Trying to get it started with a manual `systemctl start` command failed. Toggling wifi on/off made no difference. I couldn't see any indication of what was wrong in dmesg or journalctl, so I tried a reboot. The iwd service started successfully upon rebooting. Is it expected that switching over to iwd like this can't work without a reboot, or is there a bug?
Bug#1025344: jq man page: "## INVOKING JQ"
Package: jq Version: 1.6-2.1 I see this in the jq manual page: But that's getting ahead of ourselves. :) Let's start with something simpler: ## INVOKING JQ This doesn't look right. -- Jakub Wilk
Bug#1025343: z3: Please link against -latomic for "riscv64" arch
Source: z3 Version: 4.8.12-3 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hi, The package needs to link against libatomic in this architecture, with the patch attached or an equivalent. I built it successfully on local hardware. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru z3-4.8.12/debian/changelog z3-4.8.12/debian/changelog --- z3-4.8.12/debian/changelog 2022-10-21 17:24:40.0 + +++ z3-4.8.12/debian/changelog 2022-11-28 16:02:35.0 + @@ -1,3 +1,10 @@ +z3 (4.8.12-3+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: link against -latomic + + -- Manuel A. Fernandez Montecelo Mon, 28 Nov 2022 16:02:35 + + z3 (4.8.12-3) unstable; urgency=medium * Do not use SSE2 unconditionally on i386 diff -Nru z3-4.8.12/debian/rules z3-4.8.12/debian/rules --- z3-4.8.12/debian/rules 2022-10-21 13:51:13.0 + +++ z3-4.8.12/debian/rules 2022-11-28 16:02:35.0 + @@ -6,6 +6,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CXXFLAGS_MAINT_APPEND = -fPIC -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 +ifeq ($(DEB_HOST_ARCH),riscv64) +export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -Wl,-latomic -Wl,--as-needed +endif + DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) ifneq (,$(shell dh_listpackages -a | grep libz3-jni))
Bug#1004275: php upgrade apache2: After upgrade php install apache2 and i have intalled lighttpd
Control: tags -1 moreinfo Control: reassign php Hi Thank you for your report. On Mon, 24 Jan 2022 01:33:24 +0100 wrote: > After apt update & upgrade a new php update appear but the upgrade also > installed apache2. Can you provide a log of your commands and outputs? Which php package(s) were updated from which version to which version? > I am running lighttpd server and apache2 it's not neccesary on my system. Makes sense. Which version of lighthttpd is installed? I’m reassigning this package to php, exclusively, because I don’t think any change in the apache2 package(s) can fix the issue. Cheers henk
Bug#1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails
On Fr 02 Dez 2022 20:55:32 CET, Thomas Uhle wrote: I think that moving polkit-mate-authentication-agent-1 to /usr/libexec and updating debian/control appropriately would be just enough to close this ticket. Sorry, I am delayed with this. I'll see to an upload the coming days. Thanks to Simon for the various solution approaches, I'll agree with the /usr/libexec switch as the best and least invasive solution. Thanks! Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpC_9qzEYgKP.pgp Description: Digitale PGP-Signatur
Bug#1025342: coreutils: paste tokenises -d on bytes, not characters, contrary to POSIX
Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, POSIX Issue 7 TC 2, XCU, paste, OPTIONS says: -- >8 -- -d list Unless a character appears in list, each character in list is an element specifying a delimiter character. -- >8 -- So one would expect the following to hold: -- >8 -- $ printf '%s\n' a b c d | out/cmd/paste -sdя aяbяcяd -- >8 -- Why, then, is the coreutils output, with LC_CTYPE correctly set to UTF-8: -- >8 -- $ printf '%s\n' a b c d | paste -sdя a�b�c�d $ printf '%s\n' a b c d | paste -sdя | hd 61 d1 62 8f 63 d1 64 0a |a.b.c.d.| 0008 -- >8 -- ? наб -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: amd64, i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.3.1-1 ii libattr1 1:2.5.1-1 ii libc62.36-6 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libselinux1 3.4-1+b2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1025341: rust-lalrpop: flaky autopkgtest on s390x
Source: rust-lalrpop Version: 0.19.8-3 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of rust-lalrpop as it was blocking glibc. I noticed that it sometimes fails on s390x with the following error: thread 'lr1::build::test::expr_grammar1' has overflowed its stack fatal runtime error: stack overflow error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: `/tmp/tmp.ylFj0b7NXt/target/s390x-unknown-linux-gnu/debug/deps/lalrpop-d02d6930d272c3cf` (signal: 6, SIGABRT: process abort signal) autopkgtest [23:12:06]: test librust-lalrpop-dev:lexer: ---] autopkgtest [23:12:06]: test librust-lalrpop-dev:lexer: - - - - - - - - - - results - - - - - - - - - - librust-lalrpop-dev:lexer FAIL non-zero exit status 101 See the logs of failed and successful runs: https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-lalrpop/28902703/log.gz https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-lalrpop/28902705/log.gz Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Regards Aurelien
Bug#745605: please retest
Control: tags -1 -fixed-upstream It seems this bugreport was tagged 'fixed-upstream' automatically after the upstream bug was closed automatically due to age or inactivity. AFAICT the bug is not fixed, the change proposed in [1] / [2] does not seem to be applied, see [3]. Someone would need to retest this (as described in upstream’s bugtracker’s closing comment), report back, and depending on result either close this bug or reopen upstream’s bug; or alternatively provide a minimal example how to reproduce it for someone else to test. Thanks! [1]: https://bz.apache.org/bugzilla/show_bug.cgi?id=35049#c1 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745605#55 [3]: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?view=markup#l80
Bug#714083: default-ssl.conf should also be prefixed with 000- to be sure to be first ssl virtualhost
Control: retitle -1 default-ssl.conf should also be prefixed with 000- to be sure to be first ssl virtualhost Control: severity -1 normal Control: tags -1 help Increased severity because this does easily cause problems, unexpected behaviour, confusion, and support requests when an ssl vhost is put in a config with a filename that is sorted before 'default-ssl.conf', e.g. 'custom-vhost.conf' or 'a-vhost.conf'. There is already a pull request [1] that was already merged but then reverted because changing this config file’s name is not trivial and I had not thought of how to do this migration on productive systems. Concrete questions are: * how to deal with this on all variations of systems ** unchanged, not activated (will dpkg/ucf/whatever-handles-these-config-files do the right thing? I guess the old file will be removed and the new file placed, but how to be certain?) ** changed, not activated (what do we do? move the existing file? remove it, install the new?) ** unchanged, activated (similar to first variant, but how to deal with the symlink in sites-enabled/?) ** changed, activated (do we even do anything in this case or just assume that it’s working as intended and leave the admin to it?) Concrete suggestions, patches, references to relevant docs, merge requests, etc. welcome! Cheers henk
Bug#1025324: libc6: Xserver with nouveau not workiing.
Hi, On Fri, 2 Dec 2022 20:13:05 +0100 Aurelien Jarno wrote: > Can you please give more details, especially which previous version of > libc6 were you using? Also can you please try to downgrade your system > to this version to confirm that the issue is linked to libc6? Some people on #debian-next @ oftc reported issues with the recent mesa upgrade to 22.3.0, all with nvidia GPUs. Downgrading solved their issues. Being in the red team, i can't bring more infos :) François.
Bug#1025340: xserver-xorg: Xorg segfaults at start-up in recent Debian Live images
Package: xserver-xorg Version: 1:7.7+23 Severity: important Usertags: openqa X-Debbugs-Cc: rclo...@rclobus.nl Hi folks, Debian Live images built in the last day seem not to be able to start X. It segfaults at start-up, thus: [20.784] (EE) Backtrace: [20.785] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x564d21cafc59] [20.787] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f5d44e5af90] [20.788] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.788] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7f5d45a99029] [20.788] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7f5d44f6de9a] [20.789] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7f5d44f6df4f] [20.789] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7f5d44ea3dc7] [20.790] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7f5d44ea3b26] [20.820] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7f5d4326bf44] [20.821] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7f5d4326b190] [20.821] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.821] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7f5d4282e179] [20.832] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7f5d42e39156] [20.832] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7f5d42e390c4] [20.832] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7f5d4282ea34] [20.833] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7f5d428384b5] [20.833] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.833] (EE) 14: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7f5d44b6fd77] [20.833] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.833] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7f5d44b6eb7f] [20.834] (EE) 16: /usr/lib/xorg/Xorg (_CallCallbacks+0x34) [0x564d21b41a24] [20.834] (EE) 17: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x10af) [0x564d21c6da9f] [20.838] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x89) [0x564d21bad2a9] [20.838] (EE) 19: /usr/lib/xorg/Xorg (InitFonts+0x1e8) [0x564d21b404e8] [20.838] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f5d44e4618a] [20.839] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f5d44e46245] [20.839] (EE) 22: /usr/lib/xorg/Xorg (_start+0x21) [0x564d21b29b61] [20.839] (EE) [20.839] (EE) Segmentation fault at address 0x337 [20.839] (EE) Fatal server error: [20.839] (EE) Caught signal 11 (Segmentation fault). Server aborting Full log file is here: https://openqa.debian.net/tests/101031/logfile?filename=Xorg.0.log.txt I'm not sure what's causing this, hence the bug report against xserver-xorg. libglx-mesa0 seems like it _might_ be worth a look, given that the last thing before the segfault in Xorg.0.log is this: [17.912] (II) Initializing extension GLX [17.912] (II) AIGLX: Screen 0 is not DRI2 capable Here is the list of packages that are part of that broken live image: https://openqa.debian.net/tests/101031/logfile?filename=_graphical_wait_login-installed-pkgs.txt and here's a version of that list from a day earlier, when things were still working, for comparison: https://openqa.debian.net/tests/100587/logfile?filename=_collect_data-debs.txt BTW I notice that libglx-mesa0 went from 22.2.4-1 to 22.3.0-1, among many other changes. If you want to give it a try yourself, the most recent version of the live image we're testing comes from here: https://tests.reproducible-builds.org/debian_live_build/artifacts/r00t-me/kde-sid.iso Since the image there is regularly generated anew, you'll probably want to check that it's still causing a problem before testing things yourself, which you can do here: https://openqa.debian.net/tests/latest?arch=x86_64=debian=live-build=64bit=live-build-desktop_browser=sid_kde#next_previous If you want a copy of the image that caused a failing test, just click on the red dot for the failed test, go to the "Logs & Assets" tab, and you'll find a link to the image at the bottom of the list. Cheers, Phil.
Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked
On 02/12/2022 19:15, Scott Talbert wrote: Source: ansible-core Version: 2.14.0-1 Severity: important ansible-core's autopkgtests need to add a Depends on python3-pytest-forked. python3-pytest-xdist used to depend on -forked, but it no longer does. See, for example: https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz Thanks! Will update it in the next release.
Bug#1025339: libjpeg: CVE-2022-37769: Segmentation fault in HuffmanDecoder::Get
Source: libjpeg Version: 0.0~git20220615.842c7ba-2 Severity: important Tags: security upstream Forwarded: https://github.com/thorfdbg/libjpeg/issues/78 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for libjpeg. CVE-2022-37769[0]: | libjpeg commit 281daa9 was discovered to contain a segmentation fault | via HuffmanDecoder::Get at huffmandecoder.hpp. This vulnerability | allows attackers to cause a Denial of Service (DoS) via a crafted | file. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-37769 https://www.cve.org/CVERecord?id=CVE-2022-37769 [1] https://github.com/thorfdbg/libjpeg/issues/78 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails
On Thu, 1 Dec 2022, Simon McVittie wrote:
Forwarding this from -devel since I'm not sure whether you saw it there.
[...]
On Fri, 18 Nov 2022 at 22:23:05 +, Mike Gabriel wrote:
> The flaw in mate-polkit is that the
> /etc/xdg/autostart/.desktop file so far has been shipped in
> mate-polkit-common (which usually got built on amd64 builders) and that that
> .desktop file contains a multi-arch path in the Exec= key.
Probably a silly question, but could you build mate-polkit with
--libdir=/usr/libexec instead of /usr/lib/x86_64-linux-gnu/polkit-mate,
so that the polkit auth agent is at a location that does not vary between
architectures?
mate-polkit is currently Multi-Arch: same, but that seems wrong to me:
on a dual-architecture amd64/i386 system (or arm64/armhf or any other
combination), there is no point in running more than one architecture's
copy of the MATE polkit authentication agent. They'll all have the same
UI and the same behaviour, so any single architecture is enough. This
seems like a textbook case of a Multi-Arch: foreign package.
I do agree with Simon. It really seems to make sense to use /usr/libexec
as location (as a quick solution at least). polkit-agent-helper-1 from
the package policykit-1 for instance is also there.
(On amd64 it would maybe be nice to leave behind a symlink
/usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1 ->
/usr/libexec/polkit-mate-authentication-agent-1 so that if a sysadmin has
edited the conffile and therefore doesn't receive the new version, then
the agent will still start. But that's an optional quality-of-implementation
thing.)
It's the other way around. Nobody needs to change a configuration file on
an amd64 system because this is the only architecture where that path is
correct. Anyway, I guess the user would be asked by dpkg during upgrade
whether to install the new configuration file if it is kept in
mate-polkit-common and there are already local changes. So I am not quite
sure if that additional symlink is really needed.
Another possible solution to this would be to not install an XDG
autostart file into /etc at all, and instead do one or more of these:
1. teach MATE to read additional autostart files from a location below
/usr as a lower priority than XDG_CONFIG_DIRS, for instance if it
is currently reading
[g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":")]
then that could be changed to
[g_get_user_config_dir() + "/autostart",
x + "/autostart" for x in g_get_system_config_dirs().split(":"),
"/usr/share/mate/autostart"]
2. launch this polkit agent programmatically in MATE code (perhaps via
D-Bus activation) instead of relying on XDG autostart as a way to
discover it
3. integrate it into the desktop shell so it doesn't need to be launched
separately at all
[...]
I like the second proposal quite much. It would be good if
mate-session-manager could take care of it.
Although I fully understand the benefits of the third proposal, I doubt
that the MATE developers will go this way. Some of the MATE components
are also used in X11 environments that are not MATE (e.g. awesome or i3wm)
because these components are still kind of stand-alone and not bundled
like their counterparts in GNOME.
However, I guess that this is something that should rather be discussed
and dealt with upstream.
I think that moving polkit-mate-authentication-agent-1 to /usr/libexec
and updating debian/control appropriately would be just enough to close
this ticket.
Cheers,
Thomas
Bug#1025297: libgl1-mesa-dri: qemu+vga virtio: segmentation fault after update to version 22.3.0-1
Package: libgl1-mesa-dri Followup-For: Bug #1025297 Dear Maintainer, I think I'm seeing the same issue using qubes (xen virtualization), when I upgraded to 22.3.0-1. Rolling back to 22.2.4-1 solved the problem. My stacktrace is a bit different: (==) Log file: "/home/user/.local/share/xorg/Xorg.0.log", Time: Thu Dec 1 21:18:02 2022 (++) Using config file: "/etc/X11/xorg-qubes.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5f8b336e3c59] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7b08c685af90] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7b08c7421029] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7b08c696de9a] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7b08c696df4f] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7b08c68a3dc7] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7b08c68a3b26] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7b08c2ee7f44] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7b08c2ee7190] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7b08c24aa179] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7b08c2ab5156] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7b08c2ab50c4] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7b08c24aaa34] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7b08c24b44b5] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 14: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7b08c64f9d77] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7b08c64f8b7f] (EE) 16: /usr/lib/xorg/Xorg (_CallCallbacks+0x34) [0x5f8b33575a24] (EE) 17: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x10af) [0x5f8b336a1a9f] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x89) [0x5f8b335e12a9] (EE) 19: /usr/lib/xorg/Xorg (InitFonts+0x1e8) [0x5f8b335744e8] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7b08c684618a] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7b08c6846245] (EE) 22: /usr/lib/xorg/Xorg (_start+0x21) [0x5f8b3355db61] (EE) (EE) Segmentation fault at address 0x337 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/user/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. /usr/bin/xinit: giving up /usr/bin/xinit: unable to connect to X server: Connection refused /usr/bin/xinit: server error Let me know if I can provide any extra information to help here.
Bug#1025324: libc6: Xserver with nouveau not workiing.
Hi, On 2022-12-02 16:07, Santiago José López Borrazás wrote: > Package: libc6 > Version: 2.36-6 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > It crashes only when I restart the graphical environment and gives me errors > on several sides when I have the module. I am loading through the generic > graphics card module. > > The failure is the following when booting Xorg. Attached is the Xorg file, > where the libc6 bug is specified. The fact that libc6 is mentioned might be normal, if some functions get passed wrong pointer values, they will crash. > In the previous version of libc6 it didn't crash for a moment. It is only in > the new version of libc6. Can you please give more details, especially which previous version of libc6 were you using? Also can you please try to downgrade your system to this version to confirm that the issue is linked to libc6? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1025338: firmware-linux-free: Unrecognized video cards and wifi
Package: firmware-linux-free Version: 20200122-1 Severity: important Tags: patch X-Debbugs-Cc: teodoro777.coluc...@live.com Dear Maintainer, *** 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: 11.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-18-amd64 (SMP w/20 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-linux-free depends on no packages. firmware-linux-free recommends no packages. Versions of packages firmware-linux-free suggests: ii initramfs-tools 0.140 -- debconf information: rep Description: application/json
Bug#1024494: ITP: python3-fints -- python library for the FinTS protocol
Sorry. I moved it to https://salsa.debian.org/werdahias/python-fints Matthias
Bug#1025337: nmu: texstudio_4.3.1+ds-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: LXQt Packaging Team
nmu texstudio_4.3.1+ds-1 . ANY . unstable . -m "Rebuild against the new
qtermwidget"
This is for #1025215.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1025336: swi-prolog: Please link against -latomic for "riscv64" arch
Source: swi-prolog Version: 8.4.3+dfsg-2 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hi, The package needs to link against libatomic in this architecture, with the patch attached or an equivalent. I built it locally on hardware, it built fine. (This happened with 8.4.3+dfsg-2, the patch is for 9.0.0). Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru swi-prolog-9.0.0+dfsg/debian/changelog swi-prolog-9.0.0+dfsg/debian/changelog --- swi-prolog-9.0.0+dfsg/debian/changelog 2022-12-02 09:49:17.0 + +++ swi-prolog-9.0.0+dfsg/debian/changelog 2022-12-02 17:40:49.0 + @@ -1,3 +1,10 @@ +swi-prolog (9.0.0+dfsg-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: link against -latomic + + -- Manuel A. Fernandez Montecelo Fri, 02 Dec 2022 17:40:49 + + swi-prolog (9.0.0+dfsg-1) unstable; urgency=medium * New upstream version 9.0.0+dfsg diff -Nru swi-prolog-9.0.0+dfsg/debian/rules swi-prolog-9.0.0+dfsg/debian/rules --- swi-prolog-9.0.0+dfsg/debian/rules 2022-12-02 09:49:17.0 + +++ swi-prolog-9.0.0+dfsg/debian/rules 2022-12-02 17:40:30.0 + @@ -6,6 +6,11 @@ DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk +ifeq ($(DEB_BUILD_ARCH),riscv64) +DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -Wl,-latomic -Wl,--as-needed +export DEB_LDFLAGS_MAINT_APPEND +endif + PLBASENAME := swi-prolog PLBASE := /usr/lib/$(PLBASENAME)/ JNIDIR := /usr/lib/$(DEB_BUILD_MULTIARCH)/jni
Bug#1025332: Subtle build failure
On 2022-12-02 18:46, Shengjing Zhu wrote: On Sat, Dec 3, 2022 at 1:09 AM Gunnar Hjalmarsson wrote: make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1 I can't reproduce the build failure locally in Debian testing or Ubuntu development environments. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025312 Nice catch, Shengjing Zhu. Thanks! -- Gunnar
Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked
Source: ansible-core Version: 2.14.0-1 Severity: important ansible-core's autopkgtests need to add a Depends on python3-pytest-forked. python3-pytest-xdist used to depend on -forked, but it no longer does. See, for example: https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
On Sat, Dec 3, 2022 at 1:54 AM Shengjing Zhu wrote: > > On Sat, Dec 3, 2022 at 1:42 AM Pirate Praveen > wrote: > > > > Package: golang-github-cespare-xxhash > > Version: 2.1.1-2 > > > > When building gitaly I get, > > > > src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2: > > cannot find package "github.com/cespare/xxhash/v2" in any of: > > > > /<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2 > > (vendor tree) > > /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from $GOROOT) > > /<>/_build/src/github.com/cespare/xxhash/v2 (from > > $GOPATH > > > > even though golang-github-cespare-xxhash-dev is installed. > > > > I think the import path and binary package name should be bumped to > > match go.mod: > > module github.com/cespare/xxhash/v2 > > > > so binary package should be golang-github-cespare-xxhash-v2-dev. Though > > I'm not 100% sure about the XS-Go-Import-Path as I think it should > > match without a change there. > > No. The Go compiler can find it automatically. Please see the detail at > > https://lists.debian.org/debian-go/2020/06/msg9.html > > I think you may have done some non-standard magic in your package. > And you can find there are many packages which use github.com/cespare/xxhash/v2 in the code. https://codesearch.debian.net/search?q=filetype%3Ago+github.com%2Fcespare%2Fxxhash%2Fv2=1 But they are built successfully, including the golang-github-prometheus-client-golang package. -- Shengjing Zhu
Bug#1025272: RM: python-descartes -- ROM; Dead upstream
On Thu, 01 Dec 2022 20:46:17 +0100 Bas Couwenberg wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org > Control: block -1 by 1025044 > > Please remove python-decartes from the archive, it's dead upstream. Reverse depends need to be addressed first: Checking reverse dependencies... # Broken Depends: osmnx: python3-osmnx # Broken Build-Depends: osmnx: python3-descartes (>= 1.1) Dependency problem found. Please remove the moreinfo tag once this is resolved. Scott K
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
On Sat, Dec 3 2022 at 01:54:53 AM +08:00:00 +08:00:00, Shengjing Zhu wrote: On Sat, Dec 3, 2022 at 1:42 AM Pirate Praveen wrote: Package: golang-github-cespare-xxhash Version: 2.1.1-2 When building gitaly I get, src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2: cannot find package "github.com/cespare/xxhash/v2" in any of: /<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2 (vendor tree) /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from $GOROOT) /<>/_build/src/github.com/cespare/xxhash/v2 (from $GOPATH even though golang-github-cespare-xxhash-dev is installed. I think the import path and binary package name should be bumped to match go.mod: module github.com/cespare/xxhash/v2 so binary package should be golang-github-cespare-xxhash-v2-dev. Though I'm not 100% sure about the XS-Go-Import-Path as I think it should match without a change there. No. The Go compiler can find it automatically. Please see the detail at https://lists.debian.org/debian-go/2020/06/msg9.html I think you may have done some non-standard magic in your package. I just vendored some dependencies till protobuf 1.5 vs 1.3 settle down. So from a vendored module, it is not able to find this module. -- Shengjing Zhu
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
On Sat, Dec 3, 2022 at 1:42 AM Pirate Praveen wrote: > > Package: golang-github-cespare-xxhash > Version: 2.1.1-2 > > When building gitaly I get, > > src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2: > cannot find package "github.com/cespare/xxhash/v2" in any of: > > /<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2 > (vendor tree) > /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from $GOROOT) > /<>/_build/src/github.com/cespare/xxhash/v2 (from > $GOPATH > > even though golang-github-cespare-xxhash-dev is installed. > > I think the import path and binary package name should be bumped to > match go.mod: > module github.com/cespare/xxhash/v2 > > so binary package should be golang-github-cespare-xxhash-v2-dev. Though > I'm not 100% sure about the XS-Go-Import-Path as I think it should > match without a change there. No. The Go compiler can find it automatically. Please see the detail at https://lists.debian.org/debian-go/2020/06/msg9.html I think you may have done some non-standard magic in your package. -- Shengjing Zhu
Bug#1025232: hdf5: Build dependencies on openjdk-11 that will not be in bookworm
Hi, Sebastian Ramacher a écrit le 01/12/2022 à 10:25 : Source: hdf5 Version: 1.10.8+repack-4 Severity: serious Tags: sid bookworm X-Debbugs-Cc: sramac...@debian.org openjdk-11 will not be be part of bookworm (see #1023237). Please adapt the package to use the default JDK version (openjdk-17) in its build dependencies. Yes, I was told so. That's unfortunate. A change between openjdk 17~11 and 17~14 broke the hdf5 java test suite on i386 and mips64el arches. I'm running a bisect against the jdk repo to find out more about that. But this will take some time. Best, _g.
Bug#1025332: Subtle build failure
Control: block -1 by 1025312 On Sat, Dec 3, 2022 at 1:09 AM Gunnar Hjalmarsson wrote: > > package: src:ibus-cangjie > version: 2.4-6 > severity: serious > tags: ftbfs > > The buildlog in unstable (on all) states: > > make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1 > > Tail log to give context: > > # SKIP: 0 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > = > make[6]: Leaving directory '/<>' > make[5]: Leaving directory '/<>' > make[4]: Leaving directory '/<>' > make[3]: Leaving directory '/<>' > make[2]: Leaving directory '/<>' > rm -fr -- /tmp/dh-xdg-rundir-1fkxdzYs > make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:17: build-indep] Error 2 > > ibus-cangjie 2.4-5 built successfully in September, and the only > package file which has changed since then is debian/watch. > > I can't reproduce the build failure locally in Debian testing or > Ubuntu development environments. > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025312 -- Shengjing Zhu
Bug#995670: Zig package status
The package got removed from mentors. Nick, do you still have time to work on it? If not please make this a RFP.
Bug#1025334: Update binary package and XS-Go-Import-Path to match go.mod
Package: golang-github-cespare-xxhash Version: 2.1.1-2 When building gitaly I get, src/gitlab.com/gitlab-org/gitlab/vendor/github.com/prometheus/client_golang/prometheus/desc.go:22:2: cannot find package "github.com/cespare/xxhash/v2" in any of: /<>/_build/src/gitlab.com/gitlab-org/gitlab/vendor/github.com/cespare/xxhash/v2 (vendor tree) /usr/lib/go-1.19/src/github.com/cespare/xxhash/v2 (from $GOROOT) /<>/_build/src/github.com/cespare/xxhash/v2 (from $GOPATH even though golang-github-cespare-xxhash-dev is installed. I think the import path and binary package name should be bumped to match go.mod: module github.com/cespare/xxhash/v2 so binary package should be golang-github-cespare-xxhash-v2-dev. Though I'm not 100% sure about the XS-Go-Import-Path as I think it should match without a change there.
Bug#1025333: Notification with connection failure pops up despite Internet
Package: gnome Version: 1:3.38+3 My laptop is connected to the Internet via an Ethernet cable, which is what I currently want. Connections via WiFi are in general possible but today, they fail (probably because too many clients try to connect to a public wireless network), cf. the screenshot in the attachment. This failure doesn't hurt me. Still, despite already having Internet access via cable, the latop apparently tries to connect via WiFi and fails, displaying the notification with title “Verbindung gescheitert” (German for “connection failed”) and smaller text “Aktivierung der Netzverbindung ist gescheitert” (German for “activation of a network connection has failed”) every few minutes. This popup alone alone hurts. How to turn it off (without turning off the WiFi)? Moreover, it is probably useless or even harmful in general to _automatically_ try to establish another Internet connection when there's one already. More data: $ sudo cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false Thx in advance Albert
Bug#1025328:
This segfault occurs on any action inside the small pop-up window of controls of "Text tool" during edition of a text object.
Bug#1024494: ITP: python3-fints -- python library for the FinTS protocol
On Sun, 20 Nov 2022 18:11:45 +0100 (CET) matthias.geiger1...@tutanota.de wrote: The intial packaging is already done and can be viewed at https://salsa.debian.org/werdahias/fints . The git repo is not available. Removing from the Python Team's RFS queue.
Bug#1025312: libgl1-mesa-dri: multiple packages FTBFS and have autopkgtest regressions running test programs under Xvfb
Hi all, I am seeing a similar stack trace from Xorg with a dummy video driver. This is the configuration used by chrome-remote-desktop, which stopped working after the latest update. Here is the stack trace: (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55c6ad57fc59] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f260965af90] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7f260a20f029] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7f260976de9a] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7f260976df4f] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7f26096a3dc7] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7f26096a3b26] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7f25c7ee7f44] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7f25c7ee7190] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7f25c74aa179] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7f25c7ab5156] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7f25c7ab50c4] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7f25c74aaa34] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7f25c74b44b5] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 14: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7f26092e7d77] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7f26092e6b7f] (EE) 16: /usr/lib/xorg/Xorg (_CallCallbacks+0x34) [0x55c6ad411a24] (EE) 17: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x10af) [0x55c6ad53da9f] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x89) [0x55c6ad47d2a9] (EE) 19: /usr/lib/xorg/Xorg (InitFonts+0x1e8) [0x55c6ad4104e8] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f260964618a] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f2609646245] (EE) 22: /usr/lib/xorg/Xorg (_start+0x21) [0x55c6ad3f9b61] (EE) (EE) Segmentation fault at address 0x337 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) To reproduce, this is the minimal command (after installing xserver-xorg-video-dummy): $ /usr/lib/xorg/Xorg :20 -config xorg.conf The config is attached. Also, I think this bug is a duplicate: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025326 Hope it helps finding the issue. Thanks, -- Radu xorg.conf Description: Binary data
Bug#1025332: Subtle build failure
package: src:ibus-cangjie version: 2.4-6 severity: serious tags: ftbfs The buildlog in unstable (on all) states: make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1 Tail log to give context: # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 = make[6]: Leaving directory '/<>' make[5]: Leaving directory '/<>' make[4]: Leaving directory '/<>' make[3]: Leaving directory '/<>' make[2]: Leaving directory '/<>' rm -fr -- /tmp/dh-xdg-rundir-1fkxdzYs make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:17: build-indep] Error 2 ibus-cangjie 2.4-5 built successfully in September, and the only package file which has changed since then is debian/watch. I can't reproduce the build failure locally in Debian testing or Ubuntu development environments. -- Gunnar Hjalmarsson
Bug#1025331: tar: needs an unambiguous listing format
Package: tar Version: 1.30 Severity: important Control: found -1 1.34 Tags: upstream Hi, I discovered while working on #1010024 that tar (since version 1.30) lacks an unambiguous listing format, by which I mean an output of tar -t that one can then pass to tar -x and will correctly represent all legal paths. The natural approach, I think, would be to have an argument something like -print0 that could then be passed to tar --null Currently, tar listings may be quoted or unquoted. Unquoted paths are ambiguous, because you don't know if a newline represents a newline in a path or is a separator between paths. Quoted paths are unambiguous; however since tar 1.30, --verbatim-files-from (which is necessary to cope with paths starting - which are otherwise treated as command-line arguments) does not unquote paths. So if you (might) have paths that start - and paths that contain newlines, you can't win. This is what caused a lot of pain in pristine-tar. It used to be possible to correctly and unambiguously use quoted paths and --verbatim-files-from together (and pristine-tar did so) because --verbatim-files-from would unquote. That was broken with the following change in tar (which went into 1.30): " 2017-11-09 Sergey Poznyakoff Fix --verbatim-files-from * src/names.c (read_next_name): Don't unquote name read from the file, if --verbatim-files-from option is in effect. (names_options): improve description of --verbatim-files-from " Regards, Matthew
Bug#1024691: [Pkg-javascript-devel] Bug#1024691: eslint: Please update node-ajv dependency to version 8
On 02/12/2022 17:08, Jonas Smedegaard wrote: Quoting Yadd (2022-11-23 11:08:46) I prepared node-ajv 8 in experimental branch and a patch for eslint. There are remaining problems: some "throw" tests fail because error strings changed. Seems to me it is not just a few changed strings: This line is now spewed more than 17000 times: meta-schema not available Seems to me the patch is incomplete - but unfortunately I cannot help in more detail. - Jonas Hi, I think this can wait after Debian 12 release. Thanks! Yadd
Bug#1024691: [Pkg-javascript-devel] Bug#1024691: eslint: Please update node-ajv dependency to version 8
Quoting Yadd (2022-11-23 11:08:46) > I prepared node-ajv 8 in experimental branch and a patch for eslint. > There are remaining problems: some "throw" tests fail because error > strings changed. Seems to me it is not just a few changed strings: This line is now spewed more than 17000 times: meta-schema not available Seems to me the patch is incomplete - but unfortunately I cannot help in more detail. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#995838: [htcondor-debian] Bug#995838: Bug#995838: Should condor be removed?
Hello Bastian, I am working on this. Twice I had everything building and ready for upload and then something changed on sid. First change, moving to openssl 3 caused condor to FTBFS. Then migration to cgroups v2 caused condor to FTBFS. Right now I have it building. However, some change is causing the install step to not place files in the proper directories. Perhaps, something to do with usrmerge or some change in the build tools. Still working on that one. ...Tim On 11/30/22 11:05, Bastian Germann wrote: X-Debbugs-Cc: andr...@an3as.eu Any news on condor? Upstream has released the announced version but the Debian package has only advanced in git. ___ htcondor-debian mailing list htcondor-deb...@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian -- Tim Theisen (he, him, his) Release Manager HTCondor & Open Science Grid Center for High Throughput Computing Department of Computer Sciences University of Wisconsin - Madison 4261 Computer Sciences and Statistics 1210 W Dayton St Madison, WI 53706-1685 +1 608 265 5736
Bug#1025307: yosys mips64el build failure (fix)
Hi Scott, On Fri, Dec 02, 2022 at 02:46:44PM +, Scott Ashcroft wrote: > The patch works! > > It does give a build warning due to the return type of sizeof being a > size_t not an int. Uups, I do always forget about that. > The files produced by running the grom test match exactly those from > your packaged x86_64 version. Excellent I'll upload the fix post-haste :) --Daniel
Bug#1025308: gsequencer: FTBFS with fftw3 (3.3.10-1)
Control: affects 1025312 src:gsequencer The test target still fails because it uses xvfb which is broken by the recent update of mesa (#1025312). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1024802: new monitor that works
I bought a new monitor, confirming that it works. The problem seems to be with older devices.
Bug#1025330: fsarchiver: test failure with xfsprogs 6.0
Package: fsarchiver Severity: important Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar ubuntu-patch X-Debbugs-Cc: juli...@ubuntu.com In Ubuntu, the attached patch was applied to achieve the following: * Update XFS test to use a 500MB filesystem as mkfs.xfs now imposes a 300MB minimum size since 6.0.0 Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers lunar APT policy: (500, 'lunar'), (500, 'kinetic-security'), (500, 'jammy-security') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-060100rc5-generic (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en diff -Nru fsarchiver-0.8.6/debian/tests/backup-and-restore-xfs.sh fsarchiver-0.8.6/debian/tests/backup-and-restore-xfs.sh --- fsarchiver-0.8.6/debian/tests/backup-and-restore-xfs.sh 2021-02-27 19:56:03.0 +0100 +++ fsarchiver-0.8.6/debian/tests/backup-and-restore-xfs.sh 2022-12-01 17:56:02.0 +0100 @@ -8,7 +8,7 @@ FILE=/tmp/loop # Create a 100M file -dd if=/dev/zero of=$FILE bs=1M count=100 status=none +dd if=/dev/zero of=$FILE bs=1M count=500 status=none DEVICE=$(losetup -fP --show $FILE) echo "Successfully created $DEVICE"
Bug#1025329: bullseye-pu: package cwltool/3.0.20210124104916-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cru...@debian.org
[ Reason ]
cwltool is not usable without the python3-distutils package also
installed. This is rare, but can happen on fresh Debian installs.
I discovered this today while testing instructions for WSL2 users.
The cwltool version in unstable/testing does not have this problem.
[ Impact ]
cwltool fails to run
ImportError: cannot import name 'spawn' from 'distutils'
(/usr/lib/python3.9/distutils/__init__.py)
[ Tests ]
I can confirm that installing python3-distutils is sufficient to avoid
the problem.
[ Risks ]
Basically no risk, just a change to the depenendency of the cwltool
binary package.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Add python3-distutils as a dependency of the cwltool binary package
Thanks!
diff -Nru cwltool-3.0.20210124104916/debian/changelog
cwltool-3.0.20210124104916/debian/changelog
--- cwltool-3.0.20210124104916/debian/changelog 2021-01-25 10:36:01.0
+0100
+++ cwltool-3.0.20210124104916/debian/changelog 2022-12-02 16:06:31.0
+0100
@@ -1,3 +1,9 @@
+cwltool (3.0.20210124104916-3+deb11u1) bullseye; urgency=medium
+
+ * debian/control: cwltool needs python3-distutils
+
+ -- Michael R. Crusoe Fri, 02 Dec 2022 16:06:31 +0100
+
cwltool (3.0.20210124104916-3) unstable; urgency=high
* debian/control: this version of cwltool breaks toil less than
diff -Nru cwltool-3.0.20210124104916/debian/control
cwltool-3.0.20210124104916/debian/control
--- cwltool-3.0.20210124104916/debian/control 2021-01-25 09:12:25.0
+0100
+++ cwltool-3.0.20210124104916/debian/control 2022-12-02 16:05:13.0
+0100
@@ -43,7 +43,8 @@
${misc:Depends},
python3-mypy-extensions,
python3-arcp,
- python3-argcomplete
+ python3-argcomplete,
+ python3-distutils
Recommends: nodejs
Breaks: toil (<< 5)
Suggests: docker.io | singularity-container
Bug#1025328: Fwd: GIMP Segmentation fault in g_object_new_with_properties
Package: gimp Version: 2.10.22-4 Linux 5.19.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1~bpo11+1 (2022-10-03) x86_64 GNU/Linux Description: Debian GNU/Linux 11 (bullseye) GNU Image Manipulation Program version 2.10.22 git-describe: GIMP_2_10_20-217-g0c8a7891f7 Build: unknown rev 0 for linux # C compiler # Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) # Libraries # using babl version 0.1.82 (compiled against version 0.1.86) using GEGL version 0.4.26 (compiled against version 0.4.28) using GLib version 2.73.3 (compiled against version 2.66.8) using GdkPixbuf version 2.42.2 (compiled against version 2.42.2) using GTK+ version 2.24.33 (compiled against version 2.24.33) using Pango version 1.46.2 (compiled against version 1.46.2) using Fontconfig version 2.13.1 (compiled against version 2.13.1) using Cairo version 1.16.0 (compiled against version 1.16.0) ``` > fatal error: Segmentation fault Stack trace: ``` # Stack traces obtained from PID 105411 - Thread 105411 # [New LWP 105414] [New LWP 105415] [New LWP 105416] [New LWP 105417] [New LWP 105418] [New LWP 105419] [New LWP 105420] [New LWP 105428] [New LWP 105429] [New LWP 105437] [New LWP 105490] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __GI___libc_read (nbytes=256, buf=0x7ffe23d4a140, fd=15) at ../sysdeps/unix/sysv/linux/read.c:26 Id Target IdFrame * 1Thread 0x7f9d9d35fe80 (LWP 105411) "gimp-2.10" __GI___libc_read (nbytes=256, buf=0x7ffe23d4a140, fd=15) at ../sysdeps/unix/sysv/linux/read.c:26 2Thread 0x7f9d9c3ff640 (LWP 105414) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 3Thread 0x7f9d9bbfe640 (LWP 105415) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 4Thread 0x7f9d9b3fd640 (LWP 105416) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 5Thread 0x7f9d9abfc640 (LWP 105417) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 6Thread 0x7f9d9a3fb640 (LWP 105418) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 7Thread 0x7f9d99bfa640 (LWP 105419) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 8Thread 0x7f9d993f9640 (LWP 105420) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 9Thread 0x7f9d4a7fc640 (LWP 105428) "gmain" 0x7f9d9dcfda3f in __GI___poll (fds=0x5649efb711b0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 10 Thread 0x7f9d52ffd640 (LWP 105429) "gdbus" 0x7f9d9dcfda3f in __GI___poll (fds=0x5649efb86790, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 11 Thread 0x7f9d29ffb640 (LWP 105437) "async" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 12 Thread 0x7f9d297fa640 (LWP 105490) "swap writer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 Thread 12 (Thread 0x7f9d297fa640 (LWP 105490) "swap writer"): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7f9d9e09355f in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f9d9e5af53d in () at /usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0 #3 0x7f9d9e069c0d in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f9d9dc87b27 in start_thread (arg=) at ./nptl/pthread_create.c:435 ret = pd =
Bug#924685: package ready for upload
Hi Antoine, > At your convenience, please review the changes I've done on the package, > and let me know when I can upload it. Thanks so much for moving this forward! It looks great to me, please upload at your convenience. > PS: and I think you should get rid of the debian/ branches on your end > so there's no ambiguity about where the package is maintained. Ack, I'll sort this out within the Wikimedia folks involved. I think all future uploads will land in Debian first (will add myself to uploaders when the next release comes out). Cheers and have a great weekend, Moritz
Bug#1025327: ImportError: cannot import name 'spawn' from 'distutils' (/usr/lib/python3.9/distutils/__init__.py)
Package: cwltool
Version: 3.0.20210124104916-3
Severity: important
Tags: patch
X-Debbugs-Cc: cru...@debian.org
cwltool needs python3-distutils, but this wasn't detected in
autopkgtests due to one of the test packages pulling in distutils.
I just discovered this by installing cwltool in a fresh Bullseye WSL2
installation.
diff -Nru cwltool-3.0.20210124104916/debian/changelog
cwltool-3.0.20210124104916/debian/changelog
--- cwltool-3.0.20210124104916/debian/changelog 2021-01-25 10:36:01.0
+0100
+++ cwltool-3.0.20210124104916/debian/changelog 2022-12-02 16:06:31.0
+0100
@@ -1,3 +1,9 @@
+cwltool (3.0.20210124104916-3+deb11u1) bullseye; urgency=medium
+
+ * debian/control: cwltool needs python3-distutils
+
+ -- Michael R. Crusoe Fri, 02 Dec 2022 16:06:31 +0100
+
cwltool (3.0.20210124104916-3) unstable; urgency=high
* debian/control: this version of cwltool breaks toil less than
diff -Nru cwltool-3.0.20210124104916/debian/control
cwltool-3.0.20210124104916/debian/control
--- cwltool-3.0.20210124104916/debian/control 2021-01-25 09:12:25.0
+0100
+++ cwltool-3.0.20210124104916/debian/control 2022-12-02 16:05:13.0
+0100
@@ -43,7 +43,8 @@
${misc:Depends},
python3-mypy-extensions,
python3-arcp,
- python3-argcomplete
+ python3-argcomplete,
+ python3-distutils
Recommends: nodejs
Breaks: toil (<< 5)
Suggests: docker.io | singularity-container
Bug#1025326: tigervnc-standalone-server: Upgrade of libgl1-mesa-dri to 22.3.0 breaks Xvnc
Package: tigervnc-standalone-server Version: 1.12.0+dfsg-5 Severity: normal Dear Maintainer, Having upgraded mesa to 22.3.0, Xvnc will not start, giving the following: Xvnc TigerVNC 1.12.0 - built 2022-07-09 14:10 Copyright (C) 1999-2021 TigerVNC Team and many others (see README.rst) See https://www.tigervnc.org for information on TigerVNC. Underlying X server release 12101004, X.Org Fri Dec 2 14:46:58 2022 vncext: VNC extension running! vncext: Listening for VNC connections on local interface(s), port 5910 vncext: created VNC server for screen 0 (EE) (EE) Backtrace: (EE) 0: /usr/bin/Xtigervnc (OsLookupColor+0x139) [0x564f7b36e2d9] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fcc4345af90] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7fcc4402e029] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7fcc4356de9a] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7fcc4356df4f] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7fcc434a3dc7] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7fcc434a3b26] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7fcc40ee7f44] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7fcc40ee7190] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7fcc404aa179] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7fcc40ab5156] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7fcc40ab50c4] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7fcc404aaa34] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7fcc404b44b5] (EE) 14: /usr/bin/Xtigervnc (__glGetProcAddress+0x677) [0x564f7b22c417] (EE) 15: /usr/bin/Xtigervnc (RecordCreateSet+0x47f) [0x564f7b22b2df] (EE) 16: /usr/bin/Xtigervnc (_CallCallbacks+0x34) [0x564f7b31c894] (EE) 17: /usr/bin/Xtigervnc (GlxExtensionInit+0x152) [0x564f7b24c602] (EE) 18: /usr/bin/Xtigervnc (InitExtensions+0x89) [0x564f7b1ed7a9] (EE) 19: /usr/bin/Xtigervnc (dix_main+0x1a8) [0x564f7b31b398] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7fcc4344618a] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7fcc43446245] (EE) 22: /usr/bin/Xtigervnc (_start+0x21) [0x564f7b1eb7f1] (EE) (EE) Segmentation fault at address 0x337 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) Downgrading libgl1-mesa-dri to 22.2.4 solves this (even if it is the only package downgraded, leaving some "broken"). So I guess the problem must be in some incomatible change in the swrast_dri.so module. Cheers, Itaï -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tigervnc-standalone-server depends on: ii libaudit1 1:3.0.7-1.1+b2 ii libbsd0 0.11.7-1 ii libc6 2.36-6 ii libfile-readbackwards-perl 1.06-2 ii libgcrypt20 1.10.1-3 ii libgl1 1.5.0-1 ii libgnutls30 3.7.8-4 ii libjpeg62-turbo 1:2.1.2-1+b1 ii libpam0g1.5.2-5 ii libpixman-1-0 0.42.2-1 ii libselinux1 3.4-1+b3 ii libstdc++6 12.2.0-9 ii libsystemd0 252.2-1 ii libunwind8 1.6.2-2 ii libxau6 1:1.0.9-1 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.6-1 ii perl5.36.0-4 ii tigervnc-common 1.12.0+dfsg-5 ii x11-xkb-utils 7.7+7 ii xauth 1:1.1.1-1 ii xkb-data2.35.1-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages tigervnc-standalone-server recommends: ii libgl1-mesa-dri22.2.4-1 ii tigervnc-tools 1.12.0+dfsg-5 ii x11-xserver-utils 7.7+9+b1 ii xfonts-base1:1.0.5 Versions of packages tigervnc-standalone-server suggests: ii openssl 3.0.7-1 pn xfonts-100dpi | xfonts-75dpi pn xfonts-scalable -- no debconf information
Bug#1025325: ITS: dwm
Package: dwm Version: 6.4 Severity: important Tags: upstream X-Debbugs-Cc: matteo...@tiepi.it, m...@qa.debian.org Dear Hugo, I intend to salvate dwm according to: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package A new version of dwm has been released almost two months ago. Since you haven't worked on the last two releases of dwm, I would like to become the new maintainer of this package. I've emailed Hugo about the package more than fifteen days ago and he told me he was too busy to maintain it. He gave me his blessing to take care of dwm. I've already worked on the last two Debian releases of dwm and I maintain other two packages inside Debian. You can preview my 6.4 dwm Debian package at: https://mentors.debian.net/package/dwm/ -- Matteo Bini
Bug#1025312: libgl1-mesa-dri: multiple packages FTBFS and have autopkgtest regressions running test programs under Xvfb
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/7819 On Fri, 02 Dec 2022 at 12:24:00 +, Simon McVittie wrote: > - Install a VM/chroot/container with Debian testing > - Install the dependencies of gtk+3.0's autopkgtests > (adwaita-icon-theme-full at-spi2-core dbus-daemon gnome-desktop-testing >gtk-3-examples librsvg2-common xauth xvfb) > - xvfb-run -e /dev/stderr -a /usr/libexec/installed-tests/gtk+/builder I think this is happening because when Xvfb calls driCreateNewScreen2(), it ends up trying to use the D3D12 driver, which fails to load, but then tries to dlclose() a NULL handle during teardown. Workaround: run tests with LIBGL_ALWAYS_SOFTWARE=1 in the environment, which causes Mesa to skip the D3D12 driver. Backtrace from the above: #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7f2028fcad2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f2028f7bef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f2028f66472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x559b7c293f1a in OsAbort () at ../../../../os/utils.c:1352 #5 0x559b7c299083 in AbortServer () at ../../../../os/log.c:879 #6 0x559b7c29a0b5 in FatalError (f=f@entry=0x559b7c2b1710 "Caught signal %d (%s). Server aborting\n") at ../../../../os/log.c:1017 #7 0x559b7c291298 in OsSigHandler (unused=, sip=, signo=11) at ../../../../os/osinit.c:156 #8 OsSigHandler (signo=11, sip=, unused=) at ../../../../os/osinit.c:110 #9 #10 _dl_close (_map=0x0) at ./elf/dl-close.c:795 #11 0x7f202908ee9a in __GI__dl_catch_exception (exception=exception@entry=0x7ffd2818c640, operate=, args=) at ./elf/dl-error-skeleton.c:208 #12 0x7f202908ef4f in __GI__dl_catch_error (objname=0x7ffd2818c698, errstring=0x7ffd2818c6a0, mallocedp=0x7ffd2818c697, operate=, args=) at ./elf/dl-error-skeleton.c:227 #13 0x7f2028fc4dc7 in _dlerror_run (operate=, args=) at ./dlfcn/dlerror.c:138 #14 0x7f2028fc4b26 in __dlclose (handle=) at ./dlfcn/dlclose.c:31 #15 0x7f20274e7f44 in d3d12_destroy_screen (screen=0x559b7d60ab10) at ../src/gallium/drivers/d3d12/d3d12_screen.cpp:744 #16 0x7f20274e7190 in d3d12_create_dxcore_screen (winsys=winsys@entry=0x559b7d609ee0, adapter_luid=adapter_luid@entry=0x0) at ../src/gallium/drivers/d3d12/d3d12_dxcore_screen.cpp:236 #17 0x7f2026aaa179 in sw_screen_create_named (driver=0x7f2027ac30f1 "d3d12", config=0x7ffd2818c7e0, winsys=0x559b7d609ee0) at ../src/gallium/auxiliary/target-helpers/sw_helper.h:70 #18 sw_screen_create_vk (winsys=0x559b7d609ee0, config=0x7ffd2818c7e0, sw_vk=) at ../src/gallium/auxiliary/target-helpers/sw_helper.h:102 #19 0x7f20270b5156 in pipe_loader_sw_create_screen (dev=0x559b7d609e70, config=, sw_vk=) at ../src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:425 #20 0x7f20270b50c4 in pipe_loader_create_screen_vk (dev=0x559b7d609e70, sw_vk=sw_vk@entry=false) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:175 #21 0x7f20270b50f7 in pipe_loader_create_screen (dev=) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:181 #22 0x7f202634 in drisw_init_screen (sPriv=0x559b7d606e20) at ../src/gallium/frontends/dri/drisw.c:578 #23 0x7f2026ab44b5 in driCreateNewScreen2 (scrn=0, fd=, extensions=, driver_extensions=, driver_configs=0x559b7d586200, data=0x559b7d586160) at ../src/gallium/frontends/dri/dri_util.c:143 #24 0x559b7c18d7e7 in __glXDRIscreenProbe (pScreen=0x559b7d56f8a0) at ../../../../glx/glxdriswrast.c:448 #25 0x559b7c18c5ef in xorgGlxServerInit (pcbl=, param=, ext=) at ../../../../glx/glxext.c:550 #26 xorgGlxServerInit (pcbl=, param=, ext=) at ../../../../glx/glxext.c:525 #27 0x559b7c23cb64 in _CallCallbacks (pcbl=pcbl@entry=0x559b7c301168 , call_data=call_data@entry=0x559b7d585580) at ../../../../dix/dixutils.c:743 #28 0x559b7c1adc7f in CallCallbacks (call_data=0x559b7d585580, pcbl=0x559b7c301168 ) at ../../../../include/callback.h:83 #29 GlxExtensionInit () at ../../../../glx/vndext.c:244 #30 0x559b7c14e919 in InitExtensions (argc=argc@entry=9, argv=argv@entry=0x7ffd2818d508) at ../../../../../mi/miinitext.c:272 #31 0x559b7c23b628 in dix_main (argc=9, argv=, envp=) at ../../../../dix/main.c:194 #32 0x7f2028f6718a in __libc_start_call_main (main=main@entry=0x559b7c14c8f0 , argc=argc@entry=9, argv=argv@entry=0x7ffd2818d508) at ../sysdeps/nptl/libc_start_call_main.h:58 #33 0x7f2028f67245 in __libc_start_main_impl (main=0x559b7c14c8f0 , argc=9, argv=0x7ffd2818d508, init=, fini=, rtld_fini=, stack_end=0x7ffd2818d4f8) at ../csu/libc-start.c:381 #34 0x559b7c14c921 in _start () (gdb) frame 15 (gdb) p screen->d3d12_mod $1 = (util_dl_library *) 0x0
Bug#1025324: libc6: Xserver with nouveau not workiing.
Package: libc6 Version: 2.36-6 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** It crashes only when I restart the graphical environment and gives me errors on several sides when I have the module. I am loading through the generic graphics card module. The failure is the following when booting Xorg. Attached is the Xorg file, where the libc6 bug is specified. In the previous version of libc6 it didn't crash for a moment. It is only in the new version of libc6. Thanks. -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6 depends on: ii libgcc-s1 12.2.0-9 Versions of packages libc6 recommends: ii libidn2-0 2.3.3-1+b1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.80 pn glibc-doc ii libc-l10n 2.36-6 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales2.36-6 -- debconf information: glibc/restart-services: glibc/disable-screensaver: * glibc/upgrade: true * libraries/restart-without-asking: true glibc/restart-failed: glibc/kernel-too-old: glibc/kernel-not-supported: Xorg.0.log.old Description: application/json
Bug#1025114: python-parameterized: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Control: reassign -1 python3-nose Control: forcemerge 1024235 -1 The test failure «AttributeError: module 'inspect' has no attribute 'getargspec'» is coming from nose, a fix for which is pending. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025323: bullseye-pu: package nano/5.4-2+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Hi release team!
I'm requesting the acceptance of a new nano update for stable,
with 3 additional upstream patches that fix two crash conditions
and a data-loss condition.
All the patches are trivial, self-explanatory but also well
documented in their headers.
[ Reason ]
These fixes are backports of fixes for the most important
bugfixes in the latest nano releases.
[ Impact ]
Not applying these means nano can crash on certain conditions.
The errors were found via Fedora's crash data service.
[ Tests ]
Manual tests have been done to test these fixes. Besides, the
fixes have been in test in newer versions of nano across multiple
distributors.
[ Risks ]
I think the risks are minimal, but in any case, the fixes can be easily
reverted if they need to.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable (except for one of
the patches, which will be fixed in soon to be released 7.1)
[ Changes ]
The debiff consists of the addition of 3 individual patches,
plus the update of teh series file and debian changelog.
[ Other info ]
This update is very similar to the one that was previously accepted by
the release team, but this time with far less patches and lines of code
involved.
diff -Nru nano-5.4/debian/changelog nano-5.4/debian/changelog
--- nano-5.4/debian/changelog 2021-11-22 01:07:23.0 +0100
+++ nano-5.4/debian/changelog 2022-12-02 14:06:48.0 +0100
@@ -1,3 +1,11 @@
+nano (5.4-2+deb11u2) bullseye; urgency=medium
+
+ * The "No a l'ampliació del port" release.
+ * Add three additional patches from Benno Schulenberg, with two
+crash fixes and one data-loss fix.
+
+ -- Jordi Mallach Fri, 02 Dec 2022 14:06:48 +0100
+
nano (5.4-2+deb11u1) bullseye; urgency=medium
* The "Bueno, de verdad, hasta luego, paso" release.
diff -Nru
nano-5.4/debian/patches/0036-input-ensure-that-no-more-bytes-are-consumed-than-ar.patch
nano-5.4/debian/patches/0036-input-ensure-that-no-more-bytes-are-consumed-than-ar.patch
---
nano-5.4/debian/patches/0036-input-ensure-that-no-more-bytes-are-consumed-than-ar.patch
1970-01-01 01:00:00.0 +0100
+++
nano-5.4/debian/patches/0036-input-ensure-that-no-more-bytes-are-consumed-than-ar.patch
2022-12-02 13:42:39.0 +0100
@@ -0,0 +1,33 @@
+From af63d94017a26cbf3446219de5ced30e677e0f13 Mon Sep 17 00:00:00 2001
+From: Benno Schulenberg
+Date: Sun, 12 Dec 2021 15:43:15 +0100
+Subject: [PATCH 36/38] input: ensure that no more bytes are consumed than are
+ available
+
+The value of 'consumed' may not exceed the given 'length'.
+
+Bug existed since version 2.9.3, commit e739448c.
+
+(Bug was found by studying Fedora crash reports. Thank you, Fedora!)
+---
+ src/winio.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/winio.c b/src/winio.c
+index 1116c172..e12d6e6b 100644
+--- a/src/winio.c
b/src/winio.c
+@@ -466,8 +466,9 @@ int convert_SS3_sequence(const int *seq, size_t length,
int *consumed)
+ /* Translate a sequence that began with "Esc [" to its corresponding key
code. */
+ int convert_CSI_sequence(const int *seq, size_t length, int *consumed)
+ {
+- if (seq[0] < '9')
++ if (seq[0] < '9' && length > 1)
+ *consumed = 2;
++
+ switch (seq[0]) {
+ case '1':
+ if (length > 1 && seq[1] == '~')
+--
+2.37.4
+
diff -Nru
nano-5.4/debian/patches/0037-execute-don-t-crash-when-an-empty-buffer-is-piped-th.patch
nano-5.4/debian/patches/0037-execute-don-t-crash-when-an-empty-buffer-is-piped-th.patch
---
nano-5.4/debian/patches/0037-execute-don-t-crash-when-an-empty-buffer-is-piped-th.patch
1970-01-01 01:00:00.0 +0100
+++
nano-5.4/debian/patches/0037-execute-don-t-crash-when-an-empty-buffer-is-piped-th.patch
2022-12-02 13:42:39.0 +0100
@@ -0,0 +1,33 @@
+From 35b67b15652102203161beb31db786f09981de81 Mon Sep 17 00:00:00 2001
+From: Benno Schulenberg
+Date: Thu, 24 Feb 2022 11:57:56 +0100
+Subject: [PATCH 37/38] execute: don't crash when an empty buffer is piped
+ through a command
+
+That is, take into account that the cutbuffer could be NULL
+(when updating the undo item).
+
+This fixes https://savannah.gnu.org/bugs/?62107.
+
+Bug existed since version 4.9, commit b15c5a7e.
+---
+ src/text.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/text.c b/src/text.c
+index 5ff5745d..c88ca516 100644
+--- a/src/text.c
b/src/text.c
+@@ -1200,7 +1200,8 @@ void update_undo(undo_type action)
+ else if (cutbuffer != NULL) {
+ free_lines(u->cutbuffer);
+ u->cutbuffer = copy_buffer(cutbuffer);
+- }
++ } else
++
Bug#1025307: yosys mips64el build failure (fix)
On Fri, 2022-12-02 at 14:04 +, Scott Ashcroft wrote: > Hi, > > I agree if you only read the C then the code looks fine, if a bit > odd. > However, having looked at the coredump with gdb it seems the compiler > optomises the dereference out and passes back a pointer to the soon > to > be invalid stack address rather than the value. > It only crashes with the stack protection on and I initially > struggled > to reproduce the issue as I was using the upstream compiler flags. > > It isn't even handling endianness conversions as it copies the bytes > in > the same order they come in. I think their idea was to support > architectures where you can't access an 32-bit int at an odd address. > > I'll try you patch and report back. The patch works! It does give a build warning due to the return type of sizeof being a size_t not an int. If you chnage it to: for (size_t i = 0; i < sizeof(u.u8); i++) then everything is fine. The files produced by running the grom test match exactly those from your packaged x86_64 version. Cheers, Scott
Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]
Steve McIntyre writes: > Hi all! > > программист некто (in CC) reported this bug a few weeks back in > Debian. Since I applied the bundle of filesystem bounds-checking fixes > a few months back, he can't run grub-install. He's done the work to > determine that the patch that breaks things for him is > > 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end of > nat journal entries > > The full thread of our discussion is at https://bugs.debian.org/1021846 > > I don't have any knowledge of f2fs to go any further here. Help please! :-) Ergh, apologies for the regression. [somewhat off-topic: The fix came from a crash derived from fuzzing. I am not really knowledgeable about f2fs either - I was just trying to do my best based on what we could derive from the existing driver. In general, filesystems are a nightmare for fuzzing fixes because testing beyond the (quite decent!) tests that the grub test-suite runs is very challenging. There is usually no-one who is both involved in grub security and an expert on any given file system either. We do the best we can. Sadly our regression rate has been climbing, so we may need to come up with some other way to secure file systems or get access to sufficient expertise in the future.] I had a massive, massive work-in-progress spiel where I looked at this code and compared the linux code and counted sizes and so on and so forth. I was getting nowhere. But eventually I realised I had just made an off-by-one error in the test. You're allowed to have up to n = NAT_JOURNAL_ENTRIES entries _inclusive_, because the loop below uses i < n, not i <= n. D'oh. Please try the following: diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c index df6beb544cbd..855e24618c2b 100644 --- a/grub-core/fs/f2fs.c +++ b/grub-core/fs/f2fs.c @@ -650,7 +650,7 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, grub_uint32_t nid, grub_uint16_t n = grub_le_to_cpu16 (data->nat_j.n_nats); grub_uint16_t i; - if (n >= NAT_JOURNAL_ENTRIES) + if (n > NAT_JOURNAL_ENTRIES) return grub_error (GRUB_ERR_BAD_FS, "invalid number of nat journal entries"); If for some reason that doesn't work, please add the following debug code and report the results: diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c index 855e24618c2b..6e49a6d17b7a 100644 --- a/grub-core/fs/f2fs.c +++ b/grub-core/fs/f2fs.c @@ -643,6 +643,10 @@ get_nat_journal (struct grub_f2fs_data *data) return err; } +#ifdef GRUB_UTIL +#include +#endif + static grub_err_t get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, grub_uint32_t nid, grub_uint32_t *blkaddr) @@ -650,6 +654,10 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, grub_uint32_t nid, grub_uint16_t n = grub_le_to_cpu16 (data->nat_j.n_nats); grub_uint16_t i; +#ifdef GRUB_UTIL + fprintf(stderr, "%s: n = %hu\n", __func__, n); +#endif + if (n > NAT_JOURNAL_ENTRIES) return grub_error (GRUB_ERR_BAD_FS, "invalid number of nat journal entries"); Amusingly the debug code shows that the grub-fs-tester tests always have n = 0, which makes sense for a test that doesn't really stress the file-system, and also explains why we didn't catch the bug when it was introduced. Kind regards, Daniel > > - Forwarded message from программист некто > - > > From: программист некто > To: sub...@bugs.debian.org > Date: Sat, 15 Oct 2022 23:54:36 +0300 > Subject: Bug#1021846: grub-install is broken since 2.06-3: error: unknown > filesystem > Message-Id: <3168731665867...@wf4nrjvtssjecb53.iva.yp-c.yandex.net> > > Package: grub-pc > Version: 2.06-3~deb11u1 > Severity: critical > > Hello. Since version 2.06-3, grub-install is broken: it fails with "error: > unknown filesystem". > I test command /usr/sbin/grub-install -v /dev/sda > in some versions. Results in mail attachments. > Versions older than 2.06-3 works without error (2.06-2 and lower). > Tested versions: 2.04-20, 2.06-1, 2.06-2, 2.06-3~deb10u1, 2.06-3~deb11u1, > 2.06-4. > > Disk partitions: > > # fdisk --list-details > Disk /dev/sda: 29,82 GiB, 32017047552 bytes, 62533296 sectors > Disk model: TS32GSSD370S > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0xc7177f7e > > Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs > /dev/sda1 2048 22763519 22761472 83 Linux 4/4/1 1023/254/2 > /dev/sda2 * 25866240 62531583 36665344 7 HPFS/ 1023/254/2 1023/254/2 80 > > $ disktype /dev/sda1 > --- /dev/sda1 > Block device, size 10.85 GiB (11653873664 bytes) > F2FS file system (version 1.14) > > $ disktype /dev/sda2 > --- /dev/sda2 > Block device, size 17.48 GiB (18772656128 bytes) > NTFS file system > Volume size 17.48 GiB (18772652032 bytes, 36665336 sectors) > > > > > > > > > - End forwarded message - > -- >
Bug#1024908: django-cte: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Control: reassign -1 python3-nose Control: forcemerge -1 1024235 The test failure «AttributeError: module 'inspect' has no attribute 'getargspec'» is coming from nose, a fix for which is pending. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025322: pylint: FTBFS with Python 3.11 as a supported version
Source: pylint Version: 2.15.5-1 Severity: serious Tags: ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.11 Hi Maintainer As can be seen on reproducible builds [1], pylint FTBFS due to tests timing out with Python 3.11 as a supported version. I've copied the tail of the build log below. Regards Graham [1] https://tests.reproducible-builds.org/debian/rb-pkg/pylint.html dh_auto_test -O--buildsystem=pybuild I: pybuild pybuild:300: rm -f /build/1st/pylint-2.15.5/tests/functional/u/unused_typing_imports.py /build/1st/pylint-2.15.5/tests/functional/m/missing_final_newline.py I: pybuild base:240: cd /build/1st/pylint-2.15.5/.pybuild/cpython3_3.11/build; python3.11 -m pytest -k 'not test_pkginfo and not test_do_not_import_files_from_local_directory and not test_import_plugin_from_local_directory_if_pythonpath_cwd and not test_can_list_directories_without_dunder_init and not test_fail_on_exit_code and not test__test_environ_pythonpath_no_arg' = test session starts == platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack benchmark: 3.2.2 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=10) rootdir: /build/1st/pylint-2.15.5, configfile: setup.cfg plugins: benchmark-3.2.2 collected 2047 items / 15 deselected / 2032 selected tests/test_check_parallel.py F..F.FMon Nov 21 18:20:40 UTC 2022 - pbuilder was killed by timeout after 18h. Mon Nov 21 18:20:42 UTC 2022 I: https://tests.reproducible-builds.org/debian/unstable/amd64/pylint : reproducible ➤ timeout
Bug#1025321: upgrade pinta to 1.7.1
Package: pinta Version: 1.6-2.1 In Debian it is Pinta 1.6 that is 7 years old. It would be great to upgrade Pinta to 2.0 version, but like I see this was already suggested in bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979067 and the trouble is Pinta 1.x versions were Gtk2+Mono and Pinta 2.x versions are Gtk3+.NET. It looks like many other problems must be fixed before Pinta can be upgraded to 2.x versions. But in my humble opinion, can Pinta at least be upgraded to 1.7.1 which is the last 1.x version and it was taken special care to backport important bugs. Pinta 1.7.1 is way more stable and a lot of bugs fixed comparing to 1.6 version. See release links: https://www.pinta-project.com/releases/old-releases Importance of this upgrade is not just for Debian, but for all of the downstream Linux distributions that require that packages must be upgraded in Debian first. Thanks a lot
Bug#1025320: suggestion: include of markdownlint as .deb
Package: markdown Version: 1.0.1-11 Severity: wishlist X-Debbugs-Cc: nbeh...@yahoo.com Dear Maintainer, while using markdown more often for taking notes, I noticed markdownlint[1] as a handy tool to reveal inconsistencies in the formatting. On the project page, a few Linuxes are listed which provide the too from their repositories as a package. In the case of Debian (and cross-checked with `synaptic` for Debian 12/bookworm), there is no .deb yet, though the idea already floats in the project's issue at list since 2020.[2] Instead, `rubygems` and the subsequent call ```shell gem install mdl ``` is one possibility to install the program here. Thus I would like to relay the idea with the suggest to add a .deb as a vector of distribution for markdownlint. [1] https://github.com/markdownlint/markdownlint [2] https://github.com/markdownlint/markdownlint/issues/310 -- 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-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages markdown depends on: ii perl 5.36.0-4 markdown recommends no packages. markdown suggests no packages. -- no debconf information
Bug#1025319: ITP: python-blurhash -- Python implementation of the blurhash algorithm
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-blurhash Version : 1.1.4 Upstream Author : Lorenz Diener * URL : https://github.com/halcy/blurhash-python * License : MIT Programming Lang: Python Description : Python implementation of the blurhash algorithm BlurHash takes an image, and gives you a short string (only 20-30 characters) that represents the placeholder for this image. You do this on the backend of your service, and store the string along with the image. When you send data to your client, you send both the URL to the image, and the BlurHash string. Your client then takes the string, and decodes it into an image that it shows while the real image is loading over the network. The string is short enough that it comfortably fits into whatever data format you use. For instance, it can easily be added as a field in a JSON object. I plan to maintain this package as part of the Python team.
Bug#1025318: nextcloud-desktop: libGL error: failed to load driver: i915 (Segmentation fault)
Package: nextcloud-desktop
Version: 3.6.1-1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
When I open "nextcloud-desktop" on terminal, it cannot open and reture
the error messages:
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so:
cannot open shared object file: No such file or directory (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, su
ffix _dri)
libGL error: failed to load driver: i915
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so:
cannot open shared object file: No such file or directory (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, su
ffix _dri)
libGL error: failed to load driver: i915
Segmentation fault
Please help, thank you.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nextcloud-desktop depends on:
ii libc6 2.36-6
ii libcloudproviders0 0.3.1-2
ii libgcc-s1 12.2.0-9
ii libglib2.0-0 2.74.2-1
ii libnextcloudsync0 3.6.1-1
ii libqt5core5a 5.15.6+dfsg-4
ii libqt5dbus55.15.6+dfsg-4
ii libqt5gui5 5.15.6+dfsg-4
ii libqt5keychain10.13.2-5
ii libqt5network5 5.15.6+dfsg-4
ii libqt5qml5 5.15.6+dfsg-2
ii libqt5quick5 5.15.6+dfsg-2
ii libqt5quickcontrols2-5 5.15.6+dfsg-2
ii libqt5sql5-sqlite 5.15.6+dfsg-4
ii libqt5svg5 5.15.6-2
ii libqt5webenginecore5 5.15.10+dfsg-7+b1
ii libqt5webenginewidgets55.15.10+dfsg-7+b1
ii libqt5widgets5 5.15.6+dfsg-4
ii libstdc++6 12.2.0-9
ii nextcloud-desktop-common 3.6.1-1
ii nextcloud-desktop-l10n 3.6.1-1
ii qml-module-qt-labs-platform5.15.6+dfsg-2
ii qml-module-qtgraphicaleffects 5.15.6-2
ii qml-module-qtqml-models2 5.15.6+dfsg-2
ii qml-module-qtquick-controls2 5.15.6+dfsg-2
ii qml-module-qtquick-dialogs 5.15.6-2
ii qml-module-qtquick-layouts 5.15.6+dfsg-2
ii qml-module-qtquick-window2 5.15.6+dfsg-2
ii qml-module-qtquick25.15.6+dfsg-2
Versions of packages nextcloud-desktop recommends:
pn nextcloud-desktop-doc
nextcloud-desktop suggests no packages.
-- no debconf information
Bug#1025317: vips: FTBFS with fftw3 (3.3.10-1)
Source: vips
Version: 8.13.3-1
Severity: serious
Tags: ftbfs patch
Dear Maintainer,
Your package FTBFS with fftw3 (3.3.10-1) because it not longer provides
fftw3-dev.
The attached patch resolves the issue by changing the dependency to
libfftw3-dev.
Kind Regards,
Bas
diff -Nru vips-8.13.3/debian/changelog vips-8.13.3/debian/changelog
--- vips-8.13.3/debian/changelog2022-11-12 07:01:18.0 +0100
+++ vips-8.13.3/debian/changelog2022-12-02 14:09:07.0 +0100
@@ -1,3 +1,10 @@
+vips (8.13.3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Build depend on libfftw3-dev, fftw3-dev no longer provided.
+
+ -- Bas Couwenberg Fri, 02 Dec 2022 14:09:07 +0100
+
vips (8.13.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru vips-8.13.3/debian/control vips-8.13.3/debian/control
--- vips-8.13.3/debian/control 2022-02-28 22:28:00.0 +0100
+++ vips-8.13.3/debian/control 2022-12-02 14:09:06.0 +0100
@@ -5,7 +5,7 @@
libjpeg-dev, libtiff-dev, libpng-dev (>= 1.2.9), libgif-dev (>= 5.1),
libcgif-dev, librsvg2-dev (>= 2.40.0), libpoppler-glib-dev,
gobject-introspection,
- zlib1g-dev, fftw3-dev | libfftw3-dev, liblcms2-dev, libmagickcore-dev,
+ zlib1g-dev, libfftw3-dev, liblcms2-dev, libmagickcore-dev,
libmagickwand-dev, libfreetype6-dev, libpango1.0-dev, libfontconfig1-dev,
libglib2.0-dev, libice-dev, libimagequant-dev, liborc-0.4-dev, libheif-dev,
libmatio-dev, libexpat1-dev, libcfitsio-dev, libopenslide-dev, libwebp-dev,
@@ -42,7 +42,7 @@
Package: libvips-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends}, libvips42 (= ${binary:Version}), gir1.2-vips-8.0 (=
${binary:Version}), libjpeg-dev, libtiff-dev, zlib1g-dev, fftw3-dev |
libfftw3-dev, liblcms2-dev, libpng-dev, libmagickcore-dev, libmagickwand-dev,
libfreetype6-dev, libpango1.0-dev, libfontconfig1-dev, libglib2.0-dev,
libice-dev, gettext, pkg-config, liborc-0.4-dev, libopenexr-dev, libmatio-dev,
libexpat1-dev, libcfitsio-dev, libopenslide-dev, libwebp-dev, libgsf-1-dev,
libgif-dev (>= 5.1), libcgif-dev, libpoppler-glib-dev, librsvg2-dev (>=
2.40.0), libimagequant-dev, libheif-dev
+Depends: ${misc:Depends}, libvips42 (= ${binary:Version}), gir1.2-vips-8.0 (=
${binary:Version}), libjpeg-dev, libtiff-dev, zlib1g-dev, libfftw3-dev,
liblcms2-dev, libpng-dev, libmagickcore-dev, libmagickwand-dev,
libfreetype6-dev, libpango1.0-dev, libfontconfig1-dev, libglib2.0-dev,
libice-dev, gettext, pkg-config, liborc-0.4-dev, libopenexr-dev, libmatio-dev,
libexpat1-dev, libcfitsio-dev, libopenslide-dev, libwebp-dev, libgsf-1-dev,
libgif-dev (>= 5.1), libcgif-dev, libpoppler-glib-dev, librsvg2-dev (>=
2.40.0), libimagequant-dev, libheif-dev
Recommends: libvips-doc, libvips-tools
Suggests: nip2
Description: image processing system good for very large ones (dev)
Bug#1025132: firmware-linux: Missing firmware for Intel AX201
Hi, On Wed, Nov 30, 2022 at 03:05:28AM +0100, TeoCol wrote: > Package: firmware-linux > Version: 20221109-2 > Severity: normal > X-Debbugs-Cc: teodoro777.coluc...@live.com > > Dear Maintainer, > > After performing a clean install of debian testing, installing the proprietary > firmware, everything works fine, except bluetooth. > This is caused by lack of firmware to handle the device. > Indeed dmesg reports: > "[ 5.655154] Bluetooth: hci0: Failed to load Intel firmware file > intel/ibt-0040-4150.sfi (-2)" > As far as I've found, the drivers are present upstream: > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- > firmware.git/tree/intel. > Hope this can help. I have uploaded a new version including this one, https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/5894870eccac67e81fa0a0f47e10a8b55add12e7 . Can you specify what is the device in question? Regards, Salvatore
Bug#1025316: rosegarden: FTBFS with fftw3 (3.3.10-1)
Source: rosegarden Version: 1:22.06-1 Severity: serious Tags: ftbfs patch Dear Maintainer, Your package FTBFS with fftw3 (3.3.10-1) because it not longer provides fftw3-dev. The attached patch resolves the issue by changing the dependency to libfftw3-dev. Kind Regards, Bas diff -Nru rosegarden-22.06/debian/changelog rosegarden-22.06/debian/changelog --- rosegarden-22.06/debian/changelog 2022-06-12 12:56:10.0 +0200 +++ rosegarden-22.06/debian/changelog 2022-12-02 13:47:17.0 +0100 @@ -1,3 +1,10 @@ +rosegarden (1:22.06-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Build depend on libfftw3-dev, fftw3-dev no longer provided. + + -- Bas Couwenberg Fri, 02 Dec 2022 13:47:17 +0100 + rosegarden (1:22.06-1) unstable; urgency=medium * New upstream version 22.06 diff -Nru rosegarden-22.06/debian/control rosegarden-22.06/debian/control --- rosegarden-22.06/debian/control 2022-06-12 12:56:10.0 +0200 +++ rosegarden-22.06/debian/control 2022-12-02 13:47:16.0 +0100 @@ -10,7 +10,7 @@ cmake, debhelper-compat (= 13), dssi-dev (>= 0.4), - fftw3-dev, + libfftw3-dev, ladspa-sdk, libasound2-dev (>= 1.0.0), libjack-jackd2-dev | libjack-dev,
