Bug#1000733: python-pygit2-doc: Generated parts of the documentation is missing
Package: python-pygit2-doc Version: 1.4.0+dfsg1-1 Severity: normal Dear Maintainer, The HTML generated in python-pygit2-doc is currently missing whatever the RST autoclass text directive should produce. See, for instance, in html/repository.html the empty sections on "The Odb class" and "The Refdb class", and compare with the expected https://www.pygit2.org/repository.html -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 5.10.80 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages python-pygit2-doc depends on: ii libjs-sphinxdoc 3.4.3-2 ii sphinx-rtd-theme-common 0.5.1+dfsg-1 python-pygit2-doc recommends no packages. python-pygit2-doc suggests no packages. -- no debconf information
Bug#1000731: Program fails to start
Hi Osamu,
thanks for your analysis.
nautilus-scripts-manager was never meant to be more than a GUI to
handle these links in a comfortable way (with the possible benefit of
proposing localized names if the script provides them).
This is stated quite clearly in the project web page:
http://www.pietrobattiston.it/nautilus-scripts-manager
I myself used this package when I was a nautilus user, but I changed my
default file manager some time ago.
So is it an essential package? Definitely not. Is it well maintained?
Probably not. But the program works regularly in bullseye; apparently
something changed in bookworm and I have to understand what. The fact
that it didn't get new commits since 2014 is unrelated to the issue you
are experiencing.
In short: if we decide to keep this package, making it work in bookworm
should be a one liner, as the problematic line's aim is just to test if
there is an active graphic user session. By the way: I guess you are
running the program inside a graphic session?
If we decide to drop this package, I don't expect too much user
desperation either ;-) (mainly because of the low popcon)
Cheers,
Pietro
Il giorno dom, 28/11/2021 alle 14.03 +0900, Osamu Aoki ha scritto:
> Package: nautilus-scripts-manager
> Version: 2.0-1.1
> Severity: important
> X-Debbugs-Cc: Pietro Battiston , Piotr
> Ożarowski , Ondřej Nový
>
> Hi,
>
> As I try to start nautilus-scripts-manager, it doesn't start
>
> $ nautilus-scripts-manager
> /usr/bin/nautilus-scripts-manager:21: PyGIWarning: Pango was imported
> without specifying a version first. Use gi.require_version('Pango',
> '1.0') before import to ensure that the right version gets loaded.
> from gi.repository import Pango, Gtk, GLib
> /usr/bin/nautilus-scripts-manager:21: PyGIWarning: Gtk was imported
> without specifying a version first. Use gi.require_version('Gtk',
> '4.0') before import to ensure that the right version gets loaded.
> from gi.repository import Pango, Gtk, GLib
> Traceback (most recent call last):
> File "/usr/bin/nautilus-scripts-manager", line 97, in
> s = Gdk.Screen.get_default()
> File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py",
> line 32, in __getattr__
> return getattr(self._introspection_module, name)
> File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in
> __getattr__
> raise AttributeError("%r object has no attribute %r" % (
> AttributeError: 'gi.repository.Gdk' object has no attribute 'Screen'
>
>
> This package is not usable for the main purpose via GUI. (If we were
> to use command-line, we can do it via "ln -s" anyway. I suppose
> those
> CLI are there for test purpose.)
>
> I found a salsa repository which seems to be most current and updated
> some there.
> https://salsa.debian.org/debian/nautilus-scripts-manager
>
> After making some housekeeping and a few commits, I realized the
> nautilus script itself can be created and used independent of this
> package and there is no Debian package using this program to manage
> their nautilus scripts any more for user.
>
> There is a nice tutorial NautilusScriptsHowto which let us use
> nautilus
> script itself without this package.
> https://help.ubuntu.com/community/NautilusScriptsHowto
>
> So I decided to stop. What is the point of keeping this package?
>
> I am CCing git committers of this package.
>
> If anyone is interested to keep this package, please update salsa
> repo
> and make upload. The last commit by the upstream seems to be 2014.
>
> If no one respond in few months, we should remove this from the next
> release.
>
> Regards,
>
> Osamu
>
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.15.0-1-amd64 (SMP w/12 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages nautilus-scripts-manager depends on:
> ii nautilus 41.1-1
> ii python3 3.9.7-1
> ii python3-gi 3.42.0-2+b1
>
> nautilus-scripts-manager recommends no packages.
>
> nautilus-scripts-manager suggests no packages.
>
> -- no debconf information
Bug#979020: Please replace mime-support with media-types and mailcap in Recommends.
Control: tags 979020 +pending On Sun, Aug 29, 2021 at 02:30:33PM +0900, Charles Plessy wrote: > Le Sat, Jan 02, 2021 at 10:13:09AM +0900, Charles Plessy a écrit : > > > > Recently I have split the `mime-support` package into two: `media-types` > > supplies /etc/mime.types and `mailcap` supplies the mailcap system. > > `mime-support` remains as a transitional package for the moment. > > > > I believe that `mutt` and `neomutt` recommend `mime-support` for both > > functionalities. > > > > At your convenience, can you replace mime-support with media-types and > > mailcap in mutt and neomutt's Recommends ? > > Hello, > > now that Bullseye is released, it would be great if mutt and neomutt > could recommend media-types and mailcap directly, so that I can remove > mime-support. This is done in the git repository now (thanks to your patch) and it will be live once 2.1.3-2 is released.
Bug#1000730: Merge conflict marker left in Debian changelog
severity 1000605 normal reassign 1000730 src:libreoffice forcemerge 1000605 1000730 thanks Hi, Am 28.11.21 um 04:04 schrieb Josh Triplett: > The Debian changelog for libreoffice contains what looks like a merge > conflict marker around the entry for 1:7.3.0~alpha1-2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000605 Regards, Rene
Bug#1000732: python3-click-threading: broken monkeypatching
Package: python3-click-threading
Version: 0.4.4-2
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen
It seems like the monkeypatching in
/usr/lib/python3/dist-packages/click_threading/monkey.py is broken, at
least for me. I'm using python3-click-threading by way of vdirsyncer:
$ vdirsyncer -vdebug sync
debug: Using 1 maximal workers.
) -> None
lambda ) -> None: clear._real_click_fn() -> None)
error: Unknown error occurred: unmatched ')' (, line 1)
error: Use `-vdebug` to see the full traceback.
debug: File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line
30, in inner
debug: f(*a, **kw)
debug: File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line
145, in sync
debug: with wq.join():
debug: File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug: File "/usr/lib/python3/dist-packages/vdirsyncer/cli/utils.py", line
364, in join
debug: with ui_worker.patch_click():
debug: File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug: File "/usr/lib/python3/dist-packages/click_threading/__init__.py",
line 144, in patch_click
debug: with patch_ui_functions(wrapper):
debug: File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug: File "/usr/lib/python3/dist-packages/click_threading/monkey.py", line
50, in patch_ui_functions
debug: stub_f = eval('lambda {s}: {n}._real_click_fn({a})'
Adding a few prints shows that it's trying do do an eval of the string:
lambda ) -> None: clear._real_click_fn() -> None)
This, unsurprisingly, does not work. I'm not sure what component has
changed in a way that breaks python3-click-threading, but the patching
seems pretty brittle.
-- System Information:
Versions of packages python3-click-threading depends on:
ii python33.9.7-1
ii python3-click 8.0.2-1
python3-click-threading recommends no packages.
python3-click-threading suggests no packages.
-- no debconf information
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Bug#1000187: [Pkg-auth-maintainers] Bug#1000187: yubikey-manager: Exception when trying to add an oath account
Hi Tobias, On Fri, Nov 19, 2021 at 11:51:46AM +, Tobias Bengfort wrote: > Package: yubikey-manager > Version: 4.0.0~a1-4 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > >$ ykman oath accounts add foo bar > > always results in > >AttributeError: 'OATH_TYPE' object has no attribute 'upper' Can you try again with yubikey-manager 4.0.7-1 (currently in unstable and testing)? I'm unable to reproduce your issue there, and seem to be able to successfully add an account, once I figured out a valid format for the secret: $ echo '123456' | base64 MTIzNDU2Cg== $ ykman oath accounts add foo 'MTIzNDU2Cg==' $ echo $? 0 $ ykman oath accounts list foo Florian
Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines
Hello folks, what's the status on this bug? I had zero time to work on cfengine3 and I'm going to orphan it, I see that there was an ITA but no upload, now Bastian has taken over the ITA, is there any plan here? Thanks!
Bug#1000398: fixed upstream
You don't even need to use std::valarray, a one-line testcase file with "#include " fails to compile in clang in C++17 mode or newer. A fix for this issue was committed to libstdc++ on Nov 5th: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b2d97fc545635a0f6aa9c9ee3b017394bc494bf Would it be possible to pick up that change? Nick
Bug#1000233: php-remctl lost its phpapi-20190902 dependency
Adrian Bunk writes:
> Package: php-remctl
> Version: 3.17-1
> Severity: serious
> Tags: bookworm sid
> After the src:remctl rebuild to add Python 3.10 as supported version,
> php-remctl lost its phpapi-20190902 dependency:
> Package: php-remctl
> Source: remctl
> Version: 3.17-1
> Installed-Size: 109
> Depends: php-common (>= 1:7.0+33~), phpapi-20190902, libc6 (>= 2.14),
> libremctl1 (>= 3.1)
> Package: php-remctl
> Source: remctl (3.17-1)
> Version: 3.17-1+b2
> Installed-Size: 106
> Depends: php-common (>= 1:7.0+33~), libc6 (>= 2.14), libremctl1 (>= 3.1)
This appears to be intentional in dh-php 4.2:
# Disable the dependency on the phpapi for the transition period
# $depends .= ", " . join(" | ", @api_versions);
PHP maintainers, do you have guidance on this? Should I be doing anything
as a package maintainer, or is this expected? Should it be a serious bug?
--
Russ Allbery (r...@debian.org)
Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config
Hi Helmut & Manuel, Is this package still failing to cross-build? Boyuan (CC'd) updated the packaging with the 1.8.0 upstream release. Regards, Harshula
Bug#958095: closed by Jerome BENOIT (reply to calcu...@rezozer.net) (Re: singular FTCBFS: gmp check doesn't work)
Control: fixed -1 1:4.2.1-p2+ds-1 On Thu, Nov 25, 2021 at 01:33:05PM +, Debian Bug Tracking System wrote: > I am now packaging the last version of the minor 2 series: > it appears that upstream substantially changed their m4/gmp-check.m4 . > Therefore your patch does not apply as-is any more. > This new version does not rely on AC_TRY_RUN but on AC_TRY_LINK . > > I assume that the new version fixes the issue. > So I am closing the bug. Please fix with a version next time. The bug appeared fixed in unstable, but it is not. Helmut
Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config
Control: tags -1 + pending Hi Harshula, On Sat, Nov 27, 2021 at 07:11:46PM +0100, Harshula wrote: > Is this package still failing to cross-build? Boyuan (CC'd) updated the > packaging with the 1.8.0 upstream release. Yes, but it'll be fixed in 10 days when my deferred NMU arrives in unstable. I've attached the final .debdiff. Helmut diff --minimal -Nru m17n-lib-1.8.0/debian/changelog m17n-lib-1.8.0/debian/changelog --- m17n-lib-1.8.0/debian/changelog 2021-10-12 20:17:41.0 +0200 +++ m17n-lib-1.8.0/debian/changelog 2021-11-28 05:58:00.0 +0100 @@ -1,3 +1,10 @@ +m17n-lib (1.8.0-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #842441) + + -- Helmut Grohne Sun, 28 Nov 2021 05:58:00 +0100 + m17n-lib (1.8.0-3) unstable; urgency=medium * Team upload. diff --minimal -Nru m17n-lib-1.8.0/debian/patches/0004-cross.patch m17n-lib-1.8.0/debian/patches/0004-cross.patch --- m17n-lib-1.8.0/debian/patches/0004-cross.patch 1970-01-01 01:00:00.0 +0100 +++ m17n-lib-1.8.0/debian/patches/0004-cross.patch 2021-11-28 05:58:00.0 +0100 @@ -0,0 +1,74 @@ +From: Helmut Grohne +Subject: use triplet-prefixed pkg-config + +Also prefer pkg-config over libotf-config, which is not cross-aware. + +--- a/configure.ac b/configure.ac +@@ -119,8 +119,8 @@ + + M17N_EXT_LIBS= + +-AC_CHECK_PROG(HAVE_PKG_CONFIG, pkg-config, yes) +-AM_CONDITIONAL([HAVE_PKG_CONFIG], [test x$HAVE_PKG_CONFIG = xyes]) ++PKG_PROG_PKG_CONFIG ++AM_CONDITIONAL([HAVE_PKG_CONFIG], [test "x$PKG_CONFIG" != x]) + + if test "x$no_x" != "xyes"; then + AC_DEFINE(HAVE_X11, 1, [Define to 1 if you have X11.]) +@@ -169,16 +169,15 @@ + if test "x$with_libotf" != "xno"; then + save_CPPFLAGS="$CPPFLAGS" + save_LIBS="$LIBS" +- AC_CHECK_PROG(HAVE_OTFLIB_CONFIG, libotf-config, yes) +- OTF_LD_FLAGS=-lotf +- if test "x$HAVE_OTFLIB_CONFIG" = "xyes"; then +-CPPFLAGS="$CPPFLAGS `libotf-config --cflags`" +-OTF_LD_FLAGS="`libotf-config --libs`" +-LIBS="$LIBS $OTF_LD_FLAGS" +- elif test "x$HAVE_PKG_CONFIG" = "xyes" ; then +-if pkg-config libotf ; then +- CPPFLAGS="$CPPFLAGS `pkg-config --cflags libotf`" +- OTF_LD_FLAGS="`pkg-config --libs libotf`" ++ if test "x$PKG_CONFIG" != x && $PKG_CONFIG libotf; then ++CPPFLAGS="$CPPFLAGS `$PKG_CONFIG --cflags libotf`" ++OTF_LD_FLAGS="`$PKG_CONFIG --libs libotf`" ++ else ++AC_CHECK_PROG(HAVE_OTFLIB_CONFIG, libotf-config, yes) ++if test "x$HAVE_OTFLIB_CONFIG" = "xyes"; then ++ CPPFLAGS="$CPPFLAGS `libotf-config --cflags`" ++ OTF_LD_FLAGS="`libotf-config --libs`" ++ LIBS="$LIBS $OTF_LD_FLAGS" + fi + fi + ## We check the availability of OTF_check_features +@@ -233,10 +232,10 @@ + if test "x$HAVE_XFT_CONFIG" = "xyes"; then + CPPFLAGS="$CPPFLAGS `xft-config --cflags`" + XFT2_LD_FLAGS="`xft-config --libs`" +-elif test "x$HAVE_PKG_CONFIG" = "xyes" ; then +- if pkg-config xft ; then +-CPPFLAGS="$CPPFLAGS `pkg-config --cflags xft`" +-XFT2_LD_FLAGS="`pkg-config --libs xft`" ++elif test "x$PKG_CONFIG" != "x" ; then ++ if $PKG_CONFIG xft ; then ++CPPFLAGS="$CPPFLAGS `$PKG_CONFIG --cflags xft`" ++XFT2_LD_FLAGS="`$PKG_CONFIG --libs xft`" + fi + fi + LIBS="$LIBS $XFT2_LD_FLAGS" +@@ -265,10 +264,10 @@ + save_CPPFLAGS="$CPPFLAGS" + save_LIBS="$LIBS" + FONTCONFIG_LD_FLAGS=-lfontconfig +- if test "x$HAVE_PKG_CONFIG" = "xyes"; then +-if pkg-config --exists fontconfig; then +- CPPFLAGS="$CPPFLAGS `pkg-config --cflags fontconfig`" +- FONTCONFIG_LD_FLAGS="`pkg-config --libs fontconfig`" ++ if test "x$PKG_CONFIG" != "x"; then ++if $PKG_CONFIG --exists fontconfig; then ++ CPPFLAGS="$CPPFLAGS `$PKG_CONFIG --cflags fontconfig`" ++ FONTCONFIG_LD_FLAGS="`$PKG_CONFIG --libs fontconfig`" + LIBS="$LIBS $FONTCONFIG_LD_FLAGS" + fi + fi diff --minimal -Nru m17n-lib-1.8.0/debian/patches/series m17n-lib-1.8.0/debian/patches/series --- m17n-lib-1.8.0/debian/patches/series2021-10-12 20:12:04.0 +0200 +++ m17n-lib-1.8.0/debian/patches/series2021-11-28 05:57:33.0 +0100 @@ -1,3 +1,4 @@ 0001-m17n-config-remove-libtool-user-switches.patch 0002-m17n-config-modify-to-support-multi-arch.patch 0003-configure.ac-Use-pkg-config-to-detect-libfreetype2.patch +0004-cross.patch
Bug#1000731: Program fails to start
Package: nautilus-scripts-manager
Version: 2.0-1.1
Severity: important
X-Debbugs-Cc: Pietro Battiston , Piotr Ożarowski
, Ondřej Nový
Hi,
As I try to start nautilus-scripts-manager, it doesn't start
$ nautilus-scripts-manager
/usr/bin/nautilus-scripts-manager:21: PyGIWarning: Pango was imported without
specifying a version first. Use gi.require_version('Pango', '1.0') before
import to ensure that the right version gets loaded.
from gi.repository import Pango, Gtk, GLib
/usr/bin/nautilus-scripts-manager:21: PyGIWarning: Gtk was imported without
specifying a version first. Use gi.require_version('Gtk', '4.0') before import
to ensure that the right version gets loaded.
from gi.repository import Pango, Gtk, GLib
Traceback (most recent call last):
File "/usr/bin/nautilus-scripts-manager", line 97, in
s = Gdk.Screen.get_default()
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 32, in
__getattr__
return getattr(self._introspection_module, name)
File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in __getattr__
raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Gdk' object has no attribute 'Screen'
This package is not usable for the main purpose via GUI. (If we were
to use command-line, we can do it via "ln -s" anyway. I suppose those
CLI are there for test purpose.)
I found a salsa repository which seems to be most current and updated
some there.
https://salsa.debian.org/debian/nautilus-scripts-manager
After making some housekeeping and a few commits, I realized the
nautilus script itself can be created and used independent of this
package and there is no Debian package using this program to manage
their nautilus scripts any more for user.
There is a nice tutorial NautilusScriptsHowto which let us use nautilus
script itself without this package.
https://help.ubuntu.com/community/NautilusScriptsHowto
So I decided to stop. What is the point of keeping this package?
I am CCing git committers of this package.
If anyone is interested to keep this package, please update salsa repo
and make upload. The last commit by the upstream seems to be 2014.
If no one respond in few months, we should remove this from the next
release.
Regards,
Osamu
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-1-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nautilus-scripts-manager depends on:
ii nautilus41.1-1
ii python3 3.9.7-1
ii python3-gi 3.42.0-2+b1
nautilus-scripts-manager recommends no packages.
nautilus-scripts-manager suggests no packages.
-- no debconf information
Bug#1000680: python3-aiohttp: fails to import, "TypeError: function() argument 'code' must be code, not str"
> root@zion:/# python3.9 -c "import aiohttp" > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/aiohttp/__init__.py", line 6, in > > from .client import ( > File "/usr/lib/python3/dist-packages/aiohttp/client.py", line 35, in > > from . import hdrs, http, payload > File "/usr/lib/python3/dist-packages/aiohttp/http.py", line 7, in > from .http_parser import ( > File "/usr/lib/python3/dist-packages/aiohttp/http_parser.py", line 15, in > > from .helpers import NO_EXTENSIONS, BaseTimerContext > File "/usr/lib/python3/dist-packages/aiohttp/helpers.py", line 667, in > > class CeilTimeout(async_timeout.timeout): > TypeError: function() argument 'code' must be code, not str > > > root@zion:/# python3.10 -c "import aiohttp" > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/aiohttp/__init__.py", line 6, in > > from .client import ( > File "/usr/lib/python3/dist-packages/aiohttp/client.py", line 35, in > > from . import hdrs, http, payload > File "/usr/lib/python3/dist-packages/aiohttp/http.py", line 7, in > from .http_parser import ( > File "/usr/lib/python3/dist-packages/aiohttp/http_parser.py", line 15, in > > from .helpers import NO_EXTENSIONS, BaseTimerContext > File "/usr/lib/python3/dist-packages/aiohttp/helpers.py", line 667, in > > class CeilTimeout(async_timeout.timeout): > TypeError: function() argument 'code' must be code, not str Boyuan, you caused this by uploading python-async-timeout 4.x https://tracker.debian.org/news/1280914/accepted-python-async-timeout-401-1-source-into-unstable/ while aiohttp is incompatible with it. Apparently the latest version of aiohttp supports async-timeout > 4.0 https://github.com/aio-libs/aiohttp/blob/v3.8.1/setup.cfg#L54 are you going to handle this upgrade?
Bug#996294: Change in webrick 1.7.0 is causing a problem with the tests in Ruby 2.7 (at least)
I did some debugging on the issue reported that the tests fail after adding
ruby-webrick 1.7.0 to b-d for Ruby 3.0.
The problem is in parse_header() (lib/httpclient/session.rb) in the line
828 line = socket.gets("\n")
With webrick 1.7.0 it stalls here. This is caused by this small change in
webrick:
https://github.com/ruby/webrick/commit/069e9b1908aad3a30a0dcf67b6d3bb13c3216d2c
If I revert this, the tests no longer timeout and succeed under Ruby 2.7.
Regards, Daniel
--
Regards,
Daniel Leidert | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78
https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert
signature.asc
Description: This is a digitally signed message part
Bug#1000725: [Pkg-javascript-devel] Bug#1000725: Please ship TypeScript definitions
Control: fixed -1 17.0.1+dfsg+~cs102.92.74-1 Le 27/11/2021 à 23:03, Julien Puydt a écrit : > Package: node-react > Version: 17.0.2+dfsg+~cs106.66.56-1 > Severity: wishlist > > Please ship TypeScript definitions, as they're needed on the way to > jupyterlab -- especially for react and react-dom as far as I can tell. > > Cheers, > > J.Puydt Please stop opening such issues, verify before if @types/foo is really missing
Bug#1000730: Merge conflict marker left in Debian changelog
Package: libreoffice Version: 1:7.2.3-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org The Debian changelog for libreoffice contains what looks like a merge conflict marker around the entry for 1:7.3.0~alpha1-2: libreoffice (1:7.3.0~alpha1-2) experimental; urgency=medium * debian/rules: - use --without-cppunit in build-indep - use clang 12 on ppc64el (if building with LTO at least) - fix autopkgtest builds; explicitely set PACKAGE_SDK_DOCS=n -- Rene Engelhard Sun, 31 Oct 2021 09:25:30 +0100 >>> efaacb77 (actually only set TEST_TIMEOUT if we ignore the test results >>> anyway...) * debian/control*.in: also apply 1:7.2.1-2/-3 changes for libreoffice-core-nogui... -- Rene Engelhard Thu, 18 Nov 2021 18:50:36 +0100 libreoffice (1:7.2.2-1) unstable; urgency=medium
Bug#1000723: [Pkg-javascript-devel] Bug#1000723: Please ship TypeScript definitions
Control: fixed -1 0.8.0+ds+repack-1 Le 27/11/2021 à 22:53, Julien Puydt a écrit : > Package: node-marked > Version: 0.8.0+ds+repack-3 > Severity: minor > > Please ship the TypeScript definitions ; they're needed on the way to > jupyterlab. > > Cheers, > > J.Puydt One more noise-issue
Bug#1000729: ruby-hamster FTBFS caused by ruby-rbtree and ruby-sorted-set
Source: ruby-sorted-set Version: 1.0.3-2 Severity: serious User: debian-r...@lists.debian.org Usertags: ruby3.0 Tags: help After doing some debugging on the ruby-hamster FTBFS, the problem seems to be ruby-btree and ruby-sorted-set breaking the tests. In a pure Ruby 2.7 environment, this is true: SortedSet.new([1,3,2]).eql?(SortedSet.new([1,2,3])) => true Installing ruby-rbtree, and the same matcher becomes false: SortedSet.new([1,3,2]).eql?(SortedSet.new([1,2,3])) => false Now adding ruby-sorted-set in the mix for the Ruby3.0 transition, which depends on ruby-rbtree, more tests fail. This is causing ruby-hamster's tests to fail. This bug report is to indicate that this blocks the ruby-hamster fix. Regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready
On Sat, Nov 27, 2021 at 09:29:24AM +0100, Marc Haber wrote: > On Fri, Nov 26, 2021 at 07:57:37PM -0600, Corey Minyard wrote: > > If this is what I think it is, this is a common issue on systems at > > boot; ser2net is started before networking is enabled. Some sort of > > dependencies need to be added to the ser2net systemd code, though I'm > > not sure what. > > I am not sure about that, it is probably a combination of > > [Unit] > After=network-online.target > Wants=network-online.target > > https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ gives > some explanation about what systemd thinks what a "modern" service > should do. I have not yet seen a service that does it "right" the way > systemd thinks the world should be. > > I also know that there is a TCP socket option that allows a service to > bind to an IP address before the address is configured. Otoh, ser2net > listens on :: which should always be available. > > What also bothers me is the error message > > ser2net[625]: Invalid port name/number: Invalid data to parameter on > line 30 column 0 > > since it might refer to a serial port as well as to a TCP port. I guess > this misled me to ser2net complaining about the /dev/ttyAMA0 not > appearing in time. Yes, that is an issue; I have made the error message precise. > > Additionally, the ser2net.yml quoted by the original bug reporter in the > original bug report does not seem to have 30 lines. This is all very > strange for me. Also an issue. This error means that gensio was unable to parse an accepter line. On line 30. I woud guess there is something incorrect on line 30 in an accepter: . -corey
Bug#721192: ITP: apostrophe -- a simple markdown editor
retitle 721192 RFP: apostrophe -- a simple markdown editor nowner 721192 thanks With upstream response and issue resolution as it seems to be, I'm no longer interested in maintaining this package, and one shouldn't upload something that one doesn't want to maintain. Feel free to contact me for my WIP packaging if you'd like to pick up the effort. In particular, the copyright review revealed some DFSG irregularities. Regards, Nicholas signature.asc Description: PGP signature
Bug#997208: firmware-microbit-micropython: FTBFS: platform.h:25:10: fatal error: cstddef: No such file or directory
Control: severity 998365 serious Control: close 997208 On Sun, Oct 24, 2021 at 12:48:33PM +0200, Ondřej Kuzník wrote: > On Sat, Oct 23, 2021 at 09:11:58PM +0200, Lucas Nussbaum wrote: > > Source: firmware-microbit-micropython > > Version: 1.0.1-2 > > Severity: serious > > Justification: FTBFS > > Tags: bookworm sid ftbfs > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build > > on amd64. > > > > > > Relevant part (hopefully): > >> In file included from > >> /<>/yotta_modules/mbed-classic/api/Ethernet.h:19, > >> from > >> /<>/yotta_modules/mbed-classic/common/Ethernet.cpp:16: > >> /<>/yotta_modules/mbed-classic/api/platform.h:25:10: fatal > >> error: cstddef: No such file or directory > >>25 | #include > >> | ^ > >> compilation terminated. > > On my bookworm system this is caused by the ARM toolchain being out of > sync in the archive, sid/testing have: > - gcc-arm-none-eabi 10.3 (15:10.3-2021.07-1) > - libstdc++-arm-none-eabi from gcc 8 (15:8-2019-q3-1+13) > > Where bullseye has both at 15:8-2019-q3-1+13 (and 15:8-2019-q3-1+b1). > > In essence this is #953420 with different version combinations. I think > the first step would be to mark gcc builds with Breaks for the older > libstdc++ and vice versa. Or, if possible, submit them in lockstep. This is #998365, so the problem has to be fixed there. > Regards, > Ondrej cu Adrian
Bug#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Quoting Hilmar Preusse (2021-11-27 21:06:10) > Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704737 > > On 27.11.21 Jonas Smedegaard (jo...@jones.dk) wrote: > > Hi, > > > Packaging changes is unlikely to affect this, so it is therefore > > better to report it upstream. I can do that, but better if you do > > this as you are in a better position to answer eventual followup > > questions related to asymptote as producer for that sample EPS > > file. > > > > Upstream bugtracker is here: https://bugs.ghostscript.com/ > > > Funny: I have already an account there. Submitted. Excellent. Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1000728: RFP: blueprintjs -- react-based toolkit for the Web
Package: wnpp Severity: minor X-Debbugs-CC: Debian Javascript Maintainers Package name: blueprintjs Version : 3.38.0 Upstream Author : Palantir Technologies URL : https://blueprintjs.com/ License : Apache-2.0 Programming Lang: JavaScript Description : react-based toolkit for the Web Blueprint is a React-based UI toolkit for the web. . It is optimized for building complex, data-dense web interfaces for desktop applications running in modern browsers. It is a dependency on the path to jupyterlab. Cheers, J.Puydt
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
❦ 27 November 2021 17:43 GMT, Adam D. Barratt:
>> > Package: release.debian.org
>> > Severity: normal
>> > Tags: bullseye
>> > User: release.debian@packages.debian.org
>> > Usertags: pu
>> [...]
>>
>> I did the upload to bullseye as I think the change is not
>> controversial.
>
> What you've uploaded to bullseye is *not* what you proposed in this
> request, however.
>
> The debdiff attached to this bug report amounts to "4 files changed,
> 130 insertions(+)", the uploaded package is "39 files changed, 561
> insertions(+), 221 deletions(-)" and includes a new upstream release.
Ugh. Very sorry about that!
Here is the appropriate diff. How can I sort out my bad upload? Bumping
the version number? I hold uploading anything else until you approve.
>From a5a413c1f44bb0a063fc9ca4cf56ae7137f53f3d Mon Sep 17 00:00:00 2001
From: Vincent Bernat
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye
---
debian/changelog | 8 ++
...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
...-overflow-when-reading-SONMP-packets.patch | 93 +++
debian/patches/series | 2 +
4 files changed, 130 insertions(+)
create mode 100644 debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
create mode 100644 debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
diff --git a/debian/changelog b/debian/changelog
index 4fc8b730cc52..6da569249198 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.11-1+deb11u1) bullseye; urgency=high
+
+ * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+ * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat Sat, 27 Nov 2021 23:30:43 +0100
+
lldpd (1.0.11-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++ b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+ port->p_disable_rx = port->p_disable_tx = 1;
+ break;
+ }
+- if (set->vlan_tx_enabled >= -1) {
++ if (set->vlan_tx_enabled > -1) {
+ port->p_vlan_tx_enabled = set->vlan_tx_enabled;
+ port->p_vlan_tx_tag = set->vlan_tx_tag;
+ }
+--
+2.33.1
+
diff --git a/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch b/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
new file mode 100644
index ..c06689987c34
--- /dev/null
+++ b/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
@@ -0,0 +1,93 @@
+From 73d42680fce8598324364dbb31b9bc3b8320adf7 Mon Sep 17 00:00:00 2001
+From: Vincent Bernat
+Date: Sun, 19 Sep 2021 21:18:47 +0200
+Subject: [PATCH] sonmp: fix heap overflow when reading SONMP packets
+
+By sending short SONMP packets, an attacker can make the decoder crash
+by reading too much data on the heap. SONMP packets are fixed in size,
+just ensure we get the enough bytes to contain a SONMP packet.
+
+CVE-2021-43612
+---
+ NEWS | 2 ++
+ src/daemon/protocols/sonmp.c | 2 +-
+ src/daemon/protocols/sonmp.h | 2 +-
+ tests/check_sonmp.c | 10 +-
+ 4 files changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/src/daemon/protocols/sonmp.c b/src/daemon/protocols/sonmp.c
+index 41dcf6aa412d..f8f12469e28a 100644
+--- a/src/daemon/protocols/sonmp.c
b/src/daemon/protocols/sonmp.c
+@@ -311,7 +311,7 @@ sonmp_decode(struct lldpd *cfg, char *frame, int s,
+
+ length = s;
+ pos = (u_int8_t*)frame;
+- if (length < SONMP_SIZE) {
++ if (length < SONMP_SIZE + 2*ETHER_ADDR_LEN + sizeof(u_int16_t)) {
+ log_warnx("sonmp", "too short SONMP frame received on %s", hardware->h_ifname);
+ goto malformed;
+ }
+diff --git a/src/daemon/protocols/sonmp.h b/src/daemon/protocols/sonmp.h
+index 0e60106dae63..ff7a720f0b5d 100644
+--- a/src/daemon/protocols/sonmp.h
b/src/daemon/protocols/sonmp.h
+@@ -24,7 +24,7 @@
+ #define LLC_ORG_NORTEL { 0x00, 0x00, 0x81 }
+ #define LLC_PID_SONMP_HELLO 0x01a2
+ #define LLC_PID_SONMP_FLATNET 0x01a1
+-#define SONMP_SIZE (2*ETHER_ADDR_LEN + sizeof(u_int16_t)
Bug#998853: obs-frontend-api.h: fatal error: {obs,util/darray}.h: No such file or directory
Control: reassign -1 obs-move-transition 2.5.1-2 On 2021-11-27 23:12:58 +0100, Sebastian Ramacher wrote: > On 2021-11-27 17:17:56 -0300, Eriberto wrote: > > Em seg., 22 de nov. de 2021 às 20:02, Sebastian Ramacher > > escreveu: > > > > > > Control: tags -1 moreinfo > > > > > > On 2021-11-08 17:23:01 -0300, Joao Eriberto Mota Filho wrote: > > > > Package: libobs-dev > > > > Version: 26.1.2+dfsg1-2 > > > > Severity: important > > > > Tags: patch > > > > Control: affects -1 obs-move-transition > > > > > > > > Dear maintainer, > > > > > > > > In last weekend obs-move-transition[1] arrived to Debian. > > > > obs-move-transition > > > > is the most rated plugin for obs-studio. > > > > > > > > [1] https://tracker.debian.org/pkg/obs-move-transition > > > > > > > > obs-move-transition depends of the libobs-dev. When packaging this > > > > plugin, I > > > > got the following errors: > > > > > > > > In file included from > > > > /PKGS/obs-move-transition-2.5.1/move-source-filter.c:2: > > > > /usr/include/obs/obs-frontend-api.h:3:10: fatal error: obs.h: No such > > > > file or directory > > > > 3 | #include > > > >| ^~~ > > > > > > > > In file included from > > > > /PKGS/obs-move-transition-2.5.1/move-transition.c:3: > > > > /usr/include/obs/obs-frontend-api.h:4:10: fatal error: util/darray.h: > > > > No such file or directory > > > > 4 | #include > > > >| ^~~ > > > > > > > > To allow the plugin to build correctly, I created a 'fixed copy' of the > > > > /usr/include/obs/obs-frontend-api.h inside of > > > > obs-move-transition-2.5.1. > > > > > > > > On Debian, the libobs-dev put the headers in /usr/include/obs/ but the > > > > current > > > > /usr/include/obs/obs-frontend-api.h expects to find for these files in > > > > /usr/include/. However, when building obs-studio, the source code > > > > searches for > > > > the headers also in /usr/include/. Consequently, making a patch for > > > > obs-frontend-api.h to search for headers in /usr/include/obs/ will > > > > generate a > > > > FTBFS. IMO, the right way is changing the obs-frontend-api.h after the > > > > obs-studio build process. The attached patch will fix this issue. I > > > > also sent > > > > an MR to Salsa [2] to make to make easier the fix. > > > > > > In the cmake config installed by libobs-dev, the include dir is > > > specified as /usr/include/obs. Why is obs-move-transition ignoring this > > > bit? > > > > Hi Sebastian, > > > > The /usr/include/obs/obs-frontend-api.h is part of the obs-studio, not > > obs-move-transition. Thus, the obs-studio package has an internal file > > (obs-frontend-api.h) pointing to a wrong path. The problem is not in > > obs-move-transition. > > > > In other words, obs-move-transition is not ignoring the cmake config > > installed by libobs-dev. Let me know how to help you. I think my MR #5 > > will solve this issue. > > Let me reprhase that: the cmake config of obs-studio tells users to set > -I/usr/include/obs which makes #include and #include > work. Why is obs-move-transition not picking this up? I just checked obs-move-transition's CMakeLists.txt. It's missing the equivalent of a find_package(libobs REQUIRED) and then setting up the include directories. This is a bug in obs-move-transition. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#998853: obs-frontend-api.h: fatal error: {obs,util/darray}.h: No such file or directory
On 2021-11-27 17:17:56 -0300, Eriberto wrote: > Em seg., 22 de nov. de 2021 às 20:02, Sebastian Ramacher > escreveu: > > > > Control: tags -1 moreinfo > > > > On 2021-11-08 17:23:01 -0300, Joao Eriberto Mota Filho wrote: > > > Package: libobs-dev > > > Version: 26.1.2+dfsg1-2 > > > Severity: important > > > Tags: patch > > > Control: affects -1 obs-move-transition > > > > > > Dear maintainer, > > > > > > In last weekend obs-move-transition[1] arrived to Debian. > > > obs-move-transition > > > is the most rated plugin for obs-studio. > > > > > > [1] https://tracker.debian.org/pkg/obs-move-transition > > > > > > obs-move-transition depends of the libobs-dev. When packaging this > > > plugin, I > > > got the following errors: > > > > > > In file included from > > > /PKGS/obs-move-transition-2.5.1/move-source-filter.c:2: > > > /usr/include/obs/obs-frontend-api.h:3:10: fatal error: obs.h: No such > > > file or directory > > > 3 | #include > > >| ^~~ > > > > > > In file included from > > > /PKGS/obs-move-transition-2.5.1/move-transition.c:3: > > > /usr/include/obs/obs-frontend-api.h:4:10: fatal error: util/darray.h: No > > > such file or directory > > > 4 | #include > > >| ^~~ > > > > > > To allow the plugin to build correctly, I created a 'fixed copy' of the > > > /usr/include/obs/obs-frontend-api.h inside of > > > obs-move-transition-2.5.1. > > > > > > On Debian, the libobs-dev put the headers in /usr/include/obs/ but the > > > current > > > /usr/include/obs/obs-frontend-api.h expects to find for these files in > > > /usr/include/. However, when building obs-studio, the source code > > > searches for > > > the headers also in /usr/include/. Consequently, making a patch for > > > obs-frontend-api.h to search for headers in /usr/include/obs/ will > > > generate a > > > FTBFS. IMO, the right way is changing the obs-frontend-api.h after the > > > obs-studio build process. The attached patch will fix this issue. I also > > > sent > > > an MR to Salsa [2] to make to make easier the fix. > > > > In the cmake config installed by libobs-dev, the include dir is > > specified as /usr/include/obs. Why is obs-move-transition ignoring this > > bit? > > Hi Sebastian, > > The /usr/include/obs/obs-frontend-api.h is part of the obs-studio, not > obs-move-transition. Thus, the obs-studio package has an internal file > (obs-frontend-api.h) pointing to a wrong path. The problem is not in > obs-move-transition. > > In other words, obs-move-transition is not ignoring the cmake config > installed by libobs-dev. Let me know how to help you. I think my MR #5 > will solve this issue. Let me reprhase that: the cmake config of obs-studio tells users to set -I/usr/include/obs which makes #include and #include work. Why is obs-move-transition not picking this up? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#519198: [Pkg-xfce-devel] Bug#519198: xfce4-terminal: Window title bar and borders are present, but invisible
Same bug appears present in Debian 11 Stable (using nvidia non-free drivers on mine, but identical issue. Under window manager tweaks, compositor is not greyed out on mine either. I did notice "Opacity of window decorations" slider is defaulted to transparent. Sliding it to opaque fixed the problem. So somewhere in XFCE Tweaks, or compositor default opacity could just use set differently. Hope this helps. endoublessj
Bug#1000725: Please ship TypeScript definitions
Package: node-react Version: 17.0.2+dfsg+~cs106.66.56-1 Severity: wishlist Please ship TypeScript definitions, as they're needed on the way to jupyterlab -- especially for react and react-dom as far as I can tell. Cheers, J.Puydt
Bug#1000723: Please ship TypeScript definitions
Package: node-marked Version: 0.8.0+ds+repack-3 Severity: minor Please ship the TypeScript definitions ; they're needed on the way to jupyterlab. Cheers, J.Puydt
Bug#1000722: Please ship TypeScript definitions
Package: node-lodash Version: 4.17.21+dfsg+~cs8.31.196.20210220-2 Severity: minor Please ship TypeScript definitions, in particular for lodash.escape, as I'm finding I need them on the way to jupyterlab. Cheers, J.Puydt
Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1
I guess so, I have both pipewire and pipewire-pulse in the output of ps Altgough I have no idea what that is for Il lun 22 nov 2021, 11:50 Sebastian Ramacher ha scritto: > Control: tags -1 moreinfo > > On 2021-11-21 00:55:50, Arnaldo Pirrone wrote: > > Package: jackd2 > > Version: 1.9.19~dfsg-2 > > Severity: grave > > X-Debbugs-Cc: it9...@gmail.com > > > > Apparently there is something wrong with Jack and dbus. > > Also reported here: > > > https://www.reddit.com/r/linuxaudio/comments/qtmynn/problems_starting_jackd_method_requestrelease_is/ > > Find below the jack server logs. > > > > 00:41:32.228 Resetta le statistiche. > > 00:41:32.269 Connessioni di ALSA cambiate. > > 00:41:32.389 D-BUS: Servizio disponibile (org.jackaudio.service aka > jackdbus). > > Cannot connect to server socket err = File o directory non esistente > > Cannot connect to server request channel > > jack server is not running or cannot be started > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping > > unlock > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping > > unlock > > 00:41:32.563 Cambiamento nel grafico delle connessioni di ALSA. > > 00:41:47.432 D-BUS: il server JACK non può essere avviato. Mi dispiace > > Sun Nov 21 00:41:47 2021: Starting jack server... > > Sun Nov 21 00:41:47 2021: JACK server starting in realtime mode with > priority > > 10 > > Sun Nov 21 00:41:47 2021: self-connect-mode is "Don't restrict self > connect > > requests" > > Cannot connect to server socket err = File o directory non esistente > > Cannot connect to server request channel > > jack server is not running or cannot be started > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping > > unlock > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping > > unlock > > Sun Nov 21 00:41:47 2021: Device reservation request with priority > 2147483647 > > denied for "Audio1": org.freedesktop.DBus.Error.UnknownMethod (Method > > RequestRelease is not implemented on interface > org.freedesktop.ReserveDevice1) > > Sun Nov 21 00:41:47 2021: ERROR: Failed to acquire device name : Audio1 > error : > > Method RequestRelease is not implemented on interface > > org.freedesktop.ReserveDevice1 > > Sun Nov 21 00:41:47 2021: ERROR: Audio device hw:PCH,0 cannot be > acquired... > > Sun Nov 21 00:41:47 2021: ERROR: Cannot initialize driver > > Sun Nov 21 00:41:47 2021: ERROR: JackServer::Open failed with -1 > > Sun Nov 21 00:41:47 2021: ERROR: Failed to open server > > Sun Nov 21 00:41:48 2021: Saving settings to > > "/home/it9exm/.config/jack/conf.xml" ... > > 00:41:49.469 Non sono riuscito ad avviare JACK come client. - Operazione > > fallita. - Impossibile connettersi al server JACK. Controlla la finestra > dei > > messaggi per maggiori informazioni. > > Cannot connect to server socket err = File o directory non esistente > > Cannot connect to server request channel > > jack server is not running or cannot be started > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping > > unlock > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping > > unlock > > Unfortunately I'm not able to reprodue this issue. Are you running > pipewire by any chance? > > Best > Sebastian > > > > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.14.19-xanmod1 (SMP w/4 CPU threads) > > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE > not set > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages jackd2 depends on: > > ii debconf [debconf-2.0] 1.5.79 > > ii libasound2 1.2.5.1-1 > > ii libc6 2.32-4 > > ii libdbus-1-31.12.20-3 > > ii libexpat1 2.4.1-3 > > ii libgcc-s1 11.2.0-10 > > ii libjack-jackd2-0 1.9.19~dfsg-2 > > ii libreadline8 8.1-2 > > ii libsamplerate0 0.2.2-1 > > ii libsndfile11.0.31-2 > > ii libstdc++6 11.2.0-10 > > ii libsystemd0249.6-2 > > ii libzita-alsa-pcmi0 0.3.2-2 > > ii libzita-resampler1 1.8.0-2 > > ii python33.9.8-1 > > ii python3-dbus 1.2.18-3 > > > > Versions of packages jackd2 recommends: > > ii jackd2-firewire 1.9.19~dfsg-2 > > ii libpam-modules 1.4.0-10 > > ii qjackctl 0.9.5-1 > > > > Versions of packages jackd2 suggests: > > pn jack-tools > > pn meterbridge > > > > -- debconf information: > > * jackd/tweak_rt_limits: true > > -- > Sebastian Ramacher >
Bug#892664: dpkg: Please add decompression support for zstd
Package: dpkg Version: 1.20.9 Followup-For: Bug #892664 I'd also love to see zstd support in dpkg. I'm following several PPAs that offer daily builds and since ubuntu's migration to zstd-by-default I can no longer benefit from the pre-built packages. -- Package-specific info: System tainted due to merged-usr-via-aliased-dirs. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.33-0experimental2 ii liblzma5 5.2.5-2 ii libselinux1 3.3-1+b1 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.3.13 pn debsig-verify
Bug#994899: [Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Hi all, On 10/5/21 2:16 AM, Chuck Zmudzinski wrote: > On 10/4/2021 1:51 PM, Diederik de Haas wrote: >> On Monday, 4 October 2021 17:27:22 CEST Chuck Zmudzinski wrote: >>> I can confirm these 4 fix the bug on my hardware. >> \o/ >> Thanks for testing and reporting back :-) > > Thank you, Diederik, for your good work finding the commits > from upstream that fix the bug. And also thanks to you, Andy, > for helping fix this bug in the IRC and for your interest and > support of the Debian Xen Team's work. So, we're in the process of actually doing a package update now, which includes these fixes. I can confirm that my HP DL360 hardware at work also did not fully power off. And now, it does: >8 [ OK ] Reached target Late Shutdown Services. [ OK ] Finished System Power Off. [ OK ] Reached target System Power Off. [16302.044148] reboot: Power down (XEN) Disabling non-boot CPUs ... (XEN) Broke affinity for IRQ12, new: , (XEN) Broke affinity for IRQ1, new: , (XEN) Broke affinity for IRQ9, new: , (XEN) Broke affinity for IRQ16, new: , (XEN) Broke affinity for IRQ17, new: , (XEN) Broke affinity for IRQ99, new: , (XEN) Broke affinity for IRQ112, new: , (XEN) Broke affinity for IRQ113, new: , (XEN) Broke affinity for IRQ114, new: , (XEN) Broke affinity for IRQ115, new: , (XEN) Broke affinity for IRQ116, new: , (XEN) Broke affinity for IRQ117, new: , (XEN) Broke affinity for IRQ118, new: , (XEN) Broke affinity for IRQ119, new: , (XEN) Broke affinity for IRQ120, new: , (XEN) Broke affinity for IRQ121, new: , (XEN) Broke affinity for IRQ122, new: , (XEN) Broke affinity for IRQ123, new: , (XEN) Broke affinity for IRQ124, new: , (XEN) Broke affinity for IRQ125, new: , (XEN) Broke affinity for IRQ126, new: , (XEN) Broke affinity for IRQ127, new: , (XEN) Entering ACPI S5 state. The server is not powered on. The Virtual Serial Port is not available. >8 So, this one will get closed when we do the upload to unstable. Besides that, it will of course also be fixed in stable if we get the same thing into there in the next days. Hans
Bug#998853: obs-frontend-api.h: fatal error: {obs,util/darray}.h: No such file or directory
Em seg., 22 de nov. de 2021 às 20:02, Sebastian Ramacher escreveu: > > Control: tags -1 moreinfo > > On 2021-11-08 17:23:01 -0300, Joao Eriberto Mota Filho wrote: > > Package: libobs-dev > > Version: 26.1.2+dfsg1-2 > > Severity: important > > Tags: patch > > Control: affects -1 obs-move-transition > > > > Dear maintainer, > > > > In last weekend obs-move-transition[1] arrived to Debian. > > obs-move-transition > > is the most rated plugin for obs-studio. > > > > [1] https://tracker.debian.org/pkg/obs-move-transition > > > > obs-move-transition depends of the libobs-dev. When packaging this plugin, I > > got the following errors: > > > > In file included from > > /PKGS/obs-move-transition-2.5.1/move-source-filter.c:2: > > /usr/include/obs/obs-frontend-api.h:3:10: fatal error: obs.h: No such file > > or directory > > 3 | #include > >| ^~~ > > > > In file included from /PKGS/obs-move-transition-2.5.1/move-transition.c:3: > > /usr/include/obs/obs-frontend-api.h:4:10: fatal error: util/darray.h: No > > such file or directory > > 4 | #include > >| ^~~ > > > > To allow the plugin to build correctly, I created a 'fixed copy' of the > > /usr/include/obs/obs-frontend-api.h inside of > > obs-move-transition-2.5.1. > > > > On Debian, the libobs-dev put the headers in /usr/include/obs/ but the > > current > > /usr/include/obs/obs-frontend-api.h expects to find for these files in > > /usr/include/. However, when building obs-studio, the source code searches > > for > > the headers also in /usr/include/. Consequently, making a patch for > > obs-frontend-api.h to search for headers in /usr/include/obs/ will generate > > a > > FTBFS. IMO, the right way is changing the obs-frontend-api.h after the > > obs-studio build process. The attached patch will fix this issue. I also > > sent > > an MR to Salsa [2] to make to make easier the fix. > > In the cmake config installed by libobs-dev, the include dir is > specified as /usr/include/obs. Why is obs-move-transition ignoring this > bit? Hi Sebastian, The /usr/include/obs/obs-frontend-api.h is part of the obs-studio, not obs-move-transition. Thus, the obs-studio package has an internal file (obs-frontend-api.h) pointing to a wrong path. The problem is not in obs-move-transition. In other words, obs-move-transition is not ignoring the cmake config installed by libobs-dev. Let me know how to help you. I think my MR #5 will solve this issue. Regards, Eriberto
Bug#1000716: ponyorm 3.10 additional details
reassign 1000716 src:ponyorm rename 1000716 ponyorm: FTBFS on Python 3.10 thanks Oh well, it seems it does sys.exit(1) when trying to build the package, just not when running the testsuite by itself... I: pybuild base:237: python3.10 setup.py clean Sorry, but pony 0.7.14 requires Python of one of the following versions: 2.7, 3.3-3.9. You have version 3.10.0+ E: pybuild pybuild:354: clean: plugin distutils failed with: exit code=1: python3.10 setup.py clean -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704737 On 27.11.21 Jonas Smedegaard (jo...@jones.dk) wrote: Hi, > Packaging changes is unlikely to affect this, so it is therefore > better to report it upstream. I can do that, but better if you do > this as you are in a better position to answer eventual followup > questions related to asymptote as producer for that sample EPS > file. > > Upstream bugtracker is here: https://bugs.ghostscript.com/ > Funny: I have already an account there. Submitted. Hilmar -- sigmentation fault signature.asc Description: PGP signature
Bug#1000717: supysonic: FTBFS on Python 3.10
Source: supysonic Version: 0.6.2+ds-4 Severity: serious User: debian-pyt...@lists.debian.org Usertags: python3.10 supysonic FTBFS when using Python 3.10. This is caused by python3-pony not supporting Python 3.10 yet. === python3.10 === tests (unittest.loader._FailedTest) ... ERROR == ERROR: tests (unittest.loader._FailedTest) -- ImportError: Failed to import test module: tests Traceback (most recent call last): File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/tmp/autopkgtest-lxc.l2p5og5f/downtmp/autopkgtest_tmp/tests/__init__.py", line 11, in from . import base File "/tmp/autopkgtest-lxc.l2p5og5f/downtmp/autopkgtest_tmp/tests/base/__init__.py", line 10, in from .test_cli import CLITestCase File "/tmp/autopkgtest-lxc.l2p5og5f/downtmp/autopkgtest_tmp/tests/base/test_cli.py", line 14, in from pony.orm import db_session File "/usr/lib/python3/dist-packages/pony/orm/__init__.py", line 3, in from pony.orm.core import * File "/usr/lib/python3/dist-packages/pony/orm/core.py", line 18, in from pony.thirdparty.compiler import ast, parse File "/usr/lib/python3/dist-packages/pony/thirdparty/compiler/__init__.py", line 24, in from .transformer import parse, parseFile File "/usr/lib/python3/dist-packages/pony/thirdparty/compiler/transformer.py", line 32, in import parser ModuleNotFoundError: No module named 'parser' -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1000716: python3-pony: fails on Python 3.10 with "ModuleNotFoundError: No module named 'parser'"
Package: python3-pony Version: 0.7.14-1 Severity: serious User: debian-pyt...@lists.debian.org Usertags: python3.10 Hello, It seems the current version of ponyorm is broken on python3.10. If you look closely at the logs from the latest DebCI run [1], it outputs (without failing): > Sorry, but pony 0.7.14 requires Python of one of the following > versions: 2.7, 3.3-3.9. You have version 3.10.0+ Actually running pony on 3.10 outputs something like: == ERROR: tests (unittest.loader._FailedTest) -- ImportError: Failed to import test module: tests Traceback (most recent call last): File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/<>/tests/__init__.py", line 11, in from . import base File "/<>/tests/base/__init__.py", line 10, in from .test_cli import CLITestCase File "/<>/tests/base/test_cli.py", line 14, in from pony.orm import db_session File "/usr/lib/python3/dist-packages/pony/orm/__init__.py", line 3, in from pony.orm.core import * File "/usr/lib/python3/dist-packages/pony/orm/core.py", line 18, in from pony.thirdparty.compiler import ast, parse File "/usr/lib/python3/dist-packages/pony/thirdparty/compiler/__init__.py", line 24, in from .transformer import parse, parseFile File "/usr/lib/python3/dist-packages/pony/thirdparty/compiler/transformer.py", line 32, in import parser ModuleNotFoundError: No module named 'parser' This is because the parser module has been removed in Python 3.10 in favor of ast [2]. I'll suggest upstream to fail their testsuite when ran on Python 3.10. [1]: https://ci.debian.net/data/autopkgtest/unstable/amd64/p/ponyorm/17023056/log.gz [2]: https://docs.python.org/3/whatsnew/3.9.html#new-parser -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1000215: glusterfs: diff for NMU version 10.0-1.3
Control: tags 1000215 + patch Control: tags 1000215 + pending Dear maintainer, I've prepared an NMU for glusterfs (versioned as 10.0-1.3) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Cheers -- Sebastian Ramacher diff -Nru glusterfs-10.0/debian/changelog glusterfs-10.0/debian/changelog --- glusterfs-10.0/debian/changelog 2021-11-17 09:17:06.0 +0100 +++ glusterfs-10.0/debian/changelog 2021-11-27 19:20:47.0 +0100 @@ -1,3 +1,11 @@ +glusterfs (10.0-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: Set -DUATOMIC_NO_LINK_ERROR on armel, armhf and mipsel +(Closes: #1000215) (LP: #1951408) + + -- Sebastian Ramacher Sat, 27 Nov 2021 19:20:47 +0100 + glusterfs (10.0-1.2) unstable; urgency=medium * d/rules: disable tcmalloc also on x86 avoiding issues in tgt diff -Nru glusterfs-10.0/debian/rules glusterfs-10.0/debian/rules --- glusterfs-10.0/debian/rules 2021-11-17 09:17:06.0 +0100 +++ glusterfs-10.0/debian/rules 2021-11-27 19:17:52.0 +0100 @@ -1,7 +1,13 @@ #!/usr/bin/make -f +include /usr/share/dpkg/architecture.mk include /usr/share/dpkg/pkg-info.mk +# Fix build on these arches (LP: #1951408) (#1000215) +ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf mipsel)) +export DEB_CPPFLAGS_MAINT_APPEND = -DUATOMIC_NO_LINK_ERROR +endif + export DEB_BUILD_MAINT_OPTIONS = hardening=+all DEB_CONFIGURE_EXTRA_FLAGS := \ signature.asc Description: PGP signature
Bug#934602: simple-scan: Stretch to Buster: scanning no longer works
Hello, [...] > scanning works just fine, but only when > SANE doesn't insist on reporting my WiFi dongles as scanning devices The correct detection of a USB device is part of the kernel or task of a corresponding driver. Since scanning by simple-scan works, this is not a bug in simple-scan. Therefore I close this bug. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst 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#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Sat, Nov 27, 2021 at 05:47:45PM +, Adam D. Barratt wrote: > On Tue, 2021-11-23 at 15:20 -0500, Roberto C. Sanchez wrote: > > In preparing the rustc 1.51 upload/backport (to support backports of > > the > > latest firefox-esr and thunderbird packages) it has been suggested > > that > > to avoid some issues associated with providing a significant new > > version > > of rustc in the rustc binary package (along with the associated > > library > > packages), that I prepare the 1.51 rustc package with a different > > name. > > Following the model of what was done for gcc, nasm, and nodejs, I was > > considering source package rustc-mozilla with a single binary package > > (also rustc-mozilla) to ensure that rdeps don't end up getting > > surprised > > by a new rustc. Would this be considered acceptable for the bullseye > > and buster uploads of rustc 1.51? > > > > I think that sounds sensible, given that bullseye currently has 1.48 > (and buster 1.41). > > As a matter of interest, why was 1.51 the version chosen? I'm mostly > curious as that version is not currently in any suite in Debian. > Hi Adam, I had to make a minor tweak. The source package will still be rustc-mozilla. However, rather than consolidate to a single binary package (which proved to be infeasible for several reasons), I went ahead with simply renaming all the binary packages as either rust-mozilla-*, or rustc-mozilla-*, or librust-mozilla-*, and so on. I am assuming that this is also acceptable, but if it is not, please let me know. The choice of 1.51 was requested by Adrian Bunk, as rustc 1.51 is the (minimum?) version required by FireFox and ThunderBird 91. I will also file a separate bug for the buster-pu companion package. Regards, -Roberto -- Roberto C. Sánchez
Bug#1000255: mpv: autopkgtest failures
On 2021-11-23 15 h 22, Sebastian Ramacher wrote: > Control: reassign -1 src:python-mpv 0.5.2-1 > Control: forwarded -1 https://github.com/jaseg/python-mpv/issues/187 > > On 2021-11-21 23:21:24, Sebastian Ramacher wrote: >> Control: tags -1 help >> >> On 2021-11-20 09:34:37 +0100, Gianfranco Costamagna wrote: >>> Source: mpv >>> Version: 0.34.0-1 >>> Severity: serious >>> >>> >>> Hello, the last version 0.34.0 is regressed on arm64 armhf and probably >>> other architectures. >>> >>> Look, e.g. >>> https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-mpv/16812363/log.gz >>> >>> (Reading database ... 16518 files and directories currently installed.) >>> Removing autopkgtest-satdep (0) ... >>> autopkgtest [18:11:22]: test unittests: [--- >>> === python3.9 === >>> Segmentation fault >>> autopkgtest [18:11:43]: test unittests: ---] >>> autopkgtest [18:11:43]: test unittests: - - - - - - - - - - results - - - >>> - - - - - - - >>> unittestsFAIL non-zero exit status 139 >>> autopkgtest [18:11:43]: summary >>> unittestsFAIL non-zero exit status 139 >>> >>> I don't know which update triggered the regression, if the program itself >>> or something else in the toolchain. >>> >>> Can you please have a look? >>> >>> https://ci.debian.net/packages/p/python-mpv/testing/arm64/ >> >> The failing test is test_write. It crashes due to an infinte recursion >> in libx11-6's XPutImage which calls PutSubImage: >> >> #0 0xf4f3e31c in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:878 >> #1 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #2 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #3 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #4 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #5 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #6 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #7 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, >> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920 >> #8 0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, >> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, >> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, >> req_height=req_height@entry=1, >>
Bug#922789: simple-scan: Fails to scan. This was the debug message: [+11,17s] WARNING: scanner.vala:950: Unable to set single page source, please file a bug
Hello, no answer for more than 3 months. Closed. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst 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#1000715: dpkg -S fails to identify package for coreutils files: says 'no path found matching pattern' instead
Package: dpkg Version: 1.20.9 Distribution: Bookworm Architecture: AMD64 Relevant because this could have something to do with which utilities are statically linked to bash or exactly which coreutils we're talking about: bash is version 5.1-3.1 and coreutils is version 8.32-4.1 At the command line I type: >dpkg -S /usr/bin/cp I expect it to tell me coreutils: /usr/bin/cp instead, it falsely reports dpkg-query: no path found matching pattern /usr/bin/cp So I check some other things and find it working correctly. >dpkg -S /usr/bin/dpkg dpkg: /usr/bin/dpkg >dpkg -S /usr/bin/xz xz-utils: /usr/bin/xz >dpkg -S /usr/bin/yelp yelp: /usr/bin/yelp In fact it responds correctly to everything I've tried EXCEPT files installed by coreutils: >dpkg -S /usr/bin/cp dpkg-query: no path found matching pattern /usr/bin/cp >dpkg -S /usr/bin/ls dpkg-query: no path found matching pattern /usr/bin/ls >dpkg -S /usr/bin/rmdir dpkg-query: no path found matching pattern /usr/bin/rmdir >dpkg -S /usr/bin/mv dpkg-query: no path found matching pattern /usr/bin/mv >dpkg -S /usr/bin/grep dpkg-query: no path found matching pattern /usr/bin/grep But it's not entirely consistent. There are some coreutils files it identifies correctly: >dpkg -S /usr/bin/yes coreutils: /usr/bin/yes I don't know why this is happening. But I thought I should report it. Bear
Bug#1000690: Acknowledgement (cyrus-caldav: Web GUI URL responds with 204)
Sorry, I looked into the wrong documentation. The dokumentaion for 3.2 states: The Cyrus web GUI for CalDAV Collection Management is disabled by default, but can be enabled with the "caldav_allowcalendaradmin" option. This did it. Sincerely, Joachim
Bug#1000714: muparser: Please update to latest upstream version 2.3.2
Source: muparser Severity: minor Tags: patch If practical, please update muparser to the latest upstream version, 2.3.2. I've attached a patch that seems to work, and also updates debian/watch to *find* the new version. Fortunately, a nice easy update, and one that allows the previous patches to be dropped. I did not look into the dpkg-gensymbols problem that was reported earlier, though. Thank you! -- Nicholas Breen nbr...@debian.org diff --git a/debian/changelog b/debian/changelog index c48b85d..33a989b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +muparser (2.3.2-1) UNRELEASED; urgency=medium + + * New upstream release. + * Drop patches - no longer needed with upstream move to cmake. + * Update debian/watch and Homepage in debian/control. + + -- Nicholas Breen Sat, 27 Nov 2021 09:34:27 -0800 + muparser (2.2.6.1+dfsg-1) unstable; urgency=medium * Team upload. diff --git a/debian/control b/debian/control index f4f7491..8febf57 100644 --- a/debian/control +++ b/debian/control @@ -4,12 +4,12 @@ Uploaders: Gudjon I. Gudjonsson , Scott Howard Section: libs Priority: optional -Build-Depends: debhelper (>= 12~), - automake +Build-Depends: cmake, + debhelper (>= 12~) Standards-Version: 4.3.0 Vcs-Browser: https://salsa.debian.org/science-team/muparser Vcs-Git: https://salsa.debian.org/science-team/muparser.git -Homepage: http://muparser.sourceforge.net +Homepage: https://beltoforion.de/en/muparser/ Package: libmuparser-dev Architecture: any diff --git a/debian/copyright b/debian/copyright index 21065bb..11af306 100644 --- a/debian/copyright +++ b/debian/copyright @@ -2,12 +2,9 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: muparser Upstream-Contact: Ingo Berg Source: http://muparser.sourceforge.net -Files-Excluded: */*.dll -*/*.lib -*/vs Files: * -Copyright: 2004-2007 Ingo Berg +Copyright: 2004-2020 Ingo Berg License: Expat Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/debian/rules b/debian/rules index 20a3f85..43f6419 100755 --- a/debian/rules +++ b/debian/rules @@ -11,24 +11,6 @@ SAVE_FILES = configure %: dh $@ -override_dh_update_autotools_config: - # Save upstream configs - for f in $(SAVE_FILES) ; do \ - if [ ! -f $$f-orig ] ; then mv $$f $$f-orig ; fi \ - done - dh_update_autotools_config - bash build/autoconf/acregen.sh - -override_dh_auto_configure: - dh_auto_configure -- --disable-samples - -override_dh_clean: - dh_clean - # Restore upstream config - for f in $(SAVE_FILES) ; do\ - if [ -f $$f-orig ] ; then mv $$f-orig $$f ; fi \ -done - override_dh_makeshlibs: #pkgkde-symbols helper is managing the symbols file. #Sometimes we'll FTBFS on other arch's toolchains that export or miss diff --git a/debian/watch b/debian/watch index ac66e52..c869838 100644 --- a/debian/watch +++ b/debian/watch @@ -1,4 +1,4 @@ version=4 opts="repacksuffix=+dfsg,dversionmangle=auto,repack,compression=xz" \ - https://github.com/beltoforion/muparser/releases/latest .*/archive/v?@ANY_VERSION@@ARCHIVE_EXT@ + https://github.com/beltoforion/muparser/releases/latest .*/archive/refs/tags/v?@ANY_VERSION@@ARCHIVE_EXT@
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Tue, 2021-11-23 at 15:20 -0500, Roberto C. Sanchez wrote: > In preparing the rustc 1.51 upload/backport (to support backports of > the > latest firefox-esr and thunderbird packages) it has been suggested > that > to avoid some issues associated with providing a significant new > version > of rustc in the rustc binary package (along with the associated > library > packages), that I prepare the 1.51 rustc package with a different > name. > Following the model of what was done for gcc, nasm, and nodejs, I was > considering source package rustc-mozilla with a single binary package > (also rustc-mozilla) to ensure that rdeps don't end up getting > surprised > by a new rustc. Would this be considered acceptable for the bullseye > and buster uploads of rustc 1.51? > I think that sounds sensible, given that bullseye currently has 1.48 (and buster 1.41). As a matter of interest, why was 1.51 the version chosen? I'm mostly curious as that version is not currently in any suite in Debian. Regards, Adam
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
On Sat, 2021-11-27 at 15:49 +0100, Vincent Bernat wrote: > ❦ 14 November 2021 19:21 +01, Vincent Bernat: > > > Package: release.debian.org > > Severity: normal > > Tags: bullseye > > User: release.debian@packages.debian.org > > Usertags: pu > [...] > > I did the upload to bullseye as I think the change is not > controversial. What you've uploaded to bullseye is *not* what you proposed in this request, however. The debdiff attached to this bug report amounts to "4 files changed, 130 insertions(+)", the uploaded package is "39 files changed, 561 insertions(+), 221 deletions(-)" and includes a new upstream release. Regards, Adam
Bug#1000713: ocaml-ansi-terminal FTBFS on bytecode architectures
Source: ocaml-ansi-terminal Version: 0.8.3-1 Severity: important Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=ocaml-ansi-terminal=0.8.3-1 ... dh_missing -a dh_missing: warning: usr/lib/ocaml/ANSITerminal/libANSITerminal_stubs.a exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting ... make: *** [debian/rules:6: binary-arch] Error 25
Bug#1000664: Breaks weechat-python
reassign 1000664 python-aiohttp 3.7.4-2 retitle 1000664 python-aiohttp 3.7.4 depends on python-async-timeout < 4.0 thanks Tracking the dependencies between matrix-mirage and python-async-timeout, the only package with a direct dependency on python3-async-timeout is python3-aiohttp. It is also on the dependency graph of weechat-matrix. According to the source code for python-aiohttp, version 3.7.4 depends on async-timeout < 4.0: https://github.com/aio-libs/aiohttp/blob/0a26acc1de9e1b0244456b7881ec16ba8bb64fc3/setup.py#L71 Best regards, -- Sam
Bug#996878: closed by Debian FTP Masters (reply to Thomas Andrejak ) (Bug#996878: fixed in libprelude 5.2.0-5)
Hi, Thanks for this fix ! I'll test it as soon as the compiled package enters unstable. Cheers, François Le 27/11/2021 à 10:39, Debian Bug Tracking System a écrit : > This is an automatic notification regarding your Bug report > which was filed against the python3-prelude package: > > #996878: python3-prelude: python3 import prelude throws an ImportError > exception > > It has been closed by Debian FTP Masters > (reply to Thomas Andrejak ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Thomas Andrejak > ) by > replying to this email. > >
Bug#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Hi Hilmar, Quoting Hilmar Preusse (2021-11-27 16:25:19) > Since gs 9.54 the conversion of some eps files does not work for at > least one output devices. This came to my attention b/c the test suite > of asymptote fails to run for at least one file. > > The sample test file is attached. Here are two command lines, the > first fails, the second not. Hence I'd assume it to be valid EPS code. > > gs -dBATCH -dNOPAUSE -sDEVICE=pngalpha -sOutputFile=a.png hatch_.eps > gs -dBATCH -dNOPAUSE -sDEVICE=png16 -sOutputFile=a.png hatch_.eps > > Not sure, why pngalpha is affected; I tested a view variants of png, > they seem to work fine. Thanks for reporting this issue! Packaging changes is unlikely to affect this, so it is therefore better to report it upstream. I can do that, but better if you do this as you are in a better position to answer eventual followup questions related to asymptote as producer for that sample EPS file. Upstream bugtracker is here: https://bugs.ghostscript.com/ Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1000712: [Pkg-javascript-devel] Bug#1000712: Please add TypeScript definitions
Control: fixed -1 7.1.6+~7.1.3-1 Le 27/11/2021 à 16:52, Julien Puydt a écrit : > Package: node-glob > Version: 7.1.7+~cs7.5.19-2 > Severity: wishlist > > I found a package wanting fast-glob for a single call to sync... glob > would be a nice replacement if it had TypeScript declarations. > > Thanks, > > J.Puydt Already done!
Bug#1000712: Please add TypeScript definitions
Package: node-glob Version: 7.1.7+~cs7.5.19-2 Severity: wishlist I found a package wanting fast-glob for a single call to sync... glob would be a nice replacement if it had TypeScript declarations. Thanks, J.Puydt
Bug#1000708: python3-pot: Incompatible numpy version
Thanks for pointing this out, Marc! Stupid oversight on my part. Uploading a fix with the ABI dependency now. Best, Gard Marc Glisse writes: > Package: python3-pot > Version: 0.8.0+dfsg-2+b1 > Severity: normal > > Dear Maintainer, > > trying to use POT, I see > > $ python3 > Python 3.9.9 (main, Nov 16 2021, 10:24:31) > [GCC 11.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. import ot > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/ot/__init__.py", line 26, in > from . import lp > File "/usr/lib/python3/dist-packages/ot/lp/__init__.py", line 22, in > > from .emd_wrap import emd_c, check_result, emd_1d_sorted > File "ot/lp/emd_wrap.pyx", line 1, in init ot.lp.emd_wrap > ValueError: numpy.ndarray size changed, may indicate binary incompatibility. > Expected 88 from C header, got 80 from PyObject > > Maybe this package needs a dependency like python3-numpy-abi9? I am > surprised lintian doesn't report missing-dependency-on-numpy-abi for > this package if that's the case. > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing-debug > APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, > 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), > (50, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-1-amd64 (SMP w/16 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages python3-pot depends on: > ii libc6 2.32-4 > ii libgcc-s1 11.2.0-10 > ii libgomp1 11.2.0-10 > ii libstdc++6 11.2.0-10 > ii python33.9.7-1 > ii python3-numpy 1:1.19.5-1 > ii python3-scipy 1.7.1-2 > > Versions of packages python3-pot recommends: > ii python3-sklearn 0.23.2-5 > > python3-pot suggests no packages. > > -- no debconf information signature.asc Description: PGP signature
Bug#1000711: ITP: pymatgen-test-files -- test files for pymatgen
Package: wnpp Severity: wishlist Owner: Drew Parsons X-Debbugs-Cc: debian-de...@lists.debian.org, Debichem Team * Package name: pymatgen-test-files Version : 2022.0.16 Upstream Author : Shyue Ping Ong * URL : Shyue Ping Ong * License : MIT Programming Lang: Python Description : test files for pymatgen Pymatgen (Python Materials Genomics) is a robust, open-source Python library for materials analysis. This package provides pymatgen test files, used to test that the pymatgen installation is functioning correctly. These tests files are not provided in upstream pymatgen source tarballs (the tarballs made available at the upstream project website, distinct from their github repository), since their size is huge (778MB). The debian source package for pymatgen included them by taking source tarballs from upstream github releases. Upstream does not expect users (or distributions) to run these tests. They run their own tests using github facilities. But obviously for the Debian distribution we want to run the tests at build time and in debci. We can expect that the test files will change much more slowly than the pymatgen code itself. This pymatgen-test-files source package is intended to help make the size of the pymatgen package more reasonable by splitting off the test files. pymatgen will be updated to honour the nocheck build option to allow local builds without requiring access to the large test file set. To be maintained by the Debichem team alongside the main pymatgen package.
Bug#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Package: ghostscript Version: 9.55.0~dfsg-1 Severity: important Dear Maintainer, Since gs 9.54 the conversion of some eps files does not work for at least one output devices. This came to my attention b/c the test suite of asymptote fails to run for at least one file. The sample test file is attached. Here are two command lines, the first fails, the second not. Hence I'd assume it to be valid EPS code. gs -dBATCH -dNOPAUSE -sDEVICE=pngalpha -sOutputFile=a.png hatch_.eps gs -dBATCH -dNOPAUSE -sDEVICE=png16 -sOutputFile=a.png hatch_.eps Not sure, why pngalpha is affected; I tested a view variants of png, they seem to work fine. Hilmar -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.15.0-1-686-pae (SMP w/2 CPU threads) Kernel taint flags: TAINT_SOFTLOCKUP Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ghostscript depends on: ii libc6 2.32-4 ii libgs9 9.55.0~dfsg-1 ghostscript recommends no packages. Versions of packages ghostscript suggests: ii ghostscript-x 9.55.0~dfsg-1 -- no debconf information -- sigmentation fault hatch_.eps Description: PostScript document signature.asc Description: PGP signature
Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I do not know what causes that effect in scour. You can choose any section that fits your package, e.g., science or electronics. Please only add the section for the radexreader binary package. Keep the section for the source and python3-* packages. On 27.11.21 15:25, Fabrice Creuzot wrote: For the manual page, yes I have to take care of it. For the python section... I checked again the scour package, control file says "Section: graphics", but package appear in python section with Aptitude. So, I'm not sure what section to use. Thank you Le 26/11/2021 à 19:02, Bastian Germann a écrit : Control: tags -1 moreinfo Hi Fabrice, I will sponsor the package when you have fixed: radexreader: no-manual-page usr/bin/radexreader radexreader: application-in-library-section python usr/bin/radexreader Thanks, Bastian
Bug#1000708: python3-pot: Incompatible numpy version
Package: python3-pot Version: 0.8.0+dfsg-2+b1 Severity: normal Dear Maintainer, trying to use POT, I see $ python3 Python 3.9.9 (main, Nov 16 2021, 10:24:31) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ot Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/ot/__init__.py", line 26, in from . import lp File "/usr/lib/python3/dist-packages/ot/lp/__init__.py", line 22, in from .emd_wrap import emd_c, check_result, emd_1d_sorted File "ot/lp/emd_wrap.pyx", line 1, in init ot.lp.emd_wrap ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 88 from C header, got 80 from PyObject Maybe this package needs a dependency like python3-numpy-abi9? I am surprised lintian doesn't report missing-dependency-on-numpy-abi for this package if that's the case. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-1-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pot depends on: ii libc6 2.32-4 ii libgcc-s1 11.2.0-10 ii libgomp1 11.2.0-10 ii libstdc++6 11.2.0-10 ii python33.9.7-1 ii python3-numpy 1:1.19.5-1 ii python3-scipy 1.7.1-2 Versions of packages python3-pot recommends: ii python3-sklearn 0.23.2-5 python3-pot suggests no packages. -- no debconf information
Bug#1000707: bullseye-pu: package keepalived/1:2.1.5-0.2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [ Reason ] Keepalived ships a DBus policy allowing anyone to access and write any properties. We want to restrict this policy to only impact the properties owned by Keepalived. [ Impact ] Any user can read any DBus property and write any writable property. [ Tests ] Tested manually with: dbus-send --print-reply --system --dest=org.freedesktop.nm_dispatcher \ / org.freedesktop.DBus.Properties.Set \ string:com.example.Nope string:Nope variant:string:foo Thanks to Simon McVittie for its help on this. [ Risks ] Very low. I think most people don't enable DBus support, so we are unlikely to break anything. [ 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 ] Restrict allowed properties to org.keepalived.Vrrp1 destination. [ Other info ] - - Real impact seems small as most properties are already readable and are not writable. - - Security team is OK to use a point release to fix this. 9b4813899b1b -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGiR6sSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5S/gP/ipz9T9W02SEl2QOVw3falS9pQx4JUaV NYbwqbd+nocTjRTjk093QbtpfsGIxldwOBNy5cdZhEBQr+v4P+sj6zzBnP5s75mG foWBRviSQhD3XvwS9kZ5+4yhULdhv9iiSJE22nDmIRCOQ/zYvxeoaMxbjSoEetvE 4CzSNtVXP3uPmC+/FmdmdyoYxtbZTgnSkBv5bNNHtpMt9bl3jjRlLTx9vp1gbkzg nJUulyvv63wIm6pAiKbjrvW0gwutKlvlfNchlREgS4k8kAvuT/nUsZnsoMYw6m/B B8aR8z2HRTUYI/PmIqOG+UXvnL5M69SR5EB3bTGJfhgPhjDVG/M5yIdbBBBYHRdH 4/F42o5krlMPHSc96LRhaX8E1H5xcIGh3rwRq7EvP9i5C5O6Ox9cSRj+9kindvkR hBbjtdqXu4idmf9+unSk/NN+I2T+lOLKWeqhF00Wu8TtD9+JIEJbLnqcBoXc9QC7 d6qG3fuqKPyqrplliYgMEWb/GzQXvFnwx+JleBwFZ0nXXl5lGOLzOAVliYDowkZv a0w3qmdC0o46QfLzilGBPbFRLuoGCJ1ptQO9p/cK3esYEkxwicxgkhsAoSFqaWLT tvSt2KC9nC6FmuBpLrhUwK63zZOanHFwuTkVqsP+vQu+uHnDpnxaT4kvo78ckdhX e3DXALjBZLhd =uiHe -END PGP SIGNATURE- >From 9b4813899b1bd0ba9b719f458d794534e9989d22 Mon Sep 17 00:00:00 2001 From: Vincent Bernat Date: Sat, 27 Nov 2021 15:53:33 +0100 Subject: [PATCH] Fix shipped too broad DBus policy. CVE-2021-44225 --- debian/changelog | 6 ++ debian/patches/2063.patch | 38 ++ debian/patches/series | 1 + 3 files changed, 45 insertions(+) create mode 100644 debian/patches/2063.patch diff --git a/debian/changelog b/debian/changelog index 51ee7b25efc1..2491770e8103 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +keepalived (1:2.1.5-0.2+deb11u1) bullseye; urgency=medium + + * Fix shipped too broad DBus policy. CVE-2021-44225. + + -- Vincent Bernat Sat, 27 Nov 2021 15:51:39 +0100 + keepalived (1:2.1.5-0.2) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/patches/2063.patch b/debian/patches/2063.patch new file mode 100644 index ..ea9d40ec2115 --- /dev/null +++ b/debian/patches/2063.patch @@ -0,0 +1,38 @@ +From 7977fec0be89ae6fe87405b3f8da2f0b5e415e3d Mon Sep 17 00:00:00 2001 +From: Vincent Bernat +Date: Tue, 23 Nov 2021 06:50:59 +0100 +Subject: [PATCH] dbus: fix policy to not be overly broad + +The DBus policy did not restrict the message destination, allowing any +user to inspect and manipulate any property. + +Signed-off-by: Vincent Bernat +--- + keepalived/dbus/org.keepalived.Vrrp1.conf | 13 - + 1 file changed, 8 insertions(+), 5 deletions(-) + +diff --git a/keepalived/dbus/org.keepalived.Vrrp1.conf b/keepalived/dbus/org.keepalived.Vrrp1.conf +index 2b78a575c..b5ced6085 100644 +--- a/keepalived/dbus/org.keepalived.Vrrp1.conf b/keepalived/dbus/org.keepalived.Vrrp1.conf +@@ -3,12 +3,15 @@ + "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> + + +- +- ++ ++ + + +- +- +- ++ ++ ++ + + diff --git a/debian/patches/series b/debian/patches/series index e69de29bb2d1..c6683cd1715d 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -0,0 +1 @@ +2063.patch -- 2.34.0
Bug#1000703: Debian 11 - Blueman : Impossible to connect a bluetooth keyboard
It is also impossible to pair the keyboard in command lines as described in the tutorial below : https://wiki.debian.org/BluetoothUser The pairing of mouse, headset and other equipment that does not require the introduction of a PIN code works without problem. Regards.
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
❦ 14 November 2021 19:21 +01, Vincent Bernat: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu [...] I did the upload to bullseye as I think the change is not controversial. -- The lunatic, the lover, and the poet, Are of imagination all compact... -- Wm. Shakespeare, "A Midsummer Night's Dream"
Bug#1000706: RFS: shotwell/0.30.14-2 -- digital photo organizer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "shotwell": Package name: shotwell Version : 0.30.14-2 Upstream Author : Jim Nelson URL : https://wiki.gnome.org/Apps/Shotwell License : LGPL-2.1 Vcs : https://jff.email/cgit/shotwell.git Section : gnome It builds those binary packages: shotwell - digital photo organizer shotwell-common - digital photo organizer - common files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shotwell/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.14-2.dsc or for git https://jff.email/cgit/shotwell.git?h=release%2Fdebian%2F0.30.14-2 Changes since the last upload: shotwell (0.30.14-2) unstable; urgency=medium . * Enable untiy support (Closes: #1000528) - debian/control: Add Build-Depends libunity-dev. - debian/rules: Add override_dh_auto_configure. * debian/rules: - enable the apport option on Ubuntu (Closes: #1000529). * Declare compliance with Debian Policy 4.6.0.1 (No changes needed). CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst 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#1000705: RFS: ipmiutil/3.1.8-1 -- IPMI management utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ipmiutil": Package name: ipmiutil Version : 3.1.8-1 Upstream Author : [fill in name and email of upstream] URL : https://sourceforge.net/projects/ipmiutil/ License : BSD-3-clause, BSD-2-clause, Artistic-2.0, GPL-2+ with OpenSSL exception, Zlib, GPL-2+ Vcs : https://jff.email/cgit/ipmiutil.git Section : utils It builds those binary packages: ipmiutil - IPMI management utilities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ipmiutil/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ipmiutil/ipmiutil_3.1.8-1.dsc or from git https://jff.email/cgit/ipmiutil.git?h=release%2Fdebian%2F3.1.8-1 Changes since the last upload: ipmiutil (3.1.8-1) unstable; urgency=medium . * New upstream release. * Remove useless debian/lintian-overrides. * debian/rules: - Add autoreconf -i --force. * Declare compliance with Debian Policy 4.6.0.1 (No changes needed). * debian/copyright: - Add 2021 to myself. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst 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#981464: systemctl --user start fetchmail.service
Great! Just for a bit of eye candy, here's what it looks like in use: $ systemctl --user status fetchmail.service *●* fetchmail.service - Fetchmail Daemon Loaded: loaded (/home/barak/.config/systemd/user/fetchmail.service; enabled; vendor preset: enabled) Active: *active (running)* since Fri 2021-11-19 10:06:05 GMT; 1 week 1 day ago Docs: man:fetchmail(1) Main PID: 33578 (fetchmail) Tasks: 1 (limit: 19040) Memory: 3.4M CPU: 22.160s CGroup: /user.slice/user-1000.slice/user@1000.service /app.slice/fetchmail.service └─33578 fetchmail --nodetach --daemon 300 Nov 25 21:54:12 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 25 21:54:12 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (3529 header octets) (2423 body octets) flu> Nov 26 15:25:25 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 26 15:25:26 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (4387 header octets) (61207 body octets) fl> Nov 26 16:20:30 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 26 16:20:30 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (8659 header octets) (43658 body octets) fl> Nov 26 17:45:37 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 26 17:45:37 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (4271 header octets) (573358 body octets) f> Nov 27 08:11:41 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 27 08:11:42 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (7244 header octets) (196879 body octets) f>
Bug#1000704: ITP: node-css-tree -- tool set for CSS
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: Debian Javascript Maintainers * Package name: node-css-tree Version : 1.1.3 Upstream Author : Roman Dvornov * URL : https://github.com/csstree/csstree * License : Expat Programming Lang: JavaScript Description : tool set for CSS This package provides a tool set for CSS in Node.js: a parser, a walker, a generator and a lexer, based on both specs and browser implementations. . Node.js is an event-based server-side JavaScript engine. It is a dep for csstype, which is a dep for typestyle, which is a dep for jupyterlab. Cheers, J.Puydt
Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter
For the manual page, yes I have to take care of it. For the python section... I checked again the scour package, control file says "Section: graphics", but package appear in python section with Aptitude. So, I'm not sure what section to use. Thank you Le 26/11/2021 à 19:02, Bastian Germann a écrit : Control: tags -1 moreinfo Hi Fabrice, I will sponsor the package when you have fixed: radexreader: no-manual-page usr/bin/radexreader radexreader: application-in-library-section python usr/bin/radexreader Thanks, Bastian
Bug#981011: O: gftp -- X/GTK+ and console FTP client (metapackage)
Hi! I have noticed that you marked my bug orphaning gftp as owned by you (which annotation then was removed). As you can see I am still kind of maintaining gftp, even though I have marked it as orphaned. What would you say about co-maintaining the package? I would be fine with that. I noticed now recently that FTPS was compiled in, and quickly (and wrongly) enabled it in the build, uploading to unstable. This shouldn't be done, so I undid the change quickly - there are license problems with the openssl license and the GPL. [1] This however, will be solved by changing the license of gftp to the MIT license, which won't cause the same problems. Upstream is already in progress with the change. [2] After this is done we can enable the FTPS support again. The remaining bigger problem with the package is that it is still using GTK2. This is tracked at [3] and in Debian at [4]. As you probably are aware, programs that only support GTK2 will get removed from Debian sooner or later. -- Andreas Rönnquist gus...@debian.org 1: https://people.gnome.org/~markmc/openssl-and-the-gpl.html 2: https://github.com/masneyb/gftp/pull/133 3: https://github.com/masneyb/gftp/issues/91 4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967390
Bug#872418: Reproducible, forwarded
Control: forwarded -1 https://sourceforge.net/p/jmol/bugs/621/ Hello, I have just been able to reproduce the bug with version 14.30.2+dfsg-2 on an xfce desktop. Besides, I have forwarded the issue to the upstream bug tracker. -- Pierre
Bug#1000703: Debian 11 - Blueman : Impossible to connect a bluetooth keyboard
Package: Blueman Version: 2.1.4-1+b1 Bug Description: Normally, during the pairing phase, a security PIN code must appear on the screen, then it must be entered on the keypad to confirm the correct choice of the device to be installed. This function does not work which makes pairing a keyboard or smartphone impossible ?! Please submit a fix. Thank you by advance & regards. Philippe
Bug#1000702: src:sonic-visualiser: fails to migrate to testing for too long: FTBFS on armel and mipsel
Source: sonic-visualiser Version: 4.2-1 Severity: serious Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:sonic-visualiser has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package FTBFS on armel and mipsel. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=sonic-visualiser OpenPGP_signature Description: OpenPGP digital signature
Bug#1000701: node-mdn-data: Wrong license, package is covered by CC-1.0, not MPL-2.0
Source: node-mdn-data Version: 2.0.23-1 Severity: serious Justification: Policy 2.3 debian/copyright is wrong, package is covered by CC-1.0-Universal, not MPL-2.0
Bug#996154: obexftp: FTBFS: ld: final link failed: bad value
Control: reassign -1 libopenobex2-dev 1.7.2-2
Control: retitle -1 libopenobex2-dev: openobex-target-release.cmake forces
static linking
Control: affects -1 src:obexftp
Control: tags -1 patch
On Mon, Oct 11, 2021 at 10:33:44AM -0300, Antonio Terceiro wrote:
>...
> Relevant part (hopefully):
> > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libopenobex.a(api.c.o): relocation
> > R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when
> > making a shared object; recompile with -fPIC
> > /usr/bin/ld: final link failed: bad value
> > collect2: error: ld returned 1 exit status
>...
This is not a problem in obexftp, this is a regressiong in libopenobex
which installs files in the wrong order forcing usage of the static
library in the cmake files - which doesn't work when linking a shared
library.
$ grep -r libopenobex /usr/lib/x86_64-linux-gnu/cmake/OpenObex-1.7.2
/usr/lib/x86_64-linux-gnu/cmake/OpenObex-1.7.2/openobex-target-release.cmake:
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/x86_64-linux-gnu/libopenobex.a"
/usr/lib/x86_64-linux-gnu/cmake/OpenObex-1.7.2/openobex-target-release.cmake:list(APPEND
_IMPORT_CHECK_FILES_FOR_openobex
"${_IMPORT_PREFIX}/lib/x86_64-linux-gnu/libopenobex.a" )
$
Fix is below.
cu
Adrian
--- debian/rules.old2021-11-27 01:10:36.888770748 +
+++ debian/rules2021-11-27 01:10:53.572753176 +
@@ -37,6 +37,6 @@
dh_auto_build -B $(BUILDDIR)-static
override_dh_auto_install:
- dh_auto_install -B $(BUILDDIR)
dh_auto_install -B $(BUILDDIR)-static
+ dh_auto_install -B $(BUILDDIR)
cp -v $(BUILDDIR)-static/lib/*.a
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
Bug#1000699: RM: libisds -- ROM; only user of the library removed; dead upstream
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've just requested removal of the only user src:datovka and this package is dead upstream anyway. Please remove it together with src:datovka. Ondrej -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmGiNHNfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcLgxw/+NkuLuFi5m5UG1ZRmTslOOC/fyQx1KCChCtM80HCZM8p4h5QdEHMZxyLi KJw19mpl/C1gpfLW1mu5v+IqHwLwbWZgv0aFMBn9ZkymsOa/HuM87/LeFSY3Og/v nRDPJtCvtfeny2DLdTh5HfaWcp5nL4Bz/PmafXlL0hQzUjP+O6Y1FD6dXDjbydxd dtLlgO83MMMDqm1iO4nok3nQJ7ZxM6rm2yd/3VOk7L8Cr0xARZJbZh4a+kbrczqW n+ajY9t9IsiXZee3j7cvr5qwmXaa2krbK+JP5ZIdMDIE6OeijqyGkuLmHV0EEMcP jsF1jgdVFjioCDd5UjgAJsrua/8asb6IyopnBKaXWsGjUsH9B8Owru5A5qknjU2X Ej3KDZLOM0sJ8HU+tuas+XR668na46xEusv4dREIyMEYSOLe8T1lHvPyaghKz8RT opEU4tzy+jdmv60Dq/0SNYI9TDunCaDndNc+4mmGoFS//vDw3DKM3JX+kZsruzjP WrGZwpO38y/ScsChO5vQ6L/7ilpZhiGHrn3ULdi6I9KbWs/QRU1kRJNcDEv8b2Ty 8CwWonMflwdOsUdBtsJt7yxcMg6EsdWTPpOJynpMn67nssFbzcMntYO8W1OnZCJi 8+wBp7MalNlJ4B30sPJvw2QjxiF6ZatiTp5FommjYgwSDespCQM= =eIPz -END PGP SIGNATURE-
Bug#1000698: RM: datovka -- ROM; maintained outside the repository
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The upstream maintains the package in the SuSE OBS and they haven't requested any updates of the package directly in Debian. Given that the package is updated very often and calls home for upgrade, it would be better to get it just removed from Debian. Ondrej - -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmGiM4ZfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcLT9xAAkO7nFDONww9Nc0V0l1ektN9IkUcilwY1VzyB66/etHJtLjpzZy4/Vxbc 5YNJgcp1FIgH1Apas7G/chW1j2hk5oL3BlE3Mg+5iCbc+ysfG4espf0Ki/DqkqQ7 tTyKkRrHc7yH43wN4RoT3do/tLLArRZ3sk7Vc6q5EbWXeBl1rMypG7DskhZ8yo3Y u7f9u16tw/K/1ulu3BnsCfgGxoVVmSTioPX3fJZ7IoYNJKis5gUNnPY1q+r4sGhN Vv8A7W8PEDGaENwm+MhM8dR3yF40MA6bYVZbV9T+h79xVB85cHWpQXS6PrwvUYCs b6nTN+WW9sGCBN5sPtPUh3BfI+5uCSAuEacXSq6T2Jr5e8Iv95YBVGn4oevpuD8w ArmquOHMvrq+WgztdT2rG+Dkh3UaEZRDUNPLnOmvM3x2I1WgvQsu7FsF6LsOxst7 gS5/xo8Wb/BaqZew9NP5W1Iv4oI9yvQAb9bh1zl12lehuwHlVGHrINndSJbvWmqv /9RCa/LrNJ5QIPK428CbNxhh/pjoupn3mmfcwRxf0MRi1G8Dz8mp/5YDkxI3FRiF gG8jQ3KDc27u76SMGFRChiZiBGV+Ijbdr7ZIu1Y4NDZ06hiyh443gh7HMBr5htxH /yTWPu12Iv1oU0FDxCmVDMtQn1MkAlG1vXAwgORnDbIO/BRyU0g= =MLiU - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmGiNCRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcLOvw/9Hm5kkx3DvnEzAnesGXQGrLUddn6VVX+VoURgAuO3HlnsGFTONewVBW9F zZ3Fzk2bLF+psMUoHKFEkIs6q3gU6sCRnTTgeD5dqz9q1L+hZ+xlY4CYFy4NsBb9 +cIQkLWMWeAlS1oHRFvhN1y17GeTklnUcp5ZD62bt3itcPfnuyDZpH5gqXgprNAl P48rVwPl8AC3x9c84uiWZZqFiLi6cC4Ummlq8+Pmt+u7uEQr4pfPgqLkVn+pYJKW jvOdYDJ6nXSgv6DPwSEacrLOhf69xL4ZPw442rWu8E6kAAtwppdonU1NFgJXAdvH h7X3kDDdXy1Kc9MxJHQtkEZL1vQWe7FZtsr8a94m70nlm36SQ0KokkyIhIQ/j+FB +FaytuAX34o2zSHhLySvTHNUDDOTOUvCbP+1wPeQEt1k7E9TBF3ahHxfOcUGB/Ck e9KX7zz2/ePB4n7lCficHmyIE0w/4CWTX+ewGTp9jy0hbYTVrCwbVZjAG9J7Z5Qu +Q6hJ3bK2G8lWUAeDWhVJUyN9l7YLSQsENiJNFu4na42izDyEEAKEnrdNdkRlgob MUe2gCV/kWUClCNAZ6Sne5PCdnmfRB+hoFkERSUjqpaTohfsiKJKW5FX1PehuvG2 UPagsAeLz0kiqGKVJUC17eQvoYGGM5AJckBU/ZS0Sp2PEr2iZ2E= =tgQU -END PGP SIGNATURE-
Bug#998627: linux: please enable the new NTFS3 driver in 5.15
Hi, On Wed, Nov 24, 2021 at 03:14:56PM +0800, Wenbin Lv wrote: > Hi, > > On Wed, Nov 24, 2021 at 5:36 AM Salvatore Bonaccorso > wrote: > > > > Hi, > > > > > > Are tools available to handle creation and checking of such NTFS3 > > filesystems? The last time I went to the paragon software site it > > mentioned it was planning. This is not a must, but kept me for > > slightly on the on hold position for enabling it. > > > > Regards, > > Salvatore > > > > Paragon only mentioned they are planning to release mkfs.ntfs in their > FAQ, not the fsck tool[1]. So we'll need ntfs-3g or Windows for fsck > anyway if they don't release it. Stability and further code > maintenance, however, are matters of greater concern as Ted Ts'o > pointed out[2]. Maybe we should hold it back for some time to see what > will happen. Yes right, the missing tools was not an argument against it, just an additional indication. As you pointed out is more concerning, and hinting that we should wait a bit more to see how it evolves. Apart from Ted Ts'o comments, I looked up the mailinglist, https://lore.kernel.org/ntfs3/ which relatively quiet. The same goes for commits in fs/ntfs3 in mainline, since the merge in 5.15 there ws almost no activity, which is slightly unusual for something new entering. Regards and thank you! Salvatore
Bug#1000697: linux-image-amd64: NTFS3 module missing in new kernels
Control: reassign -1 src:linux Control: forcemerge 998627 -1 Hi, On Sat, Nov 27, 2021 at 06:29:46AM -0600, Ryan Thoryk wrote: > Package: linux-image-amd64 > Version: 5.15.3-1 > Severity: wishlist > > Dear Maintainer, > > The Debian Linux kernels 5.15 and 5.16-rc1 do not have the newly introduced > ntfs3 module, which was a fairly big new feature in 5.15. The module > provides an in-kernel alternative to the ntfs-3g package. > > To add the module, add "CONFIG_NTFS3_FS=m" to the kernel config. See #998627. Regards, Salvatore
Bug#999560: RM: php-nrk-predis -- ROM; NBS; arch:any packages sepeseded by php-predis
Control: retitle -1 RM: php-nrk-predis -- ROM; NBS; arch:any packages superseded by php-predis Le Fri, Nov 12, 2021 at 10:40:32AM -0400, David Prévot a écrit : > The last upload of src:php-nrk-predis only builds an arch:all package > (php-predis) that provides (versioned) php-nrk-predis (and a > compatibility symlink) to help transition I’ve added (back) an arch:all php-nrk-predis transitional dummy package to ensure upgrade to php-predis (thanks ansgar for pointing out on IRC that something was missing). > php-nrk-predis binary packages are not built anymore, they used to be > arch:any packages even if they only shipped (the same) arch:all > material, and I believe those binary packages needs to be manually > removed in order to allow php-nrk-predis transition to testing (once the > arch:all package gets built on buildd). Regards David signature.asc Description: PGP signature
Bug#1000697: linux-image-amd64: NTFS3 module missing in new kernels
Package: linux-image-amd64 Version: 5.15.3-1 Severity: wishlist Dear Maintainer, The Debian Linux kernels 5.15 and 5.16-rc1 do not have the newly introduced ntfs3 module, which was a fairly big new feature in 5.15. The module provides an in-kernel alternative to the ntfs-3g package. To add the module, add "CONFIG_NTFS3_FS=m" to the kernel config. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-amd64 depends on: ii linux-image-5.15.0-1-amd64 5.15.3-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#981464: systemctl --user start fetchmail.service
Am 24.11.21 um 18:56 schrieb László Böszörményi (GCS): It would be best if upstream integrates it to the source code. Even if 6.4.25 is just around the corner. After some discussion behind the scenes, added to contrib/systemd/ as of 6.4.25.rc2, without installation support. It should be easy enough for a distribution to add two post-install lines for contrib/systemd/README.systemd to the docs dir and the unit file to /usr/lib/systemd/user/.
Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug
On Tue, Nov 23, 2021 at 12:36:07PM -0800, Kevin J. McCarthy wrote: > On Tue, Nov 23, 2021 at 08:45:47PM +0100, Hannes von Haugwitz wrote: > > Is there any progress with this bug? > > Mutt 2.1.3 included the corrected sort commit referenced in my last email. > So, for unstable/testing it would be nice to get 2.1.3 uploaded. > > For stable/oldstable I guess it rests in the hands of Debian process, but > ideally the three links from my last email would be backported to those. > > -Kevin Updating to mutt 2.1.3 as we speak, I will prepare the fix for the stable/oldstable as well, that will go through the standard process; thanks for referencing those commits.
Bug#1000695: RFS: arqiver/0.9.0-1 [ITP] -- Simple Qt5 archive manager; front-end for libarchive, gzip and 7z.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "arqiver": * Package name : arqiver Version : 0.9.0-1 Upstream Author : Pedram Pourang * URL : https://github.com/tsujan/Arqiver * License : GPL-3.0 Section : misc It builds those binary packages: arqiver - Simple Qt5 archive manager; front-end for libarchive, gzip and 7z. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/arqiver/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/arqiver/arqiver_0.9.0-1.dsc Changes for the initial release: arqiver (0.9.0-1) unstable; urgency=medium . * Initial release (Closes: #976226) Regards, S. 7
Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready
Hi Mario, after Corey has given some input, we can try finding out what happens on your Pi. Does Raspbian use Network-Manager? systemd-networkd? ifupdown? You can try adding After=network-online.target Wants=network-online.target to the [Unit] stanza of ser2net.service. According to https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ you need to enable the correct wait-online.service matching your network management software (NetworkManager, systemd-networkd, ifupdown etc) for this to reliably work. Greetings Marc
Bug#998618: bind9.17.19: crashes with INSIST assertion fail resp->disp->active.tail or .head == or != resp
Hi Andy, do you have spare cycles to retest this with 9.17.20? We did fix some bugs related to the dispatch code and I was wondering that maybe we fixed this in the process. Cheers, Ondrej On Fri, Nov 5, 2021, at 20:53, Andy Dorman wrote: > Hi Ondrej. > > Bind finally crashed after almost 7 hours of operation (longer than > usual) and I captured the attached core dump. I ran it through gzip to > get the size down from over 100MB. > > Here is the log entry from that crash. > > > 2021-11-05T14:21:02.022265-05:00 william named[14966]: dispatch.c:1524: > > INSIST((resp->disp->active).head == (resp)) failed, back trace > > 2021-11-05T14:21:02.022736-05:00 william named[14966]: > > /usr/sbin/named(+0x1a8eb) [0x4ff8eb] > > 2021-11-05T14:21:02.022820-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(isc_assertion_failed+0x25) > > [0xb7cad775] > > 2021-11-05T14:21:02.022887-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libdns-9.17.19-1-Debian.so(dns_dispatch_cancel+0x2cc) > > [0xb7a5093c] > > 2021-11-05T14:21:02.022951-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libdns-9.17.19-1-Debian.so(+0x110d98) [0xb7b1bd98] > > 2021-11-05T14:21:02.023025-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libdns-9.17.19-1-Debian.so(+0x1170a3) [0xb7b220a3] > > 2021-11-05T14:21:02.023091-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libdns-9.17.19-1-Debian.so(+0x45d15) [0xb7a50d15] > > 2021-11-05T14:21:02.023162-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(isc__nm_async_connectcb+0xa2) > > [0xb7c9a722] > > 2021-11-05T14:21:02.023229-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(+0x1cb96) [0xb7c9bb96] > > 2021-11-05T14:21:02.023292-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(+0x1d2cc) [0xb7c9c2cc] > > 2021-11-05T14:21:02.023364-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(+0x1db28) [0xb7c9cb28] > > 2021-11-05T14:21:02.023427-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libuv.so.1(+0xd0aa) [0xb76300aa] > > 2021-11-05T14:21:02.023498-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libuv.so.1(+0x2239e) [0xb764539e] > > 2021-11-05T14:21:02.023561-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libuv.so.1(uv_run+0x10e) [0xb7630a6e] > > 2021-11-05T14:21:02.023633-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(+0x1d353) [0xb7c9c353] > > 2021-11-05T14:21:02.023695-05:00 william named[14966]: > > /usr/lib/i386-linux-gnu/libisc-9.17.19-1-Debian.so(isc__trampoline_run+0x22) > > [0xb7ce1b22] > > 2021-11-05T14:21:02.023769-05:00 william named[14966]: > > /lib/i386-linux-gnu/libpthread.so.0(+0x80af) [0xb73d70af] > > 2021-11-05T14:21:02.023831-05:00 william named[14966]: > > /lib/i386-linux-gnu/libc.so.6(clone+0x66) [0xb72e68f6] > > 2021-11-05T14:21:02.023907-05:00 william named[14966]: exiting (due to > > assertion failure) > > Please let me know if I can do anything else to assist. > > -- > Andy Dorman > Ironic Design, Inc. > AnteSpam.com > > On Fri, 5 Nov 2021 07:17:27 -0500 Andy Dorman > wrote: > > Thank you Ondrej, > > > > This is Andy. Michael set up the server many years ago and has left us, > > and I never got around to changing the user address. > > > > I have set up the system to produce a core dump on the next crash and > > restarted named. > > > > I will submit the core dump as soon as I have it. > > > > Again, thank you > > > > -- > > Andy Dorman > > Ironic Design, Inc. > > AnteSpam.com > > > > On Fri, 5 Nov 2021 07:13:18 +0100 wrote: > > > Michael, > > > > > > do you have full coredump available? > > > > > > Ondřej > > > > > > > > > -- > Andy Dorman > FanMail.com > Ironic Design, Inc. > AnteSpam.com, ComeHome.net > [read-receipt: 462751] > > CONFIDENTIALITY NOTICE: This message is for the named person's use only. > It may contain confidential, proprietary or legally privileged > information. No confidentiality or privilege is waived or lost by any > erroneous transmission. If you receive this message in error, please > immediately destroy it and notify the sender. You must not, directly or > indirectly, use, disclose, distribute, or copy any part of this message > if you are not the intended recipient. > > > > *Attachments:* > * isc-net-_core_dump.14966.gz -- Ondřej Surý (He/Him) ond...@sury.org
Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32
The root case of the problem has now been identified (see bug #100421). I'll upload a new version cppcheck with a workaround shortly (and before the autoremoval kicks in) -- just wanting to wait a bit more for a potential new upstream release. Best regards, Joachim
Bug#1000694: src:pydyf: Switch to flit plugin for pybuild
Package: src:pydyf Version: 0.1.2-1 Severity: wishlist Tags: patch Now that flit 3.3 is in Debian, pydyf can be build using the flit plugin. Please see the attached patch. Upstream uses flit to build, so I think it would be better in the long run if we did too. Currently there doesn't seem to be any significant difference in the binary produced, so it's fine either way. Note though that the included setup.py is autogenerated for use with legacy tools. The only change needed to invoke the flit plugin is to add flit to build depends (and drop setuptools, since it's no longer needed). The fact that this package can build with the flit plugind is autodetected. Please see the attached patch. Scott K diff -Nru pydyf-0.1.2/debian/changelog pydyf-0.1.2/debian/changelog --- pydyf-0.1.2/debian/changelog2021-11-14 22:31:40.0 -0500 +++ pydyf-0.1.2/debian/changelog2021-11-27 05:51:39.0 -0500 @@ -1,3 +1,9 @@ +pydyf (0.1.2-1.1) UNRELEASED; urgency=medium + + * Switch to using flit plugin for pybuild + + -- Scott Kitterman Sat, 27 Nov 2021 05:51:39 -0500 + pydyf (0.1.2-1) sid; urgency=medium * Uploading to sid. diff -Nru pydyf-0.1.2/debian/control pydyf-0.1.2/debian/control --- pydyf-0.1.2/debian/control 2021-11-14 22:31:33.0 -0500 +++ pydyf-0.1.2/debian/control 2021-11-27 05:51:35.0 -0500 @@ -7,7 +7,7 @@ dh-sequence-python3, python3-all, python3-pil , - python3-setuptools, + flit (>= 3.2), Rules-Requires-Root: no Standards-Version: 4.6.0 Homepage: https://github.com/CourtBouillon/pydyf
Bug#934258: Experimentations on packaging jupyterlab
Hi,
I tried my hand at experimental packaging for jupyterlab.
For the Python part, it lacks nbclassic, it's ITP bug #1000667, this
will be done in no time.
The JavaScript part is another story entirely. I made experiments
compiling by hand a few of the packages in packages/.
Here is how you can get as far as me: you need a trick and a patch,
both at the end of this mail. [And of course the relevant node-*
packages!]
Apply the trick in the coreutils, services and statedb directories.
That will allow you to compile, in that order: coreutils, statedb,
nbformat, settingregistry, observables, services, translation,
rendermime-interfaces, mathjax2, metapackage and pdf-extension.
For the rest, ui-components is as far as I can tell the main blocker ;
it wants typestyle, which in turn wants csstype and freestyle. Perhaps
those are easy, but I don't know yet.
Cheers,
J.Puydt
PS:
The trick is to do this in the relevant packages/ directory:
mkdir -p node_modules/@types
ln -s /usr/share/nodejs/@types/node node_modules/@types/
The patch is:
diff --git a/tsconfigbase.json b/tsconfigbase.json
index b9aea77..de6fd2a 100644
--- a/tsconfigbase.json
+++ b/tsconfigbase.json
@@ -17,6 +17,36 @@
"sourceMap": true,
"strictNullChecks": true,
"target": "es2017",
-"types": []
+"types": [],
+"paths": {
+ "@jupyterlab/coreutils": ["./packages/coreutils"],
+ "@jupyterlab/nbformat": ["./packages/nbformat"],
+ "@jupyterlab/observables": ["./packages/observables"],
+ "@jupyterlab/rendermime-interfaces": ["./packages/rendermime-
interfaces"],
+ "@jupyterlab/services": ["./packages/services"],
+ "@jupyterlab/settingregistry": ["./packages/settingregistry"],
+ "@jupyterlab/statedb": ["./packages/statedb"],
+ "@jupyterlab/translation": ["./packages/translation"],
+ "@lumino/algorithm": ["/usr/share/nodejs/@lumino/algorithm"],
+ "@lumino/commands": ["/usr/share/nodejs/@lumino/commands"],
+ "@lumino/coreutils": ["/usr/share/nodejs/@lumino/coreutils"],
+ "@lumino/datagrid": ["/usr/share/nodejs/@lumino/datagrid"],
+ "@lumino/disposable": ["/usr/share/nodejs/@lumino/disposable"],
+ "@lumino/domutils": ["/usr/share/nodejs/@lumino/domutils"],
+ "@lumino/dragdrop": ["/usr/share/nodejs/@lumino/dragdrop"],
+ "@lumino/messaging": ["/usr/share/nodejs/@lumino/messaging"],
+ "@lumino/polling": ["/usr/share/nodejs/@lumino/polling"],
+ "@lumino/properties": ["/usr/share/nodejs/@lumino/properties"],
+ "@lumino/signaling": ["/usr/share/nodejs/@lumino/signaling"],
+ "@lumino/virtualdom": ["/usr/share/nodejs/@lumino/virtualdom"],
+ "@lumino/widgets": ["/usr/share/nodejs/@lumino/widgets"],
+ "@types/node": ["/usr/share/nodejs/@types/node"],
+ "ajv": ["/usr/share/nodejs/ajv"],
+ "json5": ["/usr/share/nodejs/json5"],
+ "minimist": ["/usr/share/nodejs/minimist"],
+ "moment": ["/usr/share/nodejs/moment"],
+ "path": ["/usr/share/nodejs/@types/node"],
+ "url-parse": ["/usr/share/nodejs/url-parse"]
+}
}
}
Cheers,
J.Puydt
Bug#1000693: ITP: libnet-mqtt-simple-perl -- Minimal MQTT version 3 interface
Package: wnpp Severity: wishlist Owner: Roland Mas X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libnet-mqtt-simple-perl Version : 1.26 Upstream Author : Juerd Waalboer * URL : https://metacpan.org/release/Net-MQTT-Simple * License : any-osi Programming Lang: Perl Description : Minimal MQTT version 3 interface Net::MQTT::Simple consists of only one file and has no dependencies except core Perl modules, making it suitable for embedded installations where CPAN installers are unavailable and resources are limited. Only basic MQTT functionality is provided; if you need more, you'll have to use the full-featured Net::MQTT instead. Connections are set up on demand, automatically reconnecting to the server if a previous connection had been lost. Because sensor scripts often run unattended, connection failures will result in warnings (on STDERR if you didn't override that) without throwing an exception. Please refer to Net::MQTT::Simple::SSL for more information about encrypted and authenticated connections. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1000692: linux-image-5.15.0-1-amd64: Linux 5.15.3 kernel is missing the NTFS3 driver
Control: reassign -1 src:linux Control: forcemerge 998627 -1 Hi, On Sat, Nov 27, 2021 at 11:08:54AM +0100, Heinz Repp wrote: [...] > Seems, the devs forgot to activate the option for NTFS3 when building the > kernel. > The only patch necessary is selecting option "NTFS Read-Write file system > support" when building the kernel. No it was not forgotten :). We are waiting for activating it to see if it stabilizes enough. There are concerns about it. See #998627. Regards, Salvatore
Bug#1000692: linux-image-5.15.0-1-amd64: Linux 5.15.3 kernel is missing the NTFS3 driver
Package: src:linux
Version: 5.15.3-1
Severity: normal
Tags: patch
-- Package-specific info:
** Version:
Linux version 5.15.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian
11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian
5.15.3-1 (2021-11-18)
** Command line:
BOOT_IMAGE=/vmlinuz-5.15.0-1-amd64
root=UUID=ed4d0cfd-411a-492b-b31a-3eefa94764f6 ro vga=792 quiet
acpi_enforce_resources=lax
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[4.939466] systemd[1]: Mounting Mount unit for snapd, revision 13640...
[4.943205] systemd[1]: Mounting Mount unit for snapd, revision 14066...
[4.943776] loop3: detected capacity change from 0 to 133320
[4.944505] loop4: detected capacity change from 0 to 133552
[4.947951] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[4.948741] loop5: detected capacity change from 0 to 405848
[4.955044] loop6: detected capacity change from 0 to 113640
[4.956457] systemd[1]: Mounted Mount unit for gnome-3-38-2004, revision 76.
[4.956911] loop7: detected capacity change from 0 to 126632
[4.960079] systemd[1]: Mounted Mount unit for bare, revision 5.
[4.960265] systemd[1]: Mounted Mount unit for gtk-common-themes, revision
1515.
[4.979011] systemd[1]: Mounted Mount unit for core20, revision 1169.
[4.979314] systemd[1]: Mounted Mount unit for ausweisapp2-ce, revision 95.
[4.979394] systemd[1]: Mounted Mount unit for gtk-common-themes, revision
1519.
[4.980306] loop10: detected capacity change from 0 to 126632
[4.981181] loop11: detected capacity change from 0 to 113656
[4.983486] loop8: detected capacity change from 0 to 66440
[4.986448] loop12: detected capacity change from 0 to 507712
[4.987465] systemd[1]: Mounted Mount unit for ausweisapp2-ce, revision 96.
[4.989106] systemd[1]: Mounted Mount unit for core18, revision 2253.
[4.989628] loop9: detected capacity change from 0 to 86368
[4.999238] systemd[1]: Started Journal Service.
[5.028993] systemd-journald[338]: Received client request to flush runtime
journal.
[5.165331] nvidia: loading out-of-tree module taints kernel.
[5.165348] nvidia: module license 'NVIDIA' taints kernel.
[5.165349] Disabling lock debugging due to kernel taint
[5.204770] nvidia: module verification failed: signature and/or required
key missing - tainting kernel
[5.226669] nvidia-nvlink: Nvlink Core is being initialized, major device
number 244
[5.228245] nvidia :01:00.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=none:owns=io+mem
[5.310974] random: crng init done
[5.310979] random: 7 urandom warning(s) missed due to ratelimiting
[5.411732] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 470.86 Tue Oct
26 21:55:45 UTC 2021
[5.539813] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for
UNIX platforms 470.86 Tue Oct 26 21:46:51 UTC 2021
[5.595734] acpi_cpufreq: overriding BIOS provided _PSD data
[5.639551] input: Power Button as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3
[5.639661] ACPI: button: Power Button [PWRB]
[5.639713] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[5.639855] ACPI: button: Power Button [PWRF]
[5.705601] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver
[5.705607] [drm] Initialized nvidia-drm 0.0.0 20160202 for :01:00.0 on
minor 0
[5.837796] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[5.917797] sd 1:0:0:0: Attached scsi generic sg0 type 0
[5.950813] sd 3:0:0:0: Attached scsi generic sg1 type 0
[5.968335] sr 4:0:0:0: Attached scsi generic sg2 type 5
[5.982426] sd 6:0:0:0: Attached scsi generic sg3 type 0
[5.987716] sd 6:0:0:1: Attached scsi generic sg4 type 0
[6.015823] sd 6:0:0:2: Attached scsi generic sg5 type 0
[6.015864] sd 6:0:0:3: Attached scsi generic sg6 type 0
[6.047493] input: PC Speaker as /devices/platform/pcspkr/input/input5
[6.081842] snd_hda_intel :01:00.1: Disabling MSI
[6.081858] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[6.111807] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input6
[6.111979] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input7
[6.112031] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input8
[6.112080] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input9
[6.112187] input: HDA NVidia HDMI/DP,pcm=10 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input10
[6.120874] snd_hda_codec_realtek hdaudioC0D3: autoconfig for ALC888:
line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[6.120882] snd_hda_codec_realtek hdaudioC0D3:
Bug#1000691: RM: cylc -- ROM; replaced by cylc-flow
Package: ftp.debian.org Severity: normal This package (cylc) is being split upstream into two source packages - cylc-flow and cylc-ui. The original cylc is now replaced by cylc-flow, now present in unstable/testing. Please remove the cylc source package and binaries
Bug#1000690: cyrus-caldav: Web GUI URL responds with 204
Package: cyrus-caldav Version: 3.2.6-2+deb11u1 Severity: normal Dear Maintainer, According to the documentation (see https://www.cyrusimap.org/3.0/imap/download/installation/http/caldav.html#administration) there should be a web gui for creating calendars at https:///dav/calendars/user/. The URL (https://mail.heute-morgen.de:8443/dav/calendars/user/) does however respond with a 204 No Content. Caldav and cardav are enabled and working. Sincerely, Joachim
Bug#952121: ITA: xcffib -- CFFI-based Python binding for X
Package: wnpp Severity: normal Hi, I intend to adopt xcffib in order to update as well qtile package. Best Regards, Jérôme
Bug#1000689: screenruler: wrong dependency name
Package: screenruler Version: 0.960+bzr41+deb10-5 Severity: normal X-Debbugs-Cc: ft.alban.hun...@mail.com In the control file, the following package is listed as a dependency: "ibcanberra-gtk3-module". This is clearly just a typo, but makes the package uninstallable because of a missing dependency. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages screenruler depends on: ii libcanberra-gtk3-module 0.30-8 ii ruby 1:2.7.6 ii ruby-cairo 1.16.6-1+b2 ii ruby-cairo-gobject 3.4.3-1+b3 ii ruby-gettext 3.3.3-2 ii ruby-gtk23.4.3-1+b3 screenruler recommends no packages. screenruler suggests no packages. -- no debconf information
Bug#1000672: [Pkg-javascript-devel] Bug#1000672: @lumino/polling isn't compiled correctly
Le 27/11/2021 à 09:54, Yadd a écrit : > Le 27/11/2021 à 09:44, Julien Puydt a écrit : >> Hi, >> >> Le samedi 27 novembre 2021 à 09:24 +0100, Yadd a écrit : >>> >>> This is a known typescript bug, it is unable to use nodejs paths. To >>> workaround, use this: >>> >>> $ cat > debian/nodejs/extlinks << EOF >>> setimmediate >>> @types/node >>> EOF >> >> How does that work? >> >> Thanks, > > typescript only looks at node_modules/ directories to find dependencies. > dh-sequence-nodejs: > * link all modules declared in debian/nodejs/extlinks into >node_modules/ > * copies all modules declared in debian/nodejs/extcopies into >node_modules (useful if a ts file launch another ts file) > > See > https://salsa.debian.org/js-team/pkg-js-tools/tree/master/doc/tools#readme I took a look at your build script, you should add some "set -e" to be sure that package is well compiled: diff --git a/debian/rules b/debian/rules index 17e83d3..436cf4b 100755 --- a/debian/rules +++ b/debian/rules @@ -4,7 +4,7 @@ dh $@ override_dh_auto_build: - for package in algorithm coreutils keyboard properties \ + set -e && for package in algorithm coreutils keyboard properties \ collections domutils signaling virtualdom \ disposable messaging \ datastore dragdrop commands polling \ @@ -14,7 +14,7 @@ override_dh_auto_build: && tsc && rollup lib/*.js -f cjs -m -d dist) ; \ done ln -s packages/ @lumino - for example in example-datagrid ; do \ + set -e && for example in example-datagrid ; do \ (cd examples/$$example && echo "Compiling $$example" \ && tsc && webpack) ; \ done
Bug#1000672: [Pkg-javascript-devel] Bug#1000672: @lumino/polling isn't compiled correctly
Le 27/11/2021 à 09:44, Julien Puydt a écrit : > Hi, > > Le samedi 27 novembre 2021 à 09:24 +0100, Yadd a écrit : >> >> This is a known typescript bug, it is unable to use nodejs paths. To >> workaround, use this: >> >> $ cat > debian/nodejs/extlinks << EOF >> setimmediate >> @types/node >> EOF > > How does that work? > > Thanks, typescript only looks at node_modules/ directories to find dependencies. dh-sequence-nodejs: * link all modules declared in debian/nodejs/extlinks into node_modules/ * copies all modules declared in debian/nodejs/extcopies into node_modules (useful if a ts file launch another ts file) See https://salsa.debian.org/js-team/pkg-js-tools/tree/master/doc/tools#readme
Bug#1000611: libvtk9{,-qt}: soname change without library transition
Hi Anton, * Anton Gladky [2021-11-25 22:07]: thanks for the bug report. It was really an accidental upload into unstable instead of experimental. Yes, I will rename the package and upload it ASAP. What about uploading the old 9.0.3+dfsg1-3 as 9.1.0+really9.0.3+dfsg1-3 in the meantime to fix unstable? Cheers Jochen Am Do., 25. Nov. 2021 um 22:03 Uhr schrieb Adrian Bunk : Package: libvtk9 Version: 9.1.0+dfsg2-2 Severity: serious Control: affects -1 libvtk9-qt src:vtk9 https://ci.debian.net/data/autopkgtest/testing/amd64/f/freecad/16980590/log.gz ... ERROR: TestFemApp (unittest.loader._FailedTest) -- ImportError: Failed to import test module: TestFemApp Traceback (most recent call last): File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/usr/share/freecad/Mod/Fem/TestFemApp.py", line 33, in from femtest.app.test_mesh import TestMeshCommon as FemTest07 File "/usr/share/freecad/Mod/Fem/femtest/app/test_mesh.py", line 33, in import Fem ImportError: libvtkFiltersExtraction-9.0.so.1: cannot open shared object file: No such file or directory ... The soname of the vtk9 libraries is not 9, it is 9.0 for VTK 9.0 and 9.1 for VTK 9.1: $ objdump -p /usr/lib/x86_64-linux-gnu/libvtkChartsCore-9.1.so.1 | grep SONAME SONAME libvtkChartsCore-9.1.so.1 $ In bullseye libvtk9 and libvtk9-qt should have been named libvtk9.0 and libvtk9.0-qt, but this alone is harmless. Not harmless is that the libraries must transition to the new soname in 9.1, renaming the packages to libvtk9.1 and libvtk9.1-qt. -- debian-science-maintainers mailing list debian-science-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers signature.asc Description: PGP signature
Bug#1000687: RM: node-monocle -- ROM; Broken, useless and orphaned upstream
Package: ftp.debian.org Severity: normal Hi, node-monocle is: * broken (incompatible with node-readdirp): #1000635 * unmaintained in Debian: last MU update 2014-05-07 * orphaned upstream: last real change 2012 * useless in Debian: reverse dependencies: * node-jade: broken (#987967), ROM-RM (#1000686) * isso: broken (#959644), ROM-RM (#1000677) I think these 3 packages should be removed from Debian. Cheers, Yadd
Bug#1000672: [Pkg-javascript-devel] Bug#1000672: @lumino/polling isn't compiled correctly
Hi, Le samedi 27 novembre 2021 à 09:24 +0100, Yadd a écrit : > > This is a known typescript bug, it is unable to use nodejs paths. To > workaround, use this: > > $ cat > debian/nodejs/extlinks << EOF > setimmediate > @types/node > EOF How does that work? Thanks, J.Puydt
