Bug#1054219: "breaks beamer theme metropolis" - actually only old versions of metropolis
With latest metropolis 1.2 from https://github.com/matze/mtheme, my presentation compiles again. As it would be a lot of work to extract a minimal example from the horribly complicated beamer code, I suggest we better close this issue. Sorry, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#1054219: Font Fira not found, breaks beamer theme metropolis
Package: texlive-fonts-extra Version: 2023.20231007-2 Beamer theme metropolis uses font Fira. Worked fine under several Debian releases up to Bookworm. Broken in Trixie: Throws warnings about Could not find Fira Sans fonts ... Could not find Fira Mono fonts ... then terminates with error ! Package beamerfontthememetropolis Error: Patching frame title failed. As nothing has changed in the beamer theme, I presume the problem comes from changes in texlive-fonts-extra. smime.p7s Description: S/MIME Cryptographic Signature
Bug#1026104: why does python3-numpy depend on python3.11?
Thank you very much, Timo, for this very helpful communication.
I am indeed using a local cmake because I am occasionally contributing
to the CMake docs.
So do I understand correctly:
- If I continue to use a local CMake installation, just I have to supply the
extra command-line options
-DPython3_FIND_STRATEGY=LOCATION -DPython3_FIND_UNVERSIONED_NAMES=FIRST
which are available from unpatched CMake. They available in CMake versions
3.25 and later?
- If I return to a fully Debian based system, there will be no more transient
problems with numpy vs multi Python minor because the Debian-patched CMake
will handle them? It will do so by inserting the aformentioned -D options?
Thanks again, Joachim
On 11/01/2023 10:48, Timo Röhling wrote:
Hi Joachim,
On Wed, 30 Nov 2022 17:22:08 +0100 Joachim Wuttke
wrote:
Why does python3-numpy under bookworm, since a few days, depend on python3.10
*and* on python3.11?
This breaks our software projects that combine C++ with Python.
The CMake command
find_package(Python3 3.${version_minor_min} REQUIRED
COMPONENTS Interpreter Development NumPy)
fails with error message
CMake Error at
/usr/local/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
Could NOT find Python3 (missing: Development NumPy Development.Module
Development.Embed) (found suitable version "3.11.0", minimum required is
"3.7")
Call Stack (most recent call first):
/usr/local/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594
(_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-3.23/Modules/FindPython/Support.cmake:3192
(find_package_handle_standard_args)
/usr/local/share/cmake-3.23/Modules/FindPython3.cmake:490 (include)
CMakeLists.txt:154 (find_package)
CMake maintainer here who stumbled upon your bug report. This has
been a known issue with upstream CMake looking for the newest
available Python version by default. It has been addressed in Debian
[1], but seeing that /usr/local/share/cmake-3.23 shows up in the
callstack above, I suspect that you are not using the Debian version
of CMake.
For the record, you can work around the issue with the extra command
line options
-DPython3_FIND_STRATEGY=LOCATION -DPython3_FIND_UNVERSIONED_NAMES=FIRST
I recommend that you switch to the Debian CMake package, though.
Cheers
Timo
[1]
https://sources.debian.org/src/cmake/3.25.1-1/debian/patches/0001-Prefer-default-Python-version.patch/
smime.p7s
Description: S/MIME Cryptographic Signature
Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
> How about this?
>
> #!/bin/sh
> ":" """ "
> if which python3.11 >/dev/null 2>&1; then
> exec python3.11 "$0" "$@"
> else
> echo "Please install python3.11 to use this tool" >&2
> fi
> exit 1
> """
> print("hey, I'm running under python3.11")
>
> Admittedly, the resulting docstring is not super useful, but this can be
> the start of a compromise.
For me, would be great if the issue could be solved so easily.
> In any case, the CTTE's task is to select among available solutions and
> in this case, we have a readily available solution called "status quo"
> and the idea of a solution without working code. That does not make for
> a great choice.
Other solution?: just not release problematic transitory versions.
Joachim
smime.p7s
Description: S/MIME Cryptographic Signature
Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
Dear all: Sandro wrote: > Please compare the numpy popcon numbers (which we know are not > detailed, but it's a start) with the handful of people having reported > this issue. While maintaining numpy, my work caters towards the actual > numpy users, not people who just want to not have 2 python > interpreters installed at the same time during a time of a Python > interpreter transition, in a not-stable release. Debian testing is not stable by definition. However, in scientific computing it is not unusual that Debian testing is used routinely for productive work because Debian stable tends to be too outdated. The issue for me is not that I do "just want to not have 2 python interpreters installed". The issue for me is the Depends of the transitory python3-numpy releases break my dependent software, as described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025169. > What Depends are you referring to here? as a reminder, they are > auto-generated by the Python helper `dh-python` and none are > explicitly defined in the package Depends field Would it make sense to submit an issue against dh-python? > the burden of proof should be on the proponent(s) to come up with a > sound technical solution How about: just not release transitory versions to Debian testing until the dependency on the old Python interpreter is gone? Helmut wrote: Given a Recommends, we'd likely have to wrap these scripts in a way that produces a useful error message. Has anyone seen a patch for making this happen? Joachim, would you volunteer to write one? Sounds not too difficult ... for somebody who has full understanding of these scripts and all context. Which, unfortunately, is not even remotely the case for me. Personally, I have just given up on python3-numpy. Instead, I am now installing numpy and matplotlib using pip3. However, I would happily return to an all-Debian installation if a solution to the transition mess can be found. Thank you all for engaging in this debate. Kind greetings, Joachim
Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
Reviewing #945824, I believe that even if we were eventually to overrule the Python maintainers on this, (i) the impact to users in the meantime is very low, and (ii) we are about to freeze, so it's unlikely we'd make any decision applying to bookworm. So I think we should leave this for the January meeting. Agreed, this is not urgent. For the ongoing (or completed?) migration from 3.10 to 3.11, it's too late anyway. This is just about finding better migration strategies for future increments of the Python3 subversion. Joachim
Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
Package: tech-ctte Estimated volunteers of the Debian Technical Committee: At times, python3-numpy in testing depends on two python3 minor versions in parallel. This is unusual, annoying for many users, and breaking dependent software for some. Complaints have been filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800620 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878281 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903663 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945824 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003805 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025169 Explanations have been given in particular in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945824 According to these, the simultaneous dependency on old and new Python subversions is a deliberate choice as part of a multi-step migration strategy. My request to you, estimated committee members, would be to review this migration strategy. The best possible outcome would be an advise to the package maintainer how to continue his otherwise excellent work without publishing intermediate versions of python3-numpy that cause difficulties downstream. With best regards, Joachim Wuttke
Bug#1025169: python3-numpy: again, why force users to install two versions of Python
Dear Sandro: >> Why does python3-numpy under bookworm, since a few days, >> depend on python3.10 *and* on python3.11? > > because it provides compiled extensions for both 3.10. and 3.11. Sorry, I don't get the logic. To make good use of this package, we need either 3.10 *or* 3.11. Why then force us to install 3.10 *and* 3.11? > Please search older report similar to this one for more information. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945824 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025169 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003805 Conclusion: - Many users see a severe issue here. - You are firmly determined to keep python3-numpy dependent on several python versions. But why? - You would only accept a patch if it "works in every single situation". This amounts to saying "never". Hardly any package is free of bugs. Please take note that the current situation is very remote from working in every single situation. Any decision should be based on fairly weighed pro and cons. For the benefit of those who see this discussion while searching for a solution that just works for them: Currently the simplest solution is to deinstall python3-numpy, then reinstall numpy (and matplotlib and other packages that depend on numpy) using pip3. Cheers, Joachim
Bug#1025169: why does python3-numpy depend on python3.11?
Package: python3-numpy
Version: 1:1.21.5-2
Dear Sandro, dear Matthias, dear all:
Why does python3-numpy under bookworm, since a few days, depend on python3.10
*and* on python3.11?
This breaks our software projects that combine C++ with Python.
The CMake command
find_package(Python3 3.${version_minor_min} REQUIRED
COMPONENTS Interpreter Development NumPy)
fails with error message
CMake Error at
/usr/local/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
Could NOT find Python3 (missing: Development NumPy Development.Module
Development.Embed) (found suitable version "3.11.0", minimum required is
"3.7")
Call Stack (most recent call first):
/usr/local/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594
(_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-3.23/Modules/FindPython/Support.cmake:3192
(find_package_handle_standard_args)
/usr/local/share/cmake-3.23/Modules/FindPython3.cmake:490 (include)
CMakeLists.txt:154 (find_package)
The new dependences of python3-numpy lead to installation of python3.11-minimal,
which somehow lets CMake believe we have a Python3.11 system.
However, lots of other packages (e.g. xfce and xelatex) depend on
python3.10-minimal.
So I cannot uninstall that one.
I already experienced (and reported) similar problems with previous increments
of the Python minor version. What could be a global solution?
Kind regards, and thanks for your maintenance work - Joachim
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
Bug#1010235: provide metapackage for Matplotlib with LaTex markup
Package: python3-matplotlib Source: matplotlib (3.5.1-2) Version: 3.5.1-2+b1 The dependency problems for Matplotlib with LaTex markup are so notorious that they are already mentioned in the Matplotlib tutorial [1]: "On Ubuntu and Gentoo, the base texlive install does not ship with the type1cm package. You may need to install some of the extra packages to get all the goodies that come bundled with other LaTeX distributions." That note is outdated only insofar as the problem is no longer with type1cm, a package which does not exist in recent Debian versions. Starting with Matplotlib 3.2.1, the critical dependency is rather on file type1ec.sty [2], which is provided by package cm-super (or cm-super-minimal). I see the following possibilities. Solution 1. Let python3-matplotlib depend on cm-super-minimal, dvipng, texlive-extra-utils, texlive-latex-extra. Solution 2. As solution 1. Additionally, provide a new package python3-matplotlib-minimal for basic Matplotlib without LaTex markup. Solution 3. Leave python3-matplotlib without support for LaTeX markup. Provide a new dependency package python3-matplotlib-latex that depends on python3-matplotlib, cm-super-minimal, dvipng, texlive-extra-utils, texlive-latex-extra. [1] https://matplotlib.org/3.5.0/tutorials/text/usetex.html [2] https://github.com/matplotlib/matplotlib/issues/16911 smime.p7s Description: S/MIME Cryptographic Signature
Bug#1010216: usetex=True won't work without file type1ec.sty from package cm-super-minimal
Package: python3-matplotlib
Source: matplotlib (3.5.1-2)
Version: 3.5.1-2+b1
Run a plot script that contains
from matplotlib import rc
rc('text', usetex=True)
and makes use of LaTeX markup (some labels containing "$...$").
Execution will fail with a long traceback and an error message from LaTeX,
appended below.
Cause:
According to https://github.com/matplotlib/matplotlib/issues/16911,
Matplotlib v3.2.1 introduced the dependence on file type1ec.sty
"so that unicode input works (#14146 and linked issues)".
Proposed solution:
Add package cm-super-minimal to list of suggested packages.
In a separate report, I will propose to elevate LaTeX dependencies
from "Suggests" to "Recommends" or "Depends".
## Error message
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 233, in
_run_checked_subprocess
report = subprocess.check_output(
File "/usr/lib/python3.10/subprocess.py", line 420, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['latex', '-interaction=nonstopmode',
'--halt-on-error', '../1acea6f6c115d0ec7a634ed0529287b9.tex']' returned non-zero
exit status 1.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.10/tkinter/__init__.py", line 1921, in __call__
return self.func(*args)
File "/usr/lib/python3.10/tkinter/__init__.py", line 839, in callit
func(*args)
File "/usr/lib/python3/dist-packages/matplotlib/backends/_backend_tk.py",
line 251, in idle_draw
self.draw()
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py",
line 9, in draw
super().draw()
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py",
line 436, in draw
self.figure.draw(self.renderer)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73, in
draw_wrapper
result = draw(artist, renderer, *args, **kwargs)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in
draw_wrapper
return draw(artist, renderer)
File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2810, in draw
mimage._draw_list_compositing_images(
File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132, in
_draw_list_compositing_images
a.draw(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in
draw_wrapper
return draw(artist, renderer)
File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082, in
draw
mimage._draw_list_compositing_images(
File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132, in
_draw_list_compositing_images
a.draw(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50, in
draw_wrapper
return draw(artist, renderer)
File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1159, in draw
ticklabelBoxes, ticklabelBoxes2 = self._get_tick_bboxes(ticks_to_draw,
File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1085, in
_get_tick_bboxes
return ([tick.label1.get_window_extent(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1085, in
return ([tick.label1.get_window_extent(renderer)
File "/usr/lib/python3/dist-packages/matplotlib/text.py", line 910, in
get_window_extent
bbox, info, descent = self._get_layout(self._renderer)
File "/usr/lib/python3/dist-packages/matplotlib/text.py", line 309, in
_get_layout
_, lp_h, lp_d = renderer.get_text_width_height_descent(
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py",
line 259, in get_text_width_height_descent
w, h, d = texmanager.get_text_width_height_descent(
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 335, in
get_text_width_height_descent
dvifile = self.make_dvi(tex, fontsize)
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 271, in
make_dvi
self._run_checked_subprocess(
File "/usr/lib/python3/dist-packages/matplotlib/texmanager.py", line 241, in
_run_checked_subprocess
raise RuntimeError(
RuntimeError: latex was not able to process the following string:
b'lp'
Here is the full report generated by latex:
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2022/dev/Debian)
(preloaded format=latex)
restricted \write18 enabled.
entering extended mode
(../1acea6f6c115d0ec7a634ed0529287b9.tex
LaTeX2e <2021-11-15> patch level 1
L3 programming layer <2022-01-21>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/type1cm/type1cm.sty)
Bug#1001103: solution on the CMake side
solution or workaround? Set Python_FIND_STRATEGY to LOCATION. Or set policy CMP0094 to NEW. Or require CMake version >= 3.15. With this, CMake finds Python 3.9 even if some 3.10 modules are present on the system. Amyway, I still think that a Debian package should be able to **support** different Py minor versions without **depending** on them. It should only depend on the default Py version, which is defined by packages python3, python3-minimal etc. - Joachim
Bug#1001103: bug also reported to CMake
The broken code line find_package(Python3 COMPONENTS Interpreter Development) comes literally from the CMake docs, https://cmake.org/cmake/help/v3.22/module/FindPython3.html. So I reported the inconsistency also at https://gitlab.kitware.com/cmake/cmake/-/issues/22983. - Joachim
Bug#1001103: workaround
For the benefit of others who encounter the same problem: To work around this bug, deinstall the Debian package python3-numpy for good, and reinstall numpy using pip3. Very disappointing though that this kind of inconsistencies is allowed into Debian. - Joachim
Bug#1001152: dependence of numpy on python3.10 breaks software that depends on python3-dev
Package: python3-dev
Version: 3.9.7-1
The recent addition of python3.10:any to the dependencies
of python3-numpy under Debian testing (=bookworm) breaks
software that depends on python3-dev.
The numpy maintainer says this is not his problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001103
Can you maintainers please cooperate to find a solution?
Specifically, this CMake code
find_package(Python3 COMPONENTS Interpreter Development)
message(STATUS " Python3_VERSION : ${Python3_VERSION}")
message(STATUS " Python3_INTERPRETER_ID : ${Python3_INTERPRETER_ID}")
message(STATUS " Python3_EXECUTABLE : ${Python3_EXECUTABLE}")
message(STATUS " Python3_STDLIB : ${Python3_STDLIB}
Python3_STDARCH: ${Python3_STDARCH}")
message(STATUS " Python3_SITELIB : ${Python3_SITELIB}
Python3_SITEARCH: ${Python3_SITEARCH}")
message(STATUS " Python3_INCLUDE_DIRS : ${Python3_INCLUDE_DIRS}")
message(STATUS " Python3_LIBRARIES: ${Python3_LIBRARIES}")
message(STATUS " Python3_LIBRARY_DIRS : ${Python3_LIBRARY_DIRS}")
if(NOT Python3_FOUND)
message(FATAL_ERROR "Python3 not found.")
endif()
results in
-- Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES
Development Development.Module Development.Embed) (found version "3.10.0")
-- Python3_VERSION : 3.10.0
-- Python3_INTERPRETER_ID : Python
-- Python3_EXECUTABLE : /usr/bin/python3.10
-- Python3_STDLIB : /usr/lib/python3.10 Python3_STDARCH:
/usr/lib/python3.10
-- Python3_SITELIB : /usr/lib/python3/dist-packages
Python3_SITEARCH: /usr/lib/python3/dist-packages
-- Python3_INCLUDE_DIRS :
-- Python3_LIBRARIES: Python3_LIBRARY-NOTFOUND
-- Python3_LIBRARY_DIRS :
CMake Error at ... (message):
Python3 not found.
Cheers, Joachim
Bug#1001103: dependence of numpy on python3.10 breaks software that depends on python3-dev
Package: python3-numpy
Version: 1:1.21.4-2
The recent addition of python3.10:any to the dependencies
of python3-numpy under Debian testing (=bookworm) breaks
software that depends on python3-dev.
Specifically, this CMake code
find_package(Python3 COMPONENTS Interpreter Development)
message(STATUS " Python3_VERSION : ${Python3_VERSION}")
message(STATUS " Python3_INTERPRETER_ID : ${Python3_INTERPRETER_ID}")
message(STATUS " Python3_EXECUTABLE : ${Python3_EXECUTABLE}")
message(STATUS " Python3_STDLIB : ${Python3_STDLIB}
Python3_STDARCH: ${Python3_STDARCH}")
message(STATUS " Python3_SITELIB : ${Python3_SITELIB}
Python3_SITEARCH: ${Python3_SITEARCH}")
message(STATUS " Python3_INCLUDE_DIRS : ${Python3_INCLUDE_DIRS}")
message(STATUS " Python3_LIBRARIES: ${Python3_LIBRARIES}")
message(STATUS " Python3_LIBRARY_DIRS : ${Python3_LIBRARY_DIRS}")
if(NOT Python3_FOUND)
message(FATAL_ERROR "Python3 not found.")
endif()
results in
-- Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES
Development Development.Module Development.Embed) (found version "3.10.0")
-- Python3_VERSION : 3.10.0
-- Python3_INTERPRETER_ID : Python
-- Python3_EXECUTABLE : /usr/bin/python3.10
-- Python3_STDLIB : /usr/lib/python3.10 Python3_STDARCH:
/usr/lib/python3.10
-- Python3_SITELIB : /usr/lib/python3/dist-packages
Python3_SITEARCH: /usr/lib/python3/dist-packages
-- Python3_INCLUDE_DIRS :
-- Python3_LIBRARIES: Python3_LIBRARY-NOTFOUND
-- Python3_LIBRARY_DIRS :
CMake Error at ... (message):
Python3 not found.
Can you please revert, and wait with 3.10 until all of Python3 is ready
for that version.
Cheers, Joachim
Bug#986233: closed by Norbert Preining (Re: Bug#986233: texlive-fonts-extra: no further upgrades until #923423 is resolved)
Sorry, Norbert, for what was bogus in my report. Anyway, having this correspondence in the Debian data base may help others who will run into the same problem. Could you possibly give me a short hint how to use "eatmydata" to switch off fsync? And one more question: Isn't texlive-fonts-extra too big? Why not split it into a few topical packages, like math, greek, asian, ... Kind greetings, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#986233: texlive-fonts-extra: no further upgrades until #923423 is resolved
Package: texlive-fonts-extra Version: 2020.20210202-3 Severity: serious Upgrading texlive-fonts-extra takes incredibly long (>20'), and slows down all other processes. This issue has been reported before, and has been transferred to dpkg, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923423. May I kindly ask the texlive-fonts-extra maintainers to abstain from further upgrades until the dpkg issue is solved? - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#923423: confirm severe problem
To confirm the issue: Unpacking texlive-fonts-extra (2020.20210202-3) over (2020.20210202-1) ... is incredibly slow. I'm running Debian/bullseye; the SSD is ext4 and far from full. What is the status of this issue? What are the conclusions after all the above correspondence? Is there any hope? - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#984674: ccache: clang links missing in /usr/lib/ccache
Package: ccache Version: 4.2-1 Dear Joel or other maintainers: Package ccache installs a number of symbolic links to /usr/lib/ccache, among them clang-11 and clang++-11, but not clang and clang++. May I kindly suggest you add these two? Thank you for your work on ccache, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#972394: upstream bug report
I now reported the upstream bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972551, which may or may not be the root of the reported failure. smime.p7s Description: S/MIME Cryptographic Signature
Bug#972551: inclusion of Python3.9 breaks compatibility with libpython3-dev
Package: python3-numpy Version: 1:1.19.2-2+b1 In latest Debian/testing, python3-numpy has added a dependence on libpython3.9-minimal libpython3.9-stdlib python3.9 python3.9-minimal. This breaks compatibility with packages like python3, python3-dev, libpython3-dev that depend exclusively on 3.8. It causes failure of CMake commands like find_package(Python3 COMPONENTS Interpreter Development NumPy) Is there a way to clarify once and for all that all Python3 packages with unspecified minor version ought to depend on the same minor version? - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9
Markus: Further investigation shows that the problem is not with NumPy. CMake not even finds Python.h. The problem is most likely a mixture of Python 3.8 and 3.9 files on your system. Try to uninstall libpython3-dev, which still depends on 3.8. Good luck, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#972394: got same error in other project
Hi Markus, I confirm that this is a serious issue. I got the same error message Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES Development NumPy Development.Module Development.Embed) (found version "3.9.0") in a completely different software project after I dist-upgraded my Debian/ testing system. That upgrade did not affect my cmake, which I compile myself (version 3.18.20200714-g2da7786-dirty). However, the upgrade did change numerous Python3 packages, among them python3-numpy:amd64 (1:1.19.1-1, 1:1.19.2-2+b1) but not python3-dev. So my guess is the problem is a change in python3-numpy that breaks CMake's find_package(Python3 COMPONENTS Development NumPy) command. Accordingly, I will report the bug to python3-numpy. Regards, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#949960: Qt5::Gui: CMake does not find libEGL.so
Package: libqt5gui5 Version: 5.12.5+dfsg-2 CMake fails with the following message: CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:27 (message): The imported target "Qt5::Gui" references the file "/usr/lib/x86_64-linux-gnu/libEGL.so" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:63 (_qt5_Gui_check_file_exists) /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:85 (_qt5gui_find_extra_libs) /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:186 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:28 (find_package) CMakeLists.txt:50 (find_package) -- Configuring incomplete, errors occurred! Bug occured in docker image debian:testing, amd64. A few days before, everything still worked. Docker does install the packages libegl-mesa0 and libegl1. So I guess libEGL.so is present on the system, but not found by Qt5GuiConfig.cmake. smime.p7s Description: S/MIME Cryptographic Signature
Bug#939305: xfce4: Menu > Settings > Desktop > Background > Style=None won't override Debian wallpaper
Package: xfce4-settings Version: 4.14.1-1 After upgrade from Debian10 (buster) to Debian11 (bullseye = current testing) and rebooting, xfce4 shows a blueish wallpaper with a "debian10" logo. I should be able to override this choice from Menu > Settings > Desktop > Background, setting Style to None. However, this has no effect. smime.p7s Description: S/MIME Cryptographic Signature
Bug#884278: prevent deinstallation of boot-critical package
One last ping? Additionally to what Vincas suggested, if you can reproduce the bug and use a boot environment where systemd-journald is running, please provide the complete output of "journalctl -b". Sorry, colleagues: I have absolutely no time to reinvestigate this issue and to risk destabilizing my system. Can you put this issue to "dormant" status, to be reopened only if others encounter similar problems? Kind regards, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#882782: see also
see https://superuser.com/questions/1276256 for a workaround that worked for me. - Joachim Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Bug#884278: prevent deinstallation of boot-critical package
Could you check what packages on your system have installed have shipped AppArmor profile, and so maybe causing the issue, like this: dpkg -S /etc/apparmor.d/ # dpkg -S /etc/apparmor.d/ apparmor-profiles-extra, apparmor: /etc/apparmor.d - Joachim Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Bug#884278: prevent deinstallation of boot-critical package
How did you draw the conclusion that this system hang was caused by deinstalling the apparmor package? After the Grub chooser, on default boot mode, I got a black text screen, then one line, saying that /dev/sdb1 was clean, then nothing more happened. In recovery mode, I got more than one screen full of messages. The last line was vaguley security related, but did not indicate any failure. A few lines above, the was a Debian related line that contained "+APPARMOR", among many other flags. This recalled me that I had deinstalled apparmor. So I mounted my root file system from a rescue disk, installed apparmor, rebooted, and everything was back to normal. smime.p7s Description: S/MIME Cryptographic Signature
Bug#884278: prevent deinstallation of boot-critical package
Package: apparmor Version: 2.11.0-3 Apparmor can be boot critical. Therefore, users should be warned from deinstalling. In more detail: Cleaning up my Debian/testing installation, it occured to me that there was an unneeded package apparmor. So I deinstalled it, without any conflicting dependences and without any other resistance. When I rebooted some days later, the system hang. No error message appeared, no clue pointed to missing apparmor. To prevent this from happening to others, several measures seem in order: - Revise the package description: Make it somewhat less technical, and emphasize that the package is needed to boot the default kernel - Make other packages (which ?) depend on apparmor to prevent unconscient deinstallation of apparmor. - Consider an extra dialog popping up to say: this is boot critical, sure you want to deinstall? smime.p7s Description: S/MIME Cryptographic Signature
Bug#868894: find_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake
finally I reported it upstream at https://github.com/trilinos/Trilinos/issues/1655 - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#868894: find_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake
Package: trilinos-dev Version: 12.10.1-3 CMake's find_package takes an option COMPONENTS. Usage with Trilinos seems to be documented nowhere, but TrilinosConfig.cmake clearly is intended to support e.g. find_package(Trilinos REQUIRED COMPONENTS Epetra Belos Ifpack) However, at the bottom of TrilinosConfig.cmake there is a long list that includes all Trilinos subproject CMake files. This overwrites the component selection, and makes it ineffective: the client application will depend on _all_ of Trilinois, not just on the selected components. smime.p7s Description: S/MIME Cryptographic Signature
Bug#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make
I don't think it is possible for trilinos to depend on both versions. Of course it should not. But it does. $ apt-cache show libtrilinos-amesos-dev Package: libtrilinos-amesos-dev Source: trilinos Version: 12.10.1-3 .. Depends: libmumps-dev, libtrilinos-amesos12 (= 12.10.1-3), trilinos-dev $ apt-cache show libmumps-dev Package: libmumps-dev Source: mumps Version: 5.1.1-2 .. Depends: libmumps-5.1.1 (= 5.1.1-2), libscalapack-mpi-dev, mpi-default-dev $ apt-cache show libtrilinos-amesos12 Package: libtrilinos-amesos12 Source: trilinos Version: 12.10.1-3 .. Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libmumps-4.10.0, libopenmpi2, libstdc++6 (>= 5.2), libtrilinos-epetra12, libtrilinos-epetraext12, libtrilinos-teuchos12 smime.p7s Description: S/MIME Cryptographic Signature
Bug#868873: dependence on libmumps-4.10.0 _AND_ libmumps-5.1.1 breaks make
Package: trilinos-all-dev Version: 12.10.1-3 Since the recent update of Debian/testing from libmumps-4.10.0 to libmumps-5.1.1, trilinos-all depends on both of them. This breaks my build: make[2]: *** No rule to make target '/usr/lib/libsmumps.so', needed by after providing an ad-hoc link /usr/lib/libsmumps.so -> /usr/lib/libsmumps-4.10.0.so, the next error comes up: make[2]: *** No rule to make target '/usr/lib/libdmumps.so', needed by smime.p7s Description: S/MIME Cryptographic Signature
Bug#864779: Epetra doc missing
Package: trilinos-doc Version: 12.10.1-3 Documentation of the important Trilinos component Epetra is missing in /usr/share/doc/trilinos. smime.p7s Description: S/MIME Cryptographic Signature
Bug#846269: man clang-format: deceptive link to texinfo
Package: clang-format-3.9 Version: 1:3.9-6 The "SEE ALSO" section of the man page says: "The full documentation for clang-format is maintained as a Texinfo ... the command info clang-format should give you access to the complete manual." This is deceptive, since "info clang-format" only prints a verbatim copy of the man page (even including the "SEE ALSO" section). The "SEE ALSO" section should therefore be rewritten. The redirection to Texinfo should be deleted unless the Texinfo page is substantially enhanced. Instead, the "SEE ALSO" section should point to a full documentation of the clang-format style options. Since such documentation seems not to be available offline, I suggest to point to the web page http://llvm.org/releases/3.9.0/tools/clang/docs/ClangFormatStyleOptions.html smime.p7s Description: S/MIME Cryptographic Signature
Bug#836170: another reason why this needs to be resolved: warnings are confusing if there is another problem
I get similar messages when starting evince: Gtk-WARNING **: Failed to get the GNOME session proxy: The name org.gnome.SessionManager is not owned This is not only annoying. It can be badly confusing. Today, at each attempt to start evince, it printed twice the above message, then crashed. I did not realize that these messages were not new, but had annoyed me since long. So naturally, I assumed the cause of the crash to be somehow related to the messages. This badly diverted me from the real cause of the crash (/usr/lib/evince/evinced running as a zombie), which had nothing at all to do with GNOME. Once the evinced process was killed, I could start evince, which then printed exactly the same warnings as before, and worked. Therefore, maintainers: Please deliver us from these warnings. smime.p7s Description: S/MIME Cryptographic Signature
Bug#843997: FindBoost.cmake not ready for libboost-1.62
Package: cmake-data Version: 3.6.2-2 FindBoost.cmake contains a hard-coded choice of supported versions. In the CMake version currently distributed with Debian/testing this lists ends with 1.61. The same Debian/testing, however, comes with libboost-1.62. Obviously, this is a severe inconsistency because it breaks application builds. smime.p7s Description: S/MIME Cryptographic Signature
Bug#840490: ptpd should run as a daemon as soon as it is installed
Package: ptpd Version: 2.3.1-debian1-1 Upon fresh installation, ptpd does exactly nothing. Even the explicit command "/etc/init.d/ptpd start" is not sufficient to get the daemon started. This is not what I expected. I would expect that installation of package ptpd suffices to get daemon ptpd running in the background. I would suggest to change /etc/default/ptpd into something like -- # /etc/default/ptpd # Set to "yes" to actually start ptpd automatically START_DAEMON=yes # Add command line options for ptpd PTPD_OPTS="-c /etc/ptpd.conf" -- and to add a standard /etc/ptpd.conf to the package. - Joachim Wuttke smime.p7s Description: S/MIME Cryptographic Signature
Bug#824043: [pkg-boost-devel] Bug#824043: this should be a dependency package, instead of containing all headers
Thank you, Steve, for your detailed comment. What's certainly different now from 6 years ago is: Parts of Boost have made it into the standard library of C++11. Which makes them obsolete qua part of Boost, except transitorily to support non-compliant compilers. I would see this as one reason more not to bundle all of Boost. - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#824043: this should be a dependency package, instead of containing all headers
Package: libboost1.58-dev Version: 1.58.0+dfsg-5 and others The way Boost is currently packaged in Debian is non-standard, and inconvenient. To test dependences and build procedures in my application, I often need to selectively remove single Boost components from my system. This requires me to work against the current packaging. Standard is that -dev packages contain header files. This is violated by packages like libboost-date-time1.58-dev that contain no headers, but binary libraries. These libraries should go to libboost-date-time1.58.0. libboost-date-time1.58-dev should contain /usr/include/boost/date_time.hpp. libboost1.58-dev currently contains header files for _all_ components of Boost, which precludes selective (de)installation. It should become a dependency package, and leave it to packages like libboost-date-time1.58-dev to actually contain specific headers. smime.p7s Description: S/MIME Cryptographic Signature
Bug#811508: texlive-math-extra: requires ucharcat, which is not provided
Package: texlive-math-extra
Version: 2015.20151225-2
The command
\usepackage[<...>]{unicode-math}
causes
! LaTeX Error: File `ucharcat.sty' not found.
because per v0.8b (2015/09/09) LaTeX package unicode-math
has introduced a dependency on LaTex package ucharcat
that is not reflected in the dependences of Debian
package texlive-math-extra.
Bug#802587: at least, warn about absence of libgtest library package
Given that, can you restate what problem you encountered using the package? Somehow I discovered that there is a libgtest-dev in Debian, and a FindGTest in cmake. So I installed libgtest-dev on my system, removed ThirdParty/gtest from my project, changed CMakeList.txt files, tried to rebuild the project, saw that FindGTest did not find the library, investigated the problem, and finally discovered that libgtest-dev is deceptive in that it does not pull in the binary without which it is useless. Therefore I consider the current state of affairs as untenable, which is also attested by the high number of views of the discussion thread at http://askubuntu.com/questions/145887/why-no-library-files-installed-for-google-test. A clear word about the missing dependency on the nonexistent library package in the description of libgtest-dev would have had the potential of saving me considerable time. I do not insist that it be labelled »warning«. - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#802587: at least, warn about absence of libgtest library package
Package: libgtest-dev Version: 1.7.0-4 There exists no corresponding library binary package libgtest1. This is in accordance with a recommendation of the upstream authors, https://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog, but it is in conflict with the well-established standard way of how libraries are distributed in Debian. I wonder if there is any recommendable use of a header package that comes without the corresponding library package. Unless there is a convincing use case, I propose to remove libgtest-dev for good. Otherwise, at the very least, I suggest that the description of libgtest-dev be amended to clearly state that, quite exceptionally for a header package, its dependence on the binary library is not enforced in Debian, and that upon special recommendation of upstream the binary library is not and will not be packaged for Debian. --- Dr. Joachim Wuttke Group Leader Scientific Computing Jülich Centre for Neutron Science (JCNS) Forschungszentrum Jülich GmbH Outstation at Heinz Maier-Leibnitz Zentrum (MLZ) +49 89 289 10715 http://apps.jcns.fz-juelich.de smime.p7s Description: S/MIME Cryptographic Signature
Bug#797189: cppcheck multithreading (-j) is unreliable
Package: cppcheck Version: 1.69 Running cppcheck on a medium sized project (~40 files, 20kLOC), the number of issues found depends heavily on whether or not I use multithreading (-j7). Until this problem is fixed upstream, as a minimal solution the man page and cppcheck --help should warn about the option -j (something like under development, may affect results) smime.p7s Description: S/MIME Cryptographic Signature
Bug#778610: fourier.sty is incompatible with fontspec.sty under xelatex (Command `\hbar' already defined)
Package: texlive-fonts-extra
Version: 2014.20141024-1
Under xelatex,
\usepackage{fontspec}
\usepackage{fourier}
fails while reading fourier.sty with
! LaTeX Error: Command `\hbar' already defined.
whereas the inverse inclusion order works.
smime.p7s
Description: S/MIME Cryptographic Signature
Bug#764310: manpages-dev and libcerf-doc: error when trying to install together
As upstream maintainer of libcerf, I would like to express a clear preference for solving the conflict by withdrawing cerf.3 and cerfc.3 from manpages-dev. I already proposed this solution to upstream, https://bugzilla.kernel.org/show_bug.cgi?id=80541 where it has been received favorably, but not yet definitively accepted. It might be helpful if somebody expressed in the name of Debian that the matter is somewhat urgent. I am opposed to the alternative solution of libcerf renaming the functions cerf and cerfc. Any other names would be less pertinent. There is no conflict with glibc. On the contrary, libcerf complements glibc in providing a missing implementation. Should glibc one day provide an official implementation, then the two functions will be immediately withdrawn from libcerf. - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#744918: upstream homepage dead; needs patch to work with boost-python = 1.54
Package: python-pygccxml Version: 1.0.0-4 Bug 1: Homepage: http://www.language-binding.net/pygccxml/pygccxml.html is dead (Whoops, we can't find that page.) Bug 2: When used with boost-python 1.54, this type of error may occur: /usr/local/lib/python2.7/dist-packages/pygccxml/parser/scanner.py:337: UserWarning: unable to find out array size from expression warnings.warn( msg ) ERROR error occured, while parsing element with name FundamentalType and attrs ['attributes', 'align', 'size', 'id', 'name']. Error: pygccxml error: unable to find fundamental type with name 'atomic_int_type'.. Traceback (most recent call last): [...] File /usr/local/lib/python2.7/dist-packages/pyplusplus/module_builder/builder.py, line 92, in __init__ , indexing_suite_version) File /usr/local/lib/python2.7/dist-packages/pyplusplus/module_builder/builder.py, line 146, in __parse_declarations decls = reader.read_files( files, compilation_mode ) File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/project_reader.py, line 225, in read_files return self.__parse_file_by_file(files) File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/project_reader.py, line 264, in __parse_file_by_file decls = reader.read_xml_file( prj_file.cached_source_file ) File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/source_reader.py, line 245, in read_xml_file declarations, files = self.__parse_gccxml_created_file( ffname ) File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/source_reader.py, line 294, in __parse_gccxml_created_file scanner_.read() File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/etree_scanner.py, line 41, in read self.startElement( elem.tag, elem.attrib ) File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/scanner.py, line 199, in startElement obj = self.__readers[name]( attrs ) File /usr/local/lib/python2.7/dist-packages/pygccxml/parser/scanner.py, line 361, in __read_fundamental_type % attrs.get( XML_AN_NAME, '' ) ) RuntimeError: pygccxml error: unable to find fundamental type with name 'atomic_int_type'. This is a known problem, see https://trac.macports.org/attachment/ticket/39927/pyplusplus_base.log and http://pastebin.com/Zid3hN0p Proposed solution to both problems: Change the upstream homepage to https://bitbucket.org/ompl/pygccxml, where a patch fixing bug 2 is provided. Note: This page is clearly labelled as unofficial homepage. As the maintainer, Mark Moll, explained to me: The only reason it’s unofficial, because I don’t know if I should be in charge of accepting pull requests (since I know so little about the code). This is situation is not ideal. But it is certainly better to join forces with Mark than to continue refering to an outdated, unmaintained official homepage. smime.p7s Description: S/MIME Cryptographic Signature
Bug#675519: alternative proposal for upstream homepage
The official homepage http://sourceforge.net/projects/pygccxml/ seems to be dead; the maintainers are unresponsive. A better solution is the unofficial, but maintained homepage https://bitbucket.org/ompl/pyplusplus The decision to point there should be coordinates with project python-pygccxml. See bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744918 for more details. smime.p7s Description: S/MIME Cryptographic Signature
Bug#744864: broken link to upstream homepage
Package: python-py++ Version: 1.0.0-1 The metadata of this package (apt-cache show python-py++) include Homepage: http://www.language-binding.net/pyplusplus/pyplusplus.html This page no longer exists (Whoops, we can't find that page.) smime.p7s Description: S/MIME Cryptographic Signature
Bug#675519: suggest replacement link
It seems the code is currently hosted at http://sourceforge.net/projects/pygccxml/ This is not impressive as an upstream project homepage but certainly better than a broken link. smime.p7s Description: S/MIME Cryptographic Signature
Bug#744217: 'man gnuplot' of gnuplot-nox describes unavailable X11 options
Package: gnuplot-nox Version: 4.6.5-1 == observation 1 == man gnuplot(1) has SYNOPSIS gnuplot [X11 options] [options] [file ...] and a section X11 OPTIONS that refers to man X(1). == observation 2 == When gnuplot is invoked with X11 options, one gets $ gnuplot -title bla unrecognized option -title Cannot open load file 'bla' bla, line 0: util.c: No such file or directory == suggested fix == Since gnuplot behaves differently under gnuplot-nox and gnuplot-x11, the man page also needs to be different for these two packages. Under gnuplot-nox, man gnuplot should - not mention unavailable X11 options - indicate clearly that it describes the -nox version smime.p7s Description: S/MIME Cryptographic Signature
Bug#744218: 'man gnuplot' of gnuplot describes unavailable X11 options
Package: gnuplot-nox Version: 4.6.5-1 == observation 1 == man gnuplot(1) has SYNOPSIS gnuplot [X11 options] [options] [file ...] and a section X11 OPTIONS that refers to man X(1). == observation 2 == When gnuplot is invoked with X11 options, one gets $ gnuplot -title bla unrecognized option -title Cannot open load file 'bla' bla, line 0: util.c: No such file or directory == suggested fix == Since gnuplot behaves differently under gnuplot-nox and gnuplot-x11, the man page also needs to be different for these two packages. Under gnuplot-nox, man gnuplot should - not mention unavailable X11 options - indicate clearly that it describes the -nox version smime.p7s Description: S/MIME Cryptographic Signature
Bug#744218: sorry, duplicate submission
please delete this one; keep #744217 sorry - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#730642: deborphan: false positive: hdfview
Package: deborphan Version: 1.7.28.8 Severity: normal Tags: upstream Dear Maintainer, # apt-get install hdfview # deborphan hdfview in words: after explicitly installing hdfview, deboprhan incorrectly thinks it is an orphan. Regards, Joachim -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages deborphan depends on: ii libc6 2.17-93 Versions of packages deborphan recommends: ii apt 0.9.12.1 ii dialog1.2-20130928-1 ii gettext-base 0.18.3.1-1 deborphan suggests no packages. -- no debconf information Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630079: emacs23: file locked by user@hostname (pid this-emacs-process): (s, q, p, ?)?
Package: emacs23 Version: 23.3+1-1 Severity: important After migration from squeeze,emacs22 to wheezy,emacs23 emacs consistently shows the following behaviour: As soon as I start to modify a buffer, I am interrupted by a question showing up in the bottom line: file locked by user@hostname (pid this-emacs-process): (s, q, p, ?)? After answering 's' I am allowed to edit. When I say ^X^S to save the buffer, the very same message pops up again. Obviously, this makes working a pain. It seems I am the first to report this bug - so I am afraid I messed something up in my system. I have not the least clue what. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs23 depends on: ii emacs23-bin-common 23.3+1-1 The GNU Emacs editor's shared, arc ii libasound2 1.0.23-4 shared library for ALSA applicatio ii libatk1.0-0 2.0.0-1 The ATK accessibility toolkit ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.4.8-3 simple interprocess messaging syst ii libfontconfig1 2.8.0-2.2generic font configuration library ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libgdk-pixbuf2.0-0 2.23.3-3 GDK Pixbuf library ii libgif4 4.1.6-9 library for GIF images (library) ii libglib2.0-02.28.6-1 The GLib library of C routines ii libgpm2 1.20.4-3.4 General Purpose Mouse - shared lib ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libice6 2:1.0.7-1X11 Inter-Client Exchange library ii libjpeg62 6b1-1The Independent JPEG Group's JPEG ii libm17n-0 1.6.2-3 a multilingual text processing lib ii libncurses5 5.9-1shared libraries for terminal hand ii libotf0 0.9.12-1 A Library for handling OpenType Fo ii libpango1.0-0 1.28.3-6 Layout and rendering of internatio ii libpng12-0 1.2.44-2 PNG library - runtime ii librsvg2-2 2.32.1-1 SAX-based renderer library for SVG ii libsm6 2:1.2.0-1X11 Session Management library ii libtiff43.9.5-1 Tag Image File Format (TIFF) libra ii libx11-62:1.4.3-1X11 client-side library ii libxft2 2.2.0-2 FreeType-based font drawing librar ii libxpm4 1:3.5.9-1X11 pixmap library ii libxrender1 1:0.9.6-1X Rendering Extension client libra ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime emacs23 recommends no packages. Versions of packages emacs23 suggests: pn emacs23-common-non-dfsg none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#409745: Iceweasel Bookmarks Editor Drag and Drop Not Working
Please re-open the bug: I experience exactly the same problem as Andrea described: dragged bookmark bookmarks can't reach the desired place, resulting in returning at the starting point it's very annoying - Joachim my configuration: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1) Debian/lenny updated today Linux 2.6.22-2-686 Window manager JWM v2.0.1 - - Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender) - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366516: boot process of fresh etch installation does not lead to graphic login: inconsistent paths /usr/bin vs /usr/bin/X11
Package: xdm Version: 1.0.1-6 Inconsistencies in downgrading from sid to etch lead me to completely reinstalling Debian. So, this report is about Debian etch as of today. I installed from the CD image http://cdimage.debian.org/cdimage/etch_di_beta2/i386/iso-cd/debian-testing-i386-netinst.iso. I deselected desktop and standard to prevent the gnome overhead from being installed. After rebooting into the fresh system, I updated apt and upgraded the installed packages via ftp. Then, I installed xserver-xorg, xdm, my preferred window manager, a few other packages, and all their friends-and-relations. (1) At some stage, startx failed because some scripts expect xdm to reside in /usr/bin/X11 whereas etch installed it in /usr/bin. A symbolic link helped. At this stage, if not earlier, I was able to start X11 from tty1 via startx. (2) /etc/inittab comes with default runlevel=2. It seems that I have to change this manually. (3) After the n-th reboot, no progress: still a vt100 login to tty1 instead of the graphic X11 login screen. At last, I found an enlightening message in xdm.log: server /usr/bin/X cannot be executed server open failed for :0, giving up and so on. Another link towards /usr/bin/X11 helped. xdm developers: _please_ prevent Debian from becoming gnome-only. - Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
