Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Thank you Matthijs!
Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Source: openttd Version: 14.0-1 Severity: serious Tags: upstream Justification: Policy 12.5 Control: forwarded -1 https://github.com/OpenTTD/OpenTTD/pull/12603 Dear Maintainer, The build scripts for the initial version 14.0 release of OpenTTD include a CMake file that determines whether and how to add compile-time flags to request that libatomic should be linked. The relevant CMake file addition was sourced[1] from the LLVM codebase, which is licensed under a variant of the Apache 2.0 license with some exception clauses added for the LLVM project. This is not yet documented in the source package. I'm reporting this bug with severity 'serious' because I feel that there is a potential licensing concern here; until that is confirmed one way or the other, I've offered what I believe is a possible resolution (adding the LLVM license -- slightly confusingly _also_ referred to as v14, because that is the version of LLVM where it was introduced, despite v18 being LLVM-current), to upstream[2]. To explain my reasoning: On balance I'd prefer opening a serious-severity bug to prevent migration (that could later be reduced in severity) than to allow the package transition while being aware of a potential problem. Thanks, James [1] - https://github.com/OpenTTD/OpenTTD/pull/10513 [2] - https://github.com/OpenTTD/OpenTTD/pull/12603
Bug#1057442: onboard ftbfs with Python 3.12
Followup-For: Bug #1057442 X-Debbugs-Cc: tsu.y...@gmail.com Hi Bo, On Wed, 6 Dec 2023 17:31:52 +0800, Bo wrote: > I think it is okay to remove `-Wdeclaration-after-statement` option > which to support Arch linux build from code comment. FYI: I've reported #1064028 against Python3.12 to suggest fixing the cause of this (the non-C90-compliant code in Python3.12 headers). I'm intentionally not making it a blocker here, because other approaches are possible, but am mentioning it for awareness. Regards, James
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Followup-For: Bug #1036828 X-Debbugs-Cc: k...@debian.org On Sat, 24 Feb 2024 11:01:31 +, I wrote: > Should this bug be closed? (the logic to skip the experimental/sid firmware > image build during non-testing builds is in place for both bookworm and > trixie) Nope, it looks like I've misunderstood here. This change is ready, but pending upload (as indicated by the bug tags). (may be worth double-checking that the bugnumber is referenced-as-closed in the changelog, though?)
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Followup-For: Bug #1036828 X-Debbugs-Cc: k...@debian.org Hi Cyril, Should this bug be closed? (the logic to skip the experimental/sid firmware image build during non-testing builds is in place for both bookworm and trixie) Regards, James
Bug#1060802: stellarium: FTBFS on armel, ppc64el, s390x: unsatisfiable Build-Depends: qtwebengine5-dev (>= 5.15)
Source: stellarium Followup-For: Bug #1060802 X-Debbugs-Cc: tom...@debian.org, mity...@debian.org > stellarium 23.4-1 added a new build-dependency on qtwebengine5-dev, which > prevents it from building on some release architectures (and all non-release > ones). Would 'qtwebengine5-dev | libqt5webkit5-dev' provide an acceptable alternative build dependency spec? Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913043;msg=10
Bug#1057880: burp: FTBFS with zlib 1.3 due to 'make check' failure
Source: burp Followup-For: Bug #1057880 X-Debbugs-Cc: kapo...@melix.org Thank you, Jérémy.
Bug#1057880: burp: FTBFS with zlib 1.3 due to 'make check' failure
Source: burp
Followup-For: Bug #1057880
X-Debbugs-Cc: z...@debian.org, broo...@debian.org
Dear Maintainer,
Attached is a patch that includes the changes applied by Ubuntu[1] to remove
the problematic unit test version check from their source package.
For visibility, on cc are Shengjing Zhu (as the patch author) and Broonie (as
zlib maintainer in Debian).
Regards,
James
[1] - https://bugs.launchpad.net/ubuntu/+source/burp/+bug/2046149
diff --git a/debian/changelog b/debian/changelog
index 1974a93..c18448e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+burp (3.1.4-3ubuntu1) noble; urgency=medium
+
+ * Add patch to remove unnecessary but broken zlib version check in fzp test
+(Closes: #1057880, LP: #2046149)
+
+ -- Shengjing Zhu Mon, 11 Dec 2023 18:59:33
+0800
+
burp (3.1.4-3) unstable; urgency=medium
* fix cleanup target (Closes: #1044122)
diff --git
a/debian/patches/remove-unnecessary-but-broken-zlib-version-check-in-fzp-t.patch
b/debian/patches/remove-unnecessary-but-broken-zlib-version-check-in-fzp-t.patch
new file mode 100644
index 000..a86d269
--- /dev/null
+++
b/debian/patches/remove-unnecessary-but-broken-zlib-version-check-in-fzp-t.patch
@@ -0,0 +1,23 @@
+From: Shengjing Zhu
+Date: Mon, 11 Dec 2023 18:56:13 +0800
+Subject: remove unnecessary but broken zlib version check in fzp test
+
+Debian-Bug: http://bugs.debian.org/1057880
+Ubuntu-Bug: https://launchpad.net/bugs/2046149
+---
+ utest/test_fzp.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/utest/test_fzp.c b/utest/test_fzp.c
+index 856eae1..cac280c 100644
+--- a/utest/test_fzp.c
b/utest/test_fzp.c
+@@ -179,8 +179,6 @@ END_TEST
+
+ START_TEST(test_fzp_gzseek)
+ {
+- if(version_to_long(ZLIB_VERSION) <= version_to_long("1.2.3"))
+- fzp_gzopen_old_zlib_seek_hack=1;
+ do_seek_tests(fzp_gzopen);
+ }
+ END_TEST
diff --git a/debian/patches/series b/debian/patches/series
index 8e3360f..a81b657 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ CVE-2017-16516.patch
CVE-2022-24795.patch
CVE-2023-33460-part1.patch
CVE-2023-33460-part2.patch
+remove-unnecessary-but-broken-zlib-version-check-in-fzp-t.patch
Bug#1057880: burp: FTBFS with zlib 1.3 due to 'make check' failure
Source: burp Version: 3.1.4-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: j...@jp-hosting.net Dear Maintainer, The unit tests for 'burp' perform a version check[1] on zlib to decide[2] between a choice of zip-related assertions to run during the tests. Most zlib versions have contained two or three dots, but the version check logic considers version '1.3' to be less than a threshold value of '1.2.3' due to the single dot in the former -- but that selects a faulty test assertion: utest/test_fzp.c:95:F:Core:test_fzp_gzseek:0: Assertion 'fzp_seek(fzp, d->pos, SEEK_SET)==-1' failed The relevant conditional has been removed[3] entirely from upstream as cleanup during other test-related changes, and the version of zlib in Debian old-old-stable is 1.2.11 - so perhaps it's safe to remove the conditional from the Debian source package too? The test failure can be found in the test regressions currently blocking the migration of zlib 1.3 to Debian testing in debci[4][5]. Regards, James [1] - https://sources.debian.org/src/burp/3.1.4-3/utest/test_fzp.c/#L182 [2] - https://sources.debian.org/src/burp/3.1.4-3/utest/test_fzp.c/#L93 [3] - https://github.com/grke/burp/commit/0de49dd3e39290ba4697ae20dd8007d31731ec84#diff-a915eb7475e84e4605e12ecb65f769d80686eda03b958929fb2030331802L182-L183 [4] - https://qa.debian.org/excuses.php?package=zlib [5] - https://ci.debian.net/packages/b/burp/testing/amd64/40814901/
Bug#1035871: flare-engine: broken symlink: /usr/share/games/flare/mods/default/fonts/unifont-10.0.06.ttf -> ../../../../../fonts/truetype/unifont/unifont.ttf
Followup-For: Bug #1035871 X-Debbugs-Cc: elb...@debian.org [ not a maintainer, but I have tested the behaviour of this bug ] On Thu, 1 Jun 2023 11:57:46 +0200, Paul wrote: > On Wed, 10 May 2023 13:54:11 +0200 Andreas Beckmann wrote: > > fonts-unifont does no longer ship unifont.ttf or other *.ttf. > > There are only the *.otf variants left in most cases. > > How bad is this in practice? Does flare-engine break completely or is > this mostly an annoyance? (I can imagine either or anything in between) In short: the game remains playable in English-language, but becomes practically unusable in other supported locales (ja, ko, zh, zh_TW). For affected locales, a (non-fatal) error prompt appears and in-game text is absent. Empty labels appear wherever menu/game text is expected, and error messages of the following form are output to stdout: ERROR: FontEngine: Invalid font 'font_'. No fallback available. Workaround: As Andreas mentions, an otf font variant exist. The game does correctly load and display fonts from this file when the symlink is updated to point to that file. Also note: The package 'cataclysm-dda-data' was similarly affected; see bug #1022269 for details.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Thu, 1 Jun 2023 at 15:48, Theodore Ts'o wrote: > > In addition to Bookworm being hard frozen, I question the importance > of this patch, the bug priority, and whether the title is correct. > After all, at least with respect to e2fsprogs systemd unit *will* > still be enabled. It will just be enabled using > ../multi-user.target/wanted instead of ../default.target/wanted. > > Ok, piuparts whines about it, and I agree that it's ideal if things > are the stame regardless of whether the distro is freshly installed or > uprgaded --- but e2scrub-repeat.service will *still* be enabled, > right? And so the bug title is misleaing, right? > > So it's not a big deal; is that correct so this patch is not worth > trying to shoehorn in beform Bookworm ships, and this particular patch > can be safely downgraded from importanted, right? I think all of that is true, yep. Also, arguing against my own revert-patch: I think it could be said that multi-user is the "better" target to use here, because the default could be "graphical" or some later-reached system state whereas this is a relatively low-level (if small) system cleanup service. It's taken me too long to figure all this out, but retrospectively I suppose my preference order here was: 1. Fix comprehensively in deb-systemd-helper. 2. Revert the original change (but I thought of / suggested that too late). 3. Apply a package-specific workaround (but I didn't find one that I was comfortable with suggesting). I'd agree with downgrading the severity to below RC (and it's your package, so feel free, I think? maybe even close it?). If anyone arrives here/reports other bugs as a result of experiencing it, I think we can let them know that it's safe to remove the legacy 'default.target' symlink (does that sound correct too?). Without getting too much into opinions on systemd itself: I think declarative systems are good, but that managing stateful transitions between multiple declared states can be challenging. Not impossible, and with sufficient bugreporting and fixing, it can be made solid - so that's something to continue on after the release. (and yep, I claimed I wouldn't look at this bug again for a while.. and I was tempted not to.. but I think clearing it from the RC queue is probably worthwhile)
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 X-Debbugs-Cc: jspri...@debian.org On Thu, 1 Jun 2023 13:53:18 +0200, Jochen wrote: > * James Addison [2023-06-01 12:44]: > >Would reverting the Install.WantedBy modification[1][2], restoring > >e2scrub_reap > >enablement using 'default.target' on relevant systems, be a sensible approach > >for bookworm until we can figure out the debhelper-system behaviour when that > >setting changes? > > No, bookworm is frozen and done: > > "In the last week prior to the freeze, testing will be completely > frozen and only emergency bug fixes will be considered in this period." > > https://lists.debian.org/debian-devel-announce/2023/04/msg7.html Drats - but also, thank you for confirming that. I'd read the announcement, and it is clear, but then somehow afterwards forgot, and thought that the relevant closing date was one week before the release itself. I'll return to this after bookworm is out and until then will try to relax and perhaps may even be able to de-serious myself temporarily to allow 'celebration'. Anyway, a revert patch is attached, although naturally it'd be better to determine the cause.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 Control: tags -1 patch >From 9ad481148456520f15f92973cdd0cf6caa16a088 Mon Sep 17 00:00:00 2001 From: James Addison Date: Thu, 1 Jun 2023 13:20:29 +0100 Subject: [PATCH] Revert "e2scrub: use WantedBy=multi-user.target in e2scrub_reap.service" This reverts commit b42c9788c75de10ee3b6d1a7f9fbc2f529b64889. Signed-off-by: James Addison --- scrub/e2scrub_reap.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scrub/e2scrub_reap.service.in b/scrub/e2scrub_reap.service.in index 58a45656..10d25f06 100644 --- a/scrub/e2scrub_reap.service.in +++ b/scrub/e2scrub_reap.service.in @@ -22,4 +22,4 @@ SyslogIdentifier=%N RemainAfterExit=no [Install] -WantedBy=multi-user.target +WantedBy=default.target -- 2.39.2
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, jspri...@debian.org, ans...@debian.org, a...@debian.org, debian.bugrep...@wodny.org, debian-rele...@lists.debian.org [ re-introducing the larger cc list audience, plus debian-release ] Would reverting the Install.WantedBy modification[1][2], restoring e2scrub_reap enablement using 'default.target' on relevant systems, be a sensible approach for bookworm until we can figure out the debhelper-system behaviour when that setting changes? [1] - https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=b42c9788c75de10ee3b6d1a7f9fbc2f529b64889 [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991349
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 On Wed, 31 May 2023 09:55:13 +0100, James wrote: > On Fri, 05 May 2023 11:04:29 +0200, Andreas wrote: > > If I install systemd into the bullseye chroot and upgrade that to > > bookworm, both systemd and e2fsprogs are still installed, but > > /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service > > does *NOT* get created. > > Is there a way to pause and step through the postinst script for a package > when > it runs? (similar to an interactive debugging session) There is/was-and-may-be-again bashdb[1]; it was removed[2] from Debian in Y2017. [1] - https://bashdb.sourceforge.net [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870992
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 On Fri, 05 May 2023 11:04:29 +0200, Andreas wrote: > If I install systemd into the bullseye chroot and upgrade that to > bookworm, both systemd and e2fsprogs are still installed, but > /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service > does *NOT* get created. Is there a way to pause and step through the postinst script for a package when it runs? (similar to an interactive debugging session)
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, jspri...@debian.org, ans...@debian.org, a...@debian.org, debian.bugrep...@wodny.org Would a 'move /etc/systemd/system/default.target.wants/e2scrub_reap.service to /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service if the source file exists' during the postinst be enough to restore consistency here, and satisfy piuparts? If waiting to the point-release is better, then I'm OK with that. I have some slight frustration about the path divergence - because I think consistent results are important for robust packaging - but if there's higher risk of breakage or a sense that it's too late to fix for bookworm, I can accept that.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, jspri...@debian.org, ans...@debian.org, a...@debian.org, debian.bugrep...@wodny.org I've been 'approximately' testing this locally on bookworm by: * Editing the Install.WantedBy in /lib/systemd/system/e2scrub_reap.service * Reconfiguring the package using 'dpkg-reconfigure e2fsprogs' (I know, it's not a comprehensive workflow - but I think that it calls the relevant deb-systemd-helper and e2fsprogs postinst script sections) Also: Marcin's patch[1] from #985787 is also intended to fix a very similar problem (perhaps exactly the same issue). Some puzzles: * Why does the 'deb-systemd-helper disable' invocation not work (as found by Helmut and Jochen)? It seems like it should read the symlink path to remove from the dsh-also state file, so the Install.WantedBy change should not affect it. * Is the /var/lib/systemd/deb-systemd-helper-enabled/ path relevant? This seems to contain a shadow copy of much of the /etc/systemd/system service state. * Is the 'create links unless no links installed' logic correct? (that sounds like it could be incorrect, but I'm not sure) I did manage to get something kinda-working locally with a combination of an 'update-state' call and Marcin's patch. However, I'd like to understand more about the 'deb-systemd-helper disable' call failure before recommending that. And, quoting Andreas: > Actually the difference is between the minimal bullseye chroot upgraded > to bookworm and the bullseye chroot with some packages to be tested > installed (here: systemd) and upgraded to bookworm. Ideally, after > removing the packages to be tested and their dependencies, the two > bookworm chroots should be identical ... I agree on the goals there. Being unhappy about systemd and maintaining a package that has divergent on-filesystem results depending on how users upgraded seems distinctly worse than being unhappy about systemd while maintaining a consistently-deployed package. [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985787#25 [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035543#62
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Sun, 14 May 2023 15:21:24 -0400, Ted wrote: > On Sun, May 14, 2023 at 06:03:59PM +0200, Michael Biebl wrote: > > > Please reassign it there together with instructions how to fix it, i.e. > > > what should be done in the maintainer scripts. > > Can someone send the instructions on how to fix this? I think we want to remove the old default.target.wants directory link and replace it with a multi-user.target.wants link at some point during the upgrade process. Would calling the 'reenable' action implemented by deb-systemd-helper[1] (an equivalent to the corresponding action in systemctl[2]) during the e2fsprogs postinst script solve the problem? (the contents of the deb-systemd-helper service state file seem very relevant here. for this to work correctly, I think it needs to contain the old link during the 'disable' step, and then should use the new link during 'enable'. I could be mistaken, however. I have read #717603 while trying to figure out a solution here) [1] - https://manpages.debian.org/bullseye/init-system-helpers/deb-systemd-helper.1p.en.html [2] - https://manpages.debian.org/bullseye/systemd/systemctl.1.en.html
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 X-Debbugs-Cc: a...@debian.org, bi...@debian.org I'm having trouble reconciling these two log lines during the upgrade without systemd: ls: cannot access '/etc/systemd/system/multi-user.target.wants': No such file or directory ... (deb-systemd-helper DEBUG) All links present, considering e2scrub_reap.service was-enabled. Could those indicate some kind of inconsistency/bug?
Bug#1030545: qemu-(img|system-s390x) hang on s390x bullseye kernel
Followup-For: Bug #1030545 (adding a message in 'quiet' mode with a self-correction) I wrote: > Hi Hilko (plus Dipak, fix author on cc for awareness), My mistake there: Sumanth was the patch author for this change I believe.
Bug#1030545: qemu-(img|system-s390x) hang on s390x bullseye kernel
Followup-For: Bug #1030545 X-Debbugs-Cc: ben...@debian.org, dipak.zo...@ibm.com Hi Hilko (plus Dipak, fix author on cc for awareness), Debian kernel package 5.10.179-1 that includes a fix for this has been accepted into the stable-security (bullseye-security) suite today, and should resolve this bug. (note: I'm uncertain when/whether that update may be applied to zelenka, the porterbox host, however) Thanks, James [1] - https://tracker.debian.org/media/packages/l/linux/changelog-5.10.179-1
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Followup-For: Bug #1030284 I decline to participate further with this bugreport, although others are welcome to pick up from the patches I've submitted (please don't merge them as-is; modify them to apply corrections).
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Followup-For: Bug #1030284 X-Debbugs-Cc: t...@mirbsd.de It does seem to (continue to) function, at least on x86: ~/dygraphs-2.2.0$ NODE_PATH=/usr/share/nodejs ../nodejs-18.13.0+dfsg1/out/Release/node /usr/bin/babeljs --config-file $PWD/babel.config.json --compact false --source-maps inline -d tests5 auto_tests Successfully compiled 59 files with Babel (2744ms). (NOTE: this was an x86 system, not an ARM64 system) And the relevant v8 help text output appears to update accordingly: ~/dygraphs-2.2.0$ ../nodejs-18.13.0+dfsg1/out/Release/node --v8-options | grep -i stack-size --stack-size (default size of stack region v8 is allowed to use (in kBytes)) type: int default: --stack-size=8192
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de
Hmm.. although the build itself succeeded, there was a unit test failure that
appears related to the change:
not ok 3213 sequential/test-fs-stat-sync-overflow
---
duration_ms: 1.111
severity: fail
exitcode: 1
stack: |-
node:assert:1027
throw err;
^
AssertionError [ERR_ASSERTION]: The input did not match the regular
expression /RangeError: Maximum call stack size exceeded/. Input:
'Segmentation fault\n'
at
/root/nodejs-18.13.0+dfsg1/test/sequential/test-fs-stat-sync-overflow.js:40:10
at ChildProcess.exithandler (node:child_process:427:5)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1091:16)
at Socket. (node:internal/child_process:449:11)
at Socket.emit (node:events:513:28)
at Pipe. (node:net:321:12) {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: 'Segmentation fault\n',
expected: /RangeError: Maximum call stack size exceeded/,
operator: 'match'
}
Node.js v18.13.0
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de
Thanks, Thorsten. I'm currently rebuilding (on x86) from the attached patch,
adapted from yours.
* prefers a one-time repeat division over the clever-but-fragile div-assign
* removes the upperbound check because integer greater-than checks can be
problematic
* places comparison constants on the lhs for safety
I'll post test results when they are available.
Cheers,
James
Description: Request an rlimit-determined stack size from V8
Author: James Addison
Bug-Debian: https://bugs.debian.org/1030284
--- /dev/null
+++ nodejs-18.13.0+dfsg1/foo.c
@@ -0,0 +1,7 @@
+#include
+
+int main() {
+if (4 > (int)(8 / 3)) {
+printf("Hello world!");
+}
+}
--- nodejs-18.13.0+dfsg1.orig/src/node.cc
+++ nodejs-18.13.0+dfsg1/src/node.cc
@@ -785,6 +785,22 @@ int InitializeNodeWithArgs(std::vector (int)(lim.rlim_cur / 1024))
+ fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is too
small\n");
+ else
+ V8::SetFlagsFromString(stackSize, snprintf(stackSize,
sizeof(stackSize),
+ "--stack-size=%d", (int)(lim.rlim_cur / 1024)));
+}
+
HandleEnvOptions(per_process::cli_options->per_isolate->per_env);
#if !defined(NODE_WITHOUT_NODE_OPTIONS)
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Sat, 13 May 2023 at 12:15, James Addison wrote:
>
> On Sat, 13 May 2023 at 11:14, James Addison wrote:
> >
> > On Sat, 13 May 2023 at 02:18, Thorsten Glaser wrote:
> > >
> > > James Addison dixit:
> > >
> > > >I'm going to stay involved with this thread, but I think that it is
> > > >upon you to develop or provide further guidance towards a patch if
> > > >it's something you'd like to have implemented, Thorsten.
> > >
> > > I actually have looked into that but I don’t understand the nodejs
> > > and v8 source code enough to be able. I know C, but not CFrustFrust.
> > > I would rather prefer asm…
> >
> > Ok, thanks. We may be stalled temporarily in that case.
> >
> > On Sat, 13 May 2023 at 00:20, James Addison wrote:
> > > That said: perhaps it could be useful if someone could check whether
> > > the following commit is relevant to this:
> > > https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1
> >
> > I ran the repro case (with some simplifications) from the GitHub
> > thread using 'strace' and grepped for rlimit-related syscalls:
> >
> > # on arm64, this currently replicates the problem using debian bookworm
> > $ strace babeljs --config-file $PWD/babel.config.json --compact
> > false --source-maps inline -d tests5 auto_tests 2>&1 | grep -i rlimit
> >
> > All of the resulting calls (on an ARM64 host) are to the 'prlimit64'
> > syscall and have a zero exit-code (success).
>
> How about extending the code around after this block:
> https://github.com/nodejs/node/blob/2bb4b59fa5529569ad38d3bf7d3c926d8e47/src/node.cc#L781-L786
>
> ... to add something like this:
>
> if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
> struct rlimit lim;
> if (getrlimit(RLIMIT_STACK, ) == 0) {
> char stackSize[32];
> int buflen = snprintf(stackSize, sizeof(stackSize),
> "--stack-size=%d", lim.rlim_cur);
> if (buflen < sizeof(stackSize)) {
> V8::SetFlagsFromString(stackSize, buflen);
> }
> }
> }
>
> ?
Note: probably worth adjusting that to add another conditional to
check that the stack limit isn't unset/infinity:
if (getrlimit(RLIMIT_STACK, ) == 0 && lim.rlim_max != RLIM_INFINITY) {
I'm not sure that I have an ARM64 machine with enough memory and/or
non-flash-based disk to want to compile and test this on. But
hopefully it would be fairly straightforward (apt source nodejs, apt
build-dep ., dpkg-buildpackage, or something along those lines).
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Sat, 13 May 2023 at 11:14, James Addison wrote:
>
> On Sat, 13 May 2023 at 02:18, Thorsten Glaser wrote:
> >
> > James Addison dixit:
> >
> > >I'm going to stay involved with this thread, but I think that it is
> > >upon you to develop or provide further guidance towards a patch if
> > >it's something you'd like to have implemented, Thorsten.
> >
> > I actually have looked into that but I don’t understand the nodejs
> > and v8 source code enough to be able. I know C, but not CFrustFrust.
> > I would rather prefer asm…
>
> Ok, thanks. We may be stalled temporarily in that case.
>
> On Sat, 13 May 2023 at 00:20, James Addison wrote:
> > That said: perhaps it could be useful if someone could check whether
> > the following commit is relevant to this:
> > https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1
>
> I ran the repro case (with some simplifications) from the GitHub
> thread using 'strace' and grepped for rlimit-related syscalls:
>
> # on arm64, this currently replicates the problem using debian bookworm
> $ strace babeljs --config-file $PWD/babel.config.json --compact
> false --source-maps inline -d tests5 auto_tests 2>&1 | grep -i rlimit
>
> All of the resulting calls (on an ARM64 host) are to the 'prlimit64'
> syscall and have a zero exit-code (success).
How about extending the code around after this block:
https://github.com/nodejs/node/blob/2bb4b59fa5529569ad38d3bf7d3c926d8e47/src/node.cc#L781-L786
... to add something like this:
if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
struct rlimit lim;
if (getrlimit(RLIMIT_STACK, ) == 0) {
char stackSize[32];
int buflen = snprintf(stackSize, sizeof(stackSize),
"--stack-size=%d", lim.rlim_cur);
if (buflen < sizeof(stackSize)) {
V8::SetFlagsFromString(stackSize, buflen);
}
}
}
?
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Sat, 13 May 2023 at 02:18, Thorsten Glaser wrote: > > James Addison dixit: > > >I'm going to stay involved with this thread, but I think that it is > >upon you to develop or provide further guidance towards a patch if > >it's something you'd like to have implemented, Thorsten. > > I actually have looked into that but I don’t understand the nodejs > and v8 source code enough to be able. I know C, but not CFrustFrust. > I would rather prefer asm… Ok, thanks. We may be stalled temporarily in that case. On Sat, 13 May 2023 at 00:20, James Addison wrote: > That said: perhaps it could be useful if someone could check whether > the following commit is relevant to this: > https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1 I ran the repro case (with some simplifications) from the GitHub thread using 'strace' and grepped for rlimit-related syscalls: # on arm64, this currently replicates the problem using debian bookworm $ strace babeljs --config-file $PWD/babel.config.json --compact false --source-maps inline -d tests5 auto_tests 2>&1 | grep -i rlimit All of the resulting calls (on an ARM64 host) are to the 'prlimit64' syscall and have a zero exit-code (success).
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Fri, 12 May 2023 at 23:23, James Addison wrote: > > On Fri, 12 May 2023 at 16:54, Thorsten Glaser wrote: > > > > Yes, but given the usual ulimit, the new limit would be 4+ times > > the old one, much much harder to reach. > > That does sound promising. > > I've followed up on this discussion with the relevant upstream NodeJS > thread, and beyond there to the relevant V8 discussion group. My > sense from those, and given my own experience building NodeJS is that > I don't feel an rlimit patch is straightforward or worthwhile - > although it's possible that I didn't accurately understand or > communicate the context. > > I'm going to stay involved with this thread, but I think that it is > upon you to develop or provide further guidance towards a patch if > it's something you'd like to have implemented, Thorsten. Maybe my tone was unclear, but I'm not hugely keen to provide more effort on this -- despite being interested -- because I feel like I've been running errands to try to find a good path through, when in fact I don't really understand the nature of the problem, nor am I likely to benefit much from it. But if improvement is possible, I'll do what I can. That said: perhaps it could be useful if someone could check whether the following commit is relevant to this: https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Fri, 12 May 2023 at 16:54, Thorsten Glaser wrote: > > Yes, but given the usual ulimit, the new limit would be 4+ times > the old one, much much harder to reach. That does sound promising. I've followed up on this discussion with the relevant upstream NodeJS thread, and beyond there to the relevant V8 discussion group. My sense from those, and given my own experience building NodeJS is that I don't feel an rlimit patch is straightforward or worthwhile - although it's possible that I didn't accurately understand or communicate the context. I'm going to stay involved with this thread, but I think that it is upon you to develop or provide further guidance towards a patch if it's something you'd like to have implemented, Thorsten.
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Thu, 11 May 2023 at 23:54, Thorsten Glaser wrote: > > James Addison dixit: > > >On Thu, 11 May 2023 at 02:43, Andres Salomon wrote: > > >> For ARM64, he says that raising the stack limit is not safe for v8 > >> *embedded inside WebView*, and therefore not appropriate for upstream > >> v8. But then he says it could/should be safe for v8 *embedded inside > >> NodeJS*. > >> > >> Based on that, I suggest patching Debian's NodeJS with the patch to > >> adjust armhf/arm64 stack limit size > > That would be a good thing (huh, wasn’t armhf good?), but… > > >I have a question: if we apply the patch and begin using the same > >constant stack size of 984kb on 32-bit ARM and 64-bit ARM as is > >defined for other architectures, then does NodeJS on those platforms > >begin supporting exactly the same stack frame capacity (maximum call > >depth for any given recursive function, for example) as a build of the > >same NodeJS source on x86 and amd64 respectively? > > … no, because both stack usage and other stuff on stack differ. Ok, that's what I thought, but I'm not familiar with the details here. So: a fix here won't achieve stack capacity equality across architectures. (I say this because I think we should be clear about what the bugreport is about, and, where possible, the known limitations of fixes) Or, to put it another way: applying an increase (either static or dynamic, either ARM-specific or across all architectures) for stack size determination would move the problem, and another architecture would take the place of "architecture where RangeError can occur in code x that doesn't occur on other architectures". Do those statements seem true? (they make sense to me, but I also think it's possible that I've misunderstood something here) > Which is why I’d rather have the getrlimit-based one for nodejs. > That would give us twice to four times the limit. That makes sense, and I agree that dynamic stack-sizing could help (perhaps quite a lot on some systems). We'd need a patch to implement it, though - and based on their current policy, NodeJS upstream seem unlikely to accept it since they don't want to modify their vendored V8. But if it showed significant benefits then perhaps we could use that to contribute to further discussion with either/both of those projects.
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Thu, 11 May 2023 at 02:43, Andres Salomon wrote: > > On Sat, 11 Mar 2023 11:04:15 + James Addison > wrote: > > Package: nodejs > > Followup-For: Bug #1030284 > > X-Debbugs-Cc: t...@debian.org > > > > Guidance received from the V8 project (a vendored dependency in the > upstream > > NodeJS codebase) on the v8-dev mailing list is, in > summary/interpretation: > > > > * It is not yet safe to increase the stack size limit on ARM64 > systems. > [...] > > Sidenotes: > > > > A patch for 32-bit architectures could apparently be acceptable, > although may > > be best offered to NodeJS rather than V8. For what it's worth: > NodeJS seems > > to have a policy of not accepting patches to their vendored > dependencies. > > > > In reading Jakob's response > (https://groups.google.com/g/v8-dev/c/7ZI3vxtabcU/m/c9qvHkOBBAAJ), I'm > interpreting it slightly differently- > > He says that raising the stack limit *is* safe for 32-bit ARM, even > inside of the V8 upstream source tree. > > For ARM64, he says that raising the stack limit is not safe for v8 > *embedded inside WebView*, and therefore not appropriate for upstream > v8. But then he says it could/should be safe for v8 *embedded inside > NodeJS*. > > Based on that, I suggest patching Debian's NodeJS with the patch to > adjust armhf/arm64 stack limit size to 984kb. With the caveat that the > javascript code that is triggering this bug should really be fixed to > not be so stack-intensive, of course. Perhaps this bug cloned at a > lower severity, filed against those packages that this bug is affecting? > > (As chromium maintainer, which also embeds v8, I haven't heard of any > issues and hadn't planned on touching stacks limits. It sure would be > nice to have just one copy of V8 in the archive, though..) I have a question: if we apply the patch and begin using the same constant stack size of 984kb on 32-bit ARM and 64-bit ARM as is defined for other architectures, then does NodeJS on those platforms begin supporting exactly the same stack frame capacity (maximum call depth for any given recursive function, for example) as a build of the same NodeJS source on x86 and amd64 respectively?
Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Package: libgtk-3-0 Version: 3.24.37-2 Followup-For: Bug #1034289 Control: severity -1 important As mentioned previously: although this bug seemed RC-level in the context of Inkscape, libgtk3 has a sizable set of dependent packages, so in that context, and given that release-preparation time is finite, I think we should reduce the severity. (despite that, I intend to track this bug fairly closely because I'm interested in the results)
Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Package: libgtk-3-0 Followup-For: Bug #1034289 X-Debbugs-Cc: giuseppe.bilo...@gmail.com Hi Giuseppe, If possible: can you share some more information about your use-case for XIM as an input method (either with Inkscape in particular, or more generally on the relevant system(s)). Thanks, James
Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Followup-For: Bug #1034289 X-Debbugs-Cc: giuseppe.bilo...@gmail.com, debian-multime...@lists.debian.org Control: reassign -1 libgtk-3-0 Control: affects -1 inkscape Control: tags -1 patch After testing the patch (that is based on a suggestion in an upstream GTK bug discussion thread[1]), I can confirm that it resolves the canvas-refresh issue reported in Inkscape (that depends on libgtk-3-0 for window rendering). Based on that, I'm reassigning this bug to the package where the problem seems to originate and be fixable. Although this bug does seem RC-severity for Inkscape, it seems possible that the severity should be reduced in the context of libgtk, since that is a dependency of many other packages, few of which are likely to be affected (a call to 'gdk_window_ensure_native' is required as a minimum for the problem to occur, according to a repro test case[2]). I'll provide related updates on the upstream discussion thread(s). [1] - https://gitlab.gnome.org/GNOME/gtk/-/issues/2560#note_757809 [2] - https://gitlab.gnome.org/GNOME/gtk/-/issues/2560#note_757066
Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Package: inkscape Version: 1.2.2-2+b1 Followup-For: Bug #1034289 After installing a fresh Debian bookworm system and installing the 'inkscape' package (version 1.2.2-2+b1), I can confirm that this issue is reproducible; it can be found by running: $ GTK_IM_MODULE=xim inkscape ... and from there, attempting to create or edit text objects (shortcut: 'T') within a document (for example, after creating a new blank SVG document). I'm planning to attempt a rebuild of GTK3 with the previously-attached patch[1] and then rebuilding src:inkscape against that to confirm whether the patch resolves the problem. [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034289#15
Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box
Source: inkscape Followup-For: Bug #1034289 X-Debbugs-Cc: giuseppe.bilo...@gmail.com, debian-gtk-gn...@lists.debian.org Control: forwarded -1 https://gitlab.com/inkscape/inkscape/-/issues/3664 Dear Maintainer (and cc'ing the GTK-GNOME list), Following on from Giuseppe's upstream link: > Additional information: the issue I'm seeing seems to match upstream > issue #3664 > https://gitlab.com/inkscape/inkscape/-/issues/3664 ... to a further-upstream bug[1] in the GTK issue tracker, there's a reference to GDK window repainting as the possible cause[2] (with a suggested fix). The (untested) patch I've attached here applies the suggested change to src:gtk+3.0 (and was created from version gtk+3.0-3.24.37 of it). I don't yet have an environment prepared to build and test it, but will try to create one soon. Thanks, James [1] - https://gitlab.gnome.org/GNOME/gtk/-/issues/2560 [2] - https://gitlab.gnome.org/GNOME/gtk/-/issues/2560#note_757809 Description: gdkwindow: allow frame paint events to occur for non-toplevel windows . Partially-reverts upstream commit fc569f1ac6ff108afc17f7f439480273826af3a6. Author: James Addison Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/2560 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034289 Last-Update: 2023-04-21 --- gtk+3.0-3.24.37.orig/gdk/gdkwindow.c +++ gtk+3.0-3.24.37/gdk/gdkwindow.c @@ -3253,7 +3253,7 @@ gdk_window_begin_draw_frame (GdkWindow return NULL; } - if (gdk_window_has_native (window) && gdk_window_is_toplevel (window)) + if (gdk_window_has_native (window)) gdk_window_begin_paint_internal (window, region); impl_class = GDK_WINDOW_IMPL_GET_CLASS (window->impl); @@ -3307,7 +3307,7 @@ gdk_window_end_draw_frame (GdkWindow return; } - if (gdk_window_has_native (window) && gdk_window_is_toplevel (window)) + if (gdk_window_has_native (window)) gdk_window_end_paint_internal (window); impl_class = GDK_WINDOW_IMPL_GET_CLASS (window->impl);
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
Followup-For: Bug #994274 X-Debbugs-Cc: lu...@schwaighofer.name, pk...@debian.org, timo.lindf...@iki.fi Hi Lukas, Philipp, Timo, Does reverting the removal[1] of 'efisetjmp.h' from 'efi.h' in src:gnu-efi produce successful results? That occurred between gnu-efi versions 3.0.9 and 3.0.13 if I read the upstream history correctly. (revert patch attached for convenience, although I'm not yet going to add the corresponding tag to this bug until we confirm whether it's useful) And if that headerfile does seem relevant: this issue may affect src:shim too. Thanks, James [1] - https://sourceforge.net/u/lslrt/gnu-efi/ci/486ba3c3bdd147b7d98159b9e650be60bce0f027/ --- a/apps/setjmp.c +++ b/apps/setjmp.c @@ -1,7 +1,6 @@ #include #include -#include EFI_STATUS efi_main( --- a/inc/efi.h +++ b/inc/efi.h @@ -75,6 +75,7 @@ #include "efiudp.h" #include "efitcp.h" #include "efipoint.h" +#include "efisetjmp.h" #include "efishell.h" #endif
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Followup-For: Bug #973414 X-Debbugs-Cc: fierel...@gmail.com On Mon, 3 Apr 2023 23:07:35 +0200, Fierelier wrote: > * In terms of confusion: I think using the Rust i586 toolchain, and > building for i586 with Rust might be less confusing, because altering > the i686 definitions for rustc will make it act differently compared > to other platforms. People could compile code for i686 on Debian, get > working code, but then if someone else does the same on another > distro, the produced binary would not work on the same devices. That's a fair point, yep; matching upstream behaviour is often the simplest and most understandable approach. It seems the choice is between using an upstream-compatible definition, or an inter-toolchain-compatible definition (are there any other choices? I did notice use of per-extension feature flags in some build configurations. they don't appear widely standardized though, or at least that's my initial sense). > Although, I think changing the i686 definition down, like you did, is > the most accurate way to achieve the goal, and is what I personally > think should be mainline. If the accurate definition proves itself on > Debian, it might find itself in mainline Rust, too, which would be > awesome. Thanks - and thank you for re-stating the intent of the patch. (I confusingly wrote "my personal preference" instead of "my personal opinion" in a previous comment) I wouldn't want Debian's choice to be intended as a way to influence Rust's upstream choices. It'd be more a case of "who is comfortable using a divergent definition of "i686" for longer before their respective communities call them out on it" (in other words: each project can take their own path, and each project can decide how to proceed, as they usually would).
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: fierel...@gmail.com
Hi Fierelier - thanks for your previous comment, here's my reply, slightly
later than I'd hoped:
On Wed, 29 Mar 2023 00:10:52 +0200, Fierelier wrote:
> - issue 1: i386, i486, i586, i686 are considered as Pentium 4 in LLVM,
> which might be relevant if Rust is compiled with it:
> https://github.com/llvm/llvm-project/issues/61347
Yep, this is relevant.
Debian does currently use LLVM for rustc builds, yep. Along the way I found
the rustc build README.Debian[1] that's a very useful explanatory guide.
To be slightly more specific, currently LLVM 14 is in use, and some of the
build options for it (including that version number[2]) are placed into a
config.toml[3] file that's used by the rustc build process (x.py).
Included in Debian's patches for the LLVM 14 toolchain is a patch to adjust
the Pentium 4 target you mention down to i686:
https://sources.debian.org/src/llvm-toolchain-14/1%3A14.0.6-12/debian/patches/clang-baseline-fix-i386.patch
> - issue 2: Rust considers i686 as Pentium 4, and i586 as Pentium:
> https://github.com/rust-lang/rust/issues/82435
Also relevant, yep. Some of the comments, and the current title that I read
for that thread ("i686 target spec disagrees with downstream definitions")
discuss the core of the problem here.
There are reasons for some people to want the definition of i686 to shift
forward, perhaps towards the bulk of the processors within that family that
are in everyday use.
And there are reasons to want to keep the definition to its original, most
compatible specification (although as found on my NOPL learnings, even in the
early days of the P6 there was some divergence there).
I don't like neither wasted CPU time, nor wasted electricity, nor wasted human
time spent reading and understanding these issues, but it's difficult (for me,
at least) to see a remedy that is optimal for all of those. Even writing an
additional paragraph about this introduces overhead for future readers.
> - When building the Rust toolchain itself, if Debian uses LLVM for it,
> it might be a good idea to set the CPU target explicitly to pentiumpro
> in LLVM's flags (fix issue 1) (It could also be a good idea to set
> this for LLVM in general if possible, if not already done so). -- Also
> compile the i586 Rust toolchain, not the i686 one (fix issue 2).
It looks like that CPU target adjustment suggestion was accepted in #908561 in
September Y2018.
For my investigation regarding the presence of NOPL -- an instruction that is
unavailable[4] on a limited number of i686 CPUs -- reducing that target further
to from "pentiumpro" to "i686" appears to resolve the issue.
That, I expect, also has the side-effect of omitting MMX instructions from the
set of valid instructions that the Debian i386 Rust toolchain may output. So
there is at least one downside there.
My personal preference, that may or may not be aligned with Debian, is that
switching to build from the Rust i586 toolchain, while it would be a valid fix,
could cause confusion; it'd be a form of ecosystem fragmentation, and puzzling
for humans in particular to reason about.
Arguably that could be worthwhile puzzlement -- "why do Debian's Rust packages
and libraries refer to i586?", followed by learning about the situation and
knowledge spreading. Is that better than referring to i686 as with other
toolchains within Debian, yet having some divergence from what upstream's i686
means?
In honesty, I don't know. But I would like people who install Debian i386 on
all systems within Debian's i386 baseline to be able to use those computers and
the Debian-packaged software as intended, as completely as possible, and to me
it feels like changing the policy baseline or changing to i586 are beyond my
skills (certainly in time for bookworm), so I'm offering the best option that I
can.
Thanks again,
James
[1] -
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/README.Debian/#L28-L32
[2] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/rules/#L31
[3] -
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/config.toml.in/#L30-L43
[4] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32
Bug#1005886: debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"
Followup-For: Bug #1005886 X-Debbugs-Cc: powe...@gmail.com Control: reassign -1 cdimage.debian.org Control: retitle -1 cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware" Sorry (both to you Tony, and also the Debian CD team) for confusion and wasting time - I mistakenly reassigned this previously. I've checked the list of bug-tracking pseudo-packages[1] and I do think that cdimage.debian.org is the correct package for this bug to be assigned to. [1] - https://www.debian.org/Bugs/pseudo-packages
Bug#1031909: python3-tk: bytecode not removed on upgrade
Followup-For: Bug #1031909 Control: tags -1 patch
Bug#1031909: python3-tk: bytecode not removed on upgrade
Package: python3-tk Followup-For: Bug #1031909 Dear Maintainer, Please find a merge request on Salsa to resolve this issue for future versions of python3-tk at https://salsa.debian.org/cpython-team/python3-stdlib/-/merge_requests/5 This has been tested by installing the previous version of the package reported by the user (python3-tk_3.10.8-1) and then manually invoking the bytecode compilation[1] steps from the dpkg 'configure' script, before upgrading to the current version of the package (3.11.2-2). Without the fix applied to the previous package, the following output appears: Unpacking python3-tk:amd64 (3.11.2-2) over (3.10.8-1) ... dpkg: warning: unable to delete old directory '/usr/lib/python3.10/tkinter': Directory not empty dpkg: warning: unable to delete old directory '/usr/lib/python3.10': Directory not empty Setting up python3-tk:amd64 (3.11.2-2) ... With the fix applied, the following output appears: Unpacking python3-tk:amd64 (3.11.2-2) over (3.10.8-1) ... Setting up python3-tk:amd64 (3.11.2-2) ... Thanks, James [1] - https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/3.10.8-1/debian/python3-tk.postinst.in#L9-21
Bug#1032544: pylint: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Source: pylint Followup-For: Bug #1032544 X-Debbugs-Cc: w...@wrar.name, lu...@debian.org > This may be related, or just a duplicate, to #1032043, fixed in the newer > version which is already in testing. Yep, agreed that the updated testing package upload fixes this. (it looks like the testing distribution briefly contained a more recent version of astroid than this version of pylint's tests could pass with)
Bug#1000955: libkf5globalaccel-bin: /usr/bin/kglobalaccel5 eats up huge amount of CPU after suspend
Followup-For: Bug #1000955 Control: severity -1 normal A summary of a side-discussion between Filippo and myself about this bug: * Although the bug doesn't appear reproducible today, the cause hasn't been confirmed. * We both agreed that it makes sense for bugs to continue to stay open until it's clear that the reported problem has been solved. Based on that I think we should leave the bug open, but reduce the severity so that it isn't considered release-critical for bookworm. (this update is also partly to note that we haven't found any more information yet)
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 X-Debbugs-Cc: t...@mirbsd.de On Thu, 02 Feb 2023 01:56:10 +, Thorsten wrote: > I consider this an architecture-specific release-critical bug. Maybe > having a reproducer and access to a porterbox will allow a nodejs > maintainer to track this down. Based on what I've learned about this bug, I believe that architecture-specific behaviour related to stack sizes is inherent in the V8 library vendored by upstream NodeJS. Improvements may be possible and we can continue to track and assist towards those, however there are likely to be runtime differences that remain for a long time. Individual codebases such as the affected 'src:dygraphs' package can also be improved to reduce the likelihood of call stack size overflow. Given those, and the absence of any sense that this is a regression, I think we should lower the priority of this bug to below release-critical.
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 X-Debbugs-Cc: t...@debian.org Guidance received from the V8 project (a vendored dependency in the upstream NodeJS codebase) on the v8-dev mailing list is, in summary/interpretation: * It is not yet safe to increase the stack size limit on ARM64 systems. * For a given constant stack size, recursion depth is architecture-dependent, and so the patch to restore the 984K stack size on ARM64 would not provide equal recursion depth on all systems. * Exceeding stack depth limits is generally a sign of an application that would benefit from relevant refactoring (personal note: for example, by reducing the depth of recursion required, or by replacing a recursive algorithm with an equivalent iterative algorithm). Sidenotes: A patch for 32-bit architectures could apparently be acceptable, although may be best offered to NodeJS rather than V8. For what it's worth: NodeJS seems to have a policy of not accepting patches to their vendored dependencies. None of this rules out an rlimit-based approach as suggested by Thorsten.
Bug#1005886: cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware"
Followup-For: Bug #1005886 Control: reassign -1 debian-cd Control: retitle -1 debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"
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#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#1003044: internal 'getzoneinfofile_stream' method emits a warning message
Followup-For: Bug #1003044
On Tue, 21 Feb 2023 14:46:01 -0500, morph wrote:
> On Sun, Jan 29, 2023 at 9:45 AM Felix Geyer wrote:
> > How exactly does this break matplotlib?
> it produces output on stderr, which many tools consider it an error
> and fails build.
On Fri, 3 Mar 2023 15:05:03 -0500, morph wrote:
> 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, Arnout wrote:
> AFAICS, the API is not deprecated. It is also not really broken. Is just
> that if you ask explicitly for the bundled database, you get an empty
> database. Currently, you get an empty database and a warning is printed; my
> patch just removes that warning.
This isn't ideal, but if we're not comfortable bundling the database or coding
a compatibility interface... perhaps helping people to fix the warnings in
their own environments (re: stderr) could be a next-best-option?
We could extend the warning messaging; something like:
"An error occurred while attempting to read {0}.\n"
+
"To resolve this warning, please ensure that a dateutil-compatible timezone "
"data tarball exists and is readable at {1}.\n"
+
"Note: an empty tarball is considered valid and will silence this warning, "
"but you should check the code path(s) that emitted these warnings before "
"supplying that, since it will not provide any timezone information."
The intended effect of that would be:
* Do not hide that a failure occurred
* Provide more explanation about what went wrong
* Provide solution options to sysadmin (although sometimes user != sysadmin)
* Attempt to use messaging that python-dateutil upstream could merge
Bug#1028743: python-bottle: FTBFS: AssertionError: b'OK' != "URLError(ConnectionRefusedError(111, 'Connection refused'))"
Followup-For: Bug #1028743 Control: tags -1 fixed-upstream Note for maintainers: the patch attached to this bug has been merged into the upstream 'release-0.12' branch and is included in the 0.12.5 release. (so hopefully it is possible to drop the patch from packaging for that version onwards) Thanks, James
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Followup-For: Bug #1030284 There is one part of this patch that worries me, and it is the line: > -//See issue crbug.com/405338 I'm not able to access that bug: neither anonymously nor when logged into my gmail account. The comment would seem to indicate that it contains relevant context about why the stack limit was reduced on ARM architectures.
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 X-Debbugs-Cc: gunna...@debian.org On Fri, 3 Mar 2023 15:10:30 +0100, Gunnar wrote: > On 2023-03-03 13:21, James Addison wrote: > > I also noticed that some of gnome-desktop's default locale-to-input-source > > mappings provide multiple entries, delimited by the '+' character: > > > > https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/43.2/libgnome-desktop/default-input-sources.h#L31 > That's a misconception. The '+' character is there to specify a layout > variant. So "ch+fr" means the "French (Switzerland)" keyboard layout. Ok, that's good to have clarified - thank you Gunnar for the correction. Unrelated to that: I think I'll pause from providing any further comments on this bug thread for at least a few days.
Bug#1032255: pulseaudio: sound keeps dying (on Tiger Lake)
Package: pulseaudio Followup-For: Bug #1032255 Control: retitle -1 pulseaudio: application restart required to restore sound Control: severity -1 normal Control: tags -1 moreinfo Hi Dave, Are there any clues (error messages, service start/stops, or things like that) in the affected system's journal logs? The following command might be helpful along those lines: $ journalctl --user --merge --unit pulseaudio.service Also, the following page provides some information (and some problem-solving techniques) for PulseAudio on Debian - have you had any luck with any of these? https://wiki.debian.org/PulseAudio Cheers, James
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 I also noticed that some of gnome-desktop's default locale-to-input-source mappings provide multiple entries, delimited by the '+' character: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/43.2/libgnome-desktop/default-input-sources.h#L31 It's probably a question to ask them, but I am wondering whether it'd be possible (and/or sensible) to provide *both* anthy and mozc in the default input sources (which would correspond to adding ibus-anthy and ibus-mozc both as 'Recommends', instead of a choice between them).
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 (comment to bug-thread only) If it's true that the cause is that 'tasksel' and 'gnome-initial-setup' are mismatched, then we could apply a fix in either one. Given that we have an existing patch available for 'gnome-initial-desktop', I've opened a corresponding 'tasksel' changeset with the mirrored side of the fix at: https://salsa.debian.org/installer-team/tasksel/-/merge_requests/25
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 X-Debbugs-Cc: s...@debian.org, z...@debian.org, ken...@xdump.org, yy.y.ja...@gmail.com, iwama...@debian.org, gunna...@debian.org, debian-i...@lists.debian.org, debian-japan...@lists.debian.org, m...@packages.debian.org, ibus-an...@packages.debian.org After attempting a re-install with Japanese language defaults (to try to make sure that I understand the problem), I'd like to check some more details. If I'm on the wrong path, then I'll stop adding further comments for a while to let you all and others find a better solution. On Thu, 2 Mar 2023 15:50:22 +, Simon wrote: > When there are patches available for whatever we decide is the right > behaviour, you shouldn't need to walk through the whole install process. This is true. However, these comments seem particularly relevant: On Thu, 2 Mar 2023 18:39:04 +0800, Shengjing wrote: > I'm not a Japanese user. But I've been frustrated in the last few days > of the Bullseye release, when Gnome's upstream choice conflicts with > Debian's tasksel. On Thu, 2 Mar 2023 22:07:16 +0900, Kentaro wrote: > The problem is conflicting with task-japanese-gnome-desktop's recommends. Based on those, it seems to me that part -- perhaps most -- of the problem is the 'task-japanese-gnome-desktop' entry[1] for bookworm is currently: ibus-mozc | ibus-anthy So I believe mozc is selected as the first dep-satisfying option during a fresh Debian bookworm plus GNOME install. Please correct me if I'm wrong about that. That conflicts with the default that 'gnome-initial-setup' configures, namely the 'anthy' input method -- explaining the patch that Yoshino-san provided. So: regardless of whether we choose 'mozc' or 'anthy', we should try to match the input method that we install by default with the input method that is configured by 'gnome-initial-setup'. (the idea to query the available input engines at selection-time is theoretically a much more robust approach.. but it could take longer for that to become available and be tested thoroughly, and as noted previously in the thread, the default install of GNOME desktop for Japanese language input is known broken today) Note: if everyone else understood all that already, and I'm only finally catching up with you all now, then my apologies for being slow. It didn't seem clear to me previously what the core of the problem here is. [1] - https://sources.debian.org/src/tasksel/3.71/debian/control/#L1462
Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error
Package: python3-django-hyperkitty
Followup-For: Bug #1031928
Control: tags -1 - moreinfo
Control: tags -1 + confirmed
Control: severity -1 important
On Thu, 2 Mar 2023 20:30:04 +0100, Peter J. Holzer wrote:
> On 2023-03-02 19:53:12 +0100, Peter J. Holzer wrote:
> > So it seems that my suspicion that {% compress js %}...{% endcompress %}
> > wasn't working properly was correct. But of course that raises the
> > question why that would fail on one system and work on another. I'll
> > investigate that and then get back to you.
> Found it (RTFM helps). I had set DEBUG = True in
> /etc/mailman3/mailman-web.py. This implicitly sets COMPRESS_ENABLED =
> False, so it was just passing the wrong HTML from the template through
> to the browser.
Perfect, thank you - I can confirm that I see the same errant HTML after
turning off compression in mailman-web.py and restarting the service:
...
I'm lowering the severity by one level because I don't think that this is a
release critical bug for bookworm given that it is a non-default setting, but
please feel free to disagree with me on that.
The patch looks good to me -- and I expect that it should work -- but I haven't
tested it yet to verify that.
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 On Thu, 2 Mar 2023 15:50:22 +, smcv wrote: > When there are patches available for whatever we decide is the right > behaviour, you shouldn't need to walk through the whole install process. Thanks; yep, I think I took an unnecessarily long path through this. I'd been looking for a reason to try the latest Debian installer (and may have learned one or two things about it along the way, but I'll save any of that for separate threads). On Wed, 01 Mar 2023 16:47:22 + James Addison wrote: > 2. select 'anthy' in 'gnome-initial-setup' > 3. attempt Japanese keyboard input Result: ペンギン > 5. select 'mozc-jp' in 'gnome-initial-setup' > 6. attempt Japanese keyboard input Result: ペンギン (in truth: those are not from the d-i alpha 2 sessions I was running; after reading Simon's advice, I used a local user account instead) In both the anthy and mozc cases, the keypresses (chords?) required were fairly similar: 'pe', 'ng', 'gi', 'ng' - with some delete-key and enter-key usage to complete each glyph and/or input entry.
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 X-Debbugs-Cc: ken...@xdump.org On Thu, 02 Mar 2023 22:07:16 +0900 Kentaro Hayashi wrote: > On Wed, 01 Mar 2023 16:47:22 +0000 James Addison wrote: > > My plan is to: > > > > 1. run the graphical d-i install of a fresh GNOME 43 system > > 2. select 'anthy' in 'gnome-initial-setup' > > 3. attempt Japanese keyboard input > Need to do extra setup. > > * sudo apt install -y ibus-anthy > * ibus restart Thank you; I currently have side-by-side graphical installations of d-i alpha 2 running in both English and Japanese, to help my menu navigation, and hope to confirm keyboard input results within the next day or so. The text that I'll attempt to enter is 'ペンギン', that I believe is a translation of 'penguin' (according to libretranslate and Google Translate).
Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error
Package: python3-django-hyperkitty Followup-For: Bug #1031928 X-Debbugs-Cc: h...@hjp.at Control: tags -1 moreinfo Hi Peter, I'd like to gain some experience with configuring email infrastructure, and this bug seems like a good opportunity to learn. I haven't yet been able to reproduce the self-closing HTML script tags; here's roughly the series of install steps I used (I may have omitted one or two details) to get the interface up-and-running: # apt install mailman3-full # vim /etc/mailman3/mailman-web.py # configure REST API creds # ln -s /etc/mailman3/apache.conf /etc/apache2/conf-available/mailman3.conf # a2enconf mailman3 # a2enmod proxy_uwsgi # systemctl restart mailman3-web # systemctl restart apache2 (note that I also had postfix utilities installed on the system) That seemed to work: I was able to browse the postorius web interface and see that I had no mailing lists configured. Checking the HTML source of the page, I did see some tags -- including for 'popper.js' -- each of them had a closing tag, as expected. Could you provide any more information on configuration steps / settings that may be required to reproduce the problem? Thanks! James
Bug#1031909: python3-tk: bytecode not removed on upgrade
Package: python3-tk Followup-For: Bug #1031909 Some notes from inspecting (but not yet testing) the relevant scripts: * There is an open merge request intended to fix a bug when too-many-files are encountered by the lib2to3 'prerm' script: * https://salsa.debian.org/cpython-team/python3-stdlib/-/merge_requests/1 * The python3-distutils and python3-lib2to3 packages have prerm 'upgrade' steps to remove bytecode; python3-tk does not: * https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-distutils.prerm#L27-28 * https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-lib2to3.prerm#L27-28 * https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-tk.prerm#L27 * All three of the previously-mentioned binary packages clear out py3.9-and-older library content during 'postinst' of more recent package versions; a similar step for py3.10 library content could be worth adding * https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-lib2to3.postinst.in#L22-41
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Package: libgnome-desktop-4-2 Followup-For: Bug #1029821 X-Debbugs-Cc: yy.y.ja...@gmail.com I'd like to contribute by testing d-i with Japanese input (I'm not a Japanese speaker, but can offer some time to help). My plan is to: 1. run the graphical d-i install of a fresh GNOME 43 system 2. select 'anthy' in 'gnome-initial-setup' 3. attempt Japanese keyboard input 4. run the graphical d-i install of a fresh GNOME 43 system 5. select 'mozc-jp' in 'gnome-initial-setup' 6. attempt Japanese keyboard input For each path I may need help: how will I verify that Japanese input support is working? (maybe a naive question, but I don't know; I will search the web to find out soon, but any guidance before then would be appreciated) Also: My understanding is that the _only_ difference that the patch will make is that it will change the default in 'gnome-initial-setup'. Users could still choose 'anthy' -- or another input method -- if they want, for some reason. Is that correct?
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
If reproducible: would this bug be a good candidate for upload of a fix to 'experimental' so that it can be alpha-tested by others? On Wed, 1 Mar 2023 at 02:55, Jérémy Lal wrote: > > > > Le mer. 1 mars 2023 à 02:30, Thorsten Glaser a écrit : >> >> Jérémy Lal dixit: >> >> >I can build nodejs on amhdal.debian.org if you're not comfortable with that. >> >> The problem with the DSA porterboxen is that you cannot install your own >> built packages in the chroot to use them there… unless there’s a >> solution not yet known to me? > > > Indeed, but the binary can be run from build dir, so I just need to try and > reproduce the bug from there. >
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
That'd be great, thank you - my local (emulated) aarch64 build of nodejs is proving to be much more time consuming than I expected. On Tue, 28 Feb 2023 at 23:21, Jérémy Lal wrote: > > > > Le mar. 28 févr. 2023 à 19:06, James Addison a écrit : >> >> On Tue, Feb 28, 2023, 17:55 Thorsten Glaser wrote: >>> >>> Can you test it? I don’t have the bandwidth for that right now… >> >> >> Should be able to, yep - I seem to remember seeing some repro instructions >> from you on the GitHub thread and will give those a try in an emulator/vm. > > > I can build nodejs on amhdal.debian.org if you're not comfortable with that. > >> -- >> Pkg-javascript-devel mailing list >> pkg-javascript-de...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
On Tue, Feb 28, 2023, 17:55 Thorsten Glaser wrote: > Can you test it? I don’t have the bandwidth for that right now… Should be able to, yep - I seem to remember seeing some repro instructions from you on the GitHub thread and will give those a try in an emulator/vm.
Bug#1000955: libkf5globalaccel-bin: /usr/bin/kglobalaccel5 eats up huge amount of CPU after suspend
Package: libkf5globalaccel-bin Followup-For: Bug #1000955 X-Debbugs-Cc: lopi...@debian.org Hi Filippo, On Wed, 1 Dec 2021 12:12:44 +0100, Filippo wrote: > Should I install other packages to fix the problem? What can I do to help? Two ideas related to this part of your report: > Note that I also see a huge CPU consumption for the following processes: > > /usr/lib/xorg/Xorg (63%) > /usr/sbin/rsyslogd (14%) > /lib/systemd/systemd-journald (10%) > > Yeah, I know these percentages sum up to > 100 :-( The sum-of-percentages being above one-hundred is likely due to a multi-CPU (or perhaps multiple-core) system - I think that each percentage reported is for a single processor. If the total goes above 100 * x, where x is the number of processors, then we're allowed to become more confused. Let's not do that yet. > /lib/systemd/systemd-journald (10%) Focusing more on this line in particular -- and the fact that kglobalaccel was (and still is, in 5.103.0-1) configured to auto-restart on unhandled error[1], then I think it's possible that the process is failing and being recreated rapidly. Each occurrence of that should be logged in the system journal, and that could cause high CPU usage for that service. All a theory so far, but if you are able to replicate the behaviour (I realize it has been a while since your report) then I would suggest taking a look at the service logs in journalctl to see if there are any clues there, and let us know. Thank you, James [1] - https://sources.debian.org/src/kglobalaccel/5.78.0-3/src/runtime/main.cpp/?hl=92#L79
Bug#1023666: gcc-10 should not be shipped in bookworm
Package: gcc-10 Version: 10.4.0-7 Followup-For: Bug #1023666 Bug #1004184 implies that gcc-11 cannot build correct mips64 code for a key Debian package (source: matplotlib) without buildflag adjustments. However, gcc-10 does emit correct code for the same package and architecture. Should that be considered a blocker for this bug?
Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck
Package: d-i.debian.org Followup-For: Bug #1031923 Control: forcemerge 1031622 -1
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Source: qemu Followup-For: Bug #1030545 Control: block -1 by 1031753
Bug#1028743: python-bottle: FTBFS: AssertionError: b'OK' != "URLError(ConnectionRefusedError(111, 'Connection refused'))"
Source: python-bottle Followup-For: Bug #1028743 Control: forwarded -1 https://github.com/bottlepy/bottle/issues/1410
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 X-Debbugs-Cc: t...@debian.org > My plan is to rebuild / retest reverse deps before hard freeze. That's a good plan. Do you know whether any of those tests include cases that spin up large (as in: may consume more than 50% of a system's memory) numbers of processes/threads? Context: I've begun worrying about the additional overhead from stack preallocation -- where increasing the stack size might significantly reduce the number of processes that fit in memory while running simultaneously. > Thanks, I'll welcome any patch to start with. FWIW: I am still somewhere between 'do nothing' and 'ok, maybe, after seeing more data that it is a safe increase'. I don't trust myself enough to write any logic/syscall-related changes in a patch but may provide one that updates the constant limits in the relevant header file(s). Thorsten: if you'd like an rlimit-based approach then I think that may be upon you to write, or to request from upstream (where I accidentally impersonated you on the GitHub issue, by the way - sorry about that!).
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 X-Debbugs-Cc: t...@debian.org, reply+aagshfqluldiwi3obwdg6lgb7if7fevbnhheauz...@reply.github.com mirabilos gesagt: > We know the default ulimits for users in Debian, and they are higher > than the 1 MiB assumed by v8, by quite some factor, so this won’t break > things which are not currently broken (by that exception). This will do > for the release I think. Relaying my understanding of this, so far: An increase in the V8 stack size should not cause earlier-process-exits for any processes that previously ran on Debian systems where the architecture-default-or-greater stack size is configured[1]. In other words: the same-number-or-greater of JavaScript processes should continue to run on any given Debian system where the configured stack size is greater-than-or-equal to the architecture's default, after the V8 stack size limit is increased. And we expect that it should repair a failing reproducible build test for at least one Debian package on arm64. [1] - see limits.conf
Bug#1029668: Cannot read HEIC anymore
Package: libheif1 Version: 1.14.2-1 Followup-For: Bug #1029668 X-Debbugs-Cc: debian-multime...@lists.debian.org The inability to read HEIC content using applications that depend on libheif1 could be a symptom of a more general codec-loading problem in that package: Version 1.14.0 of upstream libheif1 introduced a plugin-based system[1] (shared modules) for codecs, and I'm not sure that we have opted-in to that and bundled either-statically-or-dynamically-loaded codecs into the binary packages yet. (also note: upstream decided to choose CMake as their single supported build system from 1.14.0; that matches the build system that Debian already uses for the most recent versions of the source package) Although these codec modules are likely only intended for use by libheif1 currently, the Debian Policy Guide section about Static Libraries[2] is helpful to refer to. [1] - https://github.com/strukturag/libheif/tree/v1.14.2#codec-plugins [2] - https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#static-libraries
Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches
Package: fakeroot Followup-For: Bug #1030638 Hi josch, Are you able to confirm whether the repro environment(s) for this bugreport used emulated and/or native (non-emulated) 32-bit systems? To explain my question: a qemu bug[1] that I was reading about a while ago highlights that there are some challenges emulating file-related system calls for a 32-bit guest from a 64-bit host. (in the situation I was looking at, that caused directory listing functions to appear to return empty results, despite directory contents being visible on the host. it may not be relevant here - if repro was found on non-emulated systems then we can ignore this theory) Thanks, James [1] - https://gitlab.com/qemu-project/qemu/-/issues/263
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 Control: forwarded -1 https://github.com/nodejs/node/issues/41163
Bug#1004184: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el
Source: gcc-11 Followup-For: Bug #1004184 X-Debbugs-Cc: frederic-emmanuel.pi...@synchrotron-soleil.fr Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 Hi Frederic: I'm linking a forwarded GCC GNU bug report that I _think_ is the upstream report matching this bug. I found it from a related GitHub issue[1] for matplotlib. The GCC bug reporter has done some work to create a minimal reproducer case. Could you check whether the issue reported there is the same one as here? (I will do eventually, but am not familiar with C and do not have mips hardware available so it may take some time) [1] - https://github.com/matplotlib/matplotlib/issues/21789
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Source: qemu Followup-For: Bug #1030545 Control: tags -1 - help Control: tags -1 + pending
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 On Wed, 15 Feb 2023 14:54:03 +0100, Jérémy wrote: > While waiting for the proper fix you describe, I propose to set higher > constants > for V8_DEFAULT_STACK_SIZE_KB - especially for arm64. That sounded good to me when I read it a week ago, but now I'm not so sure. It seems that the Node ecosystem has known unusual architecture-specific behaviours here that derive from a lower-level element (V8) in the stack. Is it wise for us to add another layer of configuration settings that are Debian-specific and will require future users/developers yet more time to unpick and understand? Especially when the configuration may -- if set too high -- introduce as many failures as it solves? (how could we tell?) Maybe it's rare to propose 'do nothing' as a technical suggestion but I think it is worth considering here, since we are not the arbiters of Node.
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 On Fri, 24 Feb 2023 12:08:03 +0100, Jochen wrote: > Fair point, attached is an alternative patch that works with the current > doc package version. I can confirm that the package builds successfully with this patch applied as an alternative. The logo in the resulting manual.pdf appears visually identical between this patch and the previous approach. In addition: the document's index (on page 43) seems more visually neat and concise to me with the updated v3 LaTeX base doc.sty file, so I would vote for the '0001-Set-nohyperref-to-fix-FTBFS.patch' patch (from the two options) on that basis. On Fri, 24 Feb 2023 00:12:39 +0100, Hilmar wrote: > This seems to be just a temporary solution, as the TL upstream people, > will stop providing the old doc.sty at any time in the future. True - it seems better to continue to use the upstream-maintained base doc.sty file if possible. If we opt with a forwards-compatible patch, perhaps we can also offer it to the upstream author?
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 Control: tags -1 - help
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 Control: tags -1 patch
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
On Thu, 23 Feb 2023 at 12:53, James Addison wrote: > > pass: texlive-base (2022.20220605-1) unstable; urgency=low > fail: texlive-base (2022.20220923-2) unstable; urgency=medium > > It should be possible to look at the differences between those (and > maybe the related packages such as texlive-latex-base) to find further > clues. I'm going to start on that fairly soon. Ok, it turns out that the problem was a compatibility-break between v2 and v3 of the base doc.sty file. Fortunately the texlive-latex-base package ships the previous (v2, feynmf-compatible) version of that file along with v3. Thanks, Jochen for providing a patch to resolve the bug. I'm able to successfully build manual.pdf using texlive-latex-base 2022.20230122-1 with that patch applied.
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 My current best guess is that this commit line in latex3 that added a dependency on 'hypdoc' to the 'latex/base/doc.sty' file could be the cause - note that GitHub may not expand the 'doc.sty' file by default in some web browsers due to their filtering of large diffs from the user in some cases: https://github.com/latex3/latex3/commit/015a0593721446d2f5ddfa8d2f5d7c44e9d00fe5#diff-7c335dcde21c7d07e25db3dd241750d7907f90e7ca9b59d4a97309b028e30275R982 I'm not sure why that would be backwards-incompatible with 'feynmf.dtx' though.
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
On Wed, 22 Feb 2023 at 22:51, Hilmar Preuße wrote: > > On 2/21/23 22:00, James Addison wrote: > Sorry, I'm not of any help here. At the first glance we look at a syntax > error in the feynmf.dtx file however I'm wondering why this did not pop > within the last > 25 years. That's OK - taking a look is already a help. With some assistance from the snapshot.debian.org archives, it seems that these errors began appearing fairly recently: pass: texlive-base (2022.20220605-1) unstable; urgency=low fail: texlive-base (2022.20220923-2) unstable; urgency=medium It should be possible to look at the differences between those (and maybe the related packages such as texlive-latex-base) to find further clues. I'm going to start on that fairly soon.
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
Package: python3-dateutil Followup-For: Bug #1003044 X-Debbugs-Cc: michael.pfu...@sartorius.com Control: retitle -1 internal 'getzoneinfofile_stream' method emits a warning message Control: forwarded -1 https://github.com/dateutil/dateutil/issues/903 Control: tags -1 moreinfo On Tue, 21 Feb 2023 22:27:53 +0100, Felix wrote: > I'm inclined to just ship the bundled timezone database with the package: 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. If the licensing status of the database in the upstream source has become dfsg-compatible, then my mistake and perhaps we can go ahead and bundle it. But that is not clear to me at the moment. On Sun, 29 Jan 2023 15:41:10 +0100, Felix wrote: >> How exactly does this break matplotlib? On Tue, 21 Feb 2023 14:46:01 -0500, morph wrote: > it produces output on stderr, which many tools consider it an error > and fails build. Michael or morph: can you provide a link or supporting details to justify the severity of this bug (currently: grave[1])? [1] - https://www.debian.org/Bugs/Developer#severities
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 X-Debbugs-Cc: debian-tex-ma...@lists.debian.org Control: tags -1 help I'm adding the 'help' tag to this bug, and am cc'ing the debian-tex-maint list, because it feels like extra brainpower could aid in figuring this one out more quickly. A brief recap of this bug so far, for folks reading the list: * the feynmf Debian package is failing to build in testing (bookworm) * the bug may somehow be related to the mflogo TeX package * successful build logs are available on buildd.debian.org for comparison
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 Assuming that we want to keep the feynmf sources as-is (I think we do; feynmf.dtx hasn't changed[1] since 1996, a sign of stability), then this bug seems like a regression in another component. Looking at the build logs for a failure-to-build[2] in this thread and a previous successful build[3], it looks like there's some divergence after this common line of output: Writing index file fmfmanps.idx And, reading a few lines below that in what I'm guessing is a LaTeX call stack (a series of package names, one-per-line), the common element that both call stacks originate from is 'l3backend-dvips.def', part of the latex3[4] codebase. My guess would be that something in latex3 has changed over the course of the past year or two that has introduced this problem as a side-effect. The 'l3backend-dvips.def' file is currently part of the 'texlive-latex-base' Debian package. [1] - https://www.ctan.org/tex-archive/macros/latex/contrib/feynmf [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029439#5 [3] - https://buildd.debian.org/status/fetch.php?pkg=feynmf=all=1.08-13=1636243992=0 [4] - https://github.com/latex3/latex3/
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
Package: python3-dateutil Followup-For: Bug #1003044 Control: tags -1 moreinfo On Tue, 21 Feb 2023 00:35:16 +, James Addison wrote: > The repro step attempted was to open a Python interpreter session and to > enter: > from matplotlib.dates import DateFormatter > > (that succeeded and did not emit any output) OK: that wasn't a hugely useful comment; a more thorough date formatting example would have been more convincing. ...the 'date_index_formatter.py'[1] example code included in the 'matplotlib' source is a better candidate: and it also completes successfully without errors when run using version 2.8.2-1 of the python3-dateutil package. Given that python3-dateutil is depended-upon by a reasonably large number of other packages, I'm reluctant to reduce the severity of this bug, but at the same time, it's unclear what the extent of the breakage is here. [1] - https://sources.debian.org/src/matplotlib/3.6.3-1/examples/ticks/date_index_formatter.py/
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
Package: python3-dateutil Followup-For: Bug #1003044 I'm unable to replicate a matplotlib failure so far when using: * python3-dateutil 2.8.2-1 * python3-matplotlib 3.6.3-1+b1 The repro step attempted was to open a Python interpreter session and to enter: from matplotlib.dates import DateFormatter (that succeeded and did not emit any output)
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
Source: feynmf Followup-For: Bug #1029439 Hi Thorsten, I'm not completely sure yet (my TeX-foo isn't that great), but I have narrowed the cause of the problem down. It looks like the problem is something to do with the '\textlogo' command that is used when the 'mflogo.sty' TeX package is available. It is referenced once in the 'feynmf.dtx' file, and this appears to be what leads to the build failure. If that clue is useful for you or someone else, please feel free to use that to develop a fix. I'm continuing to investigate. Thanks, James
Bug#1029342: jexec: can't locate java: No such file or directory
Package: openjdk-17-jre-headless Followup-For: Bug #1029342 Looking at codesearch[1] for the word 'jexec', most of the contexts that appear are from one of a few categories: * The code of OpenJDK itself * Scripts/code intended to run in FreeBSD environments (where 'jexec' is used to run a command within a jail) * The 'XB-Cnf-Extra-Commands' control file header in java-common (listing missing commands that will hint the user to install the package) Perhaps we could safely remove 'jexec' from the Debian-distributed OpenJDK? [1] - https://codesearch.debian.net/search?q=%5Cbjexec%5Cb=0=1
Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
Package: python3-zstandard Followup-For: Bug #1031443 Control: forcemerge -1 1031293 1031449
Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
Package: python3-zstandard Followup-For: Bug #1031443 Control: affects -1 = src:python-scrapy src:libzstd src:rpmlint src:python-zstandard Control: merge -1 1031293
Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
Package: python3-zstandard Followup-For: Bug #1031443 Control: affects -1 - src:rpmlint Control: affects -1 + src:rpmlint Control: merge -1 1031293
Bug#1031449: python-scrapy: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10502 hardcoded in zstd
Package: python3-zstandard Followup-For: Bug #1031449 Control: affects -1 - src:rpmlint src:python-zstandard src:python-scrapy Control: affects -1 + src:rpmlint src:python-scrapy src:python-zstandard Control: merge -1 1031293
Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
Package: python3-zstandard Followup-For: Bug #1031443 Control: affects -1 - src:python-scrapy src:rpmlint Control: affects -1 + src:python-scrapy src:rpmlint Control: merge -1 1031293
Bug#1031449: python-scrapy: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10502 hardcoded in zstd
Source: python-scrapy Followup-For: Bug #1031449 Control: reassign -1 python3-zstandard 0.19.0-3 Control: affects -1 + src:libzstd src:python-scrapy src:python-zstandard src:rpmlint Control: merge -1 1031293
