Bug#1025298: readline: Detect cross building instead of expecting option in DEB_BUILD_PROFILES
Source: readline Version: 8.2-1.2 Severity: minor X-Debbugs-Cc: jue.w...@oss.cipunited.com In debian/rules, this package expect a 'cross' option from DEB_BUILD_PROFILES, it is not usual method. In fact, we can detect cross building by compare BUILD and HOST just like other packages.
Bug#1025069: looks like its not conflicting with pulseaudio
It looks like it is not conflicting with pulseaudio. I tried these steps and I'm still have only "Dummy Output". I have not restarted though hans@delbin:~$ systemctl --user daemon-reload hans@delbin:~$ systemctl --user --now disable pulseaudio.service pulseaudio.socket hans@delbin:~$ systemctl --user --now enable pipewire pipewire-pulse Created symlink /home/hans/.config/systemd/user/default.target.wants/pipewire.service → /usr/lib/systemd/user/pipewire.service. Created symlink /home/hans/.config/systemd/user/sockets.target.wants/pipewire.socket → /usr/lib/systemd/user/pipewire.socket. Created symlink /home/hans/.config/systemd/user/default.target.wants/pipewire-pulse.service → /usr/lib/systemd/user/pipewire-pulse.service. Created symlink /home/hans/.config/systemd/user/sockets.target.wants/pipewire-pulse.socket → /usr/lib/systemd/user/pipewire-pulse.socket. hans@delbin:~$ LANG=C pactl info | grep '^Server Name' Server Name: PulseAudio (on PipeWire 0.3.61) hans@delbin:~$ $ systemctl --user --now enable wireplumber.service bash: $: command not found hans@delbin:~$ systemctl --user --now enable wireplumber.service hans@delbin:~$ systemctl --user --now enable pipewire pipewire-pulse hans@delbin:~$ systemctl --user --now start pipewire pipewire-pulse hans@delbin:~$ systemctl --user --now restart pipewire pipewire-pulse hans@delbin:~$ systemctl --user --now restart wireplumber.service hans@delbin:~$
Bug#1025299: libuv1: Fail to build
Package: libuv1 Version: 1.44.2-1 Severity: serious Tags: ftbfs Justification: FTBFS libuv1 fails to build: /usr/bin/ld: test/run_tests-test-poll-closesocket.o:./test/test-poll-closesocket.c:28: multiple definition of `sock'; test/run_tests-test-poll-close-doesnt-corrupt-stack.o:./test/test-poll-close-doesnt-corrupt-stack.c:35: first defined here collect2: error: ld returned 1 exit status make[3]: *** [Makefile:1851: test/run-tests] Error 1
Bug#1025259: Bug#1025196: zfp: (autopkgtest) needs update for python3.11: No module named 'zfpy'
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 I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfp/28796454/log.gz Testing with python3.11: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'zfpy' autopkgtest [01:18:36]: test autodep8-python3 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. Cheers Jochen From 401c0818741fcccac05c66a899319920fd415194 Mon Sep 17 00:00:00 2001 From: Jochen Sprickerhof Date: Fri, 2 Dec 2022 09:52:50 +0100 Subject: [PATCH] Use pybuild to compile for all Python versions Closes: #1025196 --- debian/control | 2 +- debian/rules | 13 +++-- 2 files changed, 4 insertions(+), 11 deletions(-) diff --git a/debian/control b/debian/control index b06e5d4..185b380 100644 --- a/debian/control +++ b/debian/control @@ -12,7 +12,7 @@ Build-Depends: cython3, gfortran, dh-python, - libpython3-dev, + libpython3-all-dev, pkg-kde-tools, python3-numpy, python3-setuptools, diff --git a/debian/rules b/debian/rules index c5428e1..55c2888 100755 --- a/debian/rules +++ b/debian/rules @@ -13,18 +13,11 @@ export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic # Package maintainers to append LDFLAGS. #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -export PYBUILD_NAME=zfpy +export PYBUILD_CONFIGURE_ARGS=-DBUILD_ZFORP=ON -DBUILD_ZFPY=ON -DZFP_BUILD_TESTING_SMALL=OFF -DZFP_BIT_STREAM_WORD_SIZE=8 +export PYBUILD_SYSTEM=cmake %: - dh $@ --with python3,pkgkde_symbolshelper --buildsystem=cmake - -override_dh_auto_configure: - dh_auto_configure -- \ - -DBUILD_ZFORP=ON \ - -DBUILD_ZFPY=ON \ - -DZFP_BUILD_TESTING_SMALL=OFF \ - -DZFP_BIT_STREAM_WORD_SIZE=8 \ - -DCMAKE_BUILD_TYPE=RelWithDebInfo + dh $@ --with python3,pkgkde_symbolshelper --buildsystem=pybuild override_dh_dwz: @echo "BYE DWZ" -- 2.38.1 signature.asc Description: PGP signature
Bug#1025299: False positive
Sorry for the noise, local problem Cheers, Yadd
Bug#941627: Packaging grub-btrfs
Hi Nicholas, it's good we get this process going again. It looks like every other Debian spin-off has a package already, so let's get one into Debian. ;-) Let me clarify some things below. Quoting Nicholas D Steeves : Control: retitle -1 RFP: grub-btrfs -- provides grub entries for btrfs snapshots (boot environments/restore points) Control: noowner We have a package already from the dev of Kaisen Linux which that dev wanted to contribute to Debian after getting a sponsor. So if you are still interested into packaging grub-btrfs I would suggest the guy from kaisen linux prepares his Debian package and you sponsor it maybe? What is Kaisen Linux? I read issue #236 that you linked to, and it seems like geckolinux (author of Spiral Linux or Gecko Linux?) should possibly be part of this conversation. Kali Linux also has its own packaging. Kaisen is a Linux distribution for IT-Admins that is based on Debian testing. They got their own grub-btrfs .deb package already and the dev of them (KaisenCAS in that conversation) has declared his will to maintain the Debian package in the future. 2. Whether manually, or with CI, there needs to be one or more regularly tested configurations. For example, a Snapper-based snapshot layout, Timeshift, or some_other_tool-based snapshot layout. I hope geckolinux can help with this. This one is important to critical. If a normal user loses data while doing something completely reasonable, then we've failed to consider the problem with due diligence. I'm also aware that Neptune OS and Linux Mint are using Timeshift. Yes, this is something we need to consider. I think grub-btrfs is 'wild'-tested in many different configurations by our users already, mostly by people who have the live build of it on Arch and Gentoo, but we have to put his into regulated procedures. I think regarding tests on Debian based distros geckolinux and Kaisen are doing this already. 3. Does Timeshift's (already in Debian) GRUB menu entry support (is this enabled yet?) conflict with grub-btrfs? Are there any other conflicts? For example, ZFS stuff? Any other pitfalls that may cause data lose? This one is important to critical. I will try this out, but I don't think it will. We just generate a grub-submenu with snapshot entries and do not touch the snapshots themselves no do we touch the other grub-submenues. 4. I think everyone will agree that users who install this will have a reasonable expectation of automatic boot environments/system restore points. This requires an apt trigger in whatever tool is used to make the snapshots. This one is normal. I don't think this is in the scope of grub-btrfs. We are generating the grub menu entries, that's it. We don't generate snapshots and there are already programs out there that are doing this way better we ever could. But I totally understand the need for Debian to integrate something like that. On Arch they seem to have hooks in pacman and users can just put there own commands there. There is Timeshift-Autosnap [1] (and many similar scripts) for that. There is also a apt version of that already. However, grub-btrfs is just looking for the snapshots and generates the grub submenu from the list that 'btrfs subvolume list' gives it. 5. A decision needs to be made about what layouts will be supported, and what layouts will be "if it breaks, you're on your own". It's possible (but unlikely, as far as I can tell) that additional Debian Installer work will be necessary. This is arguably just another aspect of #1. As far as I can tell, the following are the cases this package will encounter, in order of most common to least common: a) Our default @rootfs, no other subvolumes. b) @roots, and @home -- Ahem! This seems like it will be required, to not lose user data! Yes, this is why I stalled for so long. Debian Installer is not fun to work on. c) Either support old installations directly on subvolid=5, or loudly declare that they're not supported somewhere in the description and documentation. Seems like user data will be lost similarly to "b" d) How to protect /var/www as well as databases? e) Snapper/SUSE style, which is a superset of Ubuntu-style, as far as I can tell, or maybe Ubuntu-style is a subset of SUSE? Does anyone know? f) Ubuntu-style @ and @home This is mostly relevant to snapshot generation program like timeshift and snapper, but I can see that this could be important for us when booting with overlayfs. 6. And what happens when a user has both Debian stable and unstable/sid (or Ubuntu) installed to the same drive, and both have grub-btrfs installed? What is "The Right Thing" in this case, and will grub-btrfs Do The Right Thing? This question prompted the discussion that led to rootfs on "@rootfs" rather than "@" like Ubuntu/SUSE or "rootfs" like Fedora. I can see that this could get very complicated. I think the right thing would
Bug#1025300: octocatalog-diff crashes when the diff changes existing resources
Package: octocatalog-diff Version: 2.1.0-1 Severity: important Tags: patch upstream Control: forwarded -1 https://github.com/github/octocatalog-diff/issues/261 octocatalog-diff crashes when a diff contains changes to an existing resource with the following stack trace: /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter/compilation_dir.rb:72:in `new': tried to create Proc object without a block (ArgumentError) from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter/compilation_dir.rb:72:in `block in traverse' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter/compilation_dir.rb:72:in `map' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter/compilation_dir.rb:72:in `traverse' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter/compilation_dir.rb:63:in `remove_compilation_dir' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter/compilation_dir.rb:40:in `filtered?' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter.rb:62:in `block in filter' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter.rb:62:in `reject!' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter.rb:62:in `filter' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter.rb:42:in `block in apply_filters' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter.rb:42:in `each' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/filter.rb:42:in `apply_filters' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/differ.rb:207:in `catdiff' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/catalog-diff/differ.rb:83:in `diff' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/cli/diffs.rb:34:in `diffs' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/api/v1/catalog-diff.rb:54:in `catalog_diff' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/api/v1.rb:19:in `catalog_diff' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/cli.rb:152:in `run_octocatalog_diff' from /usr/lib/ruby/vendor_ruby/octocatalog-diff/cli.rb:126:in `cli' from /usr/bin/octocatalog-diff:34:in `' I've reported this to upstream as issue #261[0], and attached a possible fix on the upstream issue report too. [0]: https://github.com/github/octocatalog-diff/issues/261 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') 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 octocatalog-diff depends on: ii ruby 1:3.0+3.1 ii ruby-diffy 3.4.2-1 ii ruby-hashdiff 1.0.1-1 ii ruby-httparty 0.20.0-2 ii ruby-parallel 1.22.1-1 ii ruby-rugged1.5.0.1+ds-1 octocatalog-diff recommends no packages. octocatalog-diff suggests no packages. -- no debconf information OpenPGP_0xEF242F709F912FBE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#922584: [Help] Re: FTBFS against opencv 4.0.1 (exp)
Am Thu, Dec 01, 2022 at 11:39:47PM +0200 schrieb Adrian Bunk: > [1] contains a patch from a Debian porter, but considering the facts > that limereg already missed the current Debian stable bullseye and the > comment from upstream (who is also the original Debian packager) in [2], > removal from Debian might be a better option? > > I do not know how limereg compares to other tools like for example > elastix (based on ITK) or registrationx (part of CMTK) or other tools, > but neither the upstream bug tracker nor the Debian BTS indicate that > there would be an active userbase who report bugs or complained that > limereg is not in bullseye. I'll immediately ask for removal of this package. Kind regards Andreas. > [1] https://github.com/RoelofBerg/limereg/issues/3 > [2] https://github.com/RoelofBerg/limereg/issues/3#issuecomment-1296863979 -- http://fam-tille.de
Bug#1025301: RM: limereg -- ROM; Unmaintained upstream + RC buggy
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: 922...@bugs.debian.org Hi, as discussed in bug #922584 its not worth to keep limereg in Debian. Its not maintained upstream and FTBFS against opencv 4. So please remove this package from Debian. Kind regards Andreas.
Bug#1025302: RM: limereg -- ROM; Unmaintained upstream + RC buggy
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: 922...@bugs.debian.org Hi, as discussed in bug #922584 its not worth to keep limereg in Debian. Its not maintained upstream and FTBFS against opencv 4. So please remove this package from Debian. Kind regards Andreas.
Bug#1025303: maliit-inputcontext-gtk3: installs its IM module to a path GTK does not read
Source: maliit-inputcontext-gtk3
Version: 0.99.1+git20151116.72d7576-1
Severity: grave
maliit-inputcontext-gtk3 installs input modules into /usr/lib/gtk-3.0,
but GTK 3 stopped searching that directory in 2015 (3.18.0-1) after all
other GTK modules were updated to install into
/usr/lib/${DEB_HOST_MULTIARCH}/gtk-3.0. As a result, unless there is
something weird going on here, maliit-inputcontext-gtk3 will not actually
do anything. (I have not verified this, I don't have Maliit installed.)
maliit-inputcontext-gtk was first uploaded in July 2022, which makes me
wonder how it ever worked. How was this package tested?
Similarly, maliit-inputcontext-gtk2 installs input modules into
/usr/lib/gtk-2.0, which is only supported because of a Debian-specific
patch. It should install into an equivalent path below
/usr/lib/${DEB_HOST_MULTIARCH}/gtk-2.0 instead (although this part is not
currently RC, because GTK 2 still has that patch).
Looking at the source code, it seems that this package uses non-standard
installation directories (doesn't use GNUInstallDirs), but building with
COMMON_CONFIGURE_FLAGS += -DLIB_INSTALL_DIR="lib/${DEB_HOST_MULTIARCH}"
is likely to be sufficient.
smcv
Bug#1025304: maliit-inputcontext-gtk3: installs its IM module to a path GTK does not read
Package: maliit-inputcontext-gtk3
Version: 0.99.1+git20151116.72d7576-1
Severity: grave
maliit-inputcontext-gtk3 installs input modules into /usr/lib/gtk-3.0,
but GTK 3 stopped searching that directory in 2015 (3.18.0-1) after all
other GTK modules were updated to install into
/usr/lib/${DEB_HOST_MULTIARCH}/gtk-3.0. As a result, unless there is
something weird going on here, maliit-inputcontext-gtk3 will not actually
do anything. (I have not verified this, I don't have Maliit installed.)
maliit-inputcontext-gtk was first uploaded in July 2022, which makes me
wonder how it ever worked. How was this package tested?
Similarly, maliit-inputcontext-gtk2 installs input modules into
/usr/lib/gtk-2.0, which is only supported because of a Debian-specific
patch. It should install into an equivalent path below
/usr/lib/${DEB_HOST_MULTIARCH}/gtk-2.0 instead (although this part is not
currently RC, because GTK 2 still has that patch).
Looking at the source code, it seems that this package uses non-standard
installation directories (doesn't use GNUInstallDirs), but building with
COMMON_CONFIGURE_FLAGS += -DLIB_INSTALL_DIR="lib/${DEB_HOST_MULTIARCH}"
is likely to be sufficient.
smcv
Bug#1025305: RM: limereg -- ROM; Unmaintained upstream + RC buggy
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: 922...@bugs.debian.org Hi, as discussed in bug #922584 its not worth to keep limereg in Debian. Its not maintained upstream and FTBFS against opencv 4. So please remove this package from Debian. Kind regards Andreas.
Bug#923345: evince cannot start default browser due to AppArmor
Hi,
On Sun, 22 May 2022 07:53:43 +0200 intrigeri wrote:
> This suggests it's a bug in the exo-open abstraction.
> Is this problem fixed by adding the following line to
> /etc/apparmor.d/abstractions/exo-open
> /{,usr/}bin/xfce4-mime-helper rix,
> ?
>
> If that's enough, I'm happy to submit the fix upstream.
I had this problem for quite some time, and this did fix it for me after a
[sudo service apparmor reload]. Thanks!
I'm wondering however if this fix could be dangerous?
I'm fine with following URLs in the pdf files I read with evince, but I'm
happy to know that apparmor is preventing other dangerous things ; isn't
this fix defeating's some security mechanism? (other apps, other
mime-types...)
Best,
Damien
Bug#1023149: marked as done (pandoc FTBFS on i386)
On Fri, Nov 25, 2022 at 10:31:01AM -0700, John MacFarlane wrote: > Just an observation: adding the -O0 option here will create an unoptimized > build, which will run more slowly. So this is definitely not a patch that > should remain more than short-term. >... That's clear, but it is only on i386 (the old 32bit architecture). While I agree that this is not an appropriate long-term fix, slow pandoc on i386 should not be a problem for many users. cu Adrian
Bug#1025146: RM: simbody [mips64el ppc64el] -- ROM; FTBFS on mips64el and ppc64el
Hi Scott, On Wed, 30 Nov 2022 13:24:35 -0500 Scott Kitterman wrote: There are reverse depends that need to be addressed first (unless these are all arch: all, I didn't actually check). Please remove the moreinfo tag once these are resolved. All of the reverse dependencies are arch:any. Does this mean I have to RM them before simbody? I never did RMs for non-leaf packages before. Best, Andrius
Bug#1025306: ITP: carrotsearch-procfork -- process forking/killing utility
Package: wnpp Owner: Andrius Merkys Severity: wishlist Control: block 1020551 by -1 * Package name: carrotsearch-procfork Version : 1.0.6~git20211215.86e726d+ds Upstream Author : Dawid Weiss * URL : https://github.com/carrotsearch/procfork * License : BSD-3-Clause-with-acknowledgement Programming Lang: Java Description : Process forking/killing utility carrotsearch-procfork is required to package lucene9. Remark: This package is to be maintained with Debian Java Maintainers at https://salsa.debian.org/java-team/carrotsearch-procfork
Bug#1025307: yosys mips64el build failure (fix)
Package: yosys Version: 0.23-3 Hi, I've done some work on why the mips64el build fails. The issue is that the test script tests/sat/grom.ys makes yosys core in libs/fst/fstapi.cc:fstGetUint32 Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not defined, an address on the stack is returned to calling function. Because the Debian build uses various hardening flags to protect accesses to the stack that makes a segfault. The quick fix appears to be to add: -DFST_DO_MISALIGNED_OPS to CPPFLAGS. (i386 and amd64 already have this hardwired in the code.) I've tested this best I could by cross-compiling and running the binary under qemu. It passed all the tests in tests/sat. The real fix would be to either assume that all architectures can run with FST_DO_MISALIGNED_OPS and remove the broken code or fix fstGetUint32 so it returns memory allocated correctly, but either of those is a job for upstream. Cheers, Scott
Bug#1025308: gsequencer: FTBFS with fftw3 (3.3.10-1)
Source: gsequencer Version: 4.4.1-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 gsequencer-4.4.1/debian/changelog gsequencer-4.4.1/debian/changelog --- gsequencer-4.4.1/debian/changelog 2022-09-16 05:57:45.0 +0200 +++ gsequencer-4.4.1/debian/changelog 2022-12-02 12:21:38.0 +0100 @@ -1,3 +1,10 @@ +gsequencer (4.4.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Build depend on libfftw3-dev, fftw3-dev no longer provided. + + -- Bas Couwenberg Fri, 02 Dec 2022 12:21:38 +0100 + gsequencer (4.4.1-1) unstable; urgency=medium * New upstream version 4.4.1 diff -Nru gsequencer-4.4.1/debian/control gsequencer-4.4.1/debian/control --- gsequencer-4.4.1/debian/control 2022-09-16 05:57:45.0 +0200 +++ gsequencer-4.4.1/debian/control 2022-12-02 12:21:31.0 +0100 @@ -10,7 +10,7 @@ docbook-xml, docbook-xsl, dssi-dev, - fftw3-dev, + libfftw3-dev, fop, gettext, gstreamer1.0-plugins-bad,
Bug#1025310: libsamplerate: FTBFS with fftw3 (3.3.10-1)
Source: libsamplerate Version: 0.2.2-2 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 libsamplerate-0.2.2/debian/changelog libsamplerate-0.2.2/debian/changelog --- libsamplerate-0.2.2/debian/changelog2022-09-29 10:23:59.0 +0200 +++ libsamplerate-0.2.2/debian/changelog2022-12-02 13:03:36.0 +0100 @@ -1,3 +1,10 @@ +libsamplerate (0.2.2-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Build depend on libfftw3-dev, fftw3-dev no longer provided. + + -- Bas Couwenberg Fri, 02 Dec 2022 13:03:36 +0100 + libsamplerate (0.2.2-2) unstable; urgency=medium [ Jenkins ] diff -Nru libsamplerate-0.2.2/debian/control libsamplerate-0.2.2/debian/control --- libsamplerate-0.2.2/debian/control 2022-09-29 10:23:59.0 +0200 +++ libsamplerate-0.2.2/debian/control 2022-12-02 13:03:34.0 +0100 @@ -6,7 +6,7 @@ IOhannes m zmölnig (Debian/GNU) , Build-Depends: debhelper-compat (= 13), - fftw3-dev, + libfftw3-dev, libsndfile1-dev, pkg-config, Standards-Version: 4.6.1
Bug#1025311: solvespace: missing builds on mipsel and mips64el
Source: solvespace Version: 3.1+ds1-2 Severity: serious Tags: ftbfs Hi Maintainer The upload of solvespace 3.1+ds1-2 includes the change 'Drop s390x architecture due to test failures' [1], however the way this was done didn't only drop s390x, but also mipsel, mips64el, riscv64 and several other ports. The missing builds on mipsel and mips64el now prevent migration of solvespace to testing. Seeing that solvespace builds fine on s390x, if the failing tests cannot be fixed, you could skip them on s390x only. See my proposed debian/tests/control file below. You could also try asking on debian-s...@lists.debian.org for help. Regards Graham [1] https://salsa.debian.org/science-team/solvespace/-/commit/660e95c1d4583e078e31c5f91e7cd57f1aa1c7d1 Tests: htmlmesh stlmesh surfaces Restrictions: allow-stderr Depends: solvespace, findutils, grep Architecture: !s390x Tests: thumbnail view wireframe Restrictions: allow-stderr Depends: solvespace, findutils, grep
Bug#1025146: RM: simbody [mips64el ppc64el] -- ROM; FTBFS on mips64el and ppc64el
On December 2, 2022 11:40:18 AM UTC, Andrius Merkys wrote: >Hi Scott, > >On Wed, 30 Nov 2022 13:24:35 -0500 Scott Kitterman >wrote: >> There are reverse depends that need to be addressed first (unless these are >> all arch: all, I didn't actually check). Please remove the moreinfo tag >> once these are resolved. > >All of the reverse dependencies are arch:any. Does this mean I have to RM them >before simbody? I never did RMs for non-leaf packages before. Yes. Please file separate rm bugs for these. Scott K
Bug#1025312: libgl1-mesa-dri: multiple packages FTBFS and have autopkgtest regressions running test programs under Xvfb
Package: libgl1-mesa-dri Version: 22.3.0-1 Severity: serious Justification: FTBFS and autopkgtest regression in affected packages To reproduce: - Install a minimal amd64 VM with Debian testing and mesa_22.2.4-1 - apt --no-install-recommends build-dep gtk+3.0 - Build source package gtk+3.0_3.24.35-1 (it succeeds) - Upgrade all packages except the ones from src:mesa to sid - Build source package gtk+3.0_3.24.35-1 (it succeeds) - Upgrade binary packages from src:mesa - Build source package gtk+3.0_3.24.35-1 or alternatively: - Install a chroot/container with Debian testing - Run the autopkgtests for gtk+3.0 (it succeeds) - Upgrade binary packages from src:mesa to 22.3.0-1 - Run the autopkgtests for gtk+3.0 or more minimally: - 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 Expected result: successful build from source, or successful autopkgtest Actual result: FTBFS or failing autopkgtest; the test programs are unable to connect to the Xvfb server. The autopkgtests for clutter-1.0, cogl, gtk4, juce, kodi, muffin, mutter, njplot, openscad and pyopengl show similar symptoms, affecting at least amd64 and arm64. The kodi autopkgtest shows this backtrace which might be helpful: autopkgtest [17:19:52]: test gui: [--- (EE) (EE) Backtrace: (EE) 0: Xvfb (OsLookupColor+0x139) [0x562b8573d239] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fee8f45af90] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7fee8fdbe029] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7fee8f56de9a] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7fee8f56df4f] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7fee8f4a3dc7] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7fee8f4a3b26] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7fee8d70ff44] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7fee8d70f190] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7fee8ccd2179] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7fee8d2dd156] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7fee8d2dd0c4] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7fee8ccd2a34] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7fee8ccdc4b5] (EE) 14: Xvfb (ht_dump_contents+0x81a7) [0x562b856397e7] (EE) 15: Xvfb (ht_dump_contents+0x6faf) [0x562b856385ef] (EE) 16: Xvfb (_CallCallbacks+0x34) [0x562b856e8b64] (EE) 17: Xvfb (ht_dump_contents+0x2863f) [0x562b85659c7f] (EE) 18: Xvfb (InitExtensions+0x89) [0x562b855fa919] (EE) 19: Xvfb (InitFonts+0x1e8) [0x562b856e7628] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7fee8f44618a] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7fee8f446245] (EE) 22: Xvfb (_start+0x21) [0x562b855f8921] (EE) (EE) Segmentation fault at address 0x337 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) xvfb-run: error: Xvfb failed to start I get a similar backtrace when I try to run xvfb-run -e /dev/stderr -a /usr/libexec/installed-tests/gtk+/builder in a qemu VM. smcv
Bug#1025313: nip2: FTBFS with fftw3 (3.3.10-1)
Source: nip2 Version: 8.7.1-3 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 making libfftw3-dev the first alternative. Kind Regards, Bas diff -Nru nip2-8.7.1/debian/changelog nip2-8.7.1/debian/changelog --- nip2-8.7.1/debian/changelog 2022-05-26 18:28:53.0 +0200 +++ nip2-8.7.1/debian/changelog 2022-12-02 13:09:59.0 +0100 @@ -1,3 +1,10 @@ +nip2 (8.7.1-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Build depend on libfftw3-dev, fftw3-dev no longer provided. + + -- Bas Couwenberg Fri, 02 Dec 2022 13:09:59 +0100 + nip2 (8.7.1-3) unstable; urgency=medium * Backport upstream fix for compilation with ICU 68+ (closes: #1011693). diff -Nru nip2-8.7.1/debian/control nip2-8.7.1/debian/control --- nip2-8.7.1/debian/control 2021-01-19 06:42:23.0 +0100 +++ nip2-8.7.1/debian/control 2022-12-02 13:09:59.0 +0100 @@ -1,7 +1,7 @@ Source: nip2 Section: graphics Priority: optional -Build-Depends: debhelper-compat (= 12), libglib2.0-dev, libpango1.0-dev, libatk1.0-dev, libgtk2.0-dev, libvips-dev (>= 8.4), shared-mime-info, gnome-icon-theme, hicolor-icon-theme, flex, bison, intltool, fftw3-dev | libfftw3-dev, libxml2-dev, pkg-config, libjpeg-dev, zlib1g-dev, libpng-dev, libmagickcore-dev, libmagickwand-dev, libfreetype6-dev, libfontconfig1-dev, libice-dev, gettext, libgsl-dev, libgraphviz-dev +Build-Depends: debhelper-compat (= 12), libglib2.0-dev, libpango1.0-dev, libatk1.0-dev, libgtk2.0-dev, libvips-dev (>= 8.4), shared-mime-info, gnome-icon-theme, hicolor-icon-theme, flex, bison, intltool, libfftw3-dev | fftw3-dev, libxml2-dev, pkg-config, libjpeg-dev, zlib1g-dev, libpng-dev, libmagickcore-dev, libmagickwand-dev, libfreetype6-dev, libfontconfig1-dev, libice-dev, gettext, libgsl-dev, libgraphviz-dev Maintainer: Laszlo Boszormenyi (GCS) Standards-Version: 4.5.1 Homepage: https://github.com/libvips/nip2
Bug#999936: uwsgi: depends on obsolete pcre3 library
Control: forwarded -1 https://github.com/unbit/uwsgi/issues/2486 On Thu, 18 Nov 2021 11:49:08 + Matthew Vernon wrote: > Source: uwsgi > Usertags: obsolete-pcre3 Upstream project has an issue for it, updating metadata accordingly signature.asc Description: This is a digitally signed message part.
Bug#1025314: linux: ext4 checksum errors after resizing
Package: linux-image-6.0.0-0.deb11.2-cloud-amd64 Version: 6.0.3-1~bpo11+1 The bullseye-backports 6.0.3 kernel contains an ext4 bug that causes the filesystem to become corrupted after resizing the filesystem. See https://www.spinics.net/lists/linux-ext4/msg85795.html for details and a reproducer. This is particularly problematic on systems that resize the root filesystem during boot using systemd-growfs or similar. ext4 remounts the filesystem read only after the checksum fails and the system becomes unbootable. This happens on the EC2 cloud images, for example. The fix at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/ext4?h=linux-6.0.y&id=2f8d9b94176d48d733a461e13bb4f6589653ba05 is in 6.0.8. Some further fixes are identified at https://www.spinics.net/lists/linux-ext4/msg86163.html but those haven't been merged yet. I haven't tested either, but I presume the fix already on 6.0.8 is enough and the remaining fixes are more for correctness. -- Dan Nicholson | Endless OS Foundation
Bug#1023945: Mozilla and Microsoft acted
Please note that Mozilla and Microsoft have removed the certificates now. It is probably now appropriate to follow Mozilla. Google's and Apple's reaction is still open. Regards signature.asc Description: This is a digitally signed message part
Bug#1025315: pyxplot: FTBFS with fftw3 (3.3.10-1)
Source: pyxplot Version: 0.9.2-12 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 pyxplot-0.9.2/debian/changelog pyxplot-0.9.2/debian/changelog --- pyxplot-0.9.2/debian/changelog 2020-12-28 08:42:15.0 +0100 +++ pyxplot-0.9.2/debian/changelog 2022-12-02 13:29:47.0 +0100 @@ -1,3 +1,10 @@ +pyxplot (0.9.2-12.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Build depend on libfftw3-dev, fftw3-dev no longer provided. + + -- Bas Couwenberg Fri, 02 Dec 2022 13:29:47 +0100 + pyxplot (0.9.2-12) unstable; urgency=medium * Update Standards-Version to 4.5.1 (no changes required). diff -Nru pyxplot-0.9.2/debian/control pyxplot-0.9.2/debian/control --- pyxplot-0.9.2/debian/control2020-12-28 08:42:15.0 +0100 +++ pyxplot-0.9.2/debian/control2022-12-02 13:29:45.0 +0100 @@ -4,7 +4,7 @@ Section: math Build-Depends: debhelper-compat (= 13), - fftw3-dev, + libfftw3-dev, ghostscript, imagemagick, libcfitsio-dev,
Bug#1018505: python-gssapi: build-depends on python3-nose or uses it for autopkgtest
Hi, I checked the upstream source, and I found the upstream stopped using nose since v1.7.3 with the commit 5552513a47a636a4d956f76b498c6fa2e368cc98 . So I think we can re-package the more recent upstream to resolve this issue. -tai
Bug#1025314: linux: ext4 checksum errors after resizing
Control: forcemerge 1023450 -1 On Fri, Dec 02, 2022 at 05:35:06AM -0700, Dan Nicholson wrote: > The bullseye-backports 6.0.3 kernel contains an ext4 bug that causes > the filesystem to become corrupted after resizing the filesystem. See > https://www.spinics.net/lists/linux-ext4/msg85795.html for details and > a reproducer. This is a duplicate and already fixed, thus merging the bug reports. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Bug#1025314: linux: ext4 checksum errors after resizing
It's not fixed on bullseye-backports. I checked yesterday and there have been no commits on that branch since the 6.0.3 upload. On Fri, Dec 2, 2022, 5:51 AM Bastian Blank wrote: > Control: forcemerge 1023450 -1 > > On Fri, Dec 02, 2022 at 05:35:06AM -0700, Dan Nicholson wrote: > > The bullseye-backports 6.0.3 kernel contains an ext4 bug that causes > > the filesystem to become corrupted after resizing the filesystem. See > > https://www.spinics.net/lists/linux-ext4/msg85795.html for details and > > a reproducer. > > This is a duplicate and already fixed, thus merging the bug reports. > > Bastian > > -- > Earth -- mother of the most beautiful women in the universe. > -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 >
Bug#1025307: yosys mips64el build failure (fix)
Hi Scott,
thanks for having a look.
On Mon, Nov 28, 2022 at 03:14:59PM +, Scott Ashcroft wrote:
> I've done some work on why the mips64el build fails.
> The issue is that the test script tests/sat/grom.ys makes yosys core in
> libs/fst/fstapi.cc:fstGetUint32
>
> Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
> defined, an address on the stack is returned to calling function.
I'm not sure what you mean here, my reading of the code is that it's just
tring to read a big-endian uint32_t at the given address regardless of
alignment. No address is returned.
> Because the Debian build uses various hardening flags to protect
> accesses to the stack that makes a segfault.
While the code is indeed a bit iffy TBH I don't really see why it should
crash even with the stack protector etc. enabled.
Regardless if you still have a test environment could you try the attached
patch that turns the roundabout u8 to u32 conversion into a (hopefully)
more portable roundtrip through a union.
--Daniel
--- a/libs/fst/fstapi.cc
+++ b/libs/fst/fstapi.cc
@@ -348,17 +348,17 @@ static void *fstMmap2(size_t __len, int
#ifdef FST_DO_MISALIGNED_OPS
#define fstGetUint32(x) (*(uint32_t *)(x))
#else
-static uint32_t fstGetUint32(unsigned char *mem)
+static inline uint32_t fstGetUint32(unsigned char *mem)
{
-uint32_t u32;
-unsigned char *buf = (unsigned char *)(&u32);
+union {
+uint8_t u8[sizeof(uint32_t)];
+uint32_t u32;
+} u;
-buf[0] = mem[0];
-buf[1] = mem[1];
-buf[2] = mem[2];
-buf[3] = mem[3];
+for (int i=0; i < sizeof(u.u8); i++)
+u.u8[i] = mem[i];
-return (*(uint32_t *)buf);
+return u.u32;
}
#endif
Bug#985678: ITA: rasdaemon -- utility to receive RAS error tracings
Status update: - Newer upstream is packaged for uploading to Sid https://people.canonical.com/~taihsiang/rasdaemon-amd64/rasdaemon_0.6.8-1/ . - Bullseye backporting is still on the way. I finished its testing across arch with the above package. = NEXT STEP = In short, if someone: 1) could help us to review my packaging and 2) has permission to upload the package after reviewing we can then resolve this issue. Cheers, Tai On Sun, May 15, 2022 at 10:00 AM Taihsiang Ho (tai271828) wrote: > > HI everyone, some updates for closing this issue: > > 1. The package has been repackaged by Russel (Russell > Coker ) and uploaded to sid and bookworm as > version 0.6.7-1 > > 2. What's the next step? Russel and I will work together to maintain > rasdaemon, including: > 2-1. Backporting rasdaemon to bullseye. > 2-1-1. The backporting looks promising. I have packaged rasdaemon > based on Russel's effort for 0.6.7-1 with gbp flow > https://salsa.debian.org/tai271828/rasdaemon-russel > 2-1-2. Besides, the package has been tested with Ubuntu Jammy on arch > amd64, and it looks good to me[1]. The remaining tasks are 1) test the > package on arm64 2) test the package with bullseye on amd64/arm64. Let > me know if you are interested in co-working with us. > 2-1-3. If possible, I will try to fix this issue > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006344 before > uploading the package to bullseye. > > I will try to bump the version of rasdaemon to add "Closes: #985678" > when the above tasks are done. > > [1] What I meant by "testing looks good": edac-fake-inject and > edac-tests could inject fake events and caught by rasdaemon (via > ras-mc-ctl --summary) > > -tai > > > > On Wed, Dec 8, 2021 at 12:36 AM Taihsiang Ho (tai271828) > wrote: > > > > If you are interested in testing the current package under development, you > > may clone it via the dev-packaging-upstream-0.6.7 branch: > > git clone https://salsa.debian.org/tai271828/rasdaemon.git -b > > dev-packaging-upstream-0.6.7 > > > > - tai > > > > On Wed, Dec 8, 2021 at 12:01 AM Taihsiang Ho (tai271828) > > wrote: > >> > >> Hi, everyone, > >> > >> Even though it is slow, I still made some progress. Let me elaborate here > >> so you may know the current status from my side: > >> > >> - The latest upstream v0.6.7 has been packaged. See my repository > >> https://salsa.debian.org/tai271828/rasdaemon.git forked from ahs3's > >> repository https://salsa.debian.org/ahs3/rasdaemon > >> - I packaged the upstream v0.6.7 with its release tarball > >> https://www.infradead.org/~mchehab/rasdaemon/rasdaemon-0.6.7.tar.bz2 > >> - The package has not been well tested across platforms and archs. Once I > >> complete the test and confident that the package works properly, I will > >> seek for Debian developers' or maintainers' help to upload the package. > >> > >> You may build the package with this command: > >> gbp buildpackage --git-ignore-new --git-builder=sbuild > >> > >> I am very new to the whole packaging and ITA process, so I believe the > >> package needs a review by experts or veterans. In the meantime, if you are > >> interested in this work, or aware of anything that needs to do or improve. > >> Please let me know. I will appreciate your feedback. > >> > >> Cheers, > >> Tai
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,
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#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#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#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#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#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#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#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#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 - > -- > Steve
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#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#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#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#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#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#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#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#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#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#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#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#1024802: new monitor that works
I bought a new monitor, confirming that it works. The problem seems to be with older devices.
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 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&literal=1 But they are built successfully, including the golang-github-prometheus-client-golang package. -- Shengjing Zhu
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#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#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#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#1024494: ITP: python3-fints -- python library for the FinTS protocol
Sorry. I moved it to https://salsa.debian.org/werdahias/python-fints Matthias
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#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#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#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#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#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#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&distri=debian&flavor=live-build&machine=64bit&test=live-build-desktop_browser&version=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#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#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#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#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#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#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#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#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#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#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#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#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#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
