Bug#1071940: r-cran-matrix: why depend on r-base instead of r-base-core?
Package: r-cran-matrix Version: 1.7-0-2 Severity: wishlist Dear Dirk Eddelbuettel, shouldn't this package depend on r-base-core instead of r-base? The description of r-base says it "eases the transition from the pre-1.5.0 package setup" and "once installed, it can be safely removed". Thanks for your work on the R packages. Regards, Jörg.
Bug#1068506: python3-traitlets: breaks jupyter
Package: python3-traitlets Version: 5.14.3-1 Severity: important Dear Debian Python Team, version 5.14.3-1 still breaks jupyter with the same traceback. Regards, Jörg.
Bug#1069305: cython3: dependency on python3-dbg intended?
Package: cython3 Version: 3.0.10+dfsg-3 Severity: wishlist Dear Debian Python Team, is the dependency on python3-dbg intended? When upgrading apt wants to install the packages libpython3-dbg, libpython3.11t64-dbg, python3-dbg, and python3.11-dbg. Regards, Jörg.
Bug#1068506: python3-traitlets: breaks jupyter
Package: python3-traitlets
Version: 5.14.2-2
Severity: important
Dear Debian Python Team,
this version breaks jupyter (package jupyter-core), e.g., commanding
$ jupyter notebook list
which crashes with the following output:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 235, in
_resolve_classes
klass = self._resolve_string(klass)
^^^
File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 2015, in
_resolve_string
return import_item(string)
^^^
File "/usr/lib/python3/dist-packages/traitlets/utils/importstring.py", line
33, in import_item
module = __import__(package, fromlist=[obj])
^^^
ModuleNotFoundError: No module named 'jupyter_server'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/jupyter-notebook", line 33, in
sys.exit(load_entry_point('notebook==6.4.12', 'console_scripts',
'jupyter-notebook')())
^
File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 282,
in launch_instance
super().launch_instance(argv=argv, **kwargs)
File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line
1073, in launch_instance
app = cls.instance(**kwargs)
^^
File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line
583, in instance
inst = cls(*args, **kwargs)
File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1292, in
__new__
inst.setup_instance(*args, **kwargs)
File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1335, in
setup_instance
super(HasTraits, self).setup_instance(*args, **kwargs)
File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1311, in
setup_instance
init(self)
File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 226, in
instance_init
self._resolve_classes()
File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 238, in
_resolve_classes
warn(f"{klass} is not importable. Is it installed?", ImportWarning)
TypeError: warn() missing 1 required keyword-only argument: 'stacklevel'
Reverting to version 5.5.0-2 makes jupyter working again.
Regards,
Jörg.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.8.4 (SMP w/8 CPU threads)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Jupyter packages:
jupyter-client 7.4.9-2
A jupyter-core5.3.2-1
A jupyter-nbextension-jupyter-js-widg 8.1.1-2
jupyter-notebook6.4.12-2.2
A python3-jupyter-client 7.4.9-2
A python3-jupyter-core5.3.2-1
A python3-jupyterlab-pygments 0.2.2-3
A python3-notebook6.4.12-2.2
Python:
python3-dev 3.11.8-1
Versions of packages python3-traitlets depends on:
ii python3 3.11.8-1
python3-traitlets recommends no packages.
python3-traitlets suggests no packages.
-- no debconf information
Bug#1068409: dovecot-core: avoid linking against libsystemd0
Package: dovecot-core Version: 1:2.3.21+dfsg1-3+b1 Severity: wishlist Dear Maintainer(s), in light of the recent xz security breach, I'd like to ask if it would be possible to rework systemd readiness notification and socket activation patches to not link against libsystemd as just achieved for the openssh-server package in version 1:9.7p1-4 ? This would avoid /usr/bin/dovecot being linked also to three compression libraries (liblz4, liblzma, libzstd) and to libgpg-error. Regards, Jörg.
Bug#1067902: elpa-debian-el: regression regarding apt-sources-mode and still warnings (comp)
Package: elpa-debian-el Version: 37.11 Severity: normal Dear Debian Emacsen team, thanks for taking care. Unfortunately, there is a regression when detecting apt-sources-mode. Previously, loading the file /etc/apt/sources.list activated the apt-sources-mode. Now it doesn't. And there are still comp warnings when using debian-bug: Warning (comp): debian-bug.el:858:29: Warning: reference to free variable ‘term-exec-hook’ Warning (comp): debian-bug.el:931:16: Warning: ‘message’ called with 1 args to fill 0 format field(s) Warning (comp): debian-bug.el:861:10: Warning: the function ‘term-exec’ might not be defined at runtime. Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.2 (SMP w/8 CPU threads) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-5.1 ii dh-elpa-helper 2.0.17 ii emacsen-common 3.0.5 ii reportbug 13.0.1 ii xz-utils5.6.1-1 Versions of packages elpa-debian-el recommends: ii emacs1:29.3+1-1 ii emacs-lucid [emacs] 1:29.3+1-1 pn wget elpa-debian-el suggests no packages. -- no debconf information
Bug#1064042: gsettings-desktop-schemas: regression: LC_TIME=en_GB.utf8 uses 12-hour time format
Hello Simon, thank you very much for taking care. Regards, Jörg.
Bug#1064042: gsettings-desktop-schemas: regression: LC_TIME=en_GB.utf8 uses 12-hour time format
Package: gsettings-desktop-schemas Version: 46~beta-1 Severity: normal Dear Debian GNOME Maintainers, upgrading from version 45.0-2 to this version introduces a regression: with LC_TIME=en_GB.utf8 now a 12-hour time format (instead of 24-hour) is used, for example, in thunderbird. Is it intended? If so, is there a reason? Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.4 (SMP w/16 CPU threads) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages gsettings-desktop-schemas depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 gsettings-desktop-schemas recommends no packages. gsettings-desktop-schemas suggests no packages. -- no debconf information
Bug#1063702: xkb-data: german keyboard config fails
Package: xkb-data Version: 2.41-1 Severity: important Dear Maintainer(s), a german-greek keyboard configuration fails after upgrading from version 2.38-2. The config file "/etc/default/keyboard" contains: XKBMODEL="pc105" XKBLAYOUT="de,gr" XKBVARIANT="nodeadkeys,extended" XKBOPTIONS="grp:lwin_toggle,grp_led:scroll" BACKSPACE="guess" (comment lines removed). In "/var/log/Xorg.log" it says: [ 2467.320] (EE) Error loading keymap /tmp/server-0.xkm [ 2467.320] (EE) XKB: Failed to load keymap. Loading default keymap instead. Any idea? Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.3 (SMP w/16 CPU threads) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#1063590: debian-reference-common: debian-reference and mkindexhtml are broken
Package: debian-reference-common Version: 2.113 Severity: important Dear Osamu Aoki, as far as I understand the scripts /usr/share/debian-reference-common/mkindexhtml and /usr/bin/debian-reference are broken since the move of the documents to /usr/share/doc/debian-reference-common/docs . The scripts still use /usr/share/doc/debian-reference as DR_DOC_ROOT which should now be /usr/share/doc/debian-reference-common . Therefore, during installation no index.html is generated and calling debian-reference fails silently. Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.3 (SMP w/16 CPU threads) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages debian-reference-common depends on: ii sensible-utils 0.0.22 Versions of packages debian-reference-common recommends: ii firefox [www-browser] 122.0.1-1 ii w3m [www-browser] 0.5.3+git20230121-2 Versions of packages debian-reference-common suggests: pn calibre pn debian-reference pn debian-reference-de ii debian-reference-en 2.113 pn debian-reference-es pn debian-reference-fr pn debian-reference-id pn debian-reference-it pn debian-reference-ja pn debian-reference-pt pn debian-reference-zh-cn pn debian-reference-zh-tw pn mc pn vim -- no debconf information
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
nut version: 2.8.1-3 Hello Laurent, sometimes it helps to read the documentation :$ In the man page of upsd.conf I read: "LISTEN interface port" ... Multiple LISTEN addresses may be specified. The default is to bind to 127.0.0.1 if no LISTEN addresses are specified (and also ::1 if IPv6 support is compiled in). Assuming upsd is listening on ::1 only, I inserted the line LISTEN 127.0.0.1 into '/etc/nut/upsd.conf' and the UPS can be accessed again. Therefore, I think this bug report should be closed. Could you do that? Thanks for your help and sorry for the noise. Regards, Jörg.
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
nut version: 2.8.1-3 Hello Laurent, it took me a while to set up another computer now with a Debian kernel. I can affirm that nut in my configuration is working as expected. After connecting the UPS via USB cable I had to restart the nut-server: # service nut-server restart resulting in the output > Restarting NUT - power devices information server and drivers: upsd (driver(s) failed) driver(s). upsd. Then I switched off IPv6 again by adding 'ipv6.disable=1' to the variable 'GRUB_CMDLINE_LINUX' in '/etc/default/grub', commanding update-grub as root and restarting the computer. Now the daemon 'upsd' fails to start: # service nut-server restart Restarting NUT - power devices information server and drivers:No upsd found running; none killed. upsd driver(s) (driver(s) failed). (upsd failed). Therefore, I think the severity could be changed to 'minor'. Do you think it might be possible to make nut working without IPv6? Regards, Jörg.
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
Hello Laurent, thanks for taking care. Concerning the configuration files in /etc/nut/, I only changed nut.conf and ups.conf. I described the change in ups.conf in my previous e-mail. In nut.conf I changed only the line MODE=none to MODE=standalone Concerning the loopback (127.0.0.1/::1) interface, here is the output of the command 'ip ad': 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever I disabled IPv6 on my system (the linux kernel is locally configured and compiled). Ssh has no problems on the loopback device, i.e., ssh localhost works. Best regards, Jörg. Laurent Bigonville wrote on 12/01/2024 11:12: severity 1059922 important thanks > Dear Laurent Bigonville, Hello Jörg, > with version 2.8.0-7 an EATON UPS connected to a debian computer via > USB was working in standalone mode as expected. The only change in the > config files was in /etc/nut/ups.conf where I added the following lines: > > [Eaton] > driver = usbhid-ups > port = auto > vendorid = 0463 > pollfreq = 30 > > After the upgrade to version 2.8.1-1 the upsd daemon would fail to > start. The output in /var/log/syslog is > > upsd[12132]: not listening on ::1 port 3493 > upsd[12132]: listening on 127.0.0.1 port 3493 > upsd[12132]: no listening interface available > > instead of > > upsd[12553]: listening on 127.0.0.1 port 3493 > upsd[12553]: not listening on ::1 port 3493 > upsd[12553]: Connected to UPS [Eaton]: usbhid-ups-Eaton > upsd[12555]: Startup successful > > for the working version 2.8.0. > Any ideas? Could you please attach the other configuration files here (please check for clear-text passwords)? Do you have the loopback (127.0.0.1/::1) interface properly working? I cannot reproduce this at home where I have also an EATON UPS Kind regards, Laurent Bigonville
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
Package: nut-server Version: 2.8.1-1 Severity: grave Dear Laurent Bigonville, with version 2.8.0-7 an EATON UPS connected to a debian computer via USB was working in standalone mode as expected. The only change in the config files was in /etc/nut/ups.conf where I added the following lines: [Eaton] driver = usbhid-ups port = auto vendorid = 0463 pollfreq = 30 After the upgrade to version 2.8.1-1 the upsd daemon would fail to start. The output in /var/log/syslog is upsd[12132]: not listening on ::1 port 3493 upsd[12132]: listening on 127.0.0.1 port 3493 upsd[12132]: no listening interface available instead of upsd[12553]: listening on 127.0.0.1 port 3493 upsd[12553]: not listening on ::1 port 3493 upsd[12553]: Connected to UPS [Eaton]: usbhid-ups-Eaton upsd[12555]: Startup successful for the working version 2.8.0. Any ideas? Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9 (SMP w/16 CPU threads) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages nut-server depends on: ii adduser3.137 ii init-system-helpers1.66 ii libc6 2.37-12 ii libmodbus5 3.1.10-1 ii libnspr4 2:4.35-1.1 ii libnss32:3.96.1-1 ii libnutscan22.8.1-1 ii libupsclient6 2.8.1-1 ii libusb-1.0-0 2:1.0.26-1 ii libwrap0 7.6.q-32 ii nut-client 2.8.1-1 ii sysvinit-utils [lsb-base] 3.08-5 ii udev 255.2-2 nut-server recommends no packages.
Bug#1055871: umap-learn: requires tbb, which is not installed ?
Andreas Tille wrote on 14/11/2023 17:02: Am Tue, Nov 14, 2023 at 04:40:57PM +0100 schrieb Jörg-Volker Peetz: Yes, this is due to the line tbb>=2019.0 in the file /usr/lib/python3/dist-packages/umap_learn-0.5.4.egg-info/requires.txt . It's only required on x86* systems. Surely this is what the line says. I might miss something but don't you think at some other place the string tbb should occure if it is needed at all? For me it looks like some leftover from previous versions (which we could probably clarify with upstream). I just notice that the package builds, passes its autopkgtest and might be run on your side (or do you have any issues when using it). The only thing you report is that pip thinks tbb should be installed. Indeed, I just now tried on of my jupyter notebooks which uses umap-learn. That works fine. That supports your reckoning that it's some leftover. -- Regards, Jörg. Kind regards Andreas.
Bug#1055871: umap-learn: requires tbb, which is not installed ?
Hi Andreas,
Andreas Tille wrote on 14/11/2023 14:55:
Hi Jörg,
thanks a lot for your bug report.
Am Mon, Nov 13, 2023 at 11:20:53AM +0100 schrieb Jörg-Volker Peetz:
after upgrading umap-learn the command
python3 -m pip check
results in the message
umap-learn 0.5.4 requires tbb, which is not installed.
That's an interesting finding.
Should this be addressed?
If its true I confirm it should be really be addressed. However, I'm
not sure whether this is some outdated information. In my clone of the
packaging Git repository I did
$ grep -Ri tbb
grep: .git/objects/pack/pack-57537d4033d776efa30645ea203ac00a96c5745b.pack:
binary file matches
setup.py:] + (["tbb >= 2019.0"] if
platform.machine().lower().startswith("x86") else []),
grep: images/densmap_example_mnist.png: binary file matches
grep: images/umap_example_fashion_mnist1.png: binary file matches
IMHO there should be some match for the string tbb somewhere else than
in setup,py which is probably checked by pip.
What do you think?
Yes, this is due to the line
tbb>=2019.0
in the file
/usr/lib/python3/dist-packages/umap_learn-0.5.4.egg-info/requires.txt .
It's only required on x86* systems.
--
Regards,
Jörg.
Kind regards
Andreas.
Bug#1055871: umap-learn: requires tbb, which is not installed ?
Package: umap-learn Version: 0.5.4+dfsg-1 Severity: normal Dear Debian Med Packaging Team, after upgrading umap-learn the command python3 -m pip check results in the message umap-learn 0.5.4 requires tbb, which is not installed. Should this be addressed? Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.9 (SMP w/16 CPU threads) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages umap-learn depends on: ii python3 3.11.4-5+b1 ii python3-numba0.57.1+dfsg-1 ii python3-numpy1:1.24.2-1 ii python3-pandas 1.5.3+dfsg-6 ii python3-pynndescent 0.5.8-2 ii python3-scipy1.10.1-5 ii python3-sklearn 1.2.1+dfsg-1 ii python3-tqdm 4.64.1-1 umap-learn recommends no packages. umap-learn suggests no packages. -- no debconf information
Bug#1024695: and also apt-sources.el
Dear Debian Emacsen team, could you also fix these native-compile warnings: Warning (comp): apt-sources.el:172:2: Warning: defvar `apt-sources-font-lock-deb-regexp' docstring has wrong usage of unescaped single quotes (use \= or different quoting) Warning (comp): apt-sources.el:339:4: Warning: ‘end-of-buffer’ is for interactive use only; use ‘(goto-char (point-max))’ instead. Warning (comp): apt-sources.el:376:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Warning (comp): apt-sources.el:412:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Warning (comp): apt-sources.el:470:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Regards, Jörg.
Bug#1051478: elpa-debian-el: warnings (comp)
Package: elpa-debian-el Version: 37.10 Severity: normal Dear Debian Emacsen team, also for the file 'apt-sources.el' there are warnings when native-compiled: Warning (comp): apt-sources.el:172:2: Warning: defvar `apt-sources-font-lock-deb-regexp' docstring has wrong usage of unescaped single quotes (use \= or different quoting) Warning (comp): apt-sources.el:339:4: Warning: ‘end-of-buffer’ is for interactive use only; use ‘(goto-char (point-max))’ instead. Warning (comp): apt-sources.el:376:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Warning (comp): apt-sources.el:412:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Warning (comp): apt-sources.el:470:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Regards, Jörg.
Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?
Hello Sean, Sean Whitton wrote on 12/09/2023 12:42: Hello, On Tue 12 Sep 2023 at 10:14am +02, Jörg-Volker Peetz wrote: Right you are... It doesn't happen with 'emacs -q'. And putting just these lines: ;;; Set eln-cache dir (when (boundp 'native-comp-eln-load-path) (setcar native-comp-eln-load-path (expand-file-name "~/.cache/emacs-eln-cache/" user-emacs-directory))) into init.el and starting 'emacs' makes the flaw happen. And how about if you put them into early-init.el? thank you very much, that did the trick :-) Just now I learned about the Early Init File from you. As far as I'm concerned, the bug can be closed. -- Regards, Jörg.
Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?
Hello Sean, Sean Whitton wrote on 12/09/2023 09:41: Hello, On Mon 11 Sep 2023 at 08:45pm +02, Jörg-Volker Peetz wrote: Hello, thanks for looking into this. From a terminal (rxvt-unicode) running my shell (mksh) I start emacs (emacs-lucid). After about 15 seconds the following warnings appear: ■ Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘di\ red-mode-map’ ■ Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘di\ red-mode-map’ ■ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of u\ nescaped single quotes (use \= or different quoting) ■ Warning (comp): mmm-vars.el:869:2: Warning: defvar `mmm-classes-alist' docs\ tring has wrong usage of unescaped single quotes (use \= or different quoting) ■ Warning (comp): mmm-auto.el:168:2: Warning: docstring has wrong usage of un\ escaped single quotes (use \= or different quoting) I stop emacs (C-x C-c) and start the next emacs. And again, after about the same time the same warnings appear. As I understand it, the second emacs is re-compiling the modules mentioned in the warnings (and others, as can be seen in the eln-cache directory). The fact the warnings appear does not necessarily mean that any recompilation occurs. The time stamp of the eln files in the cache directory changes. init.el is appended. We'd need a reproduction with 'emacs -q'. Right you are... It doesn't happen with 'emacs -q'. And putting just these lines: ;;; Set eln-cache dir (when (boundp 'native-comp-eln-load-path) (setcar native-comp-eln-load-path (expand-file-name "~/.cache/emacs-eln-cache/" user-emacs-directory))) into init.el and starting 'emacs' makes the flaw happen. -- Regards, Jörg.
Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?
Sean Whitton wrote on 11/09/2023 18:59:
control: severity -1 normal
control: tag -1 + moreinfo
Hello,
On Sun 10 Sep 2023 at 01:15pm +02, Jörg-Volker Peetz wrote:
on my system each newly started emacs process does native-compilation of
all used modules, even the ones already compiled by previous processes.
Is this to be expected?
As I see it, the cached native-compiled modules should be re-used.
Do I have to configure something for that?
It's not expected. But we will need more precise steps to reproduce to
do anything about it.
Hello,
thanks for looking into this.
From a terminal (rxvt-unicode) running my shell (mksh) I start emacs
(emacs-lucid). After about 15 seconds the following warnings appear:
■ Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘di\
red-mode-map’
■ Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘di\
red-mode-map’
■ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of u\
nescaped single quotes (use \= or different quoting)
■ Warning (comp): mmm-vars.el:869:2: Warning: defvar `mmm-classes-alist' docs\
tring has wrong usage of unescaped single quotes (use \= or different quoting)
■ Warning (comp): mmm-auto.el:168:2: Warning: docstring has wrong usage of un\
escaped single quotes (use \= or different quoting)
I stop emacs (C-x C-c) and start the next emacs. And again, after about the same
time the same warnings appear.
As I understand it, the second emacs is re-compiling the modules mentioned in
the warnings (and others, as can be seen in the eln-cache directory).
This happens also when calling `emacs -nw`.
init.el is appended.
Best regards,
Jörg.
;;; Init File for GNU Emacs
;;; Sep 2023
;;; Set eln-cache dir
(when (boundp 'native-comp-eln-load-path)
(setcar native-comp-eln-load-path
(expand-file-name "~/.cache/emacs-eln-cache/" user-emacs-directory)))
;;; Don't show emacs startup screen
(setq inhibit-startup-screen t)
;;; Change mail directory path
(setq message-directory (concat user-emacs-directory "mail/"))
;;; Turn off tool bar
(if (> emacs-major-version 20) (tool-bar-mode 0))
;;; Scroll bar on the right side of frames
(cond (window-system (set-scroll-bar-mode 'right)))
;;; Scroll bar colors (see M-x list-colors-display)
(set-face-attribute 'scroll-bar nil :foreground '"navy" :background '"ivory2")
;;; Let `display-buffer' make a separate frame
(setq pop-up-frames "graphic-only")
;;; Display date and time in the mode line
(setq display-time-string-forms
'(monthname " " day " " 24-hours ":" minutes ))
(setq display-time-interval '3)
(display-time)
;;; As default make indentation from spaces only
(setq-default indent-tabs-mode nil)
;;; Turn on "parenthesis matching" mode
(show-paren-mode t)
;;; Make certain buffers appear in special frames
(setq special-display-regexps
'("\\*compilation\\*" "\\*[mM]an.*\\*"))
(setq special-display-frame-alist
'((height . 40) (width . 80) (unsplittable . f)))
;;; Set Fortran line number indent to zero
(add-hook 'fortran-mode-hook
'(lambda () (setq fortran-line-number-indent 0)))
Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?
Package: emacs Version: 1:29.1+1-5 Severity: wishlist Dear Rob Browning, on my system each newly started emacs process does native-compilation of all used modules, even the ones already compiled by previous processes. Is this to be expected? As I see it, the cached native-compiled modules should be re-used. Do I have to configure something for that? Thanks for your work on the debian emacs packages and regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.12 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages emacs depends on: ii emacs-lucid 1:29.1+1-5 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#1051478: elpa-debian-el: warnings (comp)
Package: elpa-debian-el Version: 37.10 Severity: normal Dear Debian Emacsen team, after starting emacs lucid under X11 the following warnings pop up after a few moments: Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘dired-mode-map’ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) Could these be taken care of? Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.12 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-5+b1 ii dh-elpa-helper 2.0.17 ii dpkg1.22.0 ii emacsen-common 3.0.5 ii reportbug 12.0.0 ii xz-utils5.4.1-0.2 Versions of packages elpa-debian-el recommends: ii emacs1:29.1+1-5 ii emacs-lucid [emacs] 1:29.1+1-5 pn wget elpa-debian-el suggests no packages. -- no debconf information
Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf
Thank you very much for taking care. Regards, Jörg.
Bug#1050864: nginx-common: dangling soft link
Package: nginx-common Version: 1.24.0-1 Severity: normal Dear Nginx Maintainer, there is this dangling soft link in the package: /usr/share/nginx/modules Shouldn't it be removed? Regards, Jörg.
Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf
Package: fontconfig-config Version: 2.14.2-3 Severity: normal Dear Debian freedesktop.org maintainers, the removal of /usr/share/fontconfig/conf.avail/10-no-sub-pixel.conf left a dangling symlink: /etc/fonts/conf.d/10-no-sub-pixel.conf Regards, Jörg. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.12 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages fontconfig-config depends on: ii debconf [debconf-2.0] 1.5.82 ii fonts-dejavu-core 2.37-8 ii fonts-freefont-otf 20211204+svn4273-2 ii fonts-liberation 1:2.1.5-3 ii fonts-noto-core20201225-2 ii fonts-texgyre 20180621-6 ii fonts-urw-base35 20200910-7 fontconfig-config recommends no packages. fontconfig-config suggests no packages. -- debconf information: * fontconfig/hinting_type: Native * fontconfig/subpixel_rendering: Never * fontconfig/enable_bitmaps: false fontconfig/hinting_style: hintslight
Bug#1042518: apt: preserve markauto if upgrading a packages with install ~U~nREGEX
Package: apt Version: 2.7.2 Severity: wishlist Dear APT Development Team, aptitude preserves the markauto state when upgrading one or more package(s) with, e.g., aptitude install '~Ulibboost' But apt does not when calling apt install '~U~nlibboost' I wished apt would also preserve the markauto settings. Regards, Jörg. -- Package-specific info: <#part type="text/plain" disposition=attachment description="Bug script output"> -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "false"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "tasks"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "zstd"; APT::Compressor::zstd::Cost "60"; APT::Compressor::zstd::CompressArg ""; APT::Compressor::zstd::CompressArg:: "-19"; APT::Compressor::zstd::UncompressArg ""; APT::Compressor::zstd::UncompressArg:: "-d"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir::Etc::netrcparts "auth.conf.d"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences "preferences"; Dir::Etc::preferencesparts "preferences.d"; Dir::Etc::trusted "trusted.gpg"; Dir::Etc::trustedparts "trusted.gpg.d"; Dir::Bin ""; Dir::Bin::methods "/usr/lib/apt/methods"; Dir::Bin::solvers ""; Dir::Bin::solvers:: "/usr/lib/apt/solvers"; Dir::Bin::planners ""; Dir::Bin::planners:: "/usr/lib/apt/planners"; Dir::Bin::dpkg "/usr/bin/dpkg"; Dir::Bin::gzip "/bin/gzip"; Dir::Bin::bzip2 "/bin/bzip2"; Dir::Bin::xz "/usr/bin/xz"; Dir::Bin::lz4 "/usr/bin/lz4"; Dir::Bin::zstd "/usr/bin/zstd"; Dir::Bin::lzma "/usr/bin/xz"; Dir::Media ""; Dir::Media::MountPath "/media/apt"; Dir::Log "var/log/apt"; Dir::Log::Terminal "term.log"; Dir::Log::History "history.log"; Dir::Log::Planner "eipp.log.xz";
Bug#1040927: redmine: bashism in postinst script
Package: redmine Version: 5.0.4-7 Severity: serious Dear Maintainer, two bashisms in the postinst script in lines 7 and 57: `if [[ ...` lead to message /var/lib/dpkg/info/redmine.postinst: 7: [[: not found and /var/lib/dpkg/info/redmine.postinst: 57: [[: not found Probably not what is intended. Regards, Jörg.
Bug#1031520: maxima: triggers kernel error about memory allocation glitch
Thank you for looking into this and the explanations. Meanwhile I found the kernel commit which introduced this warning: https://lkml.kernel.org/lkml/ceefb6c0-fbed-447f-791f-c48d3a4c4...@huawei.com/t/ Maybe then, the kernel people are to blame and the bug could be closed. Regards, Jörg. Camm Maguire wrote on 18/02/2023 15:46: Greetings, and thanks for your report! GCL based applications probe brk at runtime to determine an upper bound for its permissible heap. Running under strace -f is usually helpful to see if your kernel messages are correlated with this loop. To my understanding, if brk triggers a 'no enough memory for the allocation' condition, it should simply return an error code to the user space process, and not generate any kernel level difficulties. brk just reserves the memory, and does not actually allocate it until it is written, so no oom machinery should be involved. Take care, Jörg-Volker Peetz writes: Package: maxima Version: 5.46.0-11 Severity: normal Dear Camm Maguire, calling maxima generates a kernel message: kernel: __vm_enough_memory: 1 callbacks suppressed kernel: __vm_enough_memory: pid: 13721, comm: maxima, no enough memory for the allocation The second line appears 10 times. I'm using a self-compiled upstream kernel. Any idea? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.11 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages maxima depends on: ii libc6 2.36-8 ii libedit2 3.1-20221030-2 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libtirpc3 1.3.3+ds-1 ii libx11-6 2:1.8.3-3 Versions of packages maxima recommends: ii gnuplot-qt [gnuplot-x11] 5.4.4+dfsg1-2+b2 ii maxima-share 5.46.0-11 Versions of packages maxima suggests: ii maxima-doc5.46.0-11 ii maxima-emacs 5.46.0-11 pn texmacs ii tk [wish] 8.6.11+1 pn xmaxima -- no debconf information
Bug#1031520: maxima: triggers kernel error about memory allocation glitch
Package: maxima Version: 5.46.0-11 Severity: normal Dear Camm Maguire, calling maxima generates a kernel message: kernel: __vm_enough_memory: 1 callbacks suppressed kernel: __vm_enough_memory: pid: 13721, comm: maxima, no enough memory for the allocation The second line appears 10 times. I'm using a self-compiled upstream kernel. Any idea? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.11 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages maxima depends on: ii libc6 2.36-8 ii libedit2 3.1-20221030-2 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libtirpc3 1.3.3+ds-1 ii libx11-6 2:1.8.3-3 Versions of packages maxima recommends: ii gnuplot-qt [gnuplot-x11] 5.4.4+dfsg1-2+b2 ii maxima-share 5.46.0-11 Versions of packages maxima suggests: ii maxima-doc5.46.0-11 ii maxima-emacs 5.46.0-11 pn texmacs ii tk [wish] 8.6.11+1 pn xmaxima -- no debconf information
Bug#1029601: closed by Debian FTP Masters (reply to Daniel Leidert ) (Bug#1029601: fixed in redmine 5.0.4-2)
Hi again, right after sending the previous E-mail I noticed that the "without" setting is already done in /usr/share/redmine/.bundle/config". So that still needs the dependency on package ruby-mocha. How about using a second Gemfile for the tests? Regards, Jörg. Jörg-Volker Peetz wrote on 03/02/2023 15:03: Hi, thanks for looking into this. On a second thought it might be better to change the `bundle install` line in the postinst script to include "--without=test". I have no experience with bundle. Would that work and allow to avoid the dependency on the package ruby-mocha? Regards, Jörg.
Bug#1029601: closed by Debian FTP Masters (reply to Daniel Leidert ) (Bug#1029601: fixed in redmine 5.0.4-2)
Hi, thanks for looking into this. On a second thought it might be better to change the `bundle install` line in the postinst script to include "--without=test". I have no experience with bundle. Would that work and allow to avoid the dependency on the package ruby-mocha? Regards, Jörg.
Bug#1029834: dpkg: cycle found while processing triggers
Hi Guillem, thanks for looking into this. Guillem Jover wrote on 01/02/2023 23:20: Control: tag -1 moreinfo Hi! On Sat, 2023-01-28 at 14:30:15 +0100, Jörg-Volker Peetz wrote: Package: dpkg Version: 1.21.19 Severity: normal upgrading the openjdk-17 packages on my system with # aptitude -t sid install ~Uopenjdk gives this error messages: dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: ca-certificates-java -> ca-certificates-java -> ca-certificates-java packages' pending triggers which are or may be unresolvable: ca-certificates-java: /usr/lib/jvm dpkg: error processing package ca-certificates-java (--configure): triggers looping, abandoned Setting up openjdk-17-jdk-headless:amd64 (17.0.6+10-1) ... Setting up ca-certificates-java (20230103) ... done. Setting up openjdk-17-jre:amd64 (17.0.6+10-1) ... Setting up openjdk-17-jdk:amd64 (17.0.6+10-1) ... Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) Any ideas? Was there any other error during the unpack or installation in general? Do you have the full log of that upgrade session? From what version were you upgrading from? There was no other error during the whole upgrade but I don't have the full log anymore. In spite of the error message the upgrade was successful. After each upgrade I check the installation with the commands: # apt-get check ; dpkg -C ; aptitude search '~b' '~g' '~c' The version of openjdk-17 was 17.0.5+8-2 before this upgrade. And I have to correct the version of ca-certificates-java which was 20230103. Do you perhaps have a backup of the status files from just before that upgrade session? (Either the /var/lib/dpkg/status-old if you have not done anything else package-wise since then, or perhaps under /var/backups.) Yes I have the status file. Compressed it is ca. 400 kB. I don't know if it's o.k. to attach it. Otherwise this unfortunately seems a bit non-actionable to me. :/ Yes, I know :-( On a second, similar computer I didn't see the error message. Thanks, Guillem Thanks, Jörg.
Bug#1029834: dpkg: cycle found while processing triggers
Package: dpkg Version: 1.21.19 Severity: normal Dear Dpkg Developers, upgrading the openjdk-17 packages on my system with # aptitude -t sid install ~Uopenjdk gives this error messages: dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: ca-certificates-java -> ca-certificates-java -> ca-certificates-java packages' pending triggers which are or may be unresolvable: ca-certificates-java: /usr/lib/jvm dpkg: error processing package ca-certificates-java (--configure): triggers looping, abandoned Setting up openjdk-17-jdk-headless:amd64 (17.0.6+10-1) ... Setting up ca-certificates-java (20230103) ... done. Setting up openjdk-17-jre:amd64 (17.0.6+10-1) ... Setting up openjdk-17-jdk:amd64 (17.0.6+10-1) ... Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) Any ideas? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.6 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-5+b1 ii libc62.36-8 ii liblzma5 5.4.1-0.0 ii libmd0 1.0.4-2 ii libselinux1 3.4-1+b4 ii libzstd1 1.5.2+dfsg2-3 ii tar 1.34+dfsg-1.1 ii zlib1g 1:1.2.13.dfsg-1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.5.5 pn debsig-verify Version of packages involved: ii openjdk-17-jdk:amd64 17.0.5+8-2 ii openjdk-17-jdk-headless:amd64 17.0.5+8-2 ii openjdk-17-jre:amd64 17.0.5+8-2 ii openjdk-17-jre-headless:amd64 17.0.5+8-2 ii ca-certificates 20211016 ii ca-certificates-java 20220719 -- no debconf information
Bug#1015751: redmine: /usr/lib/x86_64-linux-gnu/rubygems-integration not in triggers file
Version: 5.0.4-1 Dear Debian Ruby Team, this bug is still present in version 5.0.4-1. Regards, Jörg.
Bug#1029601: redmine: upgrade fails because of missing dependency on mocha
Package: redmine Version: 5.0.4-1 Severity: serious Dear Debian Ruby Team, upgrading redmine from version 5.0.2-2 fails with error message: ``` Could not find gem 'mocha (>= 1.4.0)' in cached gems or installed locally. dpkg: error processing package redmine (--configure): installed redmine package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: redmine E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up redmine (5.0.4-1) ... Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root will break this application for all non-root users on this machine. Could not find gem 'mocha (>= 1.4.0)' in cached gems or installed locally. dpkg: error processing package redmine (--configure): installed redmine package post-installation script subprocess returned error exit status 1 ``` Should redmine depend on ruby-mocha? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.6 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages redmine depends on: ii dbconfig-common 2.0.22 ii debconf [debconf-2.0] 1.5.82 ii libjs-chart.js 3.9.1+~0.2.1-2 ii libjs-jquery3.6.1+dfsg+~3.5.14-1 ii libjs-jquery-ui 1.13.2+dfsg-1 ii libjs-raphael 2.3.0-4 ii libruby3.1 [ruby-csv] 3.1.2-3 ii redmine-sqlite 5.0.4-1 ii ruby1:3.1 ii ruby-actionpack-action-caching 1.2.2-1 ii ruby-actionpack-xml-parser 2.0.1-4 ii ruby-addressable2.8.0-3 ii ruby-bundler2.3.15-2 ii ruby-coderay1.1.3-8 ii ruby-commonmarker 0.23.6-1+b1 ii ruby-csv3.2.2-1 ii ruby-html-pipeline 2.14.3-1 ii ruby-i18n 1.10.0-2 ii ruby-jquery-rails 4.3.5-4 ii ruby-mail 2.7.1+dfsg1-2 ii ruby-marcel 1.0.1+dfsg-2 ii ruby-mini-magick4.11.0-1 ii ruby-mini-mime 1.1.1-2 ii ruby-net-ldap 0.17.0-1 ii ruby-nokogiri 1.13.10+dfsg-2+b1 ii ruby-rack 2.2.4-2 ii ruby-rack-test 2.0.2-2 ii ruby-rails 2:6.1.7+dfsg-3 ii ruby-rails-dom-testing 2.0.3-4 ii ruby-rails-observers0.1.5-1.1 ii ruby-rbpdf 1.20.1-2 ii ruby-redcarpet 3.5.1-1+b4 ii ruby-request-store 1.5.1-1 ii ruby-rmagick4.2.3-2+b4 ii ruby-roadie 5.1.0-1 ii ruby-roadie-rails 3.0.0-1 ii ruby-rotp 6.2.0-2 ii ruby-rouge 3.30.0-2 ii ruby-rqrcode1.2.0-1 ii ruby-sanitize 6.0.0-1 ii ruby-task-list 2.3.2-2 ii ruby-zip2.3.2-1 Versions of packages redmine recommends: pn passenger Versions of packages redmine suggests: pn bzr ii cvs 2:1.12.13+real-28 pn darcs ii git 1:2.39.0-1 pn mercurial pn ruby-fcgi ii subversion 1.14.2-4+b1 -- debconf information: redmine/instances/default/pgsql/authmethod-admin: ident redmine/instances/default/remove-error: abort redmine/instances/default/pgsql/authmethod-user: password redmine/instances/default/dbconfig-reinstall: false redmine/instances/default/pgsql/method: TCP/IP redmine/instances/default/pgsql/manualconf: redmine/instances/default/internal/reconfiguring: false redmine/instances/default/dbconfig-upgrade: true * redmine/instances/default/db/dbname: redmine.sqlite redmine/instances/default/purge: false redmine/instances/default/pgsql/no-empty-passwords: * redmine/instances/default/db/basepath: /var/lib/redmine/default/db redmine/old-instances: * redmine/instances/default/dbconfig-install: true redmine/instances/default/upgrade-error: abort * redmine/instances/default/database-type: sqlite3 redmine/instances/default/db/app-user: redmine redmine/default-language: en redmine/instances/default/mysql/method: Unix socket redmine/instances/default/mysql/admin-user: redmine/instances/default/upgrade-backup: true redmine/notify-migration: redmine/missing-redmine-package: redmine/instances/default/dbconfig-remove: redmine/instances/default/remote/port: redmine/instances/default/passwords-do-not-match: redmine/instances/default/install-error: abort * redmine/instances/default/default-language: en redmine/instances/default/internal/skip-preseed: true
Bug#1028908: python3-pynndescent: "import pynndescent.sparse as sparse" results in error
Package: python3-pynndescent
Version: 0.5.7-1
Severity: serious
Dear Debian Python Team,
in the python3 or ipython3 interpreter, the Python statement
import pynndescent.sparse as sparse
fails and the output in ipython3 is
```
---
TypingError Traceback (most recent call last)
Cell In [1], line 1
> 1 import pynndescent.sparse as sparse
File /usr/lib/python3/dist-packages/pynndescent/__init__.py:3
1 import pkg_resources
2 import numba
> 3 from .pynndescent_ import NNDescent, PyNNDescentTransformer
5 # Workaround: https://github.com/numba/numba/issues/3341
6 if numba.config.THREADING_LAYER == "omp":
File /usr/lib/python3/dist-packages/pynndescent/pynndescent_.py:16
12 from scipy.sparse import csr_matrix, coo_matrix, isspmatrix_csr, vstack
as sparse_vstack, issparse
14 import heapq
---> 16 import pynndescent.sparse as sparse
17 import pynndescent.sparse_nndescent as sparse_nnd
18 import pynndescent.distances as pynnd_dist
File /usr/lib/python3/dist-packages/pynndescent/sparse.py:381
377 result += aux_data[i] ** 2
378 return np.sqrt(result)
--> 381 @numba.njit(
382 [
383 "f4(i4[::1],f4[::1],i4[::1],f4[::1])",
384 numba.types.float32(
385 numba.types.Array(numba.types.int32, 1, "C", readonly=True),
386 numba.types.Array(numba.types.float32, 1, "C",
readonly=True),
387 numba.types.Array(numba.types.int32, 1, "C", readonly=True),
388 numba.types.Array(numba.types.float32, 1, "C",
readonly=True),
389 ),
390 ],
391 fastmath=True,
392 locals={
393 "aux_data": numba.types.float32[::1],
394 "result": numba.types.float32,
395 "diff": numba.types.float32,
396 "dim": numba.types.intp,
397 "i": numba.types.uint16,
398 },
399 )
400 def sparse_squared_euclidean(ind1, data1, ind2, data2):
401 _, aux_data = sparse_diff(ind1, data1, ind2, data2)
402 result = 0.0
File /usr/lib/python3/dist-packages/numba/core/decorators.py:219, in
_jit..wrapper(func)
217 with typeinfer.register_dispatcher(disp):
218 for sig in sigs:
--> 219 disp.compile(sig)
220 disp.disable_compile()
221 return disp
File /usr/lib/python3/dist-packages/numba/core/dispatcher.py:965, in
Dispatcher.compile(self, sig)
963 with ev.trigger_event("numba:compile", data=ev_details):
964 try:
--> 965 cres = self._compiler.compile(args, return_type)
966 except errors.ForceLiteralArg as e:
967 def folded(args, kws):
File /usr/lib/python3/dist-packages/numba/core/dispatcher.py:129, in
_FunctionCompiler.compile(self, args, return_type)
127 return retval
128 else:
--> 129 raise retval
File /usr/lib/python3/dist-packages/numba/core/dispatcher.py:139, in
_FunctionCompiler._compile_cached(self, args, return_type)
136 pass
138 try:
--> 139 retval = self._compile_core(args, return_type)
140 except errors.TypingError as e:
141 self._failed_cache[key] = e
File /usr/lib/python3/dist-packages/numba/core/dispatcher.py:152, in
_FunctionCompiler._compile_core(self, args, return_type)
149 flags = self._customize_flags(flags)
151 impl = self._get_implementation(args, {})
--> 152 cres = compiler.compile_extra(self.targetdescr.typing_context,
153 self.targetdescr.target_context,
154 impl,
155 args=args, return_type=return_type,
156 flags=flags, locals=self.locals,
157 pipeline_class=self.pipeline_class)
158 # Check typing error if object mode is used
159 if cres.typing_error is not None and not flags.enable_pyobject:
File /usr/lib/python3/dist-packages/numba/core/compiler.py:716, in
compile_extra(typingctx, targetctx, func, args, return_type, flags, locals,
library, pipeline_class)
692 """Compiler entry point
693
694 Parameter
(...)
712 compiler pipeline
713 """
714 pipeline = pipeline_class(typingctx, targetctx, library,
715 args, return_type, flags, locals)
--> 716 return pipeline.compile_extra(func)
File /usr/lib/python3/dist-packages/numba/core/compiler.py:452, in
CompilerBase.compile_extra(self, func)
450 self.state.lifted = ()
451 self.state.lifted_from = None
--> 452 return self._compile_bytecode()
File /usr/lib/python3/dist-packages/numba/core/compiler.py:520, in
CompilerBase._compile_bytecode(self)
516 """
517 Populate and run pipeline for bytecode input
518 """
519 assert self.state.func_ir is None
--> 520 return self._compile_core()
File
Bug#1027140: keepassxc: requires Qt 5.15.7 - dependencies outdated?
Julian Andres Klode wrote on 28/12/2022 15:18: Control: reassign -1 qtbase5-dev 5.15.7+dfsg-2 Control: affects -1 keepassxc On Wed, Dec 28, 2022 at 03:11:55PM +0100, Jörg-Volker Peetz wrote: Julian Andres Klode wrote on 28/12/2022 13:08: Control: tag -1 moreinfo On Wed, Dec 28, 2022 at 12:52:35PM +0100, Jörg-Volker Peetz wrote: Package: keepassxc Version: 2.7.4+dfsg.1-1 Severity: grave Dear Julian Andres Klode, Qt libraries are not updated as necessary. The dependencies should be updated? What is your issue? Dependencies are automatically generated at build-time from the shlibs files in the Qt packages, I don't control them. It can be built against any version >= 5.2.0 Hi, after upgrading keepassxc to version 2.7.4+dfsg.1-1 the executable keepassxc won't start but an error message Executable 'keepassxc' requires Qt 5.15.7, found Qt 5.15.6. pops up in a window titled "Incompatible Qt Library Error". The upgrade of keepassxc should have incurred an upgrade of the relevant Qt libraries, I thought. I guess some symbol version needs bumping and then keepassxc and other rdeps need binNMUing, but it's not a keepassxc packaging issue. Thanks for taking care and, by the way, thanks for maintaining this package I value very much :-) Regards, Jörg.
Bug#1027140: keepassxc: requires Qt 5.15.7 - dependencies outdated?
Julian Andres Klode wrote on 28/12/2022 13:08: Control: tag -1 moreinfo On Wed, Dec 28, 2022 at 12:52:35PM +0100, Jörg-Volker Peetz wrote: Package: keepassxc Version: 2.7.4+dfsg.1-1 Severity: grave Dear Julian Andres Klode, Qt libraries are not updated as necessary. The dependencies should be updated? What is your issue? Dependencies are automatically generated at build-time from the shlibs files in the Qt packages, I don't control them. It can be built against any version >= 5.2.0 Hi, after upgrading keepassxc to version 2.7.4+dfsg.1-1 the executable keepassxc won't start but an error message Executable 'keepassxc' requires Qt 5.15.7, found Qt 5.15.6. pops up in a window titled "Incompatible Qt Library Error". The upgrade of keepassxc should have incurred an upgrade of the relevant Qt libraries, I thought. Regards, Jörg.
Bug#1027140: keepassxc: requires Qt 5.15.7 - dependencies outdated?
Package: keepassxc Version: 2.7.4+dfsg.1-1 Severity: grave Dear Julian Andres Klode, Qt libraries are not updated as necessary. The dependencies should be updated? Regards, Jörg -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.15 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages keepassxc depends on: ii libargon2-10~20171227-0.3 ii libbotan-2-19 2.19.3+dfsg-1 ii libc6 2.36-6 ii libgcc-s1 12.2.0-10 ii libminizip11.1-8+b1 ii libpcsclite1 1.9.9-1 ii libqrencode4 4.1.1-1 ii libqt5concurrent5 5.15.6+dfsg-4 ii libqt5core5a 5.15.6+dfsg-4 ii libqt5dbus55.15.6+dfsg-4 ii libqt5gui5 5.15.6+dfsg-4 ii libqt5network5 5.15.6+dfsg-4 ii libqt5svg5 5.15.6-2 ii libqt5widgets5 5.15.6+dfsg-4 ii libqt5x11extras5 5.15.6-2 ii libreadline8 8.2-1.2 ii libstdc++6 12.2.0-10 ii libusb-1.0-0 2:1.0.26-1 ii libx11-6 2:1.8.3-3 ii libxtst6 2:1.2.3-1.1 ii libzxcvbn0 2.5+dfsg-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages keepassxc recommends: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 Versions of packages keepassxc suggests: pn webext-keepassxc-browser pn xclip -- no debconf information
Bug#1021947: dbus-daemon: creates socket file in /tmp readable, writeable for everyone
Package: dbus-daemon Version: 1.14.4-1 Severity: important Dear Utopia Maintenance Team, on my machine with sysv init, starting firefox through an ssh X tunnel creates a socket file in /tmp, e.g., /tmp/dbus-TisQYrBfOV which is world readable, writable, executable (o=rwx). Is this intended? Isn't it a security problem? The output of 'lsof | grep /tmp/dbus' says dbus-daemon is connected to the socket. Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.2 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages dbus-daemon depends on: ii dbus-bin 1.14.4-1 ii dbus-session-bus-common 1.14.4-1 ii libapparmor1 3.0.7-1 ii libaudit11:3.0.7-1.1 ii libc62.35-3 ii libcap-ng0 0.8.3-1+b1 ii libdbus-1-3 1.14.4-1 ii libexpat12.4.9-1 ii libselinux1 3.4-1+b2 ii libsystemd0 251.6-1 dbus-daemon recommends no packages. dbus-daemon suggests no packages. -- no debconf information
Bug#1021933: systemd-standalone-tmpfiles: should contain man-page for tmpfiles.d(5)
Package: systemd-standalone-tmpfiles Version: 251.6-1 Severity: wishlist Dear systemd Maintainer(s), shouldn't this package contain the man-page for tmpfiles.d(5) which is mentioned in the already contained man-page for systemd-tmpfiles ? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.2 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd-standalone-tmpfiles depends on: ii libacl1 2.3.1-1 ii libc62.35-3 ii libcap2 1:2.44-1 ii libselinux1 3.4-1+b2 systemd-standalone-tmpfiles recommends no packages. systemd-standalone-tmpfiles suggests no packages. -- no debconf information
Bug#1015751: redmine: /usr/lib/x86_64-linux-gnu/rubygems-integration not in triggers file
Package: redmine Version: 5.0.0-1 Severity: important Dear Debian Ruby Team, the file /var/lib/dpkg/info/redmine.triggers doesn't contain the path /usr/lib/x86_64-linux-gnu/rubygems-integration For example, a dependency of redmine is ruby-nokogiri which has its gemspec file in /usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0/specifications and an upgrade of that package renders redmine unusable. Shouldn't the triggers file be adapted? Regards, Jörg.
Bug#1012802: python3-ipykernel: breaks jupyter notebook
Package: python3-ipykernel Version: 6.13.1-1 Severity: serious Dear Debian Python Modules Team, trying to load a jupyter notebook fails with the message /usr/bin/python3: No module named ipykernel_launcher Indeed, in the package there is no file `/usr/lib/python3/dist-packages/ipykernel_launcher.py` any more. Not any file in `/usr/lib/`. Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.3 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-ipykernel depends on: ii python33.9.8-1 ii python3-ipython7.31.1-1 ii python3-jupyter-client 7.3.4-1 ii python3-matplotlib-inline 0.1.3-1 ii python3-nest-asyncio 1.5.4-1 ii python3-packaging 21.3-1 ii python3-psutil 5.9.0-1 ii python3-tornado6.1.0-3 ii python3-traitlets 5.2.2-1 python3-ipykernel recommends no packages. python3-ipykernel suggests no packages. -- no debconf information
Bug#1012681: python3-jupyter-client: unfulfilled requirements?
Package: python3-jupyter-client Version: 7.3.4-1 Severity: normal Dear Debian Python Team, the command $ python3 -m pip check gives: jupyter-client 7.3.4 has requirement python-dateutil>=2.8.2, but you have python-dateutil 2.8.1. jupyter-client 7.3.4 has requirement pyzmq>=23.0, but you have pyzmq 22.3.0. Is this serious? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.3 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-jupyter-client depends on: ii python3 3.9.8-1 ii python3-dateutil 2.8.1-6 ii python3-entrypoints 0.4-1 ii python3-jupyter-core 4.10.0-1 ii python3-nest-asyncio 1.5.4-1 ii python3-tornado 6.1.0-3 ii python3-traitlets 5.2.2-1 ii python3-zmq 22.3.0-1 python3-jupyter-client recommends no packages. python3-jupyter-client suggests no packages. -- no debconf information
Bug#1004855: python3-ipykernel: missing dependency on debugpy
Hi, in the upstream GitHub of ipykernel there's this advice concerning the dependency on debugpy: https://github.com/ipython/ipykernel/pull/767#issuecomment-916913893 "No, it shouldn't be removed in this repo. If a downstream packager wants to split this dependency, it may, but at the same time, it should also make sure to patch the package metadata when doing so to remove the dependency and satisfy pip check." Regards, Jörg.
Bug#1004150: alsa-utils: How is ALSACTLRUNTIME defined?
Dear Debian ALSA Maintainers,
meanwhile I think this is a real bug. If the pulseaudio package is installed,
the alsa-utils script will create the directory '/pulse' at boot time.
Therefore, I propose the appended patch.
Regards,
Jörg.
diff -Naur o/alsa-utils n/alsa-utils
--- o/alsa-utils 2019-11-05 16:39:55.0 +0100
+++ n/alsa-utils 2022-02-02 22:40:16.075852685 +0100
@@ -26,8 +26,9 @@
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MYNAME=/etc/init.d/alsa-utils
ALSACTLHOME=/run/alsa
+ALSACTLRUNTIME="${ALSACTLHOME}/runtime"
-[ -d "$ALSACTLHOME" ] || mkdir -p "$ALSACTLHOME"
+[ -d "$ALSACTLRUNTIME" ] || mkdir -p "$ALSACTLRUNTIME"
. /lib/lsb/init-functions
. /usr/share/alsa/utils.sh
@@ -82,7 +83,7 @@
sleep 1
return 0
else
- log_action_cont_msg "warning: 'alsactl store${CARD:+ $CARD}' -E HOME="$ALSACTLHOME" -E XDG_RUNTIME_DIR=@alsactlruntime@ failed with error message '$MSG'"
+ log_action_cont_msg "warning: 'alsactl store${CARD:+ $CARD}' -E HOME="$ALSACTLHOME" -E XDG_RUNTIME_DIR="${ALSACTLRUNTIME}" failed with error message '$MSG'"
return 1
fi
}
Bug#1003934: python3-pil: replace dependency on package mime-support
Package: python3-pil Version: 9.0.0-1 Severity: wishlist Dear Matthias Klose, `mime-support` is marked as transitional package. Maybe, the dependency on this package can be replaced by a dependency on `media-types`? Regards, Jörg.
Bug#1003722: jupyter-notebook: blank page in firefox
Package: jupyter-notebook Version: 6.4.5-3 Severity: normal X-Debbugs-Cc: none, J-V Peetz Dear Debian Python Team, with firefox (96.0-1 or 95.0.1-1) just a blank page is shown when calling the URL of the notebook server startet with `jupyter notebook --port=8177 --no-browser`. Any suggestions? Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.13 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages jupyter-notebook depends on: ii init-system-helpers 1.61 ii jupyter-core 4.9.1-1 ii python3 3.9.8-1 ii python3-notebook 6.4.5-3 jupyter-notebook recommends no packages. jupyter-notebook suggests no packages. -- no debconf information
Bug#1000260: python3-ptyprocess: should this package be visible with pip3 list?
Package: python3-ptyprocess Version: 0.7.0-1 Severity: wishlist X-Debbugs-Cc: none, J-V Peetz Dear Debian Python Team, I just wanted to ask if this python package, and may be all installed, should appear in the list delivered by the command python3 -m pip list In consequence, the command python3 -m pip check results in the message terminado 0.12.1 requires ptyprocess, which is not installed. Many thanks for your work on the python modules packages. Regards, Jörg. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.2 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-ptyprocess depends on: ii python3 3.9.8-1 python3-ptyprocess recommends no packages. python3-ptyprocess suggests no packages. -- no debconf information
Bug#998184: libsundials-sunlinsol2: dependency on certain flavor of libsundials-nvecparallel
Package: libsundials-sunlinsol2 Version: 5.8.0+dfsg-1 Severity: wishlist Dear Debian Science Team, why does this package depend on package libsundials-nvecparallel-petsc4 that is a certain flavor of the libsundials-nvecparallel packages? Wouldn't it be possible to introduce a general libsundials-nvecparallel package which in turn depends an any of the libsundials-nvecparallel flavor packages (libsundials-nvecparallel-petsc4 | libsundials-nvecparallel-openmp4 | libsundials-nvecparallel-mpi4 | libsundials-nvecparallel-hypre4)? For example, the libopenblas0 package is a dependency package which gives the choice to install one of libopenblas0-pthread | libopenblas0-openmp | libopenblas0-serial. Regards, Jörg.
Bug#998002: mupdf: What is the purpose of /usr/bin/mupdf-gl?
Package: mupdf Version: 1.19.0+ds1-1 Severity: wishlist X-Debbugs-Cc: none, J-V Peetz Dear Maintainer(s), many thanks for your work on mupdf. May I ask, what is the purpose of /usr/bin/mupdf-gl? The main script /usr/bin/mupdf doesn't make use of it. The executable used in that script is /usr/lib/mupdf-x11. Could you please say some words about /usr/bin/mupdf-gl in the changelog? Regards, Jörg.
Bug#896460: python3-tqdm works correctly only with ipywidgets 7.6
Dear Maintainer(s), package python3-tqdm won't work with current version 6.0.0. Try this short example in a jupyter notebook: from tqdm.notebook import trange, tqdm from time import sleep for i in trange(3, desc='1st loop'): for j in tqdm(range(100), desc='2nd loop'): sleep(0.01) I got this answer on tqdm's github repository: https://github.com/tqdm/tqdm/issues/1156 which supports the need for upgrading the ipywidgets version in debian. Regards, Jörg.
Bug#985582: texlive-latex-extra: Dangling link
Hello Hilmar, right you are. Te file is in the non-free package icc-profiles. I didn't search in non-free. Sorry for the noise and thanks for your effort. Regards, Jörg Hilmar Preuße wrote on 20/03/2021 17:00: Am 20.03.2021 um 12:47 teilte Jörg-Volker Peetz mit: Hi, the command 'find -L /usr -type l' shows, that there is another dangling soft link /usr/share/texlive/texmf-dist/tex/latex/pdfx/sRGB_IEC61966-2-1_black_scaled.icc I couldn't find the file sRGB_IEC61966-2-1_black_scaled.icc in any testing package. Ehhh? I can see it in icc-profiles from non-free. Maybe the location of the file changed in the meantime. Could you double check? Hilmar
Bug#985584: sysv-rc: proc: Unknown parameter 'compatible'
Package: sysv-rc Version: 2.96-6 Severity: normal Dear Maintainer, recently, my system prints out proc: Unknown parameter 'compatible' while booting. A remedy is to change line 78 in /lib/init/rc mount -t proc none /proc -ocompatible to mount -t proc none /proc The self-compiled kernel I use is not the problem, I assume. Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-security'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.11.7 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sysv-rc depends on: ii insserv 1.21.0-1.1 ii lsb-base11.1.0 ii startpar0.64-3 ii sysvinit-utils 2.96-6 sysv-rc recommends no packages. sysv-rc suggests no packages. -- debconf information: sysv-rc/unable-to-convert:
Bug#985582: texlive-latex-extra: Dangling link
Package: texlive-latex-extra Version: 2020.20210202-3 Severity: minor Dear Maintainer(s), the command 'find -L /usr -type l' shows, that there is another dangling soft link /usr/share/texlive/texmf-dist/tex/latex/pdfx/sRGB_IEC61966-2-1_black_scaled.icc I couldn't find the file sRGB_IEC61966-2-1_black_scaled.icc in any testing package. Regards, Jörg.
Bug#985513: manpages-dev: Dangling soft links
Package: manpages-dev Version: 5.10-1 Severity: minor Dear Maintainer(s), there are dangling soft links with a name starting with LIST_ in directory /usr/share/man/man3 all pointing to list.3 . And it seems, there should be only compressed files in that directory. Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-security'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.11.3 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages manpages-dev depends on: ii manpages 5.10-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.9.4-2 -- no debconf information
Bug#985499: r-cran-shiny: Wrong soft links?
Package: r-cran-shiny Version: 1.5.0+dfsg-1 Severity: normal Dear Maintainers, on my system there are three dangling links belonging to this package: fontawesome-webfont.eot fontawesome-webfont.svg fontawesome-webfont.woff2 in directory /usr/lib/R/site-library/shiny/www/shared/font-awesome/fonts pointing to the directory /usr/share/fonts/eot/font-awesome . But the referenced file do reside in directory /usr/share/fonts-font-awesome/fonts . Should these be fixed in this package or is something wrong in package fonts-font-awesome ? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-security'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.11.3 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages r-cran-shiny depends on: ii fonts-font-awesome5.0.10+really4.7.0~dfsg-4 ii libjs-bootstrap 3.4.1+dfsg-2 ii libjs-d3 3.5.17-4 ii libjs-es5-shim4.5.15-1 ii libjs-highlight.js9.18.5+dfsg1-1 ii libjs-jquery 3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-datatables 1.10.21+dfsg-1 ii libjs-jquery-selectize.js 0.12.6+dfsg-1.1 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-json0~20190826+~1.0.5-2 ii libjs-twitter-bootstrap-datepicker1.3.1+dfsg1-4.1 ii node-html5shiv3.7.3+dfsg-3 ii node-normalize.css [libjs-normalize.css] 8.0.1-3 ii r-base-core [r-api-4.0] 4.0.4-1 ii r-cran-commonmark 1.7-2 ii r-cran-crayon 1.4.0-1 ii r-cran-digest 0.6.27-1 ii r-cran-fastmap1.1.0-1 ii r-cran-glue 1.4.2-1 ii r-cran-htmltools 0.5.1.1-1 ii r-cran-httpuv 1.5.5+dfsg-1 ii r-cran-jsonlite 1.7.2+dfsg-1 ii r-cran-later 1.1.0.1+dfsg-1 ii r-cran-mime 0.9-1+b1 ii r-cran-promises 1.1.1+dfsg-1 ii r-cran-r6 2.5.0-1 ii r-cran-rlang 0.4.10-1 ii r-cran-sourcetools0.1.7-3 ii r-cran-withr 2.4.1-1 ii r-cran-xtable 1:1.8-4-2 Versions of packages r-cran-shiny recommends: pn r-cran-dygraphs pn r-cran-future ii r-cran-ggplot2 3.3.3+dfsg-1 ii r-cran-testthat 3.0.1-1 Versions of packages r-cran-shiny suggests: pn r-cran-cairo ii r-cran-knitr 1.31+dfsg-1 ii r-cran-magrittr 2.0.1-1 ii r-cran-markdown 1.1+dfsg-1+b1 ii r-cran-rmarkdown 2.6+dfsg-1 ii r-cran-yaml 2.2.1-1+b1 -- no debconf information
Bug#985493: texlive-lang-greek: Wrong link to GFSPorson.otf
Package: texlive-lang-greek Version: 2020.20210202-1 Severity: normal Dear Maintainer(s), the soft link /usr/share/texlive/texmf-dist/fonts/opentype/public/gfsporson/GFSPorson.otf -> ../../../../../../fonts/truetype/porson/GFSPorson.otf should be /usr/share/texlive/texmf-dist/fonts/opentype/public/gfsporson/GFSPorson.otf -> ../../../../../../fonts/opentype/porson/GFSPorson.otf i.e., it must point to the opentype directory. Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-security'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.11.3 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages texlive-lang-greek depends on: ii fonts-gfs-baskerville 1.1-6 ii fonts-gfs-porson 1.1-7 ii tex-common 6.16 ii texlive-base 2020.20210202-3 ii texlive-binaries 2020.20200327.54578-7 texlive-lang-greek recommends no packages. texlive-lang-greek suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.20.7.1 ii ucf 3.0043 Versions of packages tex-common suggests: pn debhelper Versions of packages texlive-lang-greek is related to: ii tex-common6.16 ii texlive-binaries 2020.20200327.54578-7 -- debconf information: tex-common/check_texmf_missing: tex-common/check_texmf_wrong:
Bug#970637: nvme-cli: missing dependency: postinst script uses uuidgen
Package: nvme-cli Version: 1.12-4 Severity: normal Dear Maintainer, maybe the package must depend on uuid-runtime since its postinst script may call uuidgen. Is it correct to list the now during installation generated files in the `nvme-cli.list` file? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.9 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages nvme-cli depends on: ii libc6 2.31-3 ii libuuid1 2.36-3 nvme-cli recommends no packages. nvme-cli suggests no packages.
Bug#968289: python3-venv: contains a dangling soft link
Package: python3-venv Version: 3.8.2-3 Severity: normal X-Debbugs-Cc: none Dear Matthias Klose, this package contains the dangling softlink /usr/share/man/man1/pyvenv.1.gz -> pyvenv-3.8.1.gz There seems to be no package in sid containing a file named "pyvenv-3.8.1.gz". Any idea? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.14 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-venv depends on: ii python33.8.2-3 ii python3-distutils 3.8.5-1 ii python3.8-venv 3.8.5-2 python3-venv recommends no packages. python3-venv suggests no packages. -- no debconf information
Bug#968133: mupdf: recognize compression with zstandard; replace tempfile
Package: mupdf Version: 1.17.0+ds1-1 Severity: wishlist X-Debbugs-Cc: none, J-V Peetz Dear Kan-Ru Chen, please find attached a patch which makes /usr/bin/mupdf able to work with files compressed with zstandard. The patch also replaces the usage of tempfile by mktemp. Maybe, you like to consider it for a future release. Best regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.14 (SMP w/8 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mupdf depends on: ii libc62.30-8 ii libfreetype6 2.10.2+dfsg-3 ii libharfbuzz0b2.6.7-1 ii libjbig2dec0 0.18+20200417-1 ii libjpeg62-turbo 1:2.0.5-1.1 ii libmujs1 1.0.7-2 ii libopenjp2-7 2.3.1-1 ii libx11-6 2:1.6.10-3 ii libxext6 2:1.3.3-1+b2 ii zlib1g 1:1.2.11.dfsg-2 mupdf recommends no packages. Versions of packages mupdf suggests: pn mupdf-tools -- no debconf information --- xx/usr/bin/mupdf 2020-08-06 14:48:09.0 +0200 +++ /usr/bin/mupdf 2020-07-23 11:23:14.114410084 +0200 @@ -23,7 +23,7 @@ cmd="/usr/lib/mupdf/mupdf-x11" -ext=".gz .Z .xz .bz2" +ext=".gz .Z .xz .bz2 .zst" file="" cmdtmp=$cmd @@ -44,12 +44,13 @@ test "$file" || exec $cmd "$@" -tmp=$(tempfile -s .pdf) +tmp=$(mktemp -t fileXX.pdf) case "$file" in *.gz|*.Z) zcat -- "$file" > $tmp && file=$tmp;; *.xz) xzcat -- "$file" > $tmp && file=$tmp;; *.bz2)bzcat -- "$file" > $tmp && file=$tmp;; +*.zst)zstdcat -- "$file" > $tmp && file=$tmp;; esac trap 'rm -f $tmp' EXIT
Bug#968110: linux-image-5.7.0-2-amd64: USB 3 storage device not detected
Package: src:linux Version: 5.7.10-1 Severity: normal Dear Maintainer, USB 3 storage devices (hdd and stick) are not detected. Nothing shows up in the log files (messages, kern.log) and the command lsusb doesn't show the device. The version 5.7.6-1 also doesn't work. A USB 2 storage device and a USB mouse are detected and can be used. Any ideas? Regards, Jörg. ** Model information sys_vendor: Hewlett-Packard product_name: HP ProBook 650 G1 product_version: A3008CD10003 chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: L77 Ver. 01.21 board_vendor: Hewlett-Packard board_name: 1993 board_version: KBC Version 16.39
Bug#965954: python3-matplotlib: import of library fails
Package: python3-matplotlib
Version: 3.3.0-1
Severity: critical
X-Debbugs-Cc: none, J-V Peetz
Dear Sandro Tosi,
in ipython3 the import of matplotlib.pyplot fails:
In[1]: import matplotlib.pyplot as plt
---
FileNotFoundError Traceback (most recent call last)
in
> 1 import matplotlib.pyplot as plt
/usr/lib/python3/dist-packages/matplotlib/__init__.py in
897 # by explicitly calling the superclass (dict.update, dict.items) to
avoid
898 # triggering resolution of _auto_backend_sentinel.
--> 899 rcParamsDefault = _rc_params_in_file(
900 cbook._get_data_path("matplotlibrc"),
901 # Strip leading comment.
/usr/lib/python3/dist-packages/matplotlib/__init__.py in
_rc_params_in_file(fname, transform, fail_on_error)
796 """
797 rc_temp = {}
--> 798 with _open_file_or_url(fname) as fd:
799 try:
800 for line_no, line in enumerate(fd, 1):
/usr/lib/python3.8/contextlib.py in __enter__(self)
111 del self.args, self.kwds, self.func
112 try:
--> 113 return next(self.gen)
114 except StopIteration:
115 raise RuntimeError("generator didn't yield") from None
/usr/lib/python3/dist-packages/matplotlib/__init__.py in
_open_file_or_url(fname)
774 if encoding is None:
775 encoding = "utf-8"
--> 776 with open(fname, encoding=encoding) as f:
777 yield f
778
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/share/matplotlib/mpl-data/matplotlibrc'
Any idea?
Regards,
Jörg.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.9 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages python3-matplotlib depends on:
ii libc6 2.30-8
ii libfreetype62.10.2+dfsg-3
ii libgcc-s1 10.1.0-6
ii libjs-jquery3.5.1+dfsg-4
ii libjs-jquery-ui 1.12.1+dfsg-5
ii libstdc++6 10.1.0-6
ii python-matplotlib-data 3.3.0-1
ii python3 3.8.2-3
ii python3-cycler 0.10.0-3
ii python3-dateutil2.8.1-4
ii python3-kiwisolver 1.0.1-3+b1
ii python3-numpy [python3-numpy-abi9] 1:1.19.0-1
ii python3-pil 7.2.0-1
ii python3-pyparsing 2.4.7-1
ii python3-six 1.15.0-1
Versions of packages python3-matplotlib recommends:
ii python3-tk 3.8.5-1
Versions of packages python3-matplotlib suggests:
ii dvipng 1.15-1.1+b1
ii ffmpeg 7:4.3-3+b1
ii ghostscript9.52~dfsg-1
ii gir1.2-gtk-3.0 3.24.20-1
ii inkscape 1.0-3
ii ipython3 7.16.1-1
ii librsvg2-common2.48.7-1
pn python-matplotlib-doc
pn python3-cairocffi
ii python3-gi 3.36.0-4
ii python3-gi-cairo 3.36.0-4
pn python3-gobject
pn python3-nose
pn python3-pyqt5
ii python3-scipy 1.4.1-2
pn python3-sip
ii python3-tornado6.0.4-2
ii texlive-extra-utils2020.20200629-1
ii texlive-latex-extra2020.20200629-1
pn ttf-staypuft
-- no debconf information
Bug#958337: libxfont-dev: depend on x11proto-dev instead of x11proto-core-dev, x11proto-fonts-dev
Package: libxfont-dev Version: 1:2.0.3-1 Severity: wishlist Dear Debian X Strike Force, the dependency on x11proto-core-dev and x11proto-fonts-dev should be replaced by dependency on x11proto-dev. Regards, Jörg.
Bug#955624: python3-pip: depend on python3.8 instead of python3.7
Package: python3-pip Version: 20.0.2-3 Severity: wishlist Dear Debian Python Modules Team, this package is one of two on my system which still depends on python3.7. When is the shift to dependency on python3.8 scheduled? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.2 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-pip depends on: ii ca-certificates 20190110 ii python-pip-whl 20.0.2-3 ii python3 3.8.2-2 ii python3-distutils 3.8.2-2 ii python3-setuptools 44.0.0-1 ii python3-wheel 0.34.2-1 ii python3.7 3.7.7-1+b1 Versions of packages python3-pip recommends: ii build-essential 12.8 ii python3-dev 3.8.2-2 python3-pip suggests no packages. -- no debconf information
Bug#955367: libdvdread7: crashes vlc when trying to read a DVD iso image
Package: libdvdread7 Version: 6.1.0-1 Severity: normal Dear Debian Multimedia Maintainers, with this version vlc crashes when trying to open a DVD iso image file. Downgrading to version 6.0.2-2 makes vlc work again. The following messages appear in xinit log: disc.c:424: error opening file BDMV/index.bdmv disc.c:424: error opening file BDMV/BACKUP/index.bdmv bluray.c:2585: nav_get_title_list((null)) failed libdvdnav: *** pgci_ut handle is NULL *** I use a self-compiled /usr/local/lib/libdvdcss.so.2.2.0 . Any ideas? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.11 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libdvdread7 depends on: ii libc6 2.30-4 Versions of packages libdvdread7 recommends: ii libdvdnav4 6.1.0-1 Versions of packages libdvdread7 suggests: pn libdvdcss2 Versions of packages libdvdnav4 depends on: ii libc6 2.30-4 Versions of packages libdvdnav4 suggests: pn libdvdcss2 -- no debconf information
Bug#918570: python3-sklearn-lib: dependency on libblas3 | libblas.so.3 instead of libatlas3-base?
Hi Christian, meanwhile the dependency on libatlas3-base is gone and I think the bug can be closed. Your second quotation was from an e-mail of Stuart Prescott. Maybe ask him about his remarks also. Thank you for caring. Regrds, Jörg. Christian Kastner wrote on 29/03/2020 21:25: > Hi Jörg, > > On 2019-01-07 14:48:40 +0100 Jörg-Volker Peetz wrote: >> some libraries of this package are linked to libcblas.so.3. >> Could this be replaced by linking to libblas.so? >> Could this package depend on libblas3 | libblas.so.3 instead of >> libatlas3-base? > > The BLAS implementation in Debian can be switched at runtime using > Debian's alternatives system. > > You can find more details here: > > https://wiki.debian.org/DebianScience/LinearAlgebraLibraries#BLAS > > > Furthermore, > >> I'm not quite sure what to make of these changes but the bigger problem is >> that as a result of not finding these libraries correctly, the build-system >> accidentally leaves behind two sets of files that are finding their way into >> the binary package: >> >> /usr/lib/python2.7/dist-packages/_configtest >> /usr/lib/python2.7/dist-packages/_configtest.c >> /usr/lib/python2.7/dist-packages/_configtest.o >> /usr/lib/python3/dist-packages/_configtest >> /usr/lib/python3/dist-packages/_configtest.c >> /usr/lib/python3/dist-packages/_configtest.o >> >> (and they absolutely should not be there). > > Those files don't appear in the binary package in the archive [1], and > an `apt-file search configtest` does not show these files appearing in > any other package. > > Perhaps something went wrong during your rebuild? > > [1] https://packages.debian.org/sid/amd64/python3-sklearn-lib/filelist >
Bug#953796: closed by Matthias Klose (Re: Bug#953796: gcc-9: kernel compilation fails)
Hi Matthias, yes, this works. Thank you very much. Regards, Jörg.
Bug#953796: gcc-9: kernel compilation fails
Package: gcc-9 Version: 9.3.0-1 Severity: normal Dear Debian GCC Maintainer, trying to compile an upstream stable kernel 5.5.8 fails with the following error output: $ make -j8 HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACCscripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/util.o In file included from scripts/kconfig/conf.c:7: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h 124 | # include_next | ^ In file included from scripts/kconfig/confdata.c:11: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h 124 | # include_next | ^ make[2]: *** [scripts/Makefile.host:124: scripts/kconfig/conf.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [scripts/Makefile.host:124: scripts/kconfig/confdata.o] Error 1 make[1]: *** [Makefile:568: syncconfig] Error 2 make: *** [Makefile:678: include/config/auto.conf.cmd] Error 2 make: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf' Compiling with gcc-9 version 9.2.1-30 works. Any idea? Best regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.8 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gcc-9 depends on: ii binutils 2.34-4 ii cpp-9 9.3.0-1 ii gcc-9-base9.3.0-1 ii libc6 2.30-2 ii libcc1-0 10-20200304-1 ii libgcc-9-dev 9.3.0-1 ii libgcc-s1 10-20200304-1 ii libgmp10 2:6.2.0+dfsg-4 ii libisl22 0.22.1-1 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.2-1 ii libstdc++610-20200304-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages gcc-9 recommends: ii libc6-dev 2.30-2 Versions of packages gcc-9 suggests: ii gcc-9-doc 9.2.0-2 pn gcc-9-locales pn gcc-9-multilib -- no debconf information
Bug#949646: libsqlite3-0: Firefox immediately crashes at start with latest libsqlite3-0
It also breaks thunderbird 1:68.4.1-1 which immediately crashes before any graphical component appears. Regards, Jörg.
Bug#948954: libblis2-pthread: undefined symbol: openblas_set_num_threads
Package: libblis2-pthread Version: 0.6.0-3 Severity: normal Dear Debian Science Team, when trying to exchange libblis2-pthread for libopenblas0-pthread, I get the following error from a self compiled program (using libopenblas-dev): /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined symbol: openblas_set_num_threads The library is actually /usr/lib/x86_64-linux-gnu/blis-pthread/libblas.so.3. I'm not quite sure which package is to blame for this and if the libraries are intended to be interchangeable at all. Can you help me? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.8 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#934475: r-cran-irkernel: Html-files missing
Hi Andreas, thanks for caring. Without a look into the source files, I just assumed it would be trivial to fix. After looking into the source files, I have to admit that I lack the capabilities for a fix, maybe the documentation is just planned by the author. I'm o.k. with closing the bug. I'll keep an eye on the sources. Regards, Jörg.
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_XXXXXXX/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
These error messages also appear in the 'make modules_install' step when building a standard Linux kernel. Regards, Jörg.
Bug#927339: gemspec filename changes upon rebuild, breaks other packages e.g. jekyll
Pirate Praveen wrote on 28/12/2019 06:54: > On Wed, 25 Dec 2019 13:21:01 +0100 =?UTF-8?Q?J=c3=b6rg-Volker_Peetz?= <> > wrote: >> Package: ruby-i18n >> Version: 1.5.3-2 >> >> Dear Ruby Extras Maintainers, >> >> Bug reappears in version 1.5.3-2 with the file >> >> /usr/share/rubygems-integration/all/specifications/i18n-1.5.3.gemspec > > I think the bug was in the previous version. 1.5.3-1 was built with gem2deb > 0.40 > and 1.5.3-2 was built with gem2deb 0.45. > >> In my case it hits the redmine package. > > The affected packages should be patched or updated to work with 1.5.3. > So, I've filed a bug against redmine: #947770 Regards, Jörg.
Bug#947770: redmine: wrong version of i18n in Gemfile
Package: redmine Version: 4.0.4-2 Severity: normal Dear Maintainers, while trying to update package ruby-i18n (1.5.3-2) I see this message: Processing triggers for redmine (4.0.4-2) ... Could not find gem 'i18n (~> 0.7)' in any of the gem sources listed in your Gemfile. Changing the according line in file /usr/share/redmine/Gemfile to gem "i18n", "~> 1.5" the update works. Version 4.0.4-3 of redmine also has the wrong version. Should this be corrected in redmine? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.6 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages redmine depends on: ii dbconfig-common 2.0.13 ii debconf [debconf-2.0] 1.5.73 ii libjs-jquery3.3.1~dfsg-3 ii libjs-jquery-ui 1.12.1+dfsg-5 ii libjs-raphael 2.1.0-1 ii redmine-sqlite 4.0.4-2 ii ruby1:2.5.2 ii ruby-actionpack-action-caching 1.2.0-2 ii ruby-actionpack-xml-parser 2.0.1-3 ii ruby-bundler1.17.3-3 ii ruby-coderay1.1.2-2 ii ruby-csv3.0.2-1 ii ruby-i18n 1.5.3-2 ii ruby-jquery-rails 4.3.3-1 ii ruby-mail 2.7.1+dfsg1-1 ii ruby-mime-types 3.2.2-1 ii ruby-mimemagic 0.3.2+dfsg-1 ii ruby-mini-mime 1.0.1-1 ii ruby-net-ldap 0.16.1-1 ii ruby-nokogiri 1.10.7+dfsg1-1 ii ruby-rack 2.0.7-2 ii ruby-rack-test 0.7.0-1 ii ruby-rails 2:5.2.3+dfsg-1 ii ruby-rails-dom-testing 2.0.3-3 ii ruby-rails-observers0.1.5-1 ii ruby-rbpdf 1.19.5+ds.1-1 ii ruby-redcarpet 3.4.0-4+b1 ii ruby-request-store 1.3.0-1 ii ruby-rmagick2.16.0-6 ii ruby-roadie 4.0.0-1 ii ruby-roadie-rails 1.3.0-2 ii ruby-rouge 3.14.0-1 Versions of packages redmine recommends: pn passenger
Bug#927339: gemspec filename changes upon rebuild, breaks other packages e.g. jekyll
Package: ruby-i18n Version: 1.5.3-2 Dear Ruby Extras Maintainers, Bug reappears in version 1.5.3-2 with the file /usr/share/rubygems-integration/all/specifications/i18n-1.5.3.gemspec In my case it hits the redmine package. Regards, Jörg.
Bug#946884: base-passwd: home directory of irc should be /run/ircd
Package: base-passwd Version: 3.5.47 Severity: normal Hi Colin, since the directory /var/run changed to /run, also home directories in /var/run should be changed to /run, I think. In this case there is /var/run/ircd in the file /usr/share/base-passwd/passwd.master . How about changing this to /run/ircd ? Regards, Jörg.
Bug#945791: libopenblas0-openmp: undefined symbol: GOMP_parallel
Package: libopenblas0-openmp Version: 0.3.7+ds-4 Severity: serious Dear Debian Science Team, when trying to exchange libopenblas0-openmp for libopenblas0-pthread, I get the following error from a self compiled program: /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined symbol: GOMP_parallel The library is actually /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3. Although this package depends on libgomp1, it seems to me that the library /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3 is not linked against /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0: $ ldd /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3 linux-vdso.so.1 (0x7ffccf5e5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f671fe5d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f671fe3c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f671fc7c000) /lib64/ld-linux-x86-64.so.2 (0x7f6721a27000) Any idea? Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.11 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libopenblas0-openmp depends on: ii libc6 2.29-1 ii libgfortran5 9.2.1-19 ii libgomp1 9.2.1-19 libopenblas0-openmp recommends no packages. libopenblas0-openmp suggests no packages. -- no debconf information
Bug#940605: libjbig2dec0: breaks mupdf with message "undefined symbol: jbig2_ctx_new"
Package: libjbig2dec0 Version: 0.16+20190905-2 Severity: normal Dear Maintainer, this version and the previous version 0.16+20190905-1 break mupdf which crashes with message "undefined symbol: jbig2_ctx_new". Regards, Jörg. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.14 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libjbig2dec0 depends on: ii libc6 2.29-1 libjbig2dec0 recommends no packages. libjbig2dec0 suggests no packages. -- no debconf information
Bug#935094: linux-image-5.2.0-2-amd64: USB 3 storage device not detected
Package: src:linux Version: 5.2.7-1 Severity: normal Dear Maintainer, USB 3 storage devices (hdd and stick) are not detected. Nothing shows up in the log files (messages, kern.log) and the command lsusb doesn't show the device. With kernel package linux-image-4.19.0-5-amd64 the same devices work. A USB 2 storage device and a USB mouse are detected and can be used. Any ideas? Regards, Jörg. -- Package-specific info: <#part type="text/plain" disposition=attachment description="Bug script output"> ** Version: Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 5.2.7-1 (2019-08-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 root=UUID=fee4c872-c3ec-4b28-9951-0bf6507cae5f ro quiet scsi_mod.use_blk_mq=1 ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Hewlett-Packard product_name: HP ProBook 650 G1 product_version: A3008CD10003 chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: L77 Ver. 01.21 board_vendor: Hewlett-Packard board_name: 1993 board_version: KBC Version 16.39 ** Loaded modules: uas usb_storage hid_generic usbhid hid bfq intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul arc4 ghash_clmulni_intel btusb btrtl btbcm btintel bluetooth snd_hda_codec_hdmi iwldvm mac80211 aesni_intel snd_hda_codec_idt aes_x86_64 crypto_simd snd_hda_codec_generic drbg cryptd glue_helper iwlwifi i915 ledtrig_audio intel_cstate drm_kms_helper tpm_infineon snd_hda_intel ansi_cprng intel_uncore ppdev cfg80211 snd_hda_codec joydev iTCO_wdt tpm_tis tpm_tis_core rtsx_pci_ms evdev snd_hda_core intel_rapl_perf ecdh_generic parport_pc tpm snd_hwdep hp_wmi pcspkr ecc sparse_keymap serio_raw wmi_bmof memstick snd_pcm hp_accel iTCO_vendor_support sg lis3lv02d watchdog parport drm input_polldev rfkill pcc_cpufreq rng_core battery mei_me snd_timer hp_wireless button snd soundcore i2c_algo_bit mei ac ie31200_edac ext4 crc16 mbcache jbd2 crc32c_generic sr_mod cdrom sd_mod rtsx_pci_sdmmc mmc_core ahci libahci libata psmouse rtsx_pci ehci_pci ehci_hcd xhci_pci xhci_hcd scsi_mod e1000e lpc_ich i2c_i801 crc32c_intel usbcore mfd_core usb_common wmi video ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [8086:0c04] (rev 06) Subsystem: Hewlett-Packard Company Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [103c:1993] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: ie31200_edac 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller]) DeviceName: 32 Subsystem: Hewlett-Packard Company 4th Gen Core Processor Integrated Graphics Controller [103c:1993] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) Subsystem: Hewlett-Packard Company Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [103c:1993] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Hewlett-Packard Company 8 Series/C220 Series Chipset Family USB xHCI [103c:1993] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) Subsystem: Hewlett-Packard Company 8 Series/C220 Series Chipset Family MEI Controller [103c:1993] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04) Subsystem: Hewlett-Packard
Bug#922772: redmine: start via unicorn fails
Dear maintainer team, meanwhile I got redmine running again within a sub-URI by just changing the file /usr/share/redmine/config.ru . For this, I replaced the line run Rails.application by the three lines map ENV['RAILS_RELATIVE_URL_ROOT'] || '/' do run Rails.application end and set the environment variable RAILS_RELATIVE_URL_ROOT to '/redmine' in the unicorn configuration file. Maybe, this modification of config.ru could be used in the redmine package. In conclusion, this bug report can be closed as solved. Sorry for the noise and thanks for your work on redmine. Regards, Jörg. On Fri, 22 Feb 2019 17:02:20 +0100 =?UTF-8?Q?J=c3=b6rg-Volker_Peetz?= wrote: > Dear Maintainer team, > > I asked to change the severity of this bug since unicorn starts with the > default > configuration. But I'm failing to get redmine running under a sub-URI ( > https:///redmine ) as it works with vesion 3.4.6. > > Regards, > Jörg. > > >
Bug#922772: redmine: start via unicorn fails
Dear Maintainer team, I asked to change the severity of this bug since unicorn starts with the default configuration. But I'm failing to get redmine running under a sub-URI ( https:///redmine ) as it works with vesion 3.4.6. Regards, Jörg.
Bug#922772: redmine: start via unicorn fails
Dear Maintainer team,
for clearness I also append my redmine/config/environment.rb which I modified to
run the redmine server in a sub-URI. The problematic line seems to be line 16
RedmineApp::Application.routes.default_scope = { :path =>
ENV['RAILS_RELATIVE_URL_ROOT'] }
before the application initialization. But I have no idea what the error
messages indicate.
The documentation concerning a sub-URI also seems unchanged.
Regards,
Jörg.
environment.rb
Description: application/ruby
Bug#922772: redmine: start via unicorn fails
Package: redmine Version: 4.0.1-1 Severity: grave Dear Maintainer team, after upgrading from 3.4.6 the start of redmine via unicorn fails. Please find the error protocol appended. It seems to fail in line 19 of /usr/share/redmine/config/environment.rb Regards, Jörg. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.10 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages redmine depends on: ii dbconfig-common 2.0.11 ii debconf [debconf-2.0] 1.5.70 ii libjs-jquery3.3.1~dfsg-1 ii libjs-jquery-ui 1.12.1+dfsg-5 ii libjs-raphael 2.1.0-1 ii redmine-sqlite 4.0.1-1 ii ruby1:2.5.1 ii ruby-actionpack-action-caching 1.2.0-2 ii ruby-actionpack-xml-parser 2.0.1-3 ii ruby-bundler1.17.3-2 ii ruby-coderay1.1.2-2 ii ruby-csv3.0.2-1 ii ruby-i18n 1.5.3-1 ii ruby-jquery-rails 4.3.3-1 ii ruby-mail 2.7.1+dfsg1-1 ii ruby-mime-types 3.2.2-1 ii ruby-mimemagic 0.3.2+dfsg-1 ii ruby-mini-mime 1.0.1-1 ii ruby-net-ldap 0.16.1-1 ii ruby-nokogiri 1.10.0+dfsg1-2 ii ruby-openid 2.7.0debian-1 ii ruby-rack 2.0.6-3 ii ruby-rack-openid1.4.2-1 ii ruby-rack-test 0.7.0-1 ii ruby-rails 2:5.2.2+dfsg-5 ii ruby-rails-dom-testing 2.0.3-3 ii ruby-rails-observers0.1.5-1 ii ruby-rbpdf 1.19.5+ds.1-1 ii ruby-redcarpet 3.4.0-4+b1 ii ruby-request-store 1.3.0-1 ii ruby-rmagick2.16.0-6 ii ruby-roadie 3.2.2-1 ii ruby-roadie-rails 1.3.0-1 ii ruby-rouge 3.3.0-1 Versions of packages redmine recommends: pn passenger Versions of packages redmine suggests: pn bzr ii cvs 2:1.12.13+real-27 pn darcs ii git 1:2.20.1-2 ii mercurial 4.9-2 pn ruby-fcgi ii subversion 1.10.4-1 -- debconf information: redmine/instances/default/missing-db-package-error: abort redmine/instances/default/pgsql/authmethod-admin: ident redmine/instances/default/remote/newhost: * redmine/current-instances: default * redmine/instances/default/default-language: en redmine/instances/default/upgrade-backup: true redmine/default-language: en redmine/instances/default/mysql/admin-user: redmine/old-instances: redmine/instances/default/pgsql/changeconf: false * redmine/instances/default/dbconfig-install: true redmine/instances/default/db/app-user: redmine redmine/instances/default/dbconfig-reinstall: false redmine/instances/default/upgrade-error: abort * redmine/instances/default/db/basepath: /var/lib/redmine/default/db redmine/notify-migration: redmine/instances/default/internal/skip-preseed: false redmine/instances/default/passwords-do-not-match: redmine/instances/default/dbconfig-remove: redmine/instances/default/remote/host: localhost redmine/instances/default/dbconfig-upgrade: true * redmine/instances/default/db/dbname: redmine.sqlite redmine/instances/default/pgsql/manualconf: redmine/instances/default/remote/port: redmine/instances/default/remove-error: abort redmine/instances/default/pgsql/no-empty-passwords: redmine/instances/default/pgsql/authmethod-user: password redmine/instances/default/pgsql/method: TCP/IP redmine/missing-redmine-package: redmine/instances/default/purge: false redmine/instances/default/internal/reconfiguring: false redmine/instances/default/pgsql/admin-user: postgres redmine/instances/default/install-error: abort redmine/instances/default/mysql/method: Unix socket * redmine/instances/default/database-type: sqlite3 I, [2019-02-20T12:01:44.139905 #29924] INFO -- : Refreshing Gem list I, [2019-02-20T12:01:48.342802 #29924] INFO -- : listening on addr=/run/www/unicorn-redmine-default.sock fd=13 I, [2019-02-20T12:01:48.353250 #29924] INFO -- : master process ready I, [2019-02-20T12:01:48.385812 #29930] INFO -- : worker=1 ready I, [2019-02-20T12:01:48.386122 #29927] INFO -- : worker=0 ready I, [2019-02-20T12:02:22.860110 #29924] INFO -- : reaped # worker=0 I, [2019-02-20T12:02:22.860331 #29924] INFO -- : reaped # worker=1 I, [2019-02-20T12:02:22.860486 #29924] INFO -- : master complete I, [2019-02-20T13:13:34.284742 #373] INFO -- : Refreshing Gem list /usr/share/rubygems-integration/all/gems/actionpack-5.2.2/lib/action_dispatch/routing/mapper.rb:2099:in `direct': The direct
Bug#918570: python3-sklearn-lib: dependency on libblas3 | libblas.so.3 instead of libatlas3-base?
Package: python3-sklearn-lib Version: 0.20.1+dfsg-1 Severity: important Dear Science-Team, some libraries of this package are linked to libcblas.so.3. Could this be replaced by linking to libblas.so? Could this package depend on libblas3 | libblas.so.3 instead of libatlas3-base? Regards, Jörg. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-sklearn-lib depends on: ii libatlas3-base 3.10.3-7+b1 ii libc6 2.28-2 ii libgcc1 1:8.2.0-13 ii libstdc++6 8.2.0-13 ii python3 3.7.1-3 ii python3-numpy [python3-numpy-abi9] 1:1.16.0~rc2-1 python3-sklearn-lib recommends no packages. python3-sklearn-lib suggests no packages.
Bug#913567: fixed in python-numpy 1:1.16.0~rc2-1)
Package: python-numpy Version: 1:1.16.0~rc2-1 Hi Sandro, please, forget my previous e-mail, everything is o.k. As I just learned, I was misled by the output of the ldd command. The right command is $ readelf -d /usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so | So everything is fine with numpy now. Many thanks again. Regards, Jörg.
Bug#913567: fixed in python-numpy 1:1.16.0~rc2-1)
Package: python-numpy Version: 1:1.16.0~rc2-1 Hi Sandro, thanks for taking care of this issue. I've upgraded to the new version and see the following $ ldd /usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so | grep blas libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x7f8f59855000) libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x7f8f57494000) Thus, python-numpy still won't work without package libopenblas-base. Maybe, there is a bug in the building system of numpy. I'm experiencing the same problem when trying to build a local version of sagemath which builds its own numpy. Any ideas? Regards, Jörg.
Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0
Hallo Dirk, the problem I see, shows when inspecting /usr/lib/R/modules/lapack.so with $ ldd /usr/lib/R/modules/lapack.so | grep blas libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x7f58c61b5000) libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x7f58c2dbb000) Thus, lapack.so of package r-base-core is linked to libopenblas.so.0 which means that r-base-core won't work without package libopenblas-base. And that is not intended AFAIU. Regards und Grüße aus Bonn, Jörg.
Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0
Package: r-base-core Version: 3.5.2-1 Severity: important Hi Dirk, the library /usr/lib/R/modules/lapack.so contained in this package is linked to /usr/lib/x86_64-linux-gnu/libopenblas.so.0 of the package libopenblas-base. Package libopenblas-base provides the dependency libblas.so.3. The library libblas.so.3 contained in package libopenblas-base is already linked to libopenblas.so.0. Therefore, it is not necessary lo link it to /usr/lib/R/modules/lapack.so, I think. Rather, it is a bug to link it to /usr/lib/R/modules/lapack.so, since other packages providing a BLAS library don't contain or provide libopenblas.so.0. Regards, Jörg.
Bug#918390: zstd: zstdgrep has return code 1 on normal exit
Package: zstd
Version: 1.3.8+dfsg-2
Severity: normal
Dear Maintainer(s),
the search command zstdgrep always returns an exit code of 1 when
called with file name(s).
The logic with EXIT_CODE and CUR_EXIT_CODE in that shell script seems
bogus to me. Shouldn't something simple like
EXIT_CODE=0
...
[ "$?" -ne 0 ] && EXIT_CODE=1
...
work?
I attach a patch which also corrects a minor nit regarding the *egrep and *fgrep
variants.
Regards,
Jörg.
--- zstdgrep.orig 2019-01-03 14:47:31.0 +0100
+++ zstdgrep 2019-01-05 19:16:01.697399037 +0100
@@ -35,8 +35,8 @@
# handle being called 'zegrep' or 'zfgrep'
case "${prg}" in
-*zegrep) grep_args="-E";;
-*zfgrep) grep_args="-F";;
+*zstdegrep) grep_args="-E";;
+*zstdfgrep) grep_args="-F";;
esac
# skip all options and pass them on to grep taking care of options
@@ -113,16 +113,11 @@
if [ "${silent}" -lt 1 ] && [ "$#" -gt 1 ]; then
grep_args="-H ${grep_args}"
fi
-CUR_EXIT_CODE=0
-EXIT_CODE=1
set -f
while [ "$#" -gt 0 ]; do
# shellcheck disable=SC2086
"${zcat}" -fq -- "$1" | "${grep}" --label="${1}" ${grep_args} -- "${pattern}" -
-CUR_EXIT_CODE=$?
-if [ "${CUR_EXIT_CODE}" -eq 0 ] && [ "${EXIT_CODE}" -ne 1 ]; then
-EXIT_CODE=0
-fi
+[ "$?" -ne 0 ] && EXIT_CODE=1
shift
done
set +f
Bug#913567: python-numpy: Why depend on libatlas3-base?
Hi Sandro, I've discussed this matter on the debian science e-mail list asking for an cblas abstraction. I got a reply from Mo Zhou (https://lists.debian.org/debian-science/2019/01/msg2.html ). In short he suggested to file a bug against numpy (severity: important). I repeat the main part of the e-mail here: """ Debian's default (generic, no optimization) Atlas is really SLOW, such that I can write a faster BLAS by simply following this guide: https://github.com/flame/how-to-optimize-gemm Debian's reference BLAS (netlib) contains both BLAS and CBLAS API/ABI, which should be able to be linked against by numpy, and then we can make numpy use a high-performance BLAS backend by simply switching alternatives. Any user of a modern x84_64 CPU can easily find the giant performance gap between the default Atlas (generic code) and the default OpenBLAS (generic+optimized, runtime-dispatch). MKL would be even faster if the user doesn't mind installing non-free. I guess "cblas" is supposed to mean a backend with "cblas_*" API/ABI, and "blas" for "*_" (Fortran) API/ABI. If this is true, then at least MKL and openblas are expected to work well. As for numpy's linkage to libcblas.so ... I guess Sandro isn't aware of the fact that BLAS implementations such as OpenBLAS squashed both C and Fortran ABI into to a single shared object. And AFAIK only Atlas split the C ABI into an individual library libcblas.so . """ Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
reopen 913567 python-numpy 1:1.16.0~rc1-3
Bug#916986: fixed in emacs 1:26.1+1-3
Dear Rob, thanks for relaxing the dependency on mailutils. I very much appreciate your care. Regards, Jörg.
Bug#916986: Downgrade hard-dependency on mailutils to recommends
Dear Rob Browning, first, I'd like to thank you for your work on emacs. As I use emacs intensivly in my daily work but very seldom its e-mail capabilities, I also would appreciate if the dependency on mailutils could be relaxed somehow. Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
Just wanted to add that openblas also provides a cblas interface in package libopenblas-dev via the header file /usr/include/x86_64-linux-gnu/cblas.h. Regards, Jörg.
Bug#914432: initscripts: syntax error for find in /lib/init/bootclean.sh
Package: initscripts Version: 2.92~beta-1 Severity: normal Dear Maintainer(s), a syntax error/ typo slipped into the script /lib/init/bootclean.sh throwing errors during boot. It should read ! ( -path ./.sujournal -uid 0 ) instead of ! ( -path ./.sujournal -uid 0) i.e., a space is missing befor the closing parenthesis. Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
Sandro Tosi wrote on 12/11/2018 14:55: >> the package now depends on libatlas3-base besides the dependencies on >> BLAS/LAPACK. Couldn't this be avoided? > > libcblas was required to build numpy properly and, AFAICS, it's only > provided by ATLAS; is this causing any problem? > Hi, no it's not causing any problem at the moment. I was just concerned about the additional blas/lapack packages, since I have already installed libopenblas-dev and libopenblas-base. I was just wondering why some libraries now depend on libcblas as well as libblas but maybe this is a question better asked upstream. Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
Package: python-numpy Version: 1:1.15.4-1 Severity: wishlist Dear Sandro Tosi, the package now depends on libatlas3-base besides the dependencies on BLAS/LAPACK. Couldn't this be avoided? Regards, Jörg.
