Hello,
This bug, as sent by the issuer, seems quite specific to xautolock:
> One would not realise this, but xautolock will not execute vlock
> after idle time because xautolock "thinks" vlock is still
> running.
Not sure of this statement due to https://bugs.debian.org/702705#72
However, if "vl
I use vlock on a console-only computer with fbterm (a frame buffer terminal
emulator) and no install of X11.
The removal of the new.so module prevents vlock from functioning on my
setup.
In fbterm I could only get vlock working with "vlock -ans" - not with
"vlock -as" which gives me the error:
"
Control: tags -1 + patch
This vulnerability appears to be very hard to fix and the buggy part
appears to be the Linux kernel. Currently vlock therefore is not part of
Debian jessie. Rather than releasing jessie without vlock, I am
proposing to reduce its functionality in a way the removes this
vul
Hi,
vlock has a RC bug (#702705). I was working on it and requesting help, without
success.
The bug seems to be in kernel, not in vlock. But vlock was removed from testing.
I sent a patch, and Bastien sent other patch, but these patches doesn't solve
the problem, only mitigate it.
Cou
Hi,
could you help us with this problem?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702705#72
Thanks.
kix
--
.''`.
: :' : Rodolfo García Peñas (kix)
`. `'` Proud Debian Developer
`-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.o
Package: vlock
Version: 2.2.2-3
control: tag -1 + patch
Ok may be a kernel problem search
Race in vt_event_wait() during suspend/resume
Nevertheless they are other problem with vlock:
- VT_WAITACTIVATE has select semantic ie
accroding to xfree86/os-support/linux/lnx_init.
There's a race here,
Hi Rodolfo,
* Rodolfo García Peñas [2013-07-12; 20:39]:
> could you try it without X11 (running the vlock -san in
> console) and see if the problem continues? If it continues,
> then probably we can run vlock -sa (without the "n" module) and
> try to see if the bug is in that module.
Sorry, I mi
Hi Rodolfo, debian developers,
* Gregor Zattler [2013-07-27; 10:47]:
> * Gregor Zattler [12. Jul. 2013]:
>> * Rodolfo García Peñas [12. Jul. 2013]:
>>> Probably the bug could be here:
>>>
>>> module new.c:
>>> 173 /* Work around stupid X11 bug: When switching immediately after the
>>> comma
Hi Rodolfo,
* Gregor Zattler [12. Jul. 2013]:
> * Rodolfo García Peñas [12. Jul. 2013]:
>> Probably the bug could be here:
>>
>> module new.c:
>> 173 /* Work around stupid X11 bug: When switching immediately after the
>> command
>> 174* is entered, the enter button may get stuck. */
>> 1
Hi Rodolfo,
* Rodolfo García Peñas [12. Jul. 2013]:
> I am not sure, but...
>
> Probably the bug could be here:
>
> module new.c:
> 173 /* Work around stupid X11 bug: When switching immediately after the
> command
> 174* is entered, the enter button may get stuck. */
> 175 if (getenv(
Hi again,
could you try it without X11 (running the vlock -san in console) and see if the
problem continues? If it continues, then probably we can run vlock -sa (without
the "n" module) and try to see if the bug is in that module.
Thanks.
kix
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ htt
Hi,
I am not sure, but...
Probably the bug could be here:
module new.c:
173 /* Work around stupid X11 bug: When switching immediately after the
command
174* is entered, the enter button may get stuck. */
175 if (getenv("DISPLAY") != NULL)
176 sleep(1);
Probably the problem is not
Hi Rodolfo,
* Rodolfo García Peñas (kix) [19. Jun. 2013]:
> I cannot reproduce the problem :-(
>
> But, I cannot understand the behaviour.
>
> 1. xautolock calls vlock. xautolock waits vlock to unlock the screen.
> 2. vlock (shell script) calls vlock-main
>
> When vlock-main finish (the user en
Hi,
I cannot reproduce the problem :-(
But, I cannot understand the behaviour.
1. xautolock calls vlock. xautolock waits vlock to unlock the screen.
2. vlock (shell script) calls vlock-main
When vlock-main finish (the user enter the right passwd), then, and
only then, xautolock should unlock
Hi Samuel,
On Dienstag, 4. Juni 2013, Samuel Thibault wrote:
> Well, I actually had never imagined running vlock under an X session,
> because I tend to think it's deemed to break sooner or later depending
> on how X is configured/behaves/etc.: vlock is supposed to be started
> from the virtual co
Holger Levsen, le Tue 07 May 2013 15:31:20 +0200, a écrit :
> # justification: defeats the purpose of the package and has security impact
Well, I actually had never imagined running vlock under an X session,
because I tend to think it's deemed to break sooner or later depending
on how X is configu
severity 702705 grave
# justification: defeats the purpose of the package and has security impact
thanks
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Dear Maintainer,
* Gregor Zattler [10. Mar. 2013]:
> I then see vlock-main in the output of ps fax.
It happened dozend of times since my bug report. This time I
made a screenshot of ps fax (see attached). I'm writing this
email while vlock is still running but obviously not locking my
screen.
Package: vlock
Version: 2.2.2-3
Severity: important
Dear Maintainer,
I start X with startx from the console, my .xsession contains:
xautolock -locker "vlock -san" &
[shortend version, not all options shown]
After some idle time xautolock executes vlock -san which in turn
locks the screen. Thi
19 matches
Mail list logo
