Bug 14510 - drakclock falsely reports failure to install chrony service
Summary: drakclock falsely reports failure to install chrony service
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-12 17:57 CET by Martin Whitaker
Modified: 2015-04-19 00:29 CEST (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Martin Whitaker 2014-11-12 17:57:07 CET
Description of problem:

When using drakclock to enable NTP, after installing the chrony package, it displays a popup window saying that the chrony service could not be installed. Checking the running services shows this to be untrue - the chrony service is running (and apparently working).

Version-Release number of selected component (if applicable):

Mageia-5 beta 1

How reproducible:

Seen on two different machines when installing M5b1.

Steps to Reproduce:
1. Start Mageia Control Centre
2. Select "Manage date and time"
3. Select "Enable Network Time Protocol"


Reproducible: 

Steps to Reproduce:
Comment 1 David Walser 2014-11-15 00:49:43 CET
Yes there are some issues with drakclock still.  See the comments also in bug 9785, bug 11092, and bug 11502.

CC: (none) => luigiwalser, mageia

Comment 2 Martin Whitaker 2014-11-15 01:13:10 CET
This one seems to be new though - I didn't see it in Mageia-4 (including numerous beta/RC test installs). Obviously it's not a showstopper, but it would nice to get it fixed. I'll try to find some time to track down what's changed.
Comment 3 Martin Whitaker 2014-11-15 16:27:15 CET
I've traced this back to /usr/lib/gurpmi2 which is returning an exit status of 1. This is because it now uses the "standalone" package, which overloads the "exit" subroutine. The standalone::exit subroutine always causes an exit status of 1 to be returned, regardless of the value passed to it. I can fix this by changing the standalone::exit subroutine from

sub exit {
    explanations('### Program is exiting ###');
    CORE::exit(@_);   
}

to

sub exit {
    explanations('### Program is exiting ###');
    c::_exit(@_);   
}

but I have no explanation for why the existing code doesn't work.
Comment 4 Martin Whitaker 2015-04-19 00:29:21 CEST
Whatever was causing this seems to have been fixed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.