Bug#1058072: linux-image-6.5.0-0.deb12.1-amd64: Backport 6.5 kernel for bookworm is very good
Hi, On Mon, Dec 11, 2023 at 07:58:54PM -0500, debian user wrote: > Package: src:linux > Version: 6.5.3-1~bpo12+1 > Severity: wishlist > Tags: upstream > > Dear Maintainer, > > $ uptime > 19:56:14 up 27 days, 8:01, 3 users, load average: 0.69, 0.49, 0.45 > > $ apt policy linux-image-6.5.0-0.deb12.1-amd64 > linux-image-6.5.0-0.deb12.1-amd64: > Installed: 6.5.3-1~bpo12+1 > Candidate: 6.5.3-1~bpo12+1 > Version table: > *** 6.5.3-1~bpo12+1 100 > 100 /var/lib/dpkg/status > > I wish you the the best. I wish you all the best. As I understand there is no specific issue, thanks for reporting back it works well for you! Regards, Salvatore
Bug#1058577: scour: mark packages as "multi-arch: foreign"
Package: scour Version: 0.38.2-3 Severity: normal 'scour' is often used for packaging purposes (it even provides 'dh-sequence-scour' for the convenience of packagers). However, since 'scour' is not marked "Multi-Arch: foreign" (or "Multi-Arch: allowed") which makes it somewhat awkward to use when cross-building packages (that depend on 'scour'). I would therefore like to ask, whether you could mark the package as being usable for cross-building by setting the "Multi-Arch" field as appropriate. thanks for your consideration. gmdsar IOhannes
Bug#1058577: scour: mark packages as "multi-arch: foreign"
Control: tag -1 pending Hello IOhannes, IOhannes m zmoelnig [2023-12-13 8:57 +0100]: > However, since 'scour' is not marked "Multi-Arch: foreign" (or "Multi-Arch: > allowed") which makes it somewhat awkward to use when cross-building packages > (that depend on 'scour'). > > I would therefore like to ask, whether you could mark the package as being > usable for cross-building by setting the "Multi-Arch" field as appropriate. Good idea! That is indeed missing, I added it. Thanks, Martin
Bug#1001132: kdenlive: Unable to Start with Use GPU processing (Movit libary) enabled
Hello @JB
Am 13.12.2023 um 01:57 schrieb Bob Wong:
kf.kio.core: Malformed JSON protocol file for protocol: "trash" , number
of the ExtraNames fields should match the number of ExtraTypes fields
kf.kio.core: Malformed JSON protocol file for protocol: "trash" , number
of the ExtraNames fields should match the number of ExtraTypes fields
[New Thread 0x7fff3fcf16c0 (LWP 6090)]
=== /// CANNOT ACCESS SPEECH DICTIONARIES FOLDER
[New Thread 0x7fff3dfff6c0 (LWP 6091)]
[New Thread 0x7fff2ebff6c0 (LWP 6092)]
QQmlEngine::setContextForObject(): Object already has a QQmlContext
[New Thread 0x7fff2ddfe6c0 (LWP 6093)]
[New Thread 0x7fff2d5fd6c0 (LWP 6094)]
Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed
QQmlEngine::setContextForObject(): Object already has a QQmlContext
[New Thread 0x7fff1ff366c0 (LWP 6095)]
[New Thread 0x7fff1f7356c0 (LWP 6096)]
QQmlEngine::setContextForObject(): Object already has a QQmlContext
QQmlEngine::setContextForObject(): Object already has a QQmlContext
[New Thread 0x7fff1cfff6c0 (LWP 6097)]
[New Thread 0x7fff0ebff6c0 (LWP 6098)]
[New Thread 0x7fff0e3fe6c0 (LWP 6099)]
[New Thread 0x7fff0dbfd6c0 (LWP 6100)]
[New Thread 0x7fff0d3fc6c0 (LWP 6101)]
[New Thread 0x7fff0cbfb6c0 (LWP 6102)]
[New Thread 0x7ffef7fff6c0 (LWP 6103)]
[New Thread 0x7ffef77fe6c0 (LWP 6104)]
[New Thread 0x7ffef6ffd6c0 (LWP 6105)]
[New Thread 0x7ffef67fc6c0 (LWP 6106)]
[New Thread 0x7ffef5ffb6c0 (LWP 6107)]
[New Thread 0x7ffef57fa6c0 (LWP 6108)]
[New Thread 0x7ffef4ff96c0 (LWP 6109)]
[New Thread 0x7ffed7fff6c0 (LWP 6110)]
[New Thread 0x7ffed77fe6c0 (LWP 6111)]
[New Thread 0x7ffed6ffd6c0 (LWP 6112)]
[New Thread 0x7ffed67fc6c0 (LWP 6113)]
[New Thread 0x7ffed5ffb6c0 (LWP 6114)]
[New Thread 0x7ffed57fa6c0 (LWP 6115)]
[New Thread 0x7ffed4ff96c0 (LWP 6116)]
[New Thread 0x7ffeb7fff6c0 (LWP 6117)]
[New Thread 0x7ffeb77fe6c0 (LWP 6118)]
[New Thread 0x7ffeb6ffd6c0 (LWP 6119)]
[New Thread 0x7ffeb67fc6c0 (LWP 6120)]
[New Thread 0x7ffeb5ffb6c0 (LWP 6121)]
[New Thread 0x7ffeb57fa6c0 (LWP 6122)]
[New Thread 0x7ffeb4ff96c0 (LWP 6123)]
[New Thread 0x7ffe97fff6c0 (LWP 6124)]
[New Thread 0x7ffe977fe6c0 (LWP 6125)]
[New Thread 0x7ffe96ffd6c0 (LWP 6126)]
[New Thread 0x7ffe967fc6c0 (LWP 6127)]
[New Thread 0x7ffe95ffb6c0 (LWP 6128)]
[New Thread 0x7ffe957fa6c0 (LWP 6129)]
[New Thread 0x7ffe94ff96c0 (LWP 6130)]
[New Thread 0x7ffe77fff6c0 (LWP 6131)]
[New Thread 0x7ffe777fe6c0 (LWP 6132)]
[New Thread 0x7ffe76ffd6c0 (LWP 6133)]
[New Thread 0x7ffe767fc6c0 (LWP 6134)]
[New Thread 0x7ffe75ffb6c0 (LWP 6135)]
[New Thread 0x7ffe757fa6c0 (LWP 6136)]
[New Thread 0x7ffe74ff96c0 (LWP 6137)]
NOT FOUND DOCUMENT GUIDES !!!
!
[New Thread 0x7ffe57fff6c0 (LWP 6138)]
QQmlEngine::setContextForObject(): Object already has a QQmlContext
qrc:/qml/timeline.qml:502: ReferenceError: proxy is not defined
qrc:/qml/timeline.qml:482: ReferenceError: proxy is not defined
[New Thread 0x7ffe577fe6c0 (LWP 6139)]
[New Thread 0x7ffe56ffd6c0 (LWP 6140)]
[New Thread 0x7ffe567fc6c0 (LWP 6141)]
[New Thread 0x7ffe55ffb6c0 (LWP 6142)]
NO PREVIOUS TIMELINE
::: connecting timeline:
QUuid("{4bc97da3-95d1-4f61-a39c-ae3ac1c1ad9b}") , DUR: 0
[New Thread 0x7fff1e39f6c0 (LWP 6143)]
[New Thread 0x7ffe557fa6c0 (LWP 6144)]
root context get sub model new function
[New Thread 0x7ffe54ff96c0 (LWP 6145)]
[New Thread 0x7ffe33fff6c0 (LWP 6146)]
[New Thread 0x7ffe337fe6c0 (LWP 6147)]
[New Thread 0x7ffe32ffd6c0 (LWP 6148)]
[New Thread 0x7ffe327fc6c0 (LWP 6149)]
INVALID BIN PLAYLIST...
=== OPENING FILE WITH TRACKS: 5
[New Thread 0x7ffe31ffb6c0 (LWP 6150)]
QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x5c0a70c0
Could you have a look here? I think this eglError is the relevant part.
Full information could be found here: https://bugs.debian.org/1001132
@Bob:
Please also report your issue here and mail me the bugid after that:
https://kdenlive.org/en/bug-reports/
Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...
* Santiago Vila [2023-12-12 20:25]: I'm sorry to see this package removed because of this bug which I filed. Actually, the main reason for requesting the removal is the fact that the package is unusable without the VIBES viewer. Note that if the latter is packaged for Debian, then the octave-vibes package can be resurrected. I trust that removing the package was the right thing to do, but I just read the removal request you did to ftpmasters (#1058025) and would like to make a minor comment which is only indirectly related: This is caused by the fact that the VIBES API uses the file $HOME/.vibes.json to communicate with the VIBES server. Since the Debian autobuilders set HOME="/nonexistent/" [3], then the unit tests for octave-vibes fail. There is actually a debhelper feature for cases like this one. This is from debhelper(7): HOME, XDG_* In compat 13 and later, these environment variables are reset before invoking the upstream build system via the dh_auto_* helpers. The variables HOME (all dh_auto_* helpers) and XDG_RUNTIME_DIR (dh_auto_test only) will be set to a writable directory. All remaining variables and XDG_RUNTIME_DIR (except for during dh_auto_test) will be cleared. The HOME directory will be created as an empty directory but it will be reused between calls to dh_auto_*. Any content will persist until explicitly deleted or dh_clean. i.e. you may rely on a writable $HOME if it's for a "good cause" (i.e. dh_auto_test). So, the simple question: Should this not be also implemented in dh_octave_check as well, which is what octave-vibes was using? Thanks for bringing this to my knowledge. However, I do not quite understand the text above. Does it mean that, when the package Build-Depends on debhelper-compat = 13, then $HOME will be set automatically to a writable directory? Well, octave-vibes that compatibility level of debhelper, but the autobuilders set HOME=/nonexistent/. Also, while we are at it, the Policy paragraph that you quoted: The Debian autobuilders set HOME to /nonexistent so that packages which try to write to a home directory will fail to build. would probably need to be reworded a little bit. I agree. I think that a bug report should be filed against debian-policy on this issue. Best, Rafael Laboissière
Bug#1057957: ITP: rust-numbat -- staticially typed programmin language for scientific computations
Control: retitle -1 ITP: rust-numbat -- statically typed programming language for scientific computations Hi, I'm happy to package numbat. Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Bug#1057589: Reassign Bug#1057589 and merge it with #1057590
reassign 1057589 src:octave-netcdf merge 1057589 1057590 stop
Bug#959964: What about moving bitshuffle into debian-science
Would you mind to migrate bitshuffle under the Debian-science umbrella. this way I could fix the package (cython3, h5py, ...) issues and and upload the latest version. thanks for considering. Frederic
Bug#1058578: pnetcdf: add build support for loongarch64
Source: pnetcdf
Version: 1.12.3-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
The pnetcdf source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control.
Please consider the patch I have attached.
The pnetcdf source package was compiled successfully on my local loong64
rootfs environment.
If you have any questions, you can contact me at any time.
thanks,
Dandan Zhang
diff -Nru pnetcdf-1.12.3/debian/control pnetcdf-1.12.3/debian/control
--- pnetcdf-1.12.3/debian/control 2023-06-20 07:34:17.0 +
+++ pnetcdf-1.12.3/debian/control 2023-06-20 07:34:17.0 +
@@ -17,7 +17,7 @@
Package: libpnetcdf-dev
Section: libdevel
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
+Architecture: amd64 arm64 loong64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
Multi-Arch: same
Depends: ${misc:Depends}, ${shlib:Depends}, libpnetcdf0d (= ${binary:Version} )
Description: Development files for the parallel netCDF library
@@ -36,7 +36,7 @@
Package: pnetcdf-bin
Depends: ${shlibs:Depends},
${misc:Depends}
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
+Architecture: amd64 arm64 loong64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
Description: Programs for reading and writing parallel NetCDF files
Contains tools for working on netCDF files in parallel.
.
@@ -50,7 +50,7 @@
Package: libpnetcdf0d
Section: libs
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
+Architecture: amd64 arm64 loong64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
Multi-Arch: same
Depends: ${shlibs:Depends},
${misc:Depends}
Bug#1058579: apt: gives misleading error when not finding Packages.xz in Release (not InRelease)
Package: apt Version: 2.6.1 # context The repo is served as a "generic package repo" on gitlab. As a first step I'm putting unsigned Release file there, because setting sigs there is another adventure. So I have Release not InRelease, and since it's 2 packages I chose to spare space using just a Package.gz, hoping for maximum compatibility (apparently mistakenly so). # observations When updating, apt acknowledges it got Release not InRelease, but its error message seems to imply it checked *InRelease* to find a *Packages* file: root@debian:~# apt update Hit:1 http://deb.debian.org/debian bookworm InRelease Hit:2 http://security.debian.org/debian-security bookworm-security InRelease Ign:3 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ InRelease Hit:4 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ Release Ign:5 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ Release.gpg Reading package lists... Done Building dependency tree... Done Reading state information... Done 77 packages can be upgraded. Run 'apt list --upgradable' to see them. W: Skipping acquire of configured file 'Packages' as repository 'https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ InRelease' does not seem to provide it (sources.list entry misspelt?) Using "-oDebug::pkgAcquire::Worker=1 -o Debug::Acquire::https=1" indeed shows no attempt at downloading anything after Release.gpg # my interpretation There are 3 misleading items in the same statement: * it likely did not check *InRelease* contents but really *Release* * OK it did not find *Packages* but only after looking for *Packages.xz*, and since adding *Packages* back does work, it does not really push users to use the default compression format. * the "sources.list entry misspelt?" suggestion feels to throw the user completely off-track: as it did find a Release file, the entry surely *does* point to a repo
Bug#1057981: bioxtasraw: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:15:47AM +, Matthias Klose wrote: > Package: src:bioxtasraw > Version: 2.2.1-1 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1057995: obitools: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:01AM +, Matthias Klose wrote: > Package: src:obitools > Version: 1.2.13+dfsg-6 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058000: primecountpy: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:05AM +, Matthias Klose wrote: > Package: src:primecountpy > Version: 0.1.0-2 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058001: python-feather-format: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:08AM +, Matthias Klose wrote: > Package: src:python-feather-format > Version: 0.3.1+dfsg1-6 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058006: python-pcl: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:11AM +, Matthias Klose wrote: > Package: src:python-pcl > Version: 0.3.0~rc1+dfsg-14 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058004: python-thinc: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:12AM +, Matthias Klose wrote: > Package: src:python-thinc > Version: 8.1.7-1 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058580: flint: autopkgtest regression
Source: flint Version: 3.0.1-1 Severity: serious https://tracker.debian.org/pkg/flint Migration status for flint (2.9.0-5 to 3.0.1-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ autopkgtest for flint/3.0.1-1: amd64: Regression or new test ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻), armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ (reference ♻), s390x: Regression or new test ♻ (reference ♻) ... 68s autopkgtest [23:16:09]: test command1: gcc debian/tests/matrix-bernoulli.c -o "$AUTOPKGTEST_TMP"/matrix-bernoulli -lflint && "$AUTOPKGTEST_TMP"/matrix-bernoulli 68s autopkgtest [23:16:09]: test command1: [--- 68s debian/tests/matrix-bernoulli.c: In function ‘main’: 68s debian/tests/matrix-bernoulli.c:35:25: warning: implicit declaration of function ‘fmpz_bin_uiui’; did you mean ‘mpz_bin_uiui’? [-Wimplicit-function-declaration] 68s35 | fmpz_bin_uiui(num, row + 2, row - col + 1); 68s | ^ 68s | mpz_bin_uiui 68s In file included from debian/tests/matrix-bernoulli.c:3: 68s debian/tests/matrix-bernoulli.c:61:24: warning: implicit declaration of function ‘fmpq_equal’; did you mean ‘mpq_equal’? [-Wimplicit-function-declaration] 68s61 | assert(fmpq_equal(&exactbern, fmpq_mat_entry(bernoullis, i, 0))); 68s |^~ 69s autopkgtest [23:16:10]: test command1: ---] 69s command1 FAIL stderr: debian/tests/matrix-bernoulli.c: In function ‘main’: 69s autopkgtest [23:16:10]: test command1: - - - - - - - - - - results - - - - - - - - - - 69s autopkgtest [23:16:10]: test command1: - - - - - - - - - - stderr - - - - - - - - - - 69s debian/tests/matrix-bernoulli.c: In function ‘main’: 69s debian/tests/matrix-bernoulli.c:35:25: warning: implicit declaration of function ‘fmpz_bin_uiui’; did you mean ‘mpz_bin_uiui’? [-Wimplicit-function-declaration] 69s35 | fmpz_bin_uiui(num, row + 2, row - col + 1); 69s | ^ 69s | mpz_bin_uiui 69s In file included from debian/tests/matrix-bernoulli.c:3: 69s debian/tests/matrix-bernoulli.c:61:24: warning: implicit declaration of function ‘fmpq_equal’; did you mean ‘mpq_equal’? [-Wimplicit-function-declaration] 69s61 | assert(fmpq_equal(&exactbern, fmpq_mat_entry(bernoullis, i, 0))); 69s |^~ 69s autopkgtest [23:16:10]: summary 69s command1 FAIL stderr: debian/tests/matrix-bernoulli.c: In function ‘main’:
Bug#1058010: tombo: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:17AM +, Matthias Klose wrote: > Package: src:tombo > Version: 1.5.1-5 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058015: unifrac: runtime dependency on cython
On Mon, Dec 11, 2023 at 08:16:22AM +, Matthias Klose wrote: > Package: src:unifrac > Version: 1.3-1 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: cython-rt-dep > > [This bug is targeted to the upcoming trixie release] > > The package build-depends on cython3 or cython3-legacy, and one of the > built binary packages also depends on cython3 or cython3-legacy. That > might be correct, but in most cases there is no runtime dependency for > a tool like cython, that is only used when building the package. > > Please check that this dependency can be removed. Most likely this > dependency is generated by pybuild, because the setup.py requires > Cython in it's 'install_requires' attribute. Please remove that, > after checking that it is not a runtime dependency, and also report > that issue upstream for upcoming releases. > > If the runtime dependency is necessary, please just close this bug > report. In addition, the runtime depends on cython3-legacy, which conflicts with cython3. So this package will not be co-installable with either cython3 or packages which have a necessary run-time dependency on cython3. If the runtime dependency is necessary, please change it to cython3 rather than cython3-legacy. Julian
Bug#1058581: rust-rusqlite: autopkgtest regression on architectures where char is unsigned
Source: rust-rusqlite
Version: 0.29.0-2
Severity: serious
https://tracker.debian.org/pkg/rust-rusqlite
Issues preventing migration:
∙ ∙ autopkgtest for rust-rusqlite/0.29.0-2: amd64: Pass, arm64: Regression or
new test ♻ (reference ♻), armel: Regression or new test ♻ (reference ♻), armhf:
Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Reference test in
progress, but real test failed already, s390x: Regression or new test ♻
(reference ♻)
...
146s error[E0308]: mismatched types
146s --> src/lib.rs:1782:44
146s |
146s 1782 | let r = unsafe { ffi::sqlite3_open(":memory:\0".as_ptr() as
*const i8, &mut handle) };
146s | -
^^ expected `*const u8`, found `*const i8`
146s | |
146s | arguments to this function are incorrect
146s |
146s = note: expected raw pointer `*const u8`
146s found raw pointer `*const i8`
146s note: function defined here
146s -->
/tmp/tmp.3mduH0HVbW/target/aarch64-unknown-linux-gnu/debug/build/libsqlite3-sys-aef3de5783c0ae0e/out/bindgen.rs:3:39519
146s |
146s 3| ...* mut :: std :: os :: raw :: c_void) ; } extern "C" { pub fn
sqlite3_open (filename : * const :: std :: os :: raw :: c_char , ppDb : *...
146s |
146s
146s For more information about this error, try `rustc --explain E0308`.
146s error: could not compile `rusqlite` due to previous error
Bug#1058477: poliastro: please (temporarily) drop python3-numba dependencies
Control: tags -1 wontfix I am afraid that python3-numba is really a hard dependency of poliastro: The line from numba import njit as jit can be found in many source files of poliastro, and the package is completely unusable without numba. Having all individual imports patched out is not maintainable on the long run. So, unless there is a general solution of having a "fake" numba (at least supporting njit and prange), I don't see a way to remove the hard dependency.
Bug#1058513: [Pkg-javascript-devel] Bug#1058513: node-signal-exit: FTBFS: SyntaxError: Cannot use import statement outside a module
Control: tags -1 + moreinfo On 12/13/23 00:52, Lucas Nussbaum wrote: Source: node-signal-exit Version: 4.1.0-6 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20231212 ftbfs-trixie Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[1]: Entering directory '/<>' tsc -p tsconfig.json tsc -p tsconfig-esm.json sh ./scripts/fixup.sh #cp debian/index.cjs dist/cjs/ make[1]: Leaving directory '/<>' dh_auto_test --buildsystem=nodejs ln -s ../. node_modules/signal-exit /bin/sh -ex debian/tests/pkg-js/test + tap -T -R spec test/all-integration-test.ts test/signal-exit-test.ts /<>/test/all-integration-test.ts:1 import assert from 'assert' ^^ Hi, I'm unable to reproduce this issue.
Bug#1058465: ipmitool package is missing enterprise-numbers.txt
Hello, the enterprise-numbers.txt file is not part of the ipmitool sources. You have to download the file manually (see man - page). Since version 1.8.19-5 the file is included in the Debian package, but may be outdated. So I close this bug. Am Dienstag, dem 12.12.2023 um 14:30 +0100 schrieb BW: > Package: ipmitool > Version: 1.8.19-4 > > Many ipmi command doesn't work because the file "/usr/share/misc/enterprise- > numbers.txt" is missing. > > If I manually grab the file from the sid package, where it exist, and place it > in "/usr/share/misc/" on my box, where package 1.8.19-4 is installed, > everything works fine :-) > > > CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1055694: klibc-utils: Patch to fix cp warning
Hi, There is a Merge Request on Salsa to fix this here (didn't test it yet): https://salsa.debian.org/kernel-team/klibc/-/merge_requests/12 Also, here is the corresponding Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/2046336 Cheers Skia
Bug#1058394: augur: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Control: reassign -1 src:pyfastx 2.0.2-1 Control: affects -1 src:augur > > /usr/lib/python3.12/importlib/__init__.py:90: in import_module > > return _bootstrap._gcd_import(name[level:], package, level) > > tests/test_align.py:16: in > > from augur import align > > augur/__init__.py:15: in > > from .io.print import print_err > > augur/io/__init__.py:6: in > > from .metadata import read_metadata # noqa: F401 > > augur/io/metadata.py:5: in > > import pyfastx > > E ModuleNotFoundError: No module named 'pyfastx' These test failures stem from pyfastx lacking Python 3.12 due to missing cython shared objects rebuild for that python3 version. I'm checking whether other packages are affected. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/5, please excuse my verbosity `-on air: Arch/Matheos - Neurotically Wired signature.asc Description: PGP signature
Bug#1053729: RFP: SAIL image decoding library
Hi Andrius, On Wed, Oct 18, 2023 at 08:38:52AM +0300, Andrius Merkys wrote: > Hi Dmitry, > > On 2023-10-17 16:25, Dmitry Baryshev wrote: > > > Does it produce desired Debian packages? > > > > I've just pushed a couple of fixes to the Debian rules. I'm able to > > build packages on LUbuntu 23.04. Maybe a couple of small fixes are still > > needed to build packages on Debian. So the recommended git sha to use is > > 4705cb4cf96. It's a release candidate and ready to use in client > > applications. > > > OK, makes sense. > > Since this is an image decoding library, my personal opinion is that it > would better fit the scope of Debian Multimedia Team instead of Debian > Science Team. Just wanted to check if you are planning to package this. Its still a RFP so I guess not, but still want to confirm. If you are not packaging this then I can take it up. -- Regards Sudip
Bug#1058579: Acknowledgement (apt: gives misleading error when not finding Packages.xz in Release (not InRelease))
I note after double-checking that, despite bookworm repos [1] providing only Packages.xz and Packages.gz and not Packages, apt does really seem to check only for Packages in my case: root@debian:~# apt update Hit:1 http://security.debian.org/debian-security bookworm-security InRelease Hit:2 http://deb.debian.org/debian bookworm InRelease Ign:3 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ InRelease Hit:4 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ Release Ign:5 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ Release.gpg Reading package lists... Done Building dependency tree... Done Reading state information... Done 77 packages can be upgraded. Run 'apt list --upgradable' to see them. W: Skipping acquire of configured file 'Packages' as repository 'https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ InRelease' does not seem to provide it (sources.list entry misspelt?) root@debian:~# curl https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/ci/Release Date: Wed, 13 Dec 2023 09:55:54 + Description: xen-guest-agent CI packages Label: xen-guest-agent-ci Suite: ci MD5Sum: 4bbd32da77623285b8a54ef926a1f028 277 Contents-amd64.gz 9c8c7743a78d4c850fbdffac54c5e159 340 Contents-amd64.xz 557f3042ec38f51a838d518739ecf4c2 925 Packages.gz a3b82abf0ab81c4d5f829ec631c9deb8 1008 Packages.xz SHA1: [1] http://ftp.debian.org/debian/dists/bookworm/main/binary-all/
Bug#1053729: RFP: SAIL image decoding library
Hi Sudip, On 2023-12-13 12:28, Sudip Mukherjee wrote: Hi Andrius, On Wed, Oct 18, 2023 at 08:38:52AM +0300, Andrius Merkys wrote: Hi Dmitry, On 2023-10-17 16:25, Dmitry Baryshev wrote: > Does it produce desired Debian packages? I've just pushed a couple of fixes to the Debian rules. I'm able to build packages on LUbuntu 23.04. Maybe a couple of small fixes are still needed to build packages on Debian. So the recommended git sha to use is 4705cb4cf96. It's a release candidate and ready to use in client applications. OK, makes sense. Since this is an image decoding library, my personal opinion is that it would better fit the scope of Debian Multimedia Team instead of Debian Science Team. Just wanted to check if you are planning to package this. Its still a RFP so I guess not, but still want to confirm. If you are not packaging this then I can take it up. No, I am not planning to work on packaging SAIL anytime soon, so please go ahead. Thanks, Andrius
Bug#1057711: ipmitool: IPMI Sensors False Positives on Failed Components
Hello Chris, thank you for your efforts in creating the bug report. You are making Debian better. Since I do not have access to the hardware described, open a bug report on the upstream. Please note the new homepage https://codeberg.org/IPMITool/ipmitool. Am Donnerstag, dem 07.12.2023 um 13:41 +0100 schrieb Christoph Auer: > Package: ipmitool > Version: 1.8.19-4 > Severity: normal > X-Debbugs-Cc: a...@nemonix.at > > Dear Maintainer, > > the command sdr will output false positives for failed Sensors. > This is repeatable by disconnecting fans or PSU from the motherboard during > operation to simulate failures. > Turning off power to a PSU does not recreate the issue. > Removing the PSU entirely during operation is necessary. > Tested on Supermicro H13SSW. > > The Output will read: > FAN1 | 0 RPM | ok > PS1 Status| 0x00 | ok > While both components have been removed from the system the status should not > be 'ok' > Expected Status 'Critical' instead. > These false positives are highly misleading. > > BR > Auer > > [...] Many thanks CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi, as you might have noticed the upstream source for r-bioc-dss and r-bioc-demixt are missing and upstream did not answered two mails about this. Since the transition looks clean for me so far[1] after I fixed two autopkgtest issues yesterday I (naively) think we could remove r-bioc-dss and r-bioc-demixt from testing and all other packages can migrate to finish the transition from r-bioc perspective. I'm wondering what I can do in some cases that are caused by the pandoc issue like shortread[2] which should be solved in principle. I'm worried about issues in r-rcan-rmarkdown[3] and r-cran-flextable[4] which are caused by pandoc errors on ppc64el architecture *only*. That's really strange and might mean that pandoc on this architecture is broken? Regarding pandoc I've just uploaded a fix for pypandoc (fixing bugs #1057946 and #1058153) I have neither any clue nor any time to check nbconvert. Kind regards Andreas. [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [2] https://tracker.debian.org/pkg/r-bioc-shortread [3] https://ci.debian.net/packages/r/r-cran-rmarkdown/testing/ppc64el/40945637/ [4] https://ci.debian.net/packages/r/r-cran-flextable/testing/ppc64el/40945625/ -- http://fam-tille.de
Bug#1058582: The build tests are not enabled in the Debian package
Package: roc-toolkit
Version: 0.3.0+dfsg-4
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
I'm was looking at libroc for Ubuntu since it's a new depends for
pipewire and noticed that upstream provide tests which aren't enable in
the package build. The attached patch make the tests run as part of the
package build, I've testing it in a ppa and seems to work as expected
https://launchpadlibrarian.net/702261581/buildlog_ubuntu-noble-amd64.roc-toolkit_0.3.0+dfsg-4ubuntu1~build1_BUILDING.txt.gz
```
debian/rules override_dh_auto_test
...
python3 scripts/scons_helpers/timeout-run.py 300
bin/x86_64-pc-linux-gnu/roc-test-core
..
..
..
OK (118 tests, 118 ran, 86418 checks, 0 ignored, 0 filtered out, 11 ms)
```
It would be nice if the tests were also enabled in Debian
Cheers,
Sébastien Bacherdiff -Nru roc-toolkit-0.3.0+dfsg/debian/changelog roc-toolkit-0.3.0+dfsg/debian/changelog
--- roc-toolkit-0.3.0+dfsg/debian/changelog 2023-12-02 09:58:05.0 +0100
+++ roc-toolkit-0.3.0+dfsg/debian/changelog 2023-12-12 21:03:29.0 +0100
@@ -1,3 +1,9 @@
+roc-toolkit (0.3.0+dfsg-5) UNRELEASED; urgency=medium
+
+ * Enable build tests
+
+ -- Sebastien Bacher Tue, 12 Dec 2023 21:03:29 +0100
+
roc-toolkit (0.3.0+dfsg-4) unstable; urgency=medium
* Restrict Build-Deps on libunwind-dev only on supported architectures
diff -Nru roc-toolkit-0.3.0+dfsg/debian/control roc-toolkit-0.3.0+dfsg/debian/control
--- roc-toolkit-0.3.0+dfsg/debian/control 2023-12-02 09:58:05.0 +0100
+++ roc-toolkit-0.3.0+dfsg/debian/control 2023-12-12 21:03:29.0 +0100
@@ -5,6 +5,7 @@
Uploaders: Dylan Aïssi
Build-Depends: debhelper-compat (= 13),
gengetopt,
+ libcpputest-dev,
libpulse-dev,
libsox-dev,
libspeexdsp-dev,
diff -Nru roc-toolkit-0.3.0+dfsg/debian/rules roc-toolkit-0.3.0+dfsg/debian/rules
--- roc-toolkit-0.3.0+dfsg/debian/rules 2023-12-02 09:58:05.0 +0100
+++ roc-toolkit-0.3.0+dfsg/debian/rules 2023-12-12 21:03:29.0 +0100
@@ -2,7 +2,7 @@
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
-SCONS_BUILD_FLAGS = --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) --disable-openfec
+SCONS_BUILD_FLAGS = --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) --disable-openfec --enable-tests
ifneq (,$(filter alpha hurd-amd64 hurd-i386 m68k sparc64 x32,$(DEB_HOST_ARCH)))
SCONS_BUILD_FLAGS += --disable-libunwind
@@ -14,5 +14,8 @@
override_dh_auto_build:
scons ${SCONS_BUILD_FLAGS}
+override_dh_auto_test:
+ scons ${SCONS_BUILD_FLAGS} test/roc_core
+
override_dh_auto_install:
scons ${SCONS_BUILD_FLAGS} install DESTDIR=debian/tmp
Bug#1057714: htop: newlines in cmdline rendered as U+FFFD
Control: forwarded -1 https://github.com/htop-dev/htop/issues/1346 You found two issues here, which we track upstream as https://github.com/htop-dev/htop/issues/1345 and https://github.com/htop-dev/htop/issues/1346 Thank you very much for submitting your bug report. /DLange
Bug#1058583: reportbug: projectm-jack missing projectm-data as a dependency
Package: projectm-jack Version: 3.1.12-3 Severity: important Dear Debian Developers, Please add projectm-data as a dependency of projectm-jack frontend too. As it is required, and as it the case with projectm-pulseaudio frontend. Kind regards, sapphire -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages projectm-jack depends on: ii jackd 5+nmu1 ii libc6 2.37-13 ii libgcc-s1 13.2.0-8 ii libgl11.7.0-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3 ii libqt5core5a 5.15.10+dfsg-5 ii libqt5gui55.15.10+dfsg-5 ii libqt5opengl5 5.15.10+dfsg-5 ii libqt5widgets55.15.10+dfsg-5 ii libstdc++613.2.0-8 projectm-jack recommends no packages. projectm-jack suggests no packages. -- no debconf information
Bug#1054725: pacparser: FTBFS: IndexError: list index out of range
Dear Maintainer,
A possible fix should be [1], however the package is severely outdated
(v1.3.6 comes from 2015...).
Please package newer version (I'm attaching the output of `git diff HEAD`
between 1.3.6 and 1.4.2 as a possible starting point; I've also skipped
git from B-D for getting VERSION from d/rules).
With those changes I was able to build pacparser is a sid chroot
environment but I haven't tested pacparser functionality.
Kind Regards
[1] https://github.com/manugarg/pacparser/commit/36010edefaf87a82a389cdiff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7f8f011..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-7
diff --git a/debian/control b/debian/control
index 6a8a280..b5551d8 100644
--- a/debian/control
+++ b/debian/control
@@ -1,10 +1,14 @@
Source: pacparser
Section: libs
-Priority: extra
+Priority: optional
Maintainer: Manu Garg
Uploaders: Andrew Pollock
-Build-Depends: debhelper (>= 5), python3-all-dev, dh-python
-Standards-Version: 3.9.6
+Build-Depends: debhelper-compat (= 13),
+ dh-sequence-python3,
+ python3-all-dev
+Rules-Requires-Root: no
+Standards-Version: 4.6.2
+Homepage: https://github.com/manugarg/pacparser
Package: libpacparser1
Section: libs
diff --git a/debian/docs b/debian/docs
index e0d7d67..9df535e 100644
--- a/debian/docs
+++ b/debian/docs
@@ -1,2 +1,2 @@
README.md
-README.win32
+#README.win32
diff --git a/debian/patches/0001-Fix-possible-memory-overwrite-vulnerability.-134.patch b/debian/patches/0001-Fix-possible-memory-overwrite-vulnerability.-134.patch
deleted file mode 100644
index e64cd6a..000
--- a/debian/patches/0001-Fix-possible-memory-overwrite-vulnerability.-134.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From 91a93b40f6b4e0a1a9ac497edfbc2a4b18196483 Mon Sep 17 00:00:00 2001
-From: Manu Garg
-Date: Wed, 13 Apr 2022 14:30:07 -0700
-Subject: Fix possible memory overwrite vulnerability. (#134)
-
- src/pacparser.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/src/pacparser.c b/src/pacparser.c
-index cc70a64..5a37d09 100644
a/src/pacparser.c
-+++ b/src/pacparser.c
-@@ -440,11 +440,11 @@ pacparser_find_proxy(const char *url, const char *host)
- // Hostname shouldn't have single quotes in them
- if (strchr(host, '\'')) {
- print_error("%s %s\n", error_prefix,
-- "Invalid hostname: hostname can't have single quotes.");
-+ "Invalid hostname: hostname can't have single quotes.");
- return NULL;
- }
-
-- script = (char*) malloc(32 + strlen(url) + strlen(host));
-+ script = (char*) malloc(32 + strlen(sanitized_url) + strlen(host));
- script[0] = '\0';
- strcat(script, "FindProxyForURL('");
- strcat(script, sanitized_url);
---
-2.30.2
-
diff --git a/debian/patches/fix-build-error-if-git-not-installed.patch b/debian/patches/fix-build-error-if-git-not-installed.patch
new file mode 100644
index 000..46146ec
--- /dev/null
+++ b/debian/patches/fix-build-error-if-git-not-installed.patch
@@ -0,0 +1,15 @@
+--- a/src/pymod/setup.py
b/src/pymod/setup.py
+@@ -67,9 +67,9 @@
+ ))
+
+ def pacparser_version():
+- if subprocess.call('git rev-parse --git-dir'.split(' '),
+- stderr=subprocess.DEVNULL) == 0:
+-return git_version()
++ #if subprocess.call('git rev-parse --git-dir'.split(' '),
++ # stderr=subprocess.DEVNULL) == 0:
++ #return git_version()
+
+ # Check if we have version.mk. It's added in the manual release tarball.
+ version_file = os.path.join(setup_dir(), '..', 'version.mk')
diff --git a/debian/patches/py3only.patch b/debian/patches/py3only.patch
index 6a74db7..0a96294 100644
--- a/debian/patches/py3only.patch
+++ b/debian/patches/py3only.patch
@@ -6,12 +6,10 @@ Origin: vendor
Forwarded: not-needed
Last-Update: 2020-03-02
-Index: pacparser-1.3.6/src/Makefile
-===
pacparser-1.3.6.orig/src/Makefile
-+++ pacparser-1.3.6/src/Makefile
-@@ -58,7 +58,7 @@ endif
- CFLAGS = -g -DXP_UNIX -Wall -DVERSION=$(VERSION)
+--- a/src/Makefile
b/src/Makefile
+@@ -63,7 +63,7 @@
+ MAINT_CFLAGS := -g -DXP_UNIX -Wall -DVERSION=$(VERSION)
ifndef PYTHON
- PYTHON = python
@@ -19,10 +17,3 @@ Index: pacparser-1.3.6/src/Makefile
endif
# Spidermonkey library.
-@@ -134,5 +134,5 @@ install-pymod: pymod
-
- clean:
- rm -f $(LIBRARY_LINK) $(LIBRARY) libjs.a pacparser.o pactester pymod/pacparser_o_buildstamp jsapi_buildstamp
-- cd pymod && python setup.py clean --all
-+ cd pymod && $(PYTHON) setup.py clean --all
- cd spidermonkey && $(MAKE) clean
diff --git a/debian/patches/series b/debian/patches/series
index 0ca96d5..0f0855b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,2 @@
py3only.patch
-0001-Fix-possible-memory-overwrite-vulnerability.-134.patch
+fix-build-error-if-git-not-installed.patch
diff --git a/debian/rules b/debian/rules
index 117ed7c..e27e3c3
Bug#986232: ITP organicmaps
Thanks for your interest in the package, Matthias, and sorry for the late reply. The packaging at https://salsa.debian.org/debian/organicmaps has been done by Jochen Sprickerhof. Feel free to take over the ITP related to libsuccint if you want: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025499 Have a nice day, -- Federico
Bug#1058584: graphite2: please remove extraneous dependency on python3-future
Source: graphite2
Version: 1.3.14-1
Severity: important
Dear Maintainer,
The old transition layer python3-future is problematic
and now fails to build with Python 3.12 with 2 RC bugs.
Your package has an old stale dependency on this package.
Please patch-it out to ease python3-future removal.
diff --git a/setup.py b/setup.py
index 3433cd3..b54dc29 100755
--- a/setup.py
+++ b/setup.py
@@ -26,7 +26,6 @@ setup(
zip_safe = False,
package_dir = {'': 'python'},
packages = ['graphite2'],
-install_requires = ['future'],
long_description = long_description,
long_description_content_type = 'text/markdown',
classifiers = [
Already submitted upstream:
https://github.com/silnrsi/graphite/pull/87/files
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1058573: bowtie: compilation errors on the loong64 architecture
Control: tags -1 moreinfo Hi, Am Wed, Dec 13, 2023 at 03:40:04AM + schrieb wuruilong: > > bowtie has compilation errors on the loong64 architecture. > Please modify the debian/control file to add support for loong64. > The code is as follows: > Architecture: alpha any-amd64 arm64 loong64 mips64el ppc64 ppc64el s390x > sparc64 riscv64 Could you please explain why we should add this architecture if it is known to cause compilation errors? Kind regards Andreas. -- http://fam-tille.de
Bug#1058585: RFS: dhcpcd/1:10.0.5-5 -- DHCPv4 and DHCPv6 dual-stack client
Package: sponsorship-requests
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear mentors,
I am looking for a sponsor for my package "dhcpcd":
* Package name : dhcpcd
Version : 1:10.0.5-5
Upstream contact : Roy Marples
* URL : https://roy.marples.name/projects/dhcpcd
* License : Expat, public-domain, ISC, BSD-3-Clause,
BSD-2-Clause-NETBSD, GPL-3+, BSD-2
* Vcs : https://salsa.debian.org/debian/dhcpcd
Section : net
The source builds the following binary packages:
dhcpcd-base - DHCPv4 and DHCPv6 dual-stack client (binaries and exit hooks)
dhcpcd - DHCPv4 and DHCPv6 dual-stack client (init.d script & systemd unit)
dhcpcd5 - DHCPv4 and DHCPv6 dual-stack client (dummy transitional package)
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/dhcpcd/
Alternatively, you can download the package with 'dget' using this command:
dget -x
https://mentors.debian.net/debian/pool/main/d/dhcpcd/dhcpcd_10.0.5-5.dsc
Changes since the last upload:
dhcpcd (1:10.0.5-5) unstable; urgency=medium
.
* [patches]
- Remove all GNU/Hurd patches. Let Hurd porters handle that.
* [control]
= Breaks/Replaces: dhcpcd5 using (<< ${binary:Version}) variable.
* [rules]
+ Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959).
Regards,
- --
Martin-Éric Racine
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmV5nqUACgkQrh+Cd8S0
17Z45Q//WTG+shwktJ5kduMQYjxEKK0UPe4XzClTRi7EWiwiaiRa1Og83Z3Zmpa9
B4rSJVDj++kkjqwBoD8kTDfmOIWlrpKRFTzXnJbi9XTtAOlB8MfVPhg4jWcVKhEp
vwtK8yKG41bPZOFdjkOy9ocTokoEn4+zG5kThazYQcauytnfL/QeOVd0ZtMl7yMq
Jdh9rBKxl0L+dOu50YJ+j6Jj2p2fkvFNk8NR0JljB+MRjuGJOl6HOmIlswt+Azly
M9XP0QE/iaV1i8Z2Anzm5wnAuw3y7dGGPjnesG3LB+DX7qIibWa1uBQCEWUguSPL
vjH7o7R90CxKqdW7uUTWAiV2an4fW5KNVpJIki6a2YjXbxkurnbmxU1FFTTHlyYe
Vm3X0Z2raHgTl36Mhp3MzbtMLHZ+uo6J9IcNosGCUXcIGhpjbomiIDt7tVG5gabL
AXZ2yrwgE3whdVWsyeEBN9uurQ4CrfoDJT4/ODgwTGG2bKrRIB03N02hT5gcRyGq
s4tbu/ehsqcfl+bc/PW8esN3Jo6NNymbmqO/DKdWGjcH9+hmKAQjRv5M6x3oYC4z
I8Ym0jPWuwdPOVXxDl2t1uKGnJ7oiXoiYU8QL7MpbTKpVtB7N9SlSwTuYvh73XBa
57x+cIOXSBo/YiaUONE+Qr9XNkycjDt/RaILL+QcoAEcxIrCls0=
=H3cY
-END PGP SIGNATURE-
Bug#1058586: bullseye-pu: package python-cogent/2020.12.21a+dfsg-4+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: python-cog...@packages.debian.org, sanv...@debian.org Control: affects -1 + src:python-cogent [ Reason ] This upload fixes Bug #1030885: FTBFS on single-CPU systems. [ Impact ] Anybody trying to build the package using a single-CPU system will see that the build will fail unexpectedly. [ Tests ] I've checked that the fixed package builds again on single-CPU systems and also that it still builds ok on multi-core systems. [ Risks ] Low risk. No real code changes. The only change is that some tests are skipped when we know that they would fail. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Skip parallel tests when the build machine has only one CPU. [ Other info ] The package is already uploaded.diff -Nru python-cogent-2020.12.21a+dfsg/debian/changelog python-cogent-2020.12.21a+dfsg/debian/changelog --- python-cogent-2020.12.21a+dfsg/debian/changelog 2021-02-09 14:42:13.0 +0100 +++ python-cogent-2020.12.21a+dfsg/debian/changelog 2023-12-13 12:30:00.0 +0100 @@ -1,3 +1,10 @@ +python-cogent (2020.12.21a+dfsg-4+deb11u1) bullseye; urgency=medium + + * Team upload. + * Skip parallel tests on single-CPU systems. Closes: #1030885. + + -- Santiago Vila Wed, 13 Dec 2023 12:30:00 +0100 + python-cogent (2020.12.21a+dfsg-4) unstable; urgency=high * Team upload. diff -Nru python-cogent-2020.12.21a+dfsg/debian/patches/series python-cogent-2020.12.21a+dfsg/debian/patches/series --- python-cogent-2020.12.21a+dfsg/debian/patches/series2021-02-07 17:23:21.0 +0100 +++ python-cogent-2020.12.21a+dfsg/debian/patches/series2023-12-13 12:30:00.0 +0100 @@ -1,3 +1,4 @@ sphinx.patch fix_interpreter.patch py39_union_dict +skip-parallel-tests-on-single-cpu-systems.patch diff -Nru python-cogent-2020.12.21a+dfsg/debian/patches/skip-parallel-tests-on-single-cpu-systems.patch python-cogent-2020.12.21a+dfsg/debian/patches/skip-parallel-tests-on-single-cpu-systems.patch --- python-cogent-2020.12.21a+dfsg/debian/patches/skip-parallel-tests-on-single-cpu-systems.patch 1970-01-01 01:00:00.0 +0100 +++ python-cogent-2020.12.21a+dfsg/debian/patches/skip-parallel-tests-on-single-cpu-systems.patch 2023-12-13 12:30:00.0 +0100 @@ -0,0 +1,73 @@ +Author: Santiago Vila +Last-Update: 2023-12-13 +Bug-Debian: https://bugs.debian.org/1030885 +Description: Skip parallel tests on single-cpu systems + +--- a/tests/test_app/test_evo.py b/tests/test_app/test_evo.py +@@ -1,5 +1,7 @@ ++import multiprocessing ++ + from os.path import dirname, join +-from unittest import TestCase, main ++from unittest import TestCase, main, skipIf + from unittest.mock import MagicMock + + from numpy.testing import assert_allclose, assert_raises +@@ -670,6 +672,7 @@ + got = deserialise_object(json) + self.assertIsInstance(got, evo_app.bootstrap_result) + ++@skipIf(multiprocessing.cpu_count() == 1, "Does not work on single-cpu systems") + def test_bstrap_parallel(self): + """exercising bootstrap with parallel""" + aln = load_aligned_seqs(join(data_dir, "brca1.fasta"), moltype="dna") +--- a/tests/test_app/test_io.py b/tests/test_app/test_io.py +@@ -3,10 +3,11 @@ + import pathlib + import shutil + import zipfile ++import multiprocessing + + from os.path import basename, join + from tempfile import TemporaryDirectory +-from unittest import TestCase, main ++from unittest import TestCase, main, skipIf + from unittest.mock import Mock, patch + + import numpy +@@ -532,6 +533,7 @@ + w = io_app.write_db(outdir, create=True, if_exists="skip") + w.data_store.close() + ++@skipIf(multiprocessing.cpu_count() == 1, "Does not work on single-cpu systems") + def test_write_db_parallel(self): + """writing with overwrite in parallel should reset db""" + dstore = io_app.get_data_store(self.basedir, suffix="fasta") +--- a/tests/test_util/test_parallel.py b/tests/test_util/test_parallel.py +@@ -35,6 +35,7 @@ + + + class ParallelTests(TestCase): ++@skipIf(multiprocessing.cpu_count() == 1, "Does not work on single-cpu systems") + def test_create_processes(self): + """Procressor pool should create multiple distingue processes""" + max_worker_count = multiprocessing.cpu_count() - 1 +@@ -45,6 +46,7 @@ + self.assertEqual(sorted(list(result_values)), index) + self.assertEqual(len(set(result_processes)), max_worker_count) + ++@skipIf(multiprocessing.cpu_count() == 1, "Does not work on single-cpu systems") + def test_random_seeding(self): + """Random seed should be set every function call""" + # On Windows process
Bug#1058587: netcdf-parallel: add build support for loongarch64
Source: netcdf-parallel
Version: 1:4.9.0-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
The netcdf-parallel source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control and d/rules.
Please consider the patch I have attached.
The netcdf-parallel source package was compiled successfully on my local
loong64 rootfs environment.
If you have any questions, you can contact me at any time.
thanks,
Dandan Zhang
diff -Nru netcdf-parallel-4.9.0/debian/control
netcdf-parallel-4.9.0/debian/control
--- netcdf-parallel-4.9.0/debian/control2022-06-14 17:45:17.0
+
+++ netcdf-parallel-4.9.0/debian/control2022-06-14 17:45:17.0
+
@@ -15,7 +15,7 @@
libbz2-dev,
libxml2-dev,
libcurl4-gnutls-dev | libcurl-ssl-dev,
- libpnetcdf-dev [amd64 arm64 mips64el ppc64el s390x alpha ia64
sparc64 kfreebsd-amd64 ppc64 riscv64]
+ libpnetcdf-dev [amd64 arm64 loong64 mips64el ppc64el s390x
alpha ia64 sparc64 kfreebsd-amd64 ppc64 riscv64]
Build-Conflicts: libhdf5-dev, hdf5-helpers
Standards-Version: 4.6.1
Vcs-Browser: https://salsa.debian.org/mckinstry/netcdf-parallel
@@ -40,7 +40,7 @@
Package: libnetcdf-pnetcdf-19
Section: libs
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
+Architecture: amd64 arm64 loong64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Interface for scientific data access to large binary data
@@ -74,7 +74,7 @@
This package provides headers.
Package: libnetcdf-pnetcdf-dev
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
+Architecture: amd64 arm64 loong64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
Multi-Arch: same
Section: libdevel
Depends: libnetcdf-pnetcdf-19 (= ${binary:Version}),
diff -Nru netcdf-parallel-4.9.0/debian/rules netcdf-parallel-4.9.0/debian/rules
--- netcdf-parallel-4.9.0/debian/rules 2022-06-14 17:45:17.0 +
+++ netcdf-parallel-4.9.0/debian/rules 2022-06-14 17:45:17.0 +
@@ -11,7 +11,7 @@
UPSTREAM_VERSION = $(shell echo $(DEB_VERSION_UPSTREAM) | sed -e 's/\+.*//')
SO_VERSION:=19
-PNETCDF_ARCHS:= amd64 arm64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
+PNETCDF_ARCHS:= amd64 arm64 loong64 mips64el ppc64el s390x alpha ia64 sparc64
kfreebsd-amd64 ppc64 riscv64
include /usr/share/mpi-default-dev/debian_defaults
MPI:=$(ARCH_DEFAULT_MPI_IMPL)
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
On Wed, Dec 13, 2023 at 11:43:56AM +0100, Andreas Tille wrote: >... > I'm worried > about issues in r-rcan-rmarkdown[3] and r-cran-flextable[4] which are > caused by pandoc errors on ppc64el architecture *only*. That's really > strange and might mean that pandoc on this architecture is broken? >... ppc64el has Lua support disabled[1] due to [2] (#1057857), AFAIK that's the last non-trivial issue of the Haskell transition. I haven't confirmed that this is related, but that would be my first guess for the ppc64el-only [3] in pandoc. > Kind regards > Andreas. >... cu Adrian [1] https://tracker.debian.org/media/packages/p/pandoc/control-3.0.1ds-3 [2] https://buildd.debian.org/status/package.php?p=haskell-lua [3] https://tracker.debian.org/pkg/pandoc
Bug#1057361: Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded load_files is ambiguous
It looks like this issue was already fixed upstream, or at least partially. I reported a separate bug that also references the upstream patch and gives some more context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057630 While this is a relatively severe bug (uninitialized memory), it doesn't manifest itself on many architectures. The build failure that occurs on arm64 and many others is actually a mistake in my Catch2 v3 patch: I used catch2::WithinRel comparison everywhere, but this doesn't work well when comparing to zero. The only surprise here is that it *doesn't* fail on amd64. I will reopen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054697 and submit an updated patch that uses catch2::WithinAbs for comparison with zero instead.
Bug#1051418: obs-studio: clicking on an xcomposite window source makes obs segfault
Package: obs-studio Version: 30.0.2+dfsg~ Followup-For: Bug #1051418 Unfortunately I can confirm the bug at question with the (not yet uploaded) obs-studio 30.0.2. the OBS shipped by flatpak does not have this problem, so it appears to be Debian packaging problem.
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
On 2023-12-12 19:40, Preuße, Hilmar wrote: > These files are in texlive-base > > hille@debian:~$ apt-file search xmltex.ini > texlive-base: > /usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdfxmltex.ini > texlive-base: > /usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/xmltex.ini > > They were in texlive-formats-extra before the latest uploaded; different > path, hence no file conflict. > >> Versions of packages texlive-binaries recommends: >> ii dvisvgm 3.1.2+ds-1 >> ii texlive-base 2023.20231007-1 >> > Upgrading texlive-base to 2023.20231207-1 should solve your issue. I've just tested that solution, and it works fine: tex-common now has no problems. Thank you! -Sanjoy
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
On 2023-12-12 20:48, Norbert Preining wrote: > The log contains > > fmtutil [WARNING]: inifile pdfxmltex.ini for pdfxmltex/pdftex not found. > fmtutil [WARNING]: inifile xmltex.ini for xmltex/pdftex not found. > > These seem to be missing Right. Upgrading the texlive-base (2023.20231007-1 => 2023.20231207-1) (suggested by Hilmar Preuße) has resurrected them. -Sanjoy
Bug#1058588: Disable numeric_limits specialization for GCC 14
Package: src:boost1.74 Version: 1.74.0+ds1-23 Severity: important Tags: sid trixie patch I really would like to see a defaults change of boost to 1.83, or 1.84 which already is on the horizon ... Up to then, please backport that commit to 1.74: https://github.com/boostorg/math/commit/f51e1b985de4d739a9f40d8c2b90debd419da267 http://launchpadlibrarian.net/702380906/boost1.74_1.74.0+ds1-23ubuntu2_1.74.0+ds1-23ubuntu3.diff.gz
Bug#1058579: Acknowledgement (apt: gives misleading error when not finding Packages.xz in Release (not InRelease))
> I note after double-checking that, despite bookworm repos [1] > providing > only Packages.xz and Packages.gz and not Packages, apt does really > seem to check only for Packages in my case: After more testing, it appears that the behavior is different depending on the way the flat repository is used: * sources.list with ".../deb-amd64/ ci/" (needs "Filename: ci/foo.deb" in Packages) => on "Packages" is checked, "Packages.xz" is ignored as previously described * sources.list with ".../deb-amd64/ci/ ./" (needs "Filename: ./foo.deb" in Packages) => a long list of compressed formats is used I'm a bit unsure whether this would be expected. Anyway (assuming this is expected), the part of the error message mentioning "Packages" name may in fact not be wrong per se, but in this (legacy?) use case it could possibly be noted that it has to be uncompressed (since "Packages" is otherwise also AFACT used to encompass compressed versions as well). Best regards, -- Yann
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
Source: developers-reference Severity: normal Hi, > 6.3.2. Selecting the upload urgency mentions only high, medum and low urgency values. Britney also supports critical and emergency. These should be documented as well. Something like: - The delays are currently 2, 5 or 10 days, depending on the urgency (high, medium or low). + The delays are currently 0, 2, 5 or 10 days, depending on the urgency: critical/emergency, high, medium or low respectively. Where emergency is simply an alias for critical. Thanks, --Daniel
Bug#1058590: getent in polkitd.postinst is broken
Package: polkitd Version: 122-3 Problem with polkitd.postinst: "getent passwd polkitd" can fail, even though polkitd can be found in /etc/passwd. Regards Harri
Bug#1058560: libncursesw6: getch(3ncurses) returns -1 with errno unchanged, only documented to return -1 with errno=EINTR
On Tue, Dec 12, 2023 at 08:30:02PM -0500, Thomas Dickey wrote:
> On Wed, Dec 13, 2023 at 01:33:59AM +0100, наб wrote:
> > On Tue, Dec 12, 2023 at 05:55:38PM -0500, Thomas Dickey wrote:
> > > On Tue, Dec 12, 2023 at 11:09:13PM +0100, наб wrote:
> > > > urlview 1c-1 whose xterm was killed but which didn't die consumes 100%
> > > > CPU.
> > > > The event loop is for(;;) switch(getch()) ... and ignores -1
> > > If it's going to ignore the error return (while at the same time
> > > manipulating the time delays with mousemask), then this is expected
> > > (mis)behavior.
> > Sure.
> >
> > Still, it doesn't set errno to EINTR,
> ...and the manual page does not say it would do that.
>
> It lists three possible causes for ERR being returned,
> and on the third it mentions that errno will be set:
>returns ERR if the window pointer is null, or if its timeout
>expires without having any data, or if the execution was interrupted by
>a signal (errno will be set to EINTR).
>
> It could be reformatted like this without changing its meaning:
>returns ERR
>* if the window pointer is null, or
>* if its timeout expires without having any data, or
>* if the execution was interrupted by a signal (errno will be set to
> EINTR).
That, to me, wasn't clear from the page itself.
"any data (errno unchanged)" would make it so.
> > and instant empty reads you get from a hung-up teletype
> > definitely aren't exceeding the timeout.
>
> https://git.sr.ht/~nabijaczleweli/urlview-ng/tree/1c/item/urlview.c#L441
>
> mouseinterval(0) tells it to not wait for mouse events,
Well, mouseinterval(3curses) says
Use mouseinterval(0) to disable click resolution.
which is different from "not wait for mouse events".
> That looks like someone's attempting to make the wheel mouse work at
> infinite velocity
The mouse wheel is checked-for with BUTTON[45]_PRESSED,
so click resolution doesn't factor in here at all.
I picked mouseinterval(0) because the default 166 value is completely
unusable. Clearly it doesn't actually disable click resolution either.
htop uses mouseinterval(0) as well.
Regardless of the mouseinterval argument I can click-hold-release
for however long I want, so long as I don't move the cursor too
much and it registers.
With the default value it just sleeps after I release.
In addition to my usual X teletype (st(1)),
this also happens with xterm(1) under both X configs I have,
so with it being under the dickey umbrella as well,
that clearly indicates that something's wrong to me.
This is also the case under gpm, on a 2002 Celeron laptop.
(And under X on that one as well.)
> I'd have used a 5msec delay (or 1msec for "modern" computers :-)
So is this a UI design choice or is it a VT-compat choice?
What's the point of this function, why does it not just correctly
associate clicks with clicks? Or, rather, why do you need mouseinterval(0)
to correctly associate clicks with clicks,
without "clearly broken" levels of delay?
Why do you suggest any delay at all?
Why 5ms or 1ms?
When is this (supposedly) needed?
What does computer recency have to do with it,
and why is that notion dispelled on the oldest piece of shit I have?
Why is none of this documented?
> -- and might be the reason for ignoring errors --
Mouse support is new, errors are ignored in 0.7 from 1997, so no.
> and might be the reason for the 100% CPU.
This all also happens with mouse and keypad disabled altogether,
so this is all moot.
> If ncurses is actually reading from a closed file descriptor, the manpage
> for read(2) suggests that errno may be set to EBADF
..? It isn't, and I never said it did. It reads from a valid fd,
which corresponds to a hanged-up tty. This is a consistent thoroughline.
> -- but since you say
> errno is _not_ being set, then there's nothing to alert ncurses to the
> problem -- the timeout expired.
There is no time-out:
> (You may get more insight using strace).
The straces you got both indicate that ncurses' first (only) read returns
empty, and any time-out isn't even attempted. You can tell because they
both say read(0, "", 1) = 0 exclusively, and neither of them have a poll.
Indeed, the only time the mouse timeout is attempted is /after/ a
mouse button down/up is read. There is another 1s poll timeout,
which happens after reading an ESC. Again, neither of those are attempted.
Similarly, they all end up in fifo_push() with
340 n = (int) read(sp->_ifd, &c2, (size_t) 1);
...
347 if ((n == -1) || (n == 0)) {
348 TR(TRACE_IEVENT, ("read(%d,&ch,1)=%d, errno=%d", sp->_ifd, n,
errno));
349 ch = ERR;
350 }
from (in the no-timeout case) _nc_wgetch()
596 } else {
597 if (head == -1)
598 fifo_push(sp EVENTLIST_2nd(evl));
599 ch = fifo_pull(sp);
600 }
601
602 if (ch == ERR) {
...
620 returnCode(ERR);
again, no sleeps or timeouts or delays or intervals in this
Bug#1057664: unshield: FTBFS on hppa - md5/libmd5.a(md5c.c.o) needs to compiled with -fPIC
I have no idea how to do that. You can MNU it from tomorrow (or the next day?) and I'll import the changes in git. Greetings unshield (1.4.2-1 to 1.5.1-1) Maintainer: Debian Games Team Migration status for unshield (1.4.2-1 to 1.5.1-1): Waiting for test results or another package, or too young (no action required now - check later) Issues preventing migration: ∙ ∙ Too young, only 9 of 10 days old Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/u/unshield.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Reproducible on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Andreas On Wed, 13 Dec 2023 at 09:45, Andreas Tille wrote: > as you might have noticed the upstream source for r-bioc-dss and > r-bioc-demixt are missing and upstream did not answered two mails about > this. Since the transition looks clean for me so far[1] after I fixed > two autopkgtest issues yesterday I (naively) think we could remove > r-bioc-dss and r-bioc-demixt from testing and all other packages can > migrate to finish the transition from r-bioc perspective. I've added removal hints for r-bioc-dss and r-bioc-demixt. Please file an RC bug for r-bioc-dss to prevent it from migrating straight back (r-bioc-demixt already has #1058278). One problem I see at [1]: Not built on buildd: arch all binaries uploaded by tille, a new source-only upload is needed to allow migration Remember, all r-bioc-* packages need to migrate together, so all of your uploads need to be ready before r-bioc-biocgenerics can migrate. I checked only the first few "Migrates after" links from [1], and found at least these packages still show autopkgtest regressions [2][3][4][5][6]. Regards Graham > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [2] https://tracker.debian.org/pkg/r-bioc-beachmat [3] https://tracker.debian.org/pkg/r-bioc-biobase [4] https://tracker.debian.org/pkg/r-bioc-biocbaseutils [5] https://tracker.debian.org/pkg/r-bioc-biocio [6] https://tracker.debian.org/pkg/r-bioc-biostrings
Bug#1058591: python3-mido: please package 1.3.0
Package: python3-mido Version: 1.2.10-1 Severity: minor Dear Maintainer, I'm doing an archive-wide review of old Python2.7/six/future that needs a cleanup either in the archive of upstream. (some things broke with Py3.12) This package only need a refresh. > Important > Removed support for Python 2.7 Greetings, -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-mido depends on: ii python3 3.11.4-5+b1 python3-mido recommends no packages. Versions of packages python3-mido suggests: pn libportmidi-dev ii libportmidi0 1:217-6.1 ii python3-rtmidi 1.5.8-1+b1 -- no debconf information
Bug#1058592: please consider switching to new upstream source: incus
Source: lxd Version: 5.0.2-6 Severity: wishlist X-Debbugs-Cc: Previously, Canonical removed LXD from the community maintained Linux Containers project, and as in-house contributors moved on / resigned, Canonical removed their commit access to the LXD project hosted at Canonical. The original Linux Containers upstream project, along with contributors from other distributions launched the Incus project, a fork of LXD that is community maintained. LWN covered this before: https://lwn.net/Articles/940684/ Now, Canonical has relicensed LXD, including relicensing for contributions that they don't own, in addition to that, they require CLA acceptance for all contributions, which might not have been a big deal if it wernen't for their history. Some more details on stgraber's blog: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ I suggest looking into Incus and consider switching to that as the LXD implementation packaged in Debian. thanks!
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
On 13.12.2023 13:38, Sanjoy Mahajan wrote: Hi, Upgrading the texlive-base (2023.20231007-1 => 2023.20231207-1) (suggested by Hilmar Preuße) has resurrected them. -Sanjoy Is it fine to close the case? H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058384: lazy-object-proxy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Control: forwarded -1 https://github.com/ionelmc/python-lazy-object-proxy/pull/78 Dear Maintainer, Root cause is that deprecations are treated as errors in pytest.ini [1] Kind regards [1] https://sources.debian.org/src/lazy-object-proxy/1.9.0-1/pytest.ini/#L35-L36
Bug#1057276: pat: PACTOR mode is broken
On Sat, Dec 09, 2023 at 10:26:17PM -0800, tony mancill wrote: > On Sat, Dec 09, 2023 at 06:37:35PM +0100, DC7IA wrote: > > Hello Tony, > > > > that's less than ideal. Currently, as a user, I just notice that the > > software does not work. I do exactly what should work, but for some reason > > it does not. I cannot see that a feature was intentionally removed. > > > > And yes, there's definitely interest, as currently there is no other > > software for PACTOR that is available in the repos. So if that feature can > > be re-added in relatively simple way, that'd be great. > > ... > > Hi Joshua, > > Yes, I agree that the disable functionality could be better documented. ... Greetings pat users -- I'm the author of the PACTOR patch-out, given I do not have access to that non-free software. This is documented in the file /usr/share/doc/pat/README.Debian: ... # ptc-go disabled The current Debian packaging of pat has "ptc-go" pactor modem support disabled. If there is interest in this feature please submit a bug report. ... Thanks for the feedback. Exciting to learn others have interest and possible cycles to progress that component. Ideally there will be follow-up test results helping confirm if things work or not. regards, donfede signature.asc Description: PGP signature
Bug#899245: kgb-bot: support for password-protected channels
On 2023-12-13 08:34:02, Yves-Alexis Perez wrote:
[...]
> since the bug is from 2018, I have to admit I don't really remember why I
> opened it and what channel was the target. I don't have a way to test the
> patch these days, but thanks for the work anyway.
Well, the patch *is* tested, and is running in propduction already. So I
suspect it works well enough for most cases.
What I would love is some review of my perl-fu, just visually, without
running anything. I made some comments on the MR that expand on that;
I'm particularly wondering about the map { $_ => 1 } structure and the
test suite.
Thanks!
--
Semantics is the gravity of abstraction.
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: > Is it fine to close the case? Actually no, the packages should have proper dependencies that this cannot happen. Hilmar, please bump the minimal dep on tl-base to the required level. Thanks Norbert -- PREINING Norbert https://www.preining.info Mercari Inc. + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1058593: picopore: please remove extraneous dependency on deprecated python3-future
Source: picopore Severity: important Hi, Upstream mistakenly declares a dependency on `future` (`from __future__`doesn't need `future). > setup.py: install_requires=['h5py>2.2.0','watchdog','future'], > requirements.txt:future Can you please patch these out and rebuild the package ? python3-future has vely little real users left. A more complete PR has been submitted upstream: https://github.com/scottgigante/picopore/pull/14 Greetings, -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
On 2023-12-13 23:10, Norbert Preining wrote: > On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: >> Is it fine to close the case? > > Actually no, the packages should have proper dependencies that this > cannot happen. > > Hilmar, please bump the minimal dep on tl-base to the required level. Agreed. That's what I was getting at (in my convoluted way) in my previous email, about not being okay to close the case. -Sanjoy
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
On 13.12.2023 15:10, Norbert Preining wrote: On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: Hi Norbert, Is it fine to close the case? Actually no, the packages should have proper dependencies that this cannot happen. Hilmar, please bump the minimal dep on tl-base to the required level. You mean the dep version tex-common or the one for texlive-formats-extra? H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058594: cpluff: [L10N,DE] cpluff_0.2.0+ds1-2_de: german translation
Source: cpluff Version: 0.2.0+ds1-2 Severity: wishlist Dear Maintainer, please find attached the po file with the german translation. It is an update of the current po template. Please consider to apply it to the package. Thank you very much! Kind regards, Christoph Brinkhaus -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled # German translation of xbmc/cpluff. # This file is distributed under the same license as the xbmc package. # Copyright © of this file Chris Leick , 2013. # Christoph Brinkhaus , 2023. # msgid "" msgstr "" "Project-Id-Version: xbmc 12.0\n" "Report-Msgid-Bugs-To: johannes.lehti...@iki.fi\n" "POT-Creation-Date: 2020-04-30 23:48+0300\n" "PO-Revision-Date: 2023-11-30 21:25+0100\n" "Last-Translator: Christoph Brinkhaus \n" "Language-Team: German \n" "Language: de\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" # FIXME s/line/ // #: console/cmdinput_basic.c:52 msgid "ERROR: Command line is too long.\n" msgstr "FEHLER: Befehlszeile ist zu lang.\n" #: console/console.c:77 msgid "displays available commands" msgstr "zeigt verfügbare Befehle" #: console/console.c:78 msgid "sets the displayed log level" msgstr "setzt die angezeigte Protokollierungsstufe" #: console/console.c:79 msgid "registers a plug-in collection" msgstr "registriert eine Plug-in-Sammlung" #: console/console.c:80 msgid "unregisters a plug-in collection" msgstr "entfernt die Registrierung einer Plug-in-Sammlung" #: console/console.c:81 msgid "unregisters all plug-in collections" msgstr "entfernt die Registrierung aller Plug-in-Sammlungen" #: console/console.c:82 msgid "loads and installs a plug-in from the specified path" msgstr "lädt und installiert ein Plug-in aus dem angegebenen Pfad" #: console/console.c:83 msgid "scans plug-ins in the registered plug-in collections" msgstr "durchsucht Plug-ins in den registrierten Plug-in-Sammlungen" #: console/console.c:84 msgid "sets context startup arguments" msgstr "setzt kontextabhängige Startargumente" #: console/console.c:85 msgid "starts a plug-in" msgstr "startet ein Plug-in" #: console/console.c:86 msgid "runs one plug-in run function" msgstr "führt eine Plug-in-Ausführungsfunktion aus" #: console/console.c:87 msgid "runs plug-in run functions until all work is done" msgstr "führt Plug-in-Ausführungsfunktionen aus, bis alles erledigt ist" #: console/console.c:88 msgid "stops a plug-in" msgstr "stoppt ein Plug-in" #: console/console.c:89 msgid "stops all plug-ins" msgstr "stoppt alle Plug-ins" #: console/console.c:90 msgid "uninstalls a plug-in" msgstr "deinstalliert ein Plug-in" #: console/console.c:91 msgid "uninstalls all plug-ins" msgstr "deinstalliert alle Plug-ins" #: console/console.c:92 msgid "lists the installed plug-ins" msgstr "listet die installierten Plug-ins auf" #: console/console.c:93 msgid "lists the installed extension points" msgstr "listet die installierten Erweiterungspunkte auf" #: console/console.c:94 msgid "lists the installed extensions" msgstr "listet alle installierten Erweiterungen auf" #: console/console.c:95 msgid "shows static plug-in information" msgstr "zeigt eine statische Plug-in-Information" #: console/console.c:96 console/console.c:97 msgid "quits the program" msgstr "beendet das Programm" #: console/console.c:103 msgid "enables upgrades of installed plug-ins" msgstr "aktiviert Aktualisierung installierter Plug-ins" #: console/console.c:104 msgid "stops all plug-ins on first upgrade" msgstr "stoppt beim ersten Aktualisieren alle Plug-ins" #: console/console.c:105 msgid "stops all plug-ins on first install or upgrade" msgstr "stoppt beim ersten Installieren oder Aktualisieren alle Plug-ins" #: console/console.c:106 msgid "restarts the currently active plug-ins after the scan" msgstr "startet das derzeit aktive Plug-in nach dem Scan wieder" #: console/console.c:112 msgid "detailed debug messages" msgstr "detaillierte Debug-Meldungen" #: console/console.c:113 msgid "informational messages" msgstr "informative Meldungen" #: console/console.c:114 msgid "warnings about possible problems" msgstr "Warnungen vor möglichen Problemen" #: console/console.c:115 msgid "error messages" msgstr "Fehlermeldungen" #: console/console.c:116 msgid "disable logging" msgstr "deaktiviert Protokollierung" #: console/console.c:153 msgid "Command has too many arguments.\n" msgstr "Befehl hat zu viele Argumente.\n" #: console/console.c:176 msgid "The following commands are availab
Bug#1058595: Bug - linux-image-6.1.0-15-amd64 - system won't shut down if using rtl8192cu wifi adapter.
Package: linux-image-6.1.0-15-amd64 Version: 6.1.661 Recent update from Linux image 6.1.0-13-amd64 to Linux image 6.1.0-15-amd64 created an issue with system shutdown while using a wifi adapter (D-Link DWA-121 150 Pico, rtl8192cu). Firmware-realtek is installed. When shutting down, the system hangs while trying to shutdown wpasupplicant and network-manager. It continues to cycle indefinitely. Without the wifi adapter, the system boots and shuts down normally. I have reverted to linux image 6.1.0-13-amd64, and there is no issue. The system boots and shuts down normally. I am using Debian 12 with the standard Gnome installation.
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
[Sorry for the resend -- my mailer [emacs+notmuch] had mangled the To: header in the first attempt] On 2023-12-13 23:10, Norbert Preining wrote: > On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: >> Is it fine to close the case? > > Actually no, the packages should have proper dependencies that this > cannot happen. > > Hilmar, please bump the minimal dep on tl-base to the required level. Agreed. That's what I was getting at (in my convoluted way) in my previous email, about not being okay to close the case. -Sanjoy
Bug#1058452: tex-common: "fmtutil failed" in post-installation script
> You mean the dep version tex-common or the one for texlive-formats-extra? Since texlive-formats-extra ships the format definitions, it needs to require the version of texlive-whatever that ships the .ini files, so the dep should be in texlive-formats-extra, IMO. Best regards Norbert -- PREINING Norbert https://www.preining.info Mercari Inc. + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1058560: libncursesw6: getch(3ncurses) returns -1 with errno unchanged, only documented to return -1 with errno=EINTR
On Wed, Dec 13, 2023 at 02:09:35PM +0100, наб wrote: > On Tue, Dec 12, 2023 at 08:30:02PM -0500, Thomas Dickey wrote: > > On Wed, Dec 13, 2023 at 01:33:59AM +0100, наб wrote: > > > On Tue, Dec 12, 2023 at 05:55:38PM -0500, Thomas Dickey wrote: > > > > On Tue, Dec 12, 2023 at 11:09:13PM +0100, наб wrote: > > > > > urlview 1c-1 whose xterm was killed but which didn't die consumes > > > > > 100% CPU. > > > > > The event loop is for(;;) switch(getch()) ... and ignores -1 > > > > If it's going to ignore the error return (while at the same time > > > > manipulating the time delays with mousemask), then this is expected > > > > (mis)behavior. > > > Sure. > > > > > > Still, it doesn't set errno to EINTR, > > ...and the manual page does not say it would do that. > > > > It lists three possible causes for ERR being returned, > > and on the third it mentions that errno will be set: > >returns ERR if the window pointer is null, or if its timeout > >expires without having any data, or if the execution was interrupted > > by > >a signal (errno will be set to EINTR). > > > > It could be reformatted like this without changing its meaning: > >returns ERR > >* if the window pointer is null, or > >* if its timeout expires without having any data, or > >* if the execution was interrupted by a signal (errno will be set to > > EINTR). > That, to me, wasn't clear from the page itself. > "any data (errno unchanged)" would make it so. > > > > and instant empty reads you get from a hung-up teletype > > > definitely aren't exceeding the timeout. > > > > https://git.sr.ht/~nabijaczleweli/urlview-ng/tree/1c/item/urlview.c#L441 > > > > mouseinterval(0) tells it to not wait for mouse events, > Well, mouseinterval(3curses) says > Use mouseinterval(0) to disable click resolution. > which is different from "not wait for mouse events". Even funnier, it also says that The mouseinterval function sets the maximum time (in thousands of a second) that can elapse between press and release events for them to be recognized as a click. and it appears to only actually be used for coalescing adjacent click events into double and triple clicks (testing confirms this), so the manual sure reads like disinformation. In light of this, > > I'd have used a 5msec delay (or 1msec for "modern" computers :-) I wouldn't, since this corresponds to the actual delay between consecutive clicks, and even I can't click twice in 5ms. So mouseinterval(0) appears to just be a boilerplate requirement if you aren't using curses-provided double- or triple-clicks, which I'm not? signature.asc Description: PGP signature
Bug#1058595: Bug - linux-image-6.1.0-15-amd64 - system won't shut down if using rtl8192cu wifi adapter.
Control: reassign -1 src:linux 6.1.66-1 Control: close -1 6.1.67-1 On Wednesday, 13 December 2023 15:27:14 CET Doug Behl wrote: > Package: linux-image-6.1.0-15-amd64 > Version: 6.1.661 > > Recent update from Linux image 6.1.0-13-amd64 to Linux image > 6.1.0-15-amd64 created an issue with system shutdown while using a wifi > adapter (D-Link DWA-121 150 Pico, rtl8192cu). Firmware-realtek is > installed. When shutting down, the system hangs while trying to > shutdown wpasupplicant and network-manager. Similar as bug #1057967 and #1057969 which are fixed in 6.1.67-1 signature.asc Description: This is a digitally signed message part.
Bug#1058353: libadios2-mpi-c-dev: ships headers already shipped in libadios2-common-c-dev
Source: adios2 Followup-For: Bug #1058353 Damn, something went badly wrong in debian/rules. Sorry about that. I'll fix it as soon as possible, in the meantime use the version in testing. Drew
Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function
Package: yarnpkg Version: 1.22.19+~cs24.27.18-2 severity: grave justification: breaks any options passed to yarnpkg yarnpkg install also fails with similar errors due to incompatible node-commander We should backport the patches in unstable to bookworm as well. # cat /usr/share/nodejs/yarn-error.log Arguments: /usr/bin/node /usr/bin/yarnpkg --help PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin Yarn version: 1.22.19 Node version: 18.13.0 Platform: linux x64 Trace: TypeError: commander.on is not a function at Object.run (/usr/share/nodejs/yarn/lib/cli/commands/help.js:75:13) at run (/usr/share/nodejs/yarn/lib/cli/index.js:494:30) at /usr/share/nodejs/yarn/lib/cli/index.js:732:24 npm manifest: No manifest yarn manifest: No manifest Lockfile: No lockfile # yarnpkg --frozen-lockfile install TypeError: _commander(...).default.optionFor is not a function at /usr/share/nodejs/yarn/lib/cli/index.js:355:88 at Array.findIndex () at _callee$ (/usr/share/nodejs/yarn/lib/cli/index.js:352:38) at tryCatch (/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:44:17) at Generator. (/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:125:22) at Generator.next (/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:69:21) at asyncGeneratorStep (/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:3:24) at _next (/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:22:9) at /usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:27:7 at new Promise ()
Bug#1058597: RM: haskell-lpeg [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058598: RM: haskell-lua-arbitrary [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058599: RM: haskell-hslua-core [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058600: RM: haskell-hslua-marshalling [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058601: RM: haskell-tasty-hslua [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058602: RM: haskell-hslua-classes [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64
Hi Ilias! On Thu, 2023-11-16 at 20:23 +0200, Ilias Tsitsimpis wrote: > Thanks for working on this. I fear that applying this patch will change > the ABI for Cabal, and hence we will have to rebuild every Haskell > package in Debian. Because of that, I plan on waiting for the current > transition to finish, and then include this patch in the next GHC > upload. Are you sure that this actually the case [1]? Adrian > [1] https://github.com/haskell/cabal/pull/9445#issuecomment-1811780089 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1058603: RM: haskell-tasty-lua [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058604: RM: haskell-hslua-aeson [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function
Control: fixed -1 1.22.19+~cs24.27.18-4 On Wed, 13 Dec 2023 20:39:39 +0530 Pirate Praveen wrote: We should backport the patches in unstable to bookworm as well. Updating the fixed info. OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1058605: RM: haskell-hslua-objectorientation [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058607: RM: haskell-hslua [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058606: RM: haskell-hslua-packaging [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058608: RM: haskell-hslua-module-path [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058609: RM: haskell-hslua-module-system [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058610: RM: haskell-hslua-module-text [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058612: RM: haskell-pandoc-lua-marshal [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058611: RM: haskell-hslua-module-version [ppc64el ppc64] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP team, Please remove this package from ppc64el and ppc64 to facilitate the removal of haskell-lua (see https://bugs.debian.org/1057857). Thanks -- Ilias
Bug#1058555: [Help] Missing proper Build-Depends from libreoffice (Wass: Bug#1058555: parallel: FTBFS: /usr/bin/install: cannot stat './parallel_cheat_bw.pdf': No such file or directory)
Control: tags -1 help Am Tue, Dec 12, 2023 at 09:52:48PM +0100 schrieb Lucas Nussbaum: > > /usr/bin/install: cannot stat './parallel_cheat_bw.pdf': No such file or > > directory This file is (re-)created via libreoffice --headless --convert-to pdf parallel_cheat_bw.fodt Formerly this worked with the only Build-Depends libreoffice-writer-nogui. Possibly since latest upgrade of libreoffice suite I had to add the following Build-Depends: libreoffice-java-common, ure-java, default-jre-headless I admit the fact that default-jre-headless is no dependency of libreoffice-java-common smells like a bug in the dependencies but well, I have not enough insight here. Unfortunately this is not sufficient to recreate the pdf. I rather get /build/parallel-20231122+ds/src # libreoffice --headless --convert-to pdf parallel_cheat_bw.fodt Error: source file could not be loaded inside the pbuilder environment where I'm building the package. However, if I try on my local (testing!) system I get: .../parallel/src(master) $ libreoffice --headless --convert-to pdf parallel_cheat_bw.fodt convert .../parallel/src/parallel_cheat_bw.fodt as a Writer document -> .../parallel/src/parallel_cheat_bw.pdf using filter : writer_pdf_Export so the conversion is working. This pretty much sounds like some additional missing build depends which is installed in my more or less functional desktop installation of libreoffice. Rene, do you have some idea what Build-Depends might be missing in my pbuilder chroot to let the convert process work properly? Kind regards Andreas. -- http://fam-tille.de
Bug#1058613: r-bioc-dss: Prevent migration to testing due to missing source
Source: r-bioc-dss Version: 2.48.0+dfsg-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: 1054...@bugs.debian.org As reported to upstream the source download for Bioconductor 3.18 of DSS is broken. To enable the Bioconductor 3.18 transition this package will be removed from testing and should not migrate again until the issue is clarified upstream. Kind regards Andreas. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1058596: [Pkg-javascript-devel] Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function
On 13/12/23 8:52 pm, Yadd wrote: since severity is grave, please prepare an update for stable also Yes, I'm backporting the updated patch. OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1058596: [Pkg-javascript-devel] Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function
On 12/13/23 19:17, Praveen Arimbrathodiyil wrote: Control: fixed -1 1.22.19+~cs24.27.18-4 On Wed, 13 Dec 2023 20:39:39 +0530 Pirate Praveen wrote: We should backport the patches in unstable to bookworm as well. Updating the fixed info. Hi, since severity is grave, please prepare an update for stable also Cheers, Yadd
Bug#1058614: xfce4-power-manager: not suspending when switching to battery if lid is already closed
Package: xfce4-power-manager
Version: 4.18.1-1
Severity: normal
Tags: patch
X-Debbugs-Cc: avfor...@gmail.com
Dear Maintainer,
my settings include:
- lid action on battery: suspend
- lid action on ac: nothing
my scenario is:
- close lid
- disconnect external power supply
expected behavior (this is systemd default behavior with similar conf):
- system should suspend
actual behavior:
- system does nothing
note: when switching the steps in the scenario - first disconnecting and
only then closing the lid - system suspends as expected.
attached a patch that solves the problem, though seems to be a little
bit hackish.
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xfce4-power-manager depends on:
ii libc6 2.36-9+deb12u1
ii libcairo-gobject2 1.16.0-7
ii libcairo2 1.16.0-7
ii libglib2.0-0 2.74.6-2
ii libgtk-3-03.24.37-2
ii libnotify40.8.1-1
ii libpango-1.0-01.50.12+ds-1
ii libpangocairo-1.0-0 1.50.12+ds-1
ii libupower-glib3 0.99.20-2
ii libx11-6 2:1.8.4-2+deb12u1
ii libxext6 2:1.3.4-1+b1
ii libxfce4ui-2-04.18.2-2
ii libxfce4util7 4.18.1-2
ii libxfconf-0-3 4.18.0-2
ii libxrandr22:1.5.2-2+b1
ii upower0.99.20-2
ii xfce4-power-manager-data 4.18.1-1
Versions of packages xfce4-power-manager recommends:
ii libpam-systemd [logind] 252.19-1~deb12u1
ii xfce4-power-manager-plugins 4.18.1-1
xfce4-power-manager suggests no packages.
-- no debconf information
Description: handle lid action upon power disconnection when lid is closed
formerly, lid actions were only handled on lid event (close). if lid is already
closed, switching from external power supply to battery didn't trigger the lid
action. now we try to see lid actions as depending on a combination of 2
states: power source and lid state, no matter the order.
.
xfce4-power-manager (4.18.1-1) unstable; urgency=medium
.
* Team upload.
* New upstream version 4.18.1.
Author: Unit 193
---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: (upstream|backport|vendor|other), (|commit:)
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By:
Last-Update: 2023-12-13
--- xfce4-power-manager-4.18.1.orig/src/xfpm-power.c
+++ xfce4-power-manager-4.18.1/src/xfpm-power.c
@@ -273,6 +273,7 @@ xfpm_power_check_lid (XfpmPower *power,
{
if (closed != power->priv->lid_is_closed )
{
+ XFPM_DEBUG("closed %d, was %d", closed, power->priv->lid_is_closed);
power->priv->lid_is_closed = closed;
g_signal_emit (G_OBJECT (power), signals [LID_CHANGED], 0,
power->priv->lid_is_closed);
}
@@ -329,8 +330,13 @@ xfpm_power_get_properties (XfpmPower *po
"lid-is-closed", &lid_is_closed,
"lid-is-present", &lid_is_present,
NULL);
- xfpm_power_check_lid (power, lid_is_present, lid_is_closed);
+
+ /* in case on battery, use this ugly hack to force rerun of lid handling */
+ if (on_battery && !power->priv->on_battery)
+ power->priv->lid_is_closed = 0;
+
xfpm_power_check_power (power, on_battery);
+ xfpm_power_check_lid (power, lid_is_present, lid_is_closed);
}
static void
Bug#1058079: tar: diff for NMU version 1.34+dfsg-1.3
Control: tags 1058079 + patch
Control: tags 1058079 + pending
Dear maintainer,
I've prepared an NMU for tar (versioned as 1.34+dfsg-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
MR as well in https://salsa.debian.org/debian/tar/-/merge_requests/5
Regards,
Salvatore
diff -Nru tar-1.34+dfsg/debian/changelog tar-1.34+dfsg/debian/changelog
--- tar-1.34+dfsg/debian/changelog 2023-04-06 16:25:47.0 +0200
+++ tar-1.34+dfsg/debian/changelog 2023-12-13 16:22:08.0 +0100
@@ -1,3 +1,11 @@
+tar (1.34+dfsg-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix handling of extended header prefixes (CVE-2023-39804)
+(Closes: #1058079)
+
+ -- Salvatore Bonaccorso Wed, 13 Dec 2023 16:22:08 +0100
+
tar (1.34+dfsg-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch
--- tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch 1970-01-01 01:00:00.0 +0100
+++ tar-1.34+dfsg/debian/patches/Fix-handling-of-extended-header-prefixes.patch 2023-12-13 16:22:08.0 +0100
@@ -0,0 +1,62 @@
+From: Sergey Poznyakoff
+Date: Sat, 28 Aug 2021 16:02:12 +0300
+Subject: Fix handling of extended header prefixes
+Origin: https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4
+Bug-Debian: https://bugs.debian.org/1058079
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-39804
+
+* src/xheader.c (locate_handler): Recognize prefix keywords only
+when followed by a dot.
+(xattr_decoder): Use xmalloc/xstrdup instead of alloc
+---
+ src/xheader.c | 17 +
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/src/xheader.c b/src/xheader.c
+index 4f8b2b27cc62..3cd694d1b12a 100644
+--- a/src/xheader.c
b/src/xheader.c
+@@ -637,11 +637,11 @@ static struct xhdr_tab const *
+ locate_handler (char const *keyword)
+ {
+ struct xhdr_tab const *p;
+-
+ for (p = xhdr_tab; p->keyword; p++)
+ if (p->prefix)
+ {
+-if (strncmp (p->keyword, keyword, strlen(p->keyword)) == 0)
++ size_t kwlen = strlen (p->keyword);
++if (keyword[kwlen] == '.' && strncmp (p->keyword, keyword, kwlen) == 0)
+ return p;
+ }
+ else
+@@ -1716,19 +1716,20 @@ xattr_decoder (struct tar_stat_info *st,
+char const *keyword, char const *arg, size_t size)
+ {
+ char *xstr, *xkey;
+-
++
+ /* copy keyword */
+- size_t klen_raw = strlen (keyword);
+- xkey = alloca (klen_raw + 1);
+- memcpy (xkey, keyword, klen_raw + 1) /* including null-terminating */;
++ xkey = xstrdup (keyword);
+
+ /* copy value */
+- xstr = alloca (size + 1);
++ xstr = xmalloc (size + 1);
+ memcpy (xstr, arg, size + 1); /* separator included, for GNU tar '\n' */;
+
+ xattr_decode_keyword (xkey);
+
+- xheader_xattr_add (st, xkey + strlen("SCHILY.xattr."), xstr, size);
++ xheader_xattr_add (st, xkey + strlen ("SCHILY.xattr."), xstr, size);
++
++ free (xkey);
++ free (xstr);
+ }
+
+ static void
+--
+2.43.0
+
diff -Nru tar-1.34+dfsg/debian/patches/series tar-1.34+dfsg/debian/patches/series
--- tar-1.34+dfsg/debian/patches/series 2023-04-06 16:25:47.0 +0200
+++ tar-1.34+dfsg/debian/patches/series 2023-12-13 16:22:08.0 +0100
@@ -3,3 +3,4 @@
listed03-linux-only
oldgnu-unknown-mode-bits.patch
proper_it_translation.patch
+Fix-handling-of-extended-header-prefixes.patch
Bug#1058079: tar: diff for NMU version 1.34+dfsg-1.3
Thank you. There is no need for delay. On Wed, 13 Dec 2023, 16:36 Salvatore Bonaccorso, wrote: > Control: tags 1058079 + patch > Control: tags 1058079 + pending > > > Dear maintainer, > > I've prepared an NMU for tar (versioned as 1.34+dfsg-1.3) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > MR as well in https://salsa.debian.org/debian/tar/-/merge_requests/5 > > Regards, > Salvatore >
Bug#1058218: libei: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test --timeout-multiplier 2 returned exit code 1
The build is failing on ppc64el for Ubuntu so it might be more of a timing issue than architecture specific. I've reported it upstream to https://bugs.launchpad.net/ubuntu/+source/libei/+bug/2046357
Bug#1058615: bookworm-pu: package node-yarnpkg/1.22.19+~cs24.27.18-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: node-yarn...@packages.debian.org
Control: affects -1 + src:node-yarnpkg
This fixes rc bug #1058596
[ Reason ]
The version in bookworm included a patch for node-commander 8+ support
but which was not working, this was fixed in unstable later but was not
backported to stable.
[ Impact ]
yarnpkg command is broken if any command line argument is used.
[ Tests ]
Tested manually on bookworm.
[ Risks ]
This is already working on unstable.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Backported the patch from unstable.
[ Other info ]
(Anything else the release team should know.)
diff -Nru node-yarnpkg-1.22.19+~cs24.27.18/debian/changelog
node-yarnpkg-1.22.19+~cs24.27.18/debian/changelog
--- node-yarnpkg-1.22.19+~cs24.27.18/debian/changelog 2022-11-14
09:52:50.0 +0530
+++ node-yarnpkg-1.22.19+~cs24.27.18/debian/changelog 2023-12-13
20:54:48.0 +0530
@@ -1,3 +1,9 @@
+node-yarnpkg (1.22.19+~cs24.27.18-2+deb12u1) bookworm; urgency=medium
+
+ * Backport patch from unstable for commander 8 support (Closes: #1058596)
+
+ -- Pirate Praveen Wed, 13 Dec 2023 20:54:48 +0530
+
node-yarnpkg (1.22.19+~cs24.27.18-2) unstable; urgency=medium
* Team upload
diff -Nru
node-yarnpkg-1.22.19+~cs24.27.18/debian/patches/fix-for-commander-8.patch
node-yarnpkg-1.22.19+~cs24.27.18/debian/patches/fix-for-commander-8.patch
--- node-yarnpkg-1.22.19+~cs24.27.18/debian/patches/fix-for-commander-8.patch
2022-11-14 09:52:50.0 +0530
+++ node-yarnpkg-1.22.19+~cs24.27.18/debian/patches/fix-for-commander-8.patch
2023-12-13 20:52:11.0 +0530
@@ -1,11 +1,1037 @@
Description: fix for node-commander ≥ 8
-Author: Yadd
+Author: Yadd , Konstantin Demin
Forwarded: no
-Last-Update: 2022-11-13
+Last-Update: 2023-09-15
+---
+ src/cli/commands/_build-sub-commands.js | 4 +-
+ src/cli/commands/access.js | 31
+ src/cli/commands/add.js | 4 +-
+ src/cli/commands/audit.js | 2 +-
+ src/cli/commands/autoclean.js | 2 +-
+ src/cli/commands/bin.js | 2 +-
+ src/cli/commands/cache.js | 8 +-
+ src/cli/commands/check.js | 2 +-
+ src/cli/commands/config.js | 27 ---
+ src/cli/commands/create.js | 4 +-
+ src/cli/commands/exec.js| 2 +-
+ src/cli/commands/generate-lock-entry.js | 2 +-
+ src/cli/commands/global.js | 22 +++---
+ src/cli/commands/help.js| 38 +-
+ src/cli/commands/import.js | 2 +-
+ src/cli/commands/info.js| 2 +-
+ src/cli/commands/init.js| 2 +-
+ src/cli/commands/install.js | 4 +-
+ src/cli/commands/licenses.js| 19 +++--
+ src/cli/commands/link.js| 4 +-
+ src/cli/commands/list.js| 6 +-
+ src/cli/commands/login.js | 2 +-
+ src/cli/commands/logout.js | 2 +-
+ src/cli/commands/node.js| 2 +-
+ src/cli/commands/outdated.js| 4 +-
+ src/cli/commands/owner.js | 23 +++---
+ src/cli/commands/pack.js| 1 +
+ src/cli/commands/policies.js| 2 +-
+ src/cli/commands/publish.js | 2 +-
+ src/cli/commands/remove.js | 4 +-
+ src/cli/commands/run.js | 2 +-
+ src/cli/commands/tag.js | 23 +++---
+ src/cli/commands/team.js| 17 +++--
+ src/cli/commands/unlink.js | 4 +-
+ src/cli/commands/unplug.js | 6 +-
+ src/cli/commands/upgrade-interactive.js | 2 +-
+ src/cli/commands/upgrade.js | 2 +-
+ src/cli/commands/version.js | 4 +-
+ src/cli/commands/versions.js| 2 +-
+ src/cli/commands/why.js | 4 +-
+ src/cli/commands/workspace.js | 2 +-
+ src/cli/commands/workspaces.js | 4 +-
+ src/cli/index.js| 99 +
+ src/rc.js | 6 +-
+ src/util/execute-lifecycle-script.js| 2 +-
+ 45 files changed, 218 insertions(+), 192 deletions(-)
+
+--- a/src/cli/commands/_build-sub-commands.js
b/src/cli/commands/_build-sub-commands.js
+@@ -26,11 +26,11 @@
+ commander.usage(`${rootCommandName} [${subCommandNames.join('|')}]
[flags]`);
+ }
+
+- async function run(config: Config, reporter: Reporter, flags: Object, args:
Array): Promise {
++ async function run(config: Config, reporter: Reporter, commander: Object,
flags: Object, args: Array): Promise {
+ const subName: ?string = camelCase(args.shift() || '');
+ if (subName && subCommands[subName]) {
+ co
Bug#1058079: tar: diff for NMU version 1.34+dfsg-1.3
That sounds good to me. Thanks for your help. On Wed, 13 Dec 2023, 16:41 Salvatore Bonaccorso, wrote: > Janos, > > On Wed, Dec 13, 2023 at 04:36:44PM +0100, Janos LENART wrote: > > Thank you. There is no need for delay. > > You are fast :). Ok then I will reschedule it to upload directly. > > As the issue is not warranting a DSA from our perspective I was > considering to just as well propose bookworm-pu (and maybe > bullseye-pu) updates for it. > > Regards, > Salvatore >
Bug#1058596: [Pkg-javascript-devel] Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function
On 13/12/23 8:54 pm, Praveen Arimbrathodiyil wrote: On 13/12/23 8:52 pm, Yadd wrote: since severity is grave, please prepare an update for stable also Yes, I'm backporting the updated patch. Proposed it to release team as #1058615 OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1058079: tar: diff for NMU version 1.34+dfsg-1.3
Janos, On Wed, Dec 13, 2023 at 04:36:44PM +0100, Janos LENART wrote: > Thank you. There is no need for delay. You are fast :). Ok then I will reschedule it to upload directly. As the issue is not warranting a DSA from our perspective I was considering to just as well propose bookworm-pu (and maybe bullseye-pu) updates for it. Regards, Salvatore
