Bug#1031773: mariadb-10.3.38.0+deb10u1: kmail fails after upgrading mariadb to 10.3.38.0+deb10u1
Forwarded: https://lists.launchpad.net/maria-discuss/msg06508.html This is most likely a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863
Bug#1032448: marked as done (gnome-initial-setup: no longer starts)
Your message dated Tue, 07 Mar 2023 00:19:01 + with message-id and subject line Bug#1032448: fixed in gnome-initial-setup 43.2-4 has caused the Debian Bug report #1032448, regarding gnome-initial-setup: no longer starts to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1032448: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032448 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: gnome-initial-setup Version: 43.2-3 Severity: serious After installing gnome-initial-setup from Unstable on my Debian Testing system, gnome-initial-setup no longer starts. When run in a terminal, I get a warning about Invalid cast from 'GtkBox' to 'GtkListBowRow' It looks like this issue was caused by one of the new keyboard patches. gnome-initial-setup 43.2-3 did start for me on login at least once so it seems it works occasionally. Here are 3 variations of how to test to make sure it's working. I guess I should add these to a README somewhere. Test Case 1 --- rm ~/.config/gnome-initial-setup-done Log out then log back in gnome-initial-setup should automatically start Test Case 2 Create a new user Log in as the new user gnome-initial-setup should automatically start Test Case 3 Run this command /usr/libexec/gnome-initial-setup --existing-user Thank you, Jeremy Bícha --- End Message --- --- Begin Message --- Source: gnome-initial-setup Source-Version: 43.2-4 Done: Simon McVittie We believe that the bug you reported is fixed in the latest version of gnome-initial-setup, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1032...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Simon McVittie (supplier of updated gnome-initial-setup package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 06 Mar 2023 23:46:19 + Source: gnome-initial-setup Architecture: source Version: 43.2-4 Distribution: unstable Urgency: medium Maintainer: Debian GNOME Maintainers Changed-By: Simon McVittie Closes: 1032448 Changes: gnome-initial-setup (43.2-4) unstable; urgency=medium . * Team upload * d/p/keyboard-Resort-refilter-list-when-picking-shortlist.patch: Add patch from upstream 44.rc to display more input methods and keyboard layouts without clicking the "more..." button. This has a known issue that the shortlist of keyboard layouts is often not particularly useful, but at least it includes the default and current layouts (possibly different) and some other possibilities. * d/p/keyboard-Correctly-update-labels-for-IBus-engines.patch, d/p/keyboard-Update-filter-and-sort-when-the-display-name-cha.patch: Rework patches for xkb layout and IBus method selection, fixing a crash on startup (Closes: #1032448) * d/README.source: Add some notes on how to smoke-test this package. Thanks to Jeremy Bicha (via #1032448) * d/p/driver-Set-a-non-trivial-window-title.patch: Add patch to set a window title. This is one of the first things a new GNOME user will see, so let's make it a bit more polished. Checksums-Sha1: d5eaefb35a0352011a4984334de20331c6599ff8 3126 gnome-initial-setup_43.2-4.dsc 860293cff03e48409068f0d559dd4192548b8e02 12640 gnome-initial-setup_43.2-4.debian.tar.xz 336b9984598d81db20017e696eb34a2b28bc3f24 20469 gnome-initial-setup_43.2-4_source.buildinfo Checksums-Sha256: f2e605249fc901e3f0ac1c4c8a5c4841dc0bab68476602e45a391931ed301df6 3126 gnome-initial-setup_43.2-4.dsc 4e69eda5fee71391267aeda3cc2bb14df8a75e598bd29b4eb34c266a22e3f261 12640 gnome-initial-setup_43.2-4.debian.tar.xz 69b7bd6da9a4ee67fb844358cc2c9f89b5e02614bd2765174311aa2474f5c4a2 20469 gnome-initial-setup_43.2-4_source.buildinfo Files: f2322880d9d1190a6b1d3863200ad0ab 3126 gnome optional gnome-initial-setup_43.2-4.dsc 1db3dfb3104aeff4ff911660e95bf2b2 12640 gnome optional gnome-initial-setup_43.2-4.debian.tar.xz f5e019fb81e966f6315be871bd611707 20469 gnome optional gnome-initial-setup_43.2-4_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAmQGf1gACgkQ4FrhR4+B
Processed: Re: Bug#1032448: gnome-initial-setup: no longer starts
Processing control commands: > tags -1 + pending Bug #1032448 [src:gnome-initial-setup] gnome-initial-setup: no longer starts Added tag(s) pending. -- 1032448: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032448 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1032448: gnome-initial-setup: no longer starts
Control: tags -1 + pending On Mon, 06 Mar 2023 at 17:46:03 -0500, Jeremy Bícha wrote: > After installing gnome-initial-setup from Unstable on my Debian > Testing system, gnome-initial-setup no longer starts. When run in a > terminal, I get a warning about > Invalid cast from 'GtkBox' to 'GtkListBowRow' > > It looks like this issue was caused by one of the new keyboard patches. Yes. I was sure that I'd tested the patches, but I must have got various test-builds mixed up and tested the wrong binary. I'm sorry, I'll try to be more careful in future. > Here are 3 variations of how to test to make sure it's working. I > guess I should add these to a README somewhere. I've added those to debian/README.source. smcv
Bug#1032448: gnome-initial-setup: no longer starts
Source: gnome-initial-setup Version: 43.2-3 Severity: serious After installing gnome-initial-setup from Unstable on my Debian Testing system, gnome-initial-setup no longer starts. When run in a terminal, I get a warning about Invalid cast from 'GtkBox' to 'GtkListBowRow' It looks like this issue was caused by one of the new keyboard patches. gnome-initial-setup 43.2-3 did start for me on login at least once so it seems it works occasionally. Here are 3 variations of how to test to make sure it's working. I guess I should add these to a README somewhere. Test Case 1 --- rm ~/.config/gnome-initial-setup-done Log out then log back in gnome-initial-setup should automatically start Test Case 2 Create a new user Log in as the new user gnome-initial-setup should automatically start Test Case 3 Run this command /usr/libexec/gnome-initial-setup --existing-user Thank you, Jeremy Bícha
Processed: RC Bug #1032444: Reassigning to src:plastex
Processing commands for cont...@bugs.debian.org: > reassign 1032444 src:plastex Bug #1032444 [plastex] plastex: FTBFS: tests fail with Jinja2 3.1 Bug reassigned from package 'plastex' to 'src:plastex'. No longer marked as found in versions plastex/2.1-3. Ignoring request to alter fixed versions of bug #1032444 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 1032444: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032444 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: plastex: FTBFS: tests fail with Jinja2 3.1
Processing control commands: > forwarded -1 https://github.com/plastex/plastex/commit/d5144e16fcae42 Bug #1032444 [plastex] plastex: FTBFS: tests fail with Jinja2 3.1 Set Bug forwarded-to-address to 'https://github.com/plastex/plastex/commit/d5144e16fcae42'. -- 1032444: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032444 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1032444: plastex: FTBFS: tests fail with Jinja2 3.1
Package: plastex Version: 2.1-3 Severity: serious Tags: ftbfs Control: forwarded -1 https://github.com/plastex/plastex/commit/d5144e16fcae42 Dear Maintainer, Your package FTBFS because tests fail [1]. Previous successful build [2] had this warning: === warnings summary === plasTeX/Renderers/PageTemplate/__init__.py:35 /<>/.pybuild/cpython3_3.9_plastex/build/plasTeX/Renderers/PageTemplate/__init__.py:35: DeprecationWarning: 'contextfunction' is renamed to 'pass_context', the old name will be removed in Jinja 3.1. def debug(context): After Jinja2 3.1 entered in unstable [3], this warning became an error making tests fail. I've built your package without errors in a sid chroot environment after applying upstream commit. Kind Regards [1] https://ci.debian.net/data/autopkgtest/testing/amd64/p/plastex/31984634/log.gz [2] https://buildd.debian.org/status/fetch.php?pkg=plastex=all=2.1-3=1651705538=0 [3] https://tracker.debian.org/news/1423360/accepted-jinja2-312-1-source-into-unstable/
Bug#1032316: llvm-toolchain-15: is this version intended for Debian 12 'bookworm'?
X-Debbugs-Cc: debian...@lists.debian.org Control: affects 1032316 src:rocm-hipamd Hello, Simon McVittie, on 2023-03-03: > llvm-toolchain-15/1:15.0.7-1 was uploaded several weeks ago, shortly > after the transition freeze, but has not migrated to testing due to an > autopkgtest regression (#1029010). I subscribe the debian-ai mailing list. The ROCm compiler is currently built on top of llvm-toolchain-15, and moving back to the llvm-toolchain-14 may require some non-trivial effort if the latter were to not target Debian 12 bookworm. Thank you, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. signature.asc Description: PGP signature
Processed: Re: Bug#1032316: llvm-toolchain-15: is this version intended for Debian 12 'bookworm'?
Processing control commands: > affects 1032316 src:rocm-hipamd Bug #1032316 [src:llvm-toolchain-15] llvm-toolchain-15: is this version intended for Debian 12 'bookworm'? Added indication that 1032316 affects src:rocm-hipamd -- 1032316: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032316 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: improve tags
Processing commands for cont...@bugs.debian.org: > # e2fsprogs reverted the defaults change, so this bug applies to trixie > tag 1031364 - bookworm-ignore Bug #1031364 [vmdb2] e2fsprogs: generates filesystems that grub-install doesn't recognize Removed tag(s) bookworm-ignore. > tag 1031364 sid trixie Bug #1031364 [vmdb2] e2fsprogs: generates filesystems that grub-install doesn't recognize Added tag(s) sid and trixie. > thanks Stopping processing here. Please contact me if you need assistance. -- 1031364: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031364 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 1032392 is forwarded to https://github.com/scikit-rf/scikit-rf/pull/542, tagging 1032392
Processing commands for cont...@bugs.debian.org: > forwarded 1032392 https://github.com/scikit-rf/scikit-rf/pull/542 Bug #1032392 [python3-scikit-rf] python3-scikit-rf: import fails: AttributeError: module 'collections' has no attribute 'Sequence' Set Bug forwarded-to-address to 'https://github.com/scikit-rf/scikit-rf/pull/542'. > tags 1032392 + upstream fixed-upstream Bug #1032392 [python3-scikit-rf] python3-scikit-rf: import fails: AttributeError: module 'collections' has no attribute 'Sequence' Added tag(s) fixed-upstream and upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 1032392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1027542: marked as done (epl: FTBFS: two tests failed)
Your message dated Mon, 06 Mar 2023 18:04:16 +
with message-id
and subject line Bug#1027542: fixed in epl 0.9-6
has caused the Debian Bug report #1027542,
regarding epl: FTBFS: two tests failed
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1027542: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027542
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: epl
Version: 0.9-5
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230101 ftbfs-bookworm
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> true
> make[1]: Leaving directory '/<>'
>dh_elpa_test
> emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list
> \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list
> 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f
> package-initialize -L . -L test -l test/epl-test.el --eval
> \(ert-run-tests-batch-and-exit\)
> Running 18 tests (2023-01-01 09:23:13+, selector ‘t’)
>passed 1/18 epl-built-in-packages/catches-all (0.001895 sec)
>passed 2/18 epl-package-as-description/variable-must-be-a-symbol
> (0.000172 sec)
>passed 3/18
> epl-package-as-description/variable-must-be-bound-to-epl-package (0.82
> sec)
> INFO Scraping files for smartie-package-autoloads.el...
> INFO Scraping files for smartie-package-autoloads.el...done
> Checking /<>/test/sandbox/smartie-package-1.2.3...
> Compiling
> /<>/test/sandbox/smartie-package-1.2.3/smartie-package-autoloads.el...
> Compiling
> /<>/test/sandbox/smartie-package-1.2.3/smartie-package-pkg.el...
> Compiling
> /<>/test/sandbox/smartie-package-1.2.3/smartie-package.el...
> Done (Total of 1 file compiled, 2 skipped)
> Setting ‘package-selected-packages’ temporarily since "emacs -q" would
> overwrite customizations
> Setting ‘package-selected-packages’ temporarily since "emacs -q" would
> overwrite customizations
> Test epl-package-delete/should-not-be-installed backtrace:
> comp-el-to-eln-filename("/<>/test/sandbox/smar
> package--delete-directory("/<>/test/sandbox/sm
> package-delete(#s(package-desc :name smartie-package :version (1 2 3
> (with-no-warnings (package-delete (progn (or (progn (and (memq (type
> (if (epl-package--package-desc-p package) (with-no-warnings (package
> (let ((delete-by-moving-to-trash nil)) (if (epl-package--package-des
> epl-package-delete(#s(epl-package :name smartie-package :description
> (let ((package (car (epl-find-installed-packages 'smartie-package)))
> (let ((smartie-package (epl-test-resource-file-name "smartie-package
> (let ((package-user-dir epl-sandbox-directory)) (if (f-dir\? epl-san
> (let ((lexical-binding t)) (let ((package-user-dir epl-sandbox-direc
> (closure (t) nil (let ((lexical-binding t)) (let ((package-user-dir
> ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
> ert-run-test(#s(ert-test :name epl-package-delete/should-not-be-inst
> ert-run-or-rerun-test(#s(ert--stats :selector t :tests [... ... ...
> ert-run-tests(t #f(compiled-function (event-type event-args) #
> ert-run-tests-batch(nil)
> ert-run-tests-batch-and-exit()
> command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
> command-line()
> normal-top-level()
> Test epl-package-delete/should-not-be-installed condition:
> (error "Cannot find suitable directory for output in
> ‘native-comp-eln-load-path’.")
>FAILED 4/18 epl-package-delete/should-not-be-installed (0.350690 sec)
> INFO Scraping files for smartie-package-autoloads.el...
> INFO Scraping files for smartie-package-autoloads.el...done
> Checking /<>/test/sandbox/smartie-package-1.2.3...
> Compiling
> /<>/test/sandbox/smartie-package-1.2.3/smartie-package-autoloads.el...
> Compiling
> /<>/test/sandbox/smartie-package-1.2.3/smartie-package-pkg.el...
> Compiling
> /<>/test/sandbox/smartie-package-1.2.3/smartie-package.el...
> Done (Total of 1 file compiled, 2 skipped)
> Setting ‘package-selected-packages’ temporarily since "emacs -q" would
> overwrite customizations
> Setting ‘package-selected-packages’ temporarily since "emacs -q" would
> overwrite customizations
> Test epl-package-directory/should-work backtrace:
> comp-el-to-eln-filename("/<>/test/sandbox/smar
> package--delete-directory("/<>/test/sandbox/sm
> package-delete(#s(package-desc :name smartie-package :version (1 2 3
> (with-no-warnings
Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25
David Bremner writes: > Adrian Bunk writes: > >>> FTR, the dates when epl started to FTBFS in sid and bookworm are >>> a good match for when emacs 1:28.2+1-9 entered sid and bookworm: >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html >> >> Correct link: >> https://tests.reproducible-builds.org/debian/history/epl.html > > Some pretty weird behaviour here > > HOME=/n0nexistent emacs -batch -Q -l package \ > --eval "(add-to-list 'package-directory-list > \"/usr/share/emacs/site-lisp/elpa\")" \ > --eval "(add-to-list 'package-directory-list > \"/usr/share/emacs/site-lisp/elpa-src\")" \ > -f package-initialize -L . -L test --eval "(progn (setq > comp-enable-subr-trampolines nil) \ > (load-file \"test/test-helper.el\") (load-file \"test/epl-test.el\"))" \ > -l test/epl-test.el --eval \(ert-run-tests-batch-and-exit\) > > fails, but replacing /n0nexistent with /nonexistent passes. I hope this is > not a sign that someone has special cased /nonexistent, but I fear otherwise. This weird behaviour is a consequence of emacs' ill-advised special-casing of "HOME==/nonexistent" in startup.el (around line 550). if HOME==/nonexistent, then emacs tries to provide a temporary directory for native compilation output. Why this is needed is a different question.
Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message
Package: python3-dateutil Followup-For: Bug #1003044 X-Debbugs-Cc: debian-le...@lists.debian.org (adding debian-legal on cc for any sanity-checks available) To recap: we have a bug, #1003044, that is rated 'grave', and so it is considered release-critical for Debian bookworm, although without a written justification for the severity so far. The bug relates to timezone data in the 'python-dateutil' source package. The request, in short, is: can we repackage a specific tarball, derived from public domain data and in an Apache-2.0 repository, from the python-dateutil package's source? Context follows. Note: this message uses selective -- chronological, and where possible, referentially sequential -- quotations; I'm trying to present a coherent thread of the discussion so far related solely to the usage of the relevant 'dateutil-zoneinfo.tar.gz' file as contained in tagged, published releases of the upstream python-dateutil[1] library. Facts as I understand them: * In its original distributed form, the IANA tz database is public domain (and therefore is DFSG-compatible). * A file, dateutil-zoneinfo.tar.gz, was built by upstream and included in their own software releases. It was built from tzdata2021a.tar.gz according to the metadata within the dateutil-zoneinfo.tar.gz file, and the metadata includes integrity hashes. * For the relevant distributed versions, the upstream library is Apache-2.0 licensed. * Debian requires[2] that users can rebuild distributed (aka 'binary') packages from source. * A bug[3] was reported about the inclusion of dateutil-zoneinfo.tar.gz in Debian's packaging, and subsequently that file was removed. This remains the status quo at the time-of-writing. * IANA tz database releases do not remove old timezone names but instead add a backwards-compatible link from the previous name to the current. * I am not an expert about the tz database, but I believe that this is relevant because python-dateutil's code may attempt to access _both_ the system timezone database (likely to be more recent) _and_ subsequently the bundled dateutil-zoneinfo.tar.gz (likely to be older), the latter as a fallback, under some circumstances. * "If a name is changed, put its old spelling in the 'backward' file as a link to the new spelling. This means old spellings will continue to work. Ordinarily a name change should occur only in the rare case when a location's consensus English-language spelling changes; for example, in 2008 Asia/Calcutta was renamed to Asia/Kolkata due to long-time widespread use of the new city name instead of the old." - https://data.iana.org/time-zones/theory.html If anyone feels like I'm misrepresenting (or under-representing) their viewpoints, please say so. On Tue, 21 Feb 2023 22:27:53 +0100, Felix wrote: > I'm inclined to just ship the bundled timezone database with the package: On Wed, 22 Feb 2023 11:52:25 +, James wrote: > That may not be an option for us (at least without more work to find and > package the sources of the relevant zoneinfo database): tz data content was > removed from src:python-dateutil (the source of this package) to resolve > previous bug #665894, relating to dfsg-compatibility. On Fri, 3 Mar 2023 15:05:03 -0500, morph wrote: > even if these APIs are deprecated upstream, i think breaking them on > purpose (by removing the bundled timezone file) is uncalled for. > Either we reintroduce the timezone file (that may not be a good idea) > or translate these deprecated APIs into the recommended one, or we do > something else entirely, it's up for debate. On Sun, 05 Mar 2023 15:37:43 +0100, Armour wrote: > I can't really comment on that. Other distros don't seem to remove it ... > One thing we could do is to regenerate the bundled database based on actual > zoneinfo. But then the package should be rebuilt every time zoneinfo is > updated... ... > In my view, no actual user is asking for the possibility of using the bundled > database, or anything nebulous like using the system database even if the > bundled one is requested explicitly. They're simply asking for an irrelevant > warning to be removed. On Sun, 5 Mar 2023 23:07:44 +0100, Felix wrote: > That's probably true but there are direct users of the dateutil.zoneinfo API > which intrinsically > uses the bundled database. ... > Therefore shipping the bundled zoneinfo tarball seems like the better > solution to me. > The timezone database is clearly DFSG-free. We would have to repackage the > upstream tarball to > include the timezone database source though. > Thankfully upstream ships the script to (re-)generate the zoneinfo tarball. Although various options have been discussed, I currently agree with Felix's recommendation (begin shipping the tarball again), as long as we can confirm that that's OK to do. Armour's concern may be correct that few - if any - people intentionally want to use
Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25
Adrian Bunk writes: >> FTR, the dates when epl started to FTBFS in sid and bookworm are >> a good match for when emacs 1:28.2+1-9 entered sid and bookworm: >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html > > Correct link: > https://tests.reproducible-builds.org/debian/history/epl.html Some pretty weird behaviour here HOME=/n0nexistent emacs -batch -Q -l package \ --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" \ --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" \ -f package-initialize -L . -L test --eval "(progn (setq comp-enable-subr-trampolines nil) \ (load-file \"test/test-helper.el\") (load-file \"test/epl-test.el\"))" \ -l test/epl-test.el --eval \(ert-run-tests-batch-and-exit\) fails, but replacing /n0nexistent with /nonexistent passes. I hope this is not a sign that someone has special cased /nonexistent, but I fear otherwise.
Processed: affects
Processing commands for cont...@bugs.debian.org:
> # rauc builds from source again in bookworm
> # adding this for completeness
> affects 1030434 src:rauc
Bug #1030434 {Done: Bastian Germann } [src:opensc] rauc:
FTBFS: tests failed writing: Error opening file
?/tmp/tmp.I4dlWcaK4g/notexisting/out.raucb?: No such file or directory
Added indication that 1030434 affects src:rauc
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1030434: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030434
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message
On 05/03/2023 23:07, Felix Geyer wrote:
On Sun, 05 Mar 2023 18:50:06 +0100 Arnout Vandecappelle
wrote:
This still fails to address the original issue: an irrelevant warning is
printed when performing a fairly mundane thing (requesting a nonexistent
timezone).
That part could be easily fixed. We can just remove the fallback from
dateutil.tz.gettz() to get_zonefile_instance() since we know that the system
database is available.
OK, attached patch does exactly that.
I repeat: I don't think anyone really wants to use the bundled database.
That's probably true but there are direct users of the dateutil.zoneinfo API
which intrinsically uses the bundled database.
For example within Debian packages:
https://sources.debian.org/src/python-hypothesis/6.67.1-1/hypothesis-python/src/hypothesis/extra/dateutil.py/?hl=56#L56
https://sources.debian.org/src/python-sqlalchemy-utils/0.38.2-2/sqlalchemy_utils/types/timezone.py/?hl=44#L44
These are currently broken. Just silencing the warning will leave them broken.
Good point. However, this has been the case already since 2014-ish, so I think
that would be a separate bug, and probably not "grave".
Regards,
Arnout
We could patch the implementation to use the system database but that means
deviating from the upstream behavior and carrying that patch forever.
The API even includes the metadata dictionary that would have to be faked as
well:
https://sources.debian.org/src/python-dateutil/2.8.2-1/dateutil/zoneinfo/__init__.py/#L46
Therefore shipping the bundled zoneinfo tarball seems like the better solution
to me.
The timezone database is clearly DFSG-free. We would have to repackage the
upstream tarball to include the timezone database source though.
Thankfully upstream ships the script to (re-)generate the zoneinfo tarball.
Felixdiff -Nru python-dateutil-2.8.2/debian/changelog python-dateutil-2.8.2/debian/changelog
--- python-dateutil-2.8.2/debian/changelog 2022-10-14 13:10:49.0 +0200
+++ python-dateutil-2.8.2/debian/changelog 2023-03-03 18:58:30.0 +0100
@@ -1,3 +1,10 @@
+python-dateutil (2.8.2-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't fall back on bundled zoneinfo database (Closes: #1003044)
+
+ -- Arnout Vandecappelle Fri, 03 Mar 2023 18:58:30 +0100
+
python-dateutil (2.8.2-1) unstable; urgency=medium
* Team upload
diff -Nru python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch
--- python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch 2022-10-14 13:10:49.0 +0200
+++ python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch 2023-03-03 18:58:30.0 +0100
@@ -1,13 +1,15 @@
-From: =?utf-8?q?Guido_G=C3=BCnther?=
+From 49f1a86aa7989e497114437dfef8ad51d5b413fe Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?=
Date: Sat, 27 Sep 2014 20:52:15 +0200
-Subject: Remove Zoneinfo Tarball
+Subject: [PATCH] Remove Zoneinfo Tarball
---
MANIFEST.in | 1 +
dateutil/test/test_tz.py | 2 ++
+ dateutil/tz/tz.py| 4
python_dateutil.egg-info/SOURCES.txt | 3 +--
setup.cfg| 3 ---
- 4 files changed, 4 insertions(+), 5 deletions(-)
+ 5 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/MANIFEST.in b/MANIFEST.in
index d4d9f32..3e8b3fb 100644
@@ -19,7 +21,7 @@
global-exclude *.py[co]
+exclude dateutil/zoneinfo/dateutil-zoneinfo.tar.gz
diff --git a/dateutil/test/test_tz.py b/dateutil/test/test_tz.py
-index 6cd8ea0..042f28e 100644
+index e5e4772..fa84872 100644
--- a/dateutil/test/test_tz.py
+++ b/dateutil/test/test_tz.py
@@ -1193,6 +1193,7 @@ def test_gettz_weakref():
@@ -38,8 +40,23 @@
def testPickleZoneFileGettz(self):
zoneinfo_file = zoneinfo.get_zonefile_instance()
tzi = zoneinfo_file.get('America/New_York')
+diff --git a/dateutil/tz/tz.py b/dateutil/tz/tz.py
+index c67f56d..e350cdb 100644
+--- a/dateutil/tz/tz.py
b/dateutil/tz/tz.py
+@@ -1650,10 +1650,6 @@ def __get_gettz():
+ # UnicodeEncodeError is for Python 2.7 compat
+ tz = None
+
+-if not tz:
+-from dateutil.zoneinfo import get_zonefile_instance
+-tz = get_zonefile_instance().get(name)
+-
+ if not tz:
+ for c in name:
+ # name is not a tzstr unless it has at least
diff --git a/python_dateutil.egg-info/SOURCES.txt b/python_dateutil.egg-info/SOURCES.txt
-index c0d2a0f..ae4d43f 100644
+index c8e5497..a0ccdca 100644
--- a/python_dateutil.egg-info/SOURCES.txt
+++ b/python_dateutil.egg-info/SOURCES.txt
@@ -60,7 +60,6 @@ dateutil/tz/_factories.py
@@ -58,7 +75,7 @@
\ No newline at end of file
+requirements/3.3/requirements-dev.txt
diff
Bug#1030511: marked as done (libguestfs: FTBFS on s390x: timeout)
Your message dated Mon, 06 Mar 2023 15:04:28 + with message-id and subject line Bug#1030511: fixed in libguestfs 1:1.48.6-2 has caused the Debian Bug report #1030511, regarding libguestfs: FTBFS on s390x: timeout to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1030511: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030511 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: libguestfs Version: 1:1.48.6-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=libguestfs=s390x=1%3A1.48.6-1%2Bb3=1675413376=0 cd ../../.. && /<>/debian/build-2/generator/generator generated 555164 lines of code touch stamp-generator make[4]: Leaving directory '/<>/debian/build-2/generator' Making all in test-data make[4]: Entering directory '/<>/debian/build-2/test-data' Making all in binaries make[5]: Entering directory '/<>/debian/build-2/test-data/binaries' make[5]: Nothing to be done for 'all'. make[5]: Leaving directory '/<>/debian/build-2/test-data/binaries' Making all in blank-disks make[5]: Entering directory '/<>/debian/build-2/test-data/blank-disks' qemu-img create -f raw blank-disk-1s.raw 512 qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512 Formatting 'blank-disk-1s.raw', fmt=raw size=512 Formatting 'blank-disk-1s.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=512 lazy_refcounts=off refcount_bits=16 qemu-img create -f raw blank-disk-1K.raw 1K Formatting 'blank-disk-1K.raw', fmt=raw size=1024 qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1K.qcow2 1K Formatting 'blank-disk-1K.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=1024 lazy_refcounts=off refcount_bits=16 qemu-img create -f raw blank-disk-1M.raw 1M Formatting 'blank-disk-1M.raw', fmt=raw size=1048576 qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1M.qcow2 1M Formatting 'blank-disk-1M.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=1048576 lazy_refcounts=off refcount_bits=16 qemu-img create -f qcow2 -b blank-disk-1M.raw -F raw blank-disk-with-backing.qcow2 Formatting 'blank-disk-with-backing.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1048576 backing_file=blank-disk-1M.raw backing_fmt=raw lazy_refcounts=off refcount_bits=16 E: Build killed with signal TERM after 150 minutes of inactivity Cheers -- Sebastian Ramacher --- End Message --- --- Begin Message --- Source: libguestfs Source-Version: 1:1.48.6-2 Done: Hilko Bengen We believe that the bug you reported is fixed in the latest version of libguestfs, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1030...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hilko Bengen (supplier of updated libguestfs package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 06 Mar 2023 15:29:41 +0100 Source: libguestfs Architecture: source Version: 1:1.48.6-2 Distribution: unstable Urgency: medium Maintainer: Debian Libvirt Maintainers Changed-By: Hilko Bengen Closes: 1030511 Changes: libguestfs (1:1.48.6-2) unstable; urgency=medium . * Add Brazilian Portuguese debconf translation, thanks to Paulo Henrique de Lima Santana (Clsoes: #1025726) * Disable tests (quickcheck) on s390x. Closes: #1030511 * Replace libncurses*-dev build-dependencies Checksums-Sha1: 96a74b6b8ccc3f9f357c78206a6eda30bb3d2900 6825 libguestfs_1.48.6-2.dsc 76711451b8726826baa51d3d1c614f6135d13743 40200 libguestfs_1.48.6-2.debian.tar.xz 213568a511a68abed80f7fe3d20b1030fcf879dc 25368 libguestfs_1.48.6-2_source.buildinfo Checksums-Sha256: d5b14c28b8bcc23112ead85c65b83304b32051db263734e91d99388e5d29911e 6825 libguestfs_1.48.6-2.dsc 7f6e2f63ea2ab9f9ca0d214197c63b61568c7652a48064607e5f28aaa902 40200 libguestfs_1.48.6-2.debian.tar.xz 4e71fdf2880c389aa9b5513a4e3e16aca7b7a5d56f1cf7c6f71a40c28140cd98 25368 libguestfs_1.48.6-2_source.buildinfo
Bug#1013933: xsane: Another vote for XSane!
Package: xsane Version: 0.999-11ubuntu1 Followup-For: Bug #1013933 Thanks for keeping XSane alive in Debian. I am a long-time user myself, out of necessity: I have tried several times to use simple-scan (the only alternative I can find), and it just doesn’t offer the functionality of XSane. XSane is clunky and buggy, but it gets the job done. I have provided patches for XSane in the past, and will continue to do so when I can find the time. It’s a shame that there’s no better alternative, but I fear that flatbed scanning is increasingly a niche area, as people now more and more use their phones to scan documents on the rare occasions that they actually need a scan of a paper document. Therefore, doing our best to keep XSane working is probably the best we can manage, absent someone coming up with the sort of investment that saw simple-scan created. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-56-generic (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xsane depends on: ii libc6 2.35-0ubuntu3.1 ii libgimp2.0 2.10.30-1build1 ii libglib2.0-02.72.4-0ubuntu1 ii libgtk2.0-0 2.24.33-2ubuntu2 ii libjpeg88c-2ubuntu10 ii liblcms2-2 2.12~rc1-2build2 ii libpng16-16 1.6.37-3build5 ii libsane11.1.1-5 ii libtiff54.3.0-6ubuntu0.3 ii sensible-utils 0.0.17 ii xsane-common0.999-11ubuntu1 ii zlib1g 1:1.2.11.dfsg-2ubuntu9.2 Versions of packages xsane recommends: ii chromium-browser [www-browser] 1:110.0.5481.177-0ubuntu0.22.04.1sav0 ii cups-client 2.4.1op1-1ubuntu4.1 ii firefox-esr [www-browser] 102.8.0esr+build2-0ubuntu0.22.04.1 ii links [www-browser] 2.25-1build1 ii lynx [www-browser] 2.9.0dev.10-1 ii w3m [www-browser] 0.5.3+git20210102-6ubuntu0.1 Versions of packages xsane suggests: ii gimp 2.10.30-1build1 ii gocr 0.52-3 ii gv 1:3.7.4-2 pn hylafax-client | mgetty-fax ii tesseract-ocr4.1.1-2.1build1 -- no debconf information
Bug#1031765: pgrep: signal handler matching breaks argument parsing
Upstream bug report created: https://github.com/ganeti/ganeti/issues/1691 Ubuntu bug LP #2009498
Bug#1032420: libtpms: CVE-2023-1017 CVE-2023-1018
Source: libtpms Version: 0.9.2-3 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for libtpms. CVE-2023-1017[0]: | An out-of-bounds write vulnerability exists in TPM2.0's Module Library | allowing writing of a 2-byte data past the end of TPM2.0 command in | the CryptParameterDecryption routine. An attacker who can successfully | exploit this vulnerability can lead to denial of service (crashing the | TPM chip/process or rendering it unusable) and/or arbitrary code | execution in the TPM context. CVE-2023-1018[1]: | An out-of-bounds read vulnerability exists in TPM2.0's Module Library | allowing a 2-byte read past the end of a TPM2.0 command in the | CryptParameterDecryption routine. An attacker who can successfully | exploit this vulnerability can read or access sensitive data stored in | the TPM. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-1017 https://www.cve.org/CVERecord?id=CVE-2023-1017 [1] https://security-tracker.debian.org/tracker/CVE-2023-1018 https://www.cve.org/CVERecord?id=CVE-2023-1018 [2] https://github.com/stefanberger/libtpms/commit/324dbb4c27ae789c73b69dbf4611242267919dd4 [3] https://kb.cert.org/vuls/id/782720 [4] https://trustedcomputinggroup.org/wp-content/uploads/TCGVRT0007-Advisory-FINAL.pdf Regards, Salvatore
Bug#1019273: marked as done (apt: Missing licenses and copyright statements in debian/copyright)
Your message dated Mon, 06 Mar 2023 12:49:04 + with message-id and subject line Bug#1019273: fixed in apt 2.6.0 has caused the Debian Bug report #1019273, regarding apt: Missing licenses and copyright statements in debian/copyright to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1019273: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019273 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: apt Severity: serious Version: 2.5.2 Tags: patch The debian/copyright (COPYING) file is missing at least two licenses (Expat, BSD-3-clause) and some copyright statements. A machine-readable version of COPYING is attached that fixes these.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: apt Upstream-Contact: APT Development Team Source: https://salsa.debian.org/apt-team/apt Files: * Copyright: 1997-1999 Jason Gunthorpe and others License: GPL-2+ Files: apt-pkg/cachefilter-patterns.* apt-private/private-json-hooks.* test/libapt/pattern_test.cc Copyright: 2018, 2019 Canonical Ltd License: GPL-2+ Files: po/lt.po Copyright: 2006 Canonical Ltd, and Rosetta Contributors 2006 License: GPL-2+ Files: apt-pkg/contrib/weakptr.h apt-pkg/contrib/string_view.h CMakeLists.txt Copyright: 2009, 2010, 2015, 2016 Julian Andres Klode License: GPL-2+ Files: debian/apt.postrm Copyright: 1998, Ben Gertzfield License: GPL-2+ Files: doc/po/pt.po po/bg.po po/it.po po/sv.po po/th.po Copyright: 2002-2019 Free Software Foundation, Inc. License: GPL-2+ Files: doc/po/es.po po/tl.po Copyright: 2003, 2004, 2005, 2009, 2010, 2012 Software in the Public Interest License: GPL-2+ Files: po/nb.po Copyright: 2002-2003 Lars Bahner 2003-2004 Axel Bojer 2004 Klaus Ade Johnstad 2004 Bjorn Steensrud 2003, 2005-2010 Hans Fredrik Nordhaug 2016, 2018 Petter Reinholdtsen License: GPL-2 Files: po/tr.po Copyright: 2009 Rosetta Contributors and Canonical Ltd 2009 2013 Debian L10n Turkish 2013 2013-2018 Mert Dirik License: GPL-2+ Files: doc/po/pl.po Copyright: 2004 Krzysztof Fiertek 2000-2004, 2010, 2012 Robert Luberda License: GPL-2+ Files: doc/po/it.po Copyright: 2000-2017 Debian Italian l10n team License: GPL-2+ Files: doc/po/ja.po Copyright: 2003-2017 Debian Japanese List License: GPL-2+ Files: doc/po/fr.po Copyright: 2000-2018 Debian French l10n team License: GPL-2+ Files: doc/design.dbk Copyright: 1997 Manoj Srivastava License: GPL-2+ Files: doc/dpkg-tech.dbk Copyright: 1997 Tom Lees License: GPL-2+ Files: methods/rred.cc Copyright: 2014 Anthony Towns License: GPL-2+ Files: methods/rsh.cc Copyright: 2000 Ben Collins License: GPL-2 Files: CMake/FindBerkeley.cmake Copyright: 2006, Alexander Dymo, 2016, Julian Andres Klode License: BSD-3-clause Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: . 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. . THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Files: CMake/Documentation.cmake CMake/FindLFS.cmake Copyright: 2016 Julian Andres Klode License: Expat Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without
Bug#1013872: salt: CVE-2022-22967
On Thu, 1 Sep 2022 08:13:07 +0200 Paul Gevers wrote: Hi, On Sun, 26 Jun 2022 13:55:24 +0200 Salvatore Bonaccorso wrote: > Source: salt > The following vulnerability was published for salt. > > CVE-2022-22967[0]: > | An issue was discovered in SaltStack Salt in versions before 3002.9, > | 3003.5, 3004.2. PAM auth fails to reject locked accounts, which allows > | a previously authorized user whose account is locked still run Salt > | commands when their account is locked. This affects both local shell > | accounts with an active session and salt-api users that authenticate > | via PAM eauth. As much as I'd like to stay away from fixing packages, do you need help with this one? It causing RC issues in testing even though it's removed. https://qa.debian.org/dose/debcheck/src_testing_main/1661922002/packages/pytest-testinfra.html#076c12ad0c0676e354433b4fd854e3d5 There's a new upstream release and I pulled it locally, but there are a lot of changes. So without experience with the package, it's a bit much to go over. The fix for this is very simple. We are ignoring pam_acct_mgmt()'s return value. The upstream fix (with tests) is at: https://github.com/saltstack/salt/commit/e068a34ccb2e17ae7224f8016a24b727f726d4c8 Cheers, Emilio
Bug#1032418: zcfan service is not stopped on package removal
Package: zcfan Severity: serious X-Debbugs-Cc: deb...@rocketjump.eu Hi, while testing the Breaks: directive between zcfan and thinkfan, I noticed that the zcfan service is not stopped upon uninstall. This is not caught by piuparts, as by default the zcfan service is not started. The solution is to have a debian/rules entry like in [0]. I noticed that you're a DM, and since it's fairly late in the freeze process, I'm willing to guide your through the process of fixing the package for the bookworm release. Regards, Lee [0] https://salsa.debian.org/debian/thinkfan/-/blob/master/debian/rules#L24 Full terminal output showing the issue below: 12:59:18 [root@batou:~] 4s # apt install zcfan Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: zcfan 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 0 B/8.980 B of archives. After this operation, 36,9 kB of additional disk space will be used. Selecting previously unselected package zcfan. (Reading database ... 377831 files and directories currently installed.) Preparing to unpack .../zcfan_1.2.1-1+b1_amd64.deb ... Unpacking zcfan (1.2.1-1+b1) ... Setting up zcfan (1.2.1-1+b1) ... Processing triggers for man-db (2.11.2-1) ... Scanning processes... Scanning candidates... Scanning processor microcode... Scanning linux images... Running kernel seems to be up-to-date. The processor microcode seems to be up-to-date. No services need to be restarted. No containers need to be restarted. User sessions running outdated binaries: randall @ session #2: gdm-wayland-ses[1967] randall @ user manager service: firefox-esr[3254], gnome-session-b[2019], gnome-shell[2048], systemd[1784], thunderbird[2932] No VM guests are running outdated hypervisor (qemu) binaries on this host. 12:59:27 [root@batou:~] 4s # systemctl status zcfan ○ zcfan.service - Zero-configuration fan control for ThinkPad Loaded: loaded (/lib/systemd/system/zcfan.service; enabled; preset: enabled) Active: inactive (dead) since Mon 2023-03-06 12:58:59 CET; 36s ago Duration: 1min 9.982s Process: 17359 ExecStart=/usr/bin/zcfan (code=exited, status=0/SUCCESS) Main PID: 17359 (code=exited, status=0/SUCCESS) CPU: 275ms Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 90C fan is set to maximum Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 80C fan is set to medium Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 70C fan is set to low Mär 06 12:57:49 batou zcfan[17359]: [FAN] Temperature now 51C, fan set to off Mär 06 12:58:23 batou zcfan[17359]: [FAN] Temperature now 71C, fan set to low Mär 06 12:58:26 batou zcfan[17359]: [FAN] Temperature now 50C, fan set to off Mär 06 12:58:59 batou zcfan[17359]: [FAN] Quit requested, reenabling thinkpad_acpi fan control Mär 06 12:58:59 batou systemd[1]: Stopping zcfan.service - Zero-configuration fan control for ThinkPad... Mär 06 12:58:59 batou systemd[1]: zcfan.service: Deactivated successfully. Mär 06 12:58:59 batou systemd[1]: Stopped zcfan.service - Zero-configuration fan control for ThinkPad. 12:59:35 [root@batou:~] 3 # systemctl start zcfan 12:59:39 [root@batou:~] # systemctl status zcfan ● zcfan.service - Zero-configuration fan control for ThinkPad Loaded: loaded (/lib/systemd/system/zcfan.service; enabled; preset: enabled) Active: active (running) since Mon 2023-03-06 12:59:39 CET; 3s ago Main PID: 18995 (zcfan) Tasks: 1 (limit: 28396) Memory: 264.0K CPU: 21ms CGroup: /system.slice/zcfan.service └─18995 /usr/bin/zcfan Mär 06 12:59:39 batou systemd[1]: Started zcfan.service - Zero-configuration fan control for ThinkPad. Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 90C fan is set to maximum Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 80C fan is set to medium Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 70C fan is set to low Mär 06 12:59:39 batou zcfan[18995]: [FAN] Temperature now 50C, fan set to off 12:59:43 [root@batou:~] # apt purge zcfan Reading package lists... Done Building dependency tree... Done Reading state information... Done The following
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 Echoing some notes and findings from the GitHub issue thread: * https://crbug.com/405338 seems inaccessible to at least two people * https://codereview.chromium.org/555943003 was initially proposed to resolve that bug * https://codereview.chromium.org/583163002 was chosen instead, for reasons of simplicity and performance concerns It is the latter codereview (583163002) that introduced the reduction in the stack size on ARM (that the patch in this bug thread removes). I'm planning to write to the V8 contributors mailing list to summarize these findings and ask whether they have any guidance/recommendations.
Bug#1019273: marked as pending in apt
Control: tag -1 pending Hello, Bug #1019273 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/5039c586a833b67f00fe5e480bf2f3e074cf7fc5 machine-readable version of COPYING The debian/copyright (COPYING) file is missing at least two licenses (Expat, BSD-3-clause) and some copyright statements. A machine-readable version of COPYING is attached that fixes these. Closes: #1019273 (this message was generated automatically) -- Greetings https://bugs.debian.org/1019273
Processed: Bug#1019273 marked as pending in apt
Processing control commands: > tag -1 pending Bug #1019273 [src:apt] apt: Missing licenses and copyright statements in debian/copyright Added tag(s) pending. -- 1019273: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019273 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1032029: mosquitto ignores ip address for websocket listeners
Processing commands for cont...@bugs.debian.org: > severity 1032029 normal Bug #1032029 [mosquitto] mosquitto ignores ip address for websocket listeners Severity set to 'normal' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 1032029: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032029 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1032029: mosquitto ignores ip address for websocket listeners
severity 1032029 normal
thanks
Hi,
I looked into this as it's the underlying reason for why a bunch of
packages are "flagged for removal" because of "buggy deps
mosquitto".
* Helmut Grohne [Sun Feb 26, 2023 at 08:37:13PM +0100]:
> If you configure a websocket listener for mosquitto with an IP address
> to bind to, mosquitto will instead bind the wildcard address. This
> renders a secure configuration insecure.
>
> A simple configuration producing this behaviour is a default
> installation together with one config update:
>
> $ cat /etc/mosquitto/conf.d/listen.conf
> bind_address localhost
> listener 9001 127.0.0.1
> protocol websockets
> $
>
> If you (re)start mosquitto, you can see the insecure bind:
>
> $ ss -tlp
> ...
> LISTEN0 4096 *:9001 *:*
>users:(("mosquitto",pid=269,fd=7))
> ...
> $
>
> The mosquitto.conf manual page in section 5 says that for websockets,
> you can only give an IP address as bind address, which kinda implies
> that you can given an IP address there. I think it is a reasonable
> expectation that binding to 127.0.0.1 should be secure.
With your configuration applied I see the following line in the logs:
| mosquitto[1750]: 1678096815: The 'bind_address' option is now deprecated and
will be removed in a future version. The behaviour will default to true.
Quoting from mosquitto.conf(5) (also see
https://mosquitto.org/man/mosquitto-conf-5.html):
|bind_address address
|
|This option is deprecated and will be removed in a future
|version. Use the listener instead.
|
|Listen for incoming network connections on the specified IP
|address/hostname only. This is useful to restrict access to
|certain network interfaces. To restrict access to mosquitto
|to the local host only, use "bind_address localhost". This
|only applies to the default listener. Use the listener option
|to control other listeners.
|
|It is recommended to use an explicit listener rather than
|rely on the implicit default listener options like this.
And indeed, with a configuration like follows:
| # cat /etc/mosquitto/conf.d/listen.conf
| listener 1883 127.0.0.1
| socket_domain ipv4
| protocol mqtt
|
| listener 9001 127.0.0.1
| socket_domain ipv4
| protocol websockets
... it behaves as documented/expected:
| # ss -tlpn | grep mosquitto
| LISTEN 0 4096 127.0.0.1:9001 0.0.0.0:*
users:(("mosquitto",pid=1994,fd=8))
| LISTEN 0 100127.0.0.1:1883 0.0.0.0:*
users:(("mosquitto",pid=1994,fd=5))
Using *only* `bind_address localhost` inside
/etc/mosquitto/conf.d/listen.conf also makes the default listener to
be active on localhost only, as expected and documented:
| # ss -tlpn | grep mosquitto
| LISTEN 0 100127.0.0.1:1883 0.0.0.0:*
users:(("mosquitto",pid=2027,fd=5))
> I am filing this as severity serious, because normally a security
> vulnerability would be grave, but this vulnerability only surfaces in a
> (possibly common) non-default configuration. Hence lowering to serious.
IMO this isn't even a bug, so for now I downgraded the severity,
though if you agree I'd tend to close this bug report. (But I'm
neither the bug reporter nor the package maintainer, so leaving that
to either one of you :))
regards
-mika-
signature.asc
Description: PGP signature
