[Dextrose] [PATCH] Fix for bugs sl#2713 and au#885.

Anish Mangal anish at activitycentral.org
Wed Sep 14 06:30:25 EDT 2011

Hash: SHA1

On 09/13/2011 01:29 AM, Aleksey Lim wrote:
> On Mon, Sep 12, 2011 at 12:35:17AM +0530, Ajay Garg wrote:
>> Running the "dextrose-updater" cron.daily job, "touches" a "/var/lib/dextrose-updater" file. This file is then used in the subsequent run, to determine if it
>> is ok to re-run the job. Effectively, the "last-touched-timestamp" value of "/var/lib/dextrose-updater" is made use of in the "dextrose-updater" job script.
>> Used similar logic - used the "last-touched-time" as the time when the yum-updater was last run.
>> Thanks to Anish, for some wonderful review feedback.
> There are a couple of issues in the patch, but my concern is about
> not having all hardcoded stuf (not only for dextrose but, eg, for OLPC's
> XS) in shell code and relying only on command line API (the reason is
> that this command might be called w/o shell's UI at all and might have
> quite different release schedule in comapring w/ shell).
> In other words, it will be useful to:
> * rehash such code in Dextrose patch (for updater and school server backups)
> * rehash XS related code
> * create a Feature/ page on SL wiki for such refactoring/adding-new-code
> * in Feature's code, use sugar-client[1] command line API to all
>   interactions with [school] server (and hide such UI if sugar-client
>   command doesn't exist)
> [1] http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-client

Ajay, Perhaps we could simply use the 'yum history' command here. It would:
* Make the patch not depend on dextrose-updater
* Not do too many things in shell (except invoke yum history)
* yum is a critical and mature fedora component. It won't be too
volatile in terms of compatibility IMHO

Aleksey, I didn't fully understand your comment. In part, how is this
related to XS, particularly, the server side (maybe you're implying
sugar-client side here, but I'm not sure if that is ready to be included
in dx3 yet?).

The bug is a simple one: Find out when the yum updater last ran and
updated successfully. It most probably has value integrating it(finding
such info) into SSK client/server implementation following the approach
you mentioned. However, I would also like this to be working for current

- -- 
Anish Mangal
Dextrose Project Manager
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


More information about the Dextrose mailing list