Package: dpkg-dev
Version: 1.22.0
Severity: normal
Dear Maintainer,
* What led up to the situation?
using: dpkg-source --commit
* What exactly did you do (or not do) that was effective (or
ineffective)?
I used `update-alternatives --config editor` because I want to edit
Hello Tom,
I'm very sorry, I overlooked that on this machine "which texstudio"
resulted in "/usr/local/bin/texstudio".
Some self compiled version at some point due to testing something back
then, which took preference. I removed that, started the
correct distribution one, and yes the terminal is
Package: texstudio
Version: 4.3.1+ds-2
Severity: wishlist
Dear Maintainer,
3 Years ago I wrote an integrated terminal for TeXStudio, (
https://github.com/texstudio-org/texstudio/pull/993 ), since then it has been
integreated into upstream, but please you need to enable it in build
configuration
Package: plymouth
Version: 0.9.5-3
Severity: minor
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I just had a user complaining they entered the crypt password wrongly and then
said "maximum tries exceeded" and
Package: libvirt-daemon
Version: 3.0.0-4+deb9u3
Severity: normal
Dear Maintainer,
* What led up to the situation?
Tonight I had a powerfailure on our virtual machine host, when I came into the
office in the morning I noticed, when it came back up all virtual machines that
had Spice configured
I got the same issue which drove me crazy for weeks and months. Every so
often or seldom, some (not all!) files/dirs suddendly belong to 4294967294.
Causing the strangest errors out of the view for my users due to software
running into permission problems where there shouldn't be any. Then after a
tags - wheezy-ignore
I just had this issue. I'm using libnss-ldapd already.
Patched libldap from Carlos Alberto Lopez Perez worked like a charm, thanks!
Thats what by common-auth looks like
auth[success=2 default=ignore] pam_unix.so nullok_secure
auth[success=1
Also note that recently I released Lsyncd 2.0.6 (upstream) which
includes this fix along with a few others.
- Axel
On Mon, Mar 5, 2012 at 5:56 PM, Timo Juhani Lindfors
timo.lindf...@iki.fi wrote:
Hi Axel,
if you send email to 659...@bugs.debian.org the email will only go the
maintainer of
Thank you!!!
Finally, finally someone managed to figure out what mysterious error
13 from rsync means and why it does that. There have been several
reports on this, and I couldn't reproduce it, and even rsync mailling
list failed to explain me why rsync might to a 13 :-))
Going to make a fix
In case of Lsyncd configured with a logfile Lsyncd will redirect
stderr to the logfile. But it will not do any redirect when no logfile
is specified.
However, in case of daemonize() it should have reopened its own stderr
to /dev/null and rsync should inherit that.
Does your syslog ever contain:
Forget the last message, found it:
In lsyncd.c where it says:
-
// disconnects stdstreams
if (!freopen(/dev/null, r, stdin) ||
!freopen(/dev/null, r, stdout) ||
!freopen(/dev/null, r, stderr)
) {
-
change that to
-
// disconnects stdstreams
if
Yes, I could reproduce this with Lsyncd 1.34, and I can confirm the
issue to be gone with 2.0.3.
To quote the strace man page:
On some platforms a process that has a system call trace applied
to it with the -p option will receive a SIGSTOP. This signal
may interrupt a system call
Lsycnd upstream here, 2.0 cannot use fanotify.
I tried to use it, but fanotify does not report file moves and in thus
unusable for indexing software.
(Additionally fanotify keeps open filedescriptors, which can lead to
results not wanted if the indexer is delayed. In my opinion what we need
I suppose this is fixed with version 1.34
(I figured out, every vprintf() call needs it own va_start/va_end calls
and you are not supposed to group 'em)
Kind regards, Axel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
14 matches
Mail list logo
