Merge lp:~alextu/savilerow/savvy-correct-build-id into lp:savilerow/savvy

[Alex Tu]

  fixed the issue:
  The steps followed not work:
  1. Execute "Savvy build" & "Savvy load" to apply 1st time custom.key modification.
  2. Modify custom.key again.
  3. Execute "Savvy build" & "Savvy load" agian to apply 2nd time change.
  4. The 2nd time changes did not be applied and show on device.

  Root cause:
  savvy build asign the incorrect build-id to /system/custom/build_id

[Chris Wayne (cwayne)]

Shouldn't the fix be to rm build_id and recreate it? This looks like it'd change the format of it

[Alex Tu (alextu)]

> Shouldn't the fix be to rm build_id and recreate it? This looks like it'd
> change the format of it

The old code in savvy script will always failed because of $BUILD_ID doesn't been set:
    HMS=`echo $BUILD_ID | awk -F_ '{ print $2 }' | sed 's/-/:/g'`
    DATE=`echo $BUILD_ID | awk -F_ ' { print $1 }'`
    date -d "$DATE $HMS" +%s > build_id
    /* Then it will execute "date -d +%s > build_id", but this is a failed command.*/

So the build_id file did not be created, then it also did not be included in custom.tar.xz.

And then refer upstart script "custom-dconf-update.conf":
    # /custom/build_id does not exist.
    BUILD_TIME=`cat /custom/build_id || true`

    # /custom/etc/dconf/db/custom does not exist in 1st time update.
    # After 1st time update, custom file will be created then BUILD_TIME will always less than DCONFDB_MTIME
    DCONFDB_MTIME=`stat -c %X /custom/etc/dconf/db/custom || true`

    if [ ${BUILD_TIME} -gt ${DCONFDB_MTIME} ]; then
        cp -a /custom/etc/dconf_source/* /custom/etc/dconf
        export DCONF_PROFILE=/custom/etc/dconf_profile
        export DCONF_DIR=/custom/etc/dconf
        echo "updating custom dconf"
        dconf update
    else
        echo "skipping dconf update"
    fi

So, dconf only could be update in 1st time.
In savvy script, I don't know why we need to parse $BUILD_ID and it doesn't been set.
So I just try to split the case which $BUILD_ID has been set or not.

BTW, I think the way in upstart script "custom-dconf-update.conf" also hide an issue:
Because of build_id is created by host, and /custom/etc/dconf/db/custom is created by device.
If one of them have incorrect time setting, is this comparing still reliable?

Anyway, this solution I tried on Nexus 4, and it could always work for multi-times custom.tar.xz updating by "savvy build/savvy load".

[Chris Wayne (cwayne)]

LGTM, thanks for testing it!

review: Approve

=== modified file 'usr/bin/savvy'
--- usr/bin/savvy	2014-04-02 14:31:57 +0000
+++ usr/bin/savvy	2014-07-29 09:08:41 +0000
@@ -146,9 +146,14 @@
 	done
 	mkdir build
 	# save the build ID as epoch seconds inside the tarball to facilitate updates                                                      
-	HMS=`echo $BUILD_ID | awk -F_ '{ print $2 }' | sed 's/-/:/g'`                         
-	DATE=`echo $BUILD_ID | awk -F_ ' { print $1 }'`                                       
-	date -d "$DATE $HMS" +%s > build_id
+    if [ ! -z $BUILD_ID  ]
+    then 
+        HMS=`echo $BUILD_ID | awk -F_ '{ print $2 }' | sed 's/-/:/g'`                         
+        DATE=`echo $BUILD_ID | awk -F_ ' { print $1 }'`                                      
+        date -d "$DATE $HMS" +%s > build_id
+    else
+        date +%s > build_id
+    fi
 	cp build_id src/system/custom/
 	tar Jcvf build/custom.tar.xz --owner=root --group=root -C src/ system/
 	mv build_id build