| Summary: | kbd obsoletes vlock, but vlock does not work | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Dick Gevers <dvgevers> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | luigiwalser, tmb |
| Version: | Cauldron | Keywords: | Triaged |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kbd-1.15.5-1.mga4 | CVE: | |
| Status comment: | |||
|
Description
Dick Gevers
2013-07-26 12:04:33 CEST
Dick Gevers
2013-07-26 12:07:40 CEST
Summary:
kbs obsoletes vlock, but vlock does not work =>
kbd obsoletes vlock, but vlock does not work
Manuel Hiebel
2013-07-26 18:31:16 CEST
Keywords:
(none) =>
Junior_job, Triaged I don't see why this would be a junior job, it's also not clear what the problem is. With the proper provides/obsoletes, urpmi shouldn't have complained. I also don't know why it's not working. Presumably it's working in Fedora (I'll check when I get a chance). Keywords:
Junior_job =>
(none) So I just got a chance to test it in Fedora, and it is broken there too. It's been reported twice in Fedora bugzilla with no responses: https://bugzilla.redhat.com/show_bug.cgi?id=913309 https://bugzilla.redhat.com/show_bug.cgi?id=913311 Until they fix it, we could work around it by shipping the old vlock and deleting the one from kbd in %install. It sounds like there's a proposed solution that fixes it in the second RH bug I linked (provide a PAM config for it), so that's a possibility too. tmb, any thoughts? OK, the pam config suggested in that RH bug is the same as the one that's shipped our vlock package, so I've included it in kbd, and vlock will hopefully work now. I think the reason the vlock package wasn't being automatically removed is that the vlock package has an epoch (of 0), so rather than use the rename macro, I've explicitly obsoleted vlock with the epoch. I believe both issues are now fixed in kbd-1.15.5-2.mga4. Please reopen if not. Thanks for the report! Status:
NEW =>
RESOLVED Sorry, but IMHO it is not working. When I start vlock it responds saying "The pts/1 is now locked by <username>" "Password: " Which seems very strange, to ask for a password when locking. Anyway it accepts teh password, but does not lock anything at all (I would expect to need the password only if I wanted to *unlock* the screen). Status:
RESOLVED =>
REOPENED Then it's working just fine. When you run vlock, it's locked. Yes it asks for the password. When you put in the password, it unlocks it. Status:
REOPENED =>
RESOLVED You obviously haven't tried it: nothing locks, nothing unlocks. It is supposed to make the screen inaccessible but it does nothing of the kind. Status:
RESOLVED =>
REOPENED Granted it was in Fedora 19, where this came from, but I did try it. As you indicated, when you run it, you get a password prompt (i.e., your shell is now inaccessible, therefore, it's locked), which is the same thing I saw there. This may be different from how it behaved before, but it doesn't mean it's broken. Status:
REOPENED =>
RESOLVED No, the shell is not inaccessible, nothing is locked at all anywhere. The vlock package locked the whole screen and at least did stg. This 'vlock' really does nothing at all. Obviously it is no use reopening, but I say it is not fixed. You're not making any sense. If you have to type in a password before you can get back to the shell, then yes it is inaccessible. No it doesn't clear the screen like it used to, which is unfortunate, and it would be nice if they would change that, but certainly this is now an upstream issue and not a packaging problem. The upstream author of kbd is this guy if you'd like to complain: http://sourceforge.net/users/legion-alt |