I am seeing the same issue, and the most recent version (22.3.6-
1+deb12u1) causes the problem the same as 22.3.1. One element that I
see that isn't in Cédric Nisio's log is:
(EE) open /dev/fb0: Permission denied
This does not occur (or is not logged) when X successfully starts using
22.2.4-1.
Is there any way to get elasticsearch running while the patching is in
progress, or is the YAML problem fundamental? Alternately, is there
anything I, as someone unfamiliar with the package and only slightly
proficient at Java programming, can do to help with fixing the problem?
Jamie
Package: python3-csvkit
Version: 0.9.1-1
Justification: renders package unusable
Severity: grave
Dear Maintainer,
Running csvstat or csvcut (or, likely, any command from this package)
results in an immediate error with traceback, due to a missing
dependency on openpyxl. This is a suggested
On Mon, 2014-11-17 at 23:06 +, Philipp Hug wrote:
Ist it possible that you just missed to set START_DAEMON=true
in /etc/default/elasticsearch
I had been trying it with both, and it seemed to make no difference. But
having just tested the whole process again, elasticsearch is starting
and
On Tue, 2014-11-18 at 00:04 +, Philipp Hug wrote:
I suspect you did also run into the following problem, which is related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768178
So after having elasticsearch installed with START_DAEMON not set, systemd
still thinks that elasticsearch
On Thu, 2014-11-06 at 00:50 +0100, Hilko Bengen wrote:
I ended up with systemd at some point, too. And I still have no idea how
to debug daemon startup problems. :-(
Is there someone among the systemd maintainers who might be willing to
lend a hand here?
Jamie
--
To UNSUBSCRIBE, email to
On Tue, 2014-11-04 at 22:34 +0100, Hilko Bengen wrote:
$ sudo -u elasticsearch bash -x
/usr/share/elasticsearch/bin/elasticsearch.
Could you please try if upgrading to version 1.0.3+dfsg-5 (which I just
uploaded to unstable) fixes this problem?
The above command now runs elasticsearch
On Wed, 2014-11-05 at 23:57 +0100, Hilko Bengen wrote:
It doesn't appear that /etc/init.d/elasticsearch works, however.
What init system do you have? SysV? systemd?
systemd. Sorry for not specifying that before.
# invoke-rc.d elasticsearch status
● elasticsearch.service - LSB: Starts
I am also experiencing this problem, with the IOException trying to
write to /usr/share/elasticsearch/data/elasticsearch/nodes/49 when
running:
$ sudo -u elasticsearch bash -x /usr/share/elasticsearch/bin/elasticsearch.
My /etc/elasticsearch/elasticsearch.yml does not have path.data set (it
is
Package: python3-biopython
Version: 1.63+dfsg-4
Severity: normal
Dear Maintainer,
After installing this package, the cpairwise2 C implementations of
functions are not available (see the end of Bio/pairwise2.py for the
attempted loading of these):
Python 3.3.5 (default, Mar 22 2014, 13:24:53)
On Fri, 2014-05-09 at 13:32 +0200, Jakub Wilk wrote:
But in Python 3 imports as always absolute, unless explicitly
requested, so the import fails, and this code snippet is no-op.
Changing the import line to:
from .cpairwise2 import rint, _make_score_matrix_fast
should do the trick.
Package: postgresql-9.3-postgis-2.1-scripts
Version: 2.1.0-2
Severity: important
Dear Maintainer,
The documentation (postgis README.Debian.gz) makes frequent mention
of /usr/share/postgresql/*/contrib/postgis-*/postgis.sql
and /usr/share/postgresql/*/contrib/postgis-*/spatial_ref_sys.sql as a
Package: totem
Version: 3.8.2-3
Severity: normal
Dear Maintainer,
After upgrading to version 3.8, the Open and Open Location menu
items that were previously under Movie were moved to the
top-of-screen menu. However, Play Disc is not present in either
menu, despite being referenced in the
Package: backupninja
Version: 0.9.10-1
Severity: normal
--- Please enter the report below this line. ---
After upgrading to 0.9.10-1 from 0.9.9-1, the ninjahelper script no
longer works. Every menu option (including new and quit) gives the
response:
error: cannot find the file ''
With a subsequent update to dialog, this problem no longer occurs, so I
guess it was http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646072 in
action. Apologies for the bogus report.
Jamie
signature.asc
Description: This is a digitally signed message part
Package: python-ropemacs
Version: 0.6c2-3
Severity: normal
*** Please type your report below this line ***
It is not possible to upgrade this package to 0.6c2-4 due to this issue
with the missing Python-Version field. On trying to upgrade from
0.6c2-3, I get the following:
Preparing to replace
I'm experiencing this problem (or rather, a problem which gives the same
error message) not intermittently, but every time. Here is the output I
get from ls -1 /var/cache/apt/archives/subversion_1.4.0-3_i386.deb |
/usr/sbin/apt-listbugs apt -d:
http_proxy: http://www-cache.vuw.ac.nz:8080 :
Package: nxml-mode
Version: 20041004-6
Severity: normal
Every now and then nxml-mode will go into a degraded mode because it
cannot open the file
/usr/share/emacs21/site-lisp/nxml-mode/char-name/unicode/1D400-1D7FF
- understandable, since it isn't there, but rather in the emacs (not
emacs21)
Matthias Klose writes:
Please recheck with 1.4.0 (in unstable)
This problem no longer occurs in 1.4.0-1. Thank you!
Jamie
--
Artefact Publishing: http://www.artefact.org.nz/
GnuPG Public Key: http://www.artefact.org.nz/people/jamie.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: python2.3-pylint
Version: 0.8.1-1
Severity: grave
The new release of python2.3-pylint in unstable added a dependency on
python2.3-logilab-astng, but there is no such package in the
archive. The same appears true of the 2.2 and 2.4 versions of pylint.
Jamie
--
Artefact Publishing:
Package: svn-workbench
Version: 1.1.6-1
Severity: normal
On almost any action I take, I get a TypeError - as, for example,
clicking on a newly added project:
TryWrapperwb_tree_panel.OnTreeSelChanged
Traceback (most recent call last):
File /usr/share/svn-workbench/wb_exceptions.py, line 45, in
Package: login
Version: 1:4.0.12-3
Severity: normal
I'm not sure if this is the package responsible for the behaviour I'm
experiencing, but I believe it's something from either pam or shadow
(the problem began on two machines after upgrades of only a few
packages, shadow's and pam's being common
Christian Perrier writes:
Quoting Nicolas Fran?ois ([EMAIL PROTECTED]):
Can you check with libpam_modules 0.79-2?
The packages search page for libpam-modules doesn't list 0.79-2 under
any of the distributions; where would I find this?
You can also add readenv=1 to the pam_env line in
Steve Langasek writes:
On Fri, Sep 30, 2005 at 12:06:05AM +0200, Nicolas François wrote:
Sorry I did not specify that this version was uploaded today, and will
probably be available only tomorrow.
It is available today.
I grabbed it (though the packages pages hadn't updated with the
24 matches
Mail list logo
