• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

[auto-update] Automatically keep packages up-to-date.

af123

Administrator
Staff member
I've just uploaded a rewrite of the auto-update package which logs any updates it has done so that they are shown in the web interface, along with details of changes (when available) and a link to any relevant forum topic. See related topic http://hummy.tv/forum/threads/webif-version-1-0-8-released.4553/

Example:

autoupdate.png
 
auto-update currently seems to be bust. I noticed things weren't working as normal so tried it manually:
Code:
humax ~ # opkg list-upgradable
tunefix - 1.4.5 - 1.5.0
tmenu - 1.12 - 1.21-2
ir - 1.12 - 1.12-1
tunefix-update - 1.0.16 - 1.0.17
webif - 1.3.4-12 - 1.3.4-14
rsvsync - 1.1.9 - 1.1.10
humax ~ # /mod/sbin/auto-update
/mod/webif/lib/pkg.class:26: Error: can't read "xlatest": no such variable
in procedure 'pkg' called at file "/mod/sbin/auto-update", line 11
in procedure '<reference.<pkg____>.00000000000000000000>' called at file "/mod/webif/lib/pkg.class", line 114
in procedure 'pkg _load' called at file "/mod/lib/jim/oo.tcl", line 52
at file "/mod/lib/jim/oo.tcl", line 73
at file "/mod/webif/lib/pkg.class", line 26
I guess a WebIf update has broken it, looking at this...

Updating WebIf manually to 1.3.4-14 still causes the same error with auto-update subsequently.
 
Could you please post the output of 'opkg list tunefix'?
xlatest was introduced recently but I've just checked and the code looks ok.
 
Here's the fault:
Code:
humax ~ # opkg list|grep tmenu
tmenu - 1.12
tmenu - 1.21-2 - Telnet menu
It also afflicts any other 'locally' installed packages which don't have 'description' fields as output by opkg.

And the solution:
Code:
humax ~ # diff -u /mod/webif/lib/pkg.class~ /mod/webif/lib/pkg.class
--- /mod/webif/lib/pkg.class~
+++ /mod/webif/lib/pkg.class
@@ -22,6 +22,8 @@
                if {[string match { *} $line]} {
                        append descr $line
                } else {
+                       set xlatest $latest
+                       set descr ""
                        regexp {^[^ ]+ - ([^ ]+) - (.*)$} $line x xlatest descr
                        if {[pkg vercompare $xlatest $latest] > 0} {
                                set latest $xlatest
Moral: always initialise your variables even if something else should set them (in case it doesn't, as here)

For completeness:
Code:
humax ~ # opkg list|grep ^ir
ir - 1.12-1 - Infra-red control command injection framework.
ir - 1.12
humax ~ # opkg list|grep ^tunefix
tunefix - 1.5.0 - Automatic channel organisation and maintenance.
tunefix - 1.4.5
tunefix-update - 1.0.17 - Automatic Freeview channel updates.
humax ~ # opkg list|grep ^rsvsync
rsvsync - 1.1.10 - Boot-time reservation sync service.
rsvsync - 1.1.9
 
Thanks, I'll fix it.
And the solution:
I was probably slightly mixing up regexp and lassign behaviour. lassign will set any extra variables to "".
The real solution is slightly different..
 
Code:
--- pkg.class~
+++ pkg.class
@@ -22,7 +22,9 @@
                if {[string match { *} $line]} {
                        append descr $line
                } else {
-                       regexp {^[^ ]+ - ([^ ]+) - (.*)$} $line x xlatest descr
+                       set xlatest $latest
+                       regexp {^[^ ]+ - ([^ ]+)(?: - (.*))?$} $line x \
+                           xlatest descr
                        if {[pkg vercompare $xlatest $latest] > 0} {
                                set latest $xlatest
                        }

(It's a class instance so descr and latest are always guaranteed to be initialised and I don't want to arbitrarily overwrite the class variables). Making the third part of the regexp optional is the best solution, along with initialising xlatest just in case opkg produces something unexpected.
This one will have to wait for webif 1.4 as well.
 
Is this a 'chicken and egg' situation ? If people rely on autoupdate how will they know that it is not working and that they will need to manually install the fix ?
 
Is this a 'chicken and egg' situation ? If people rely on autoupdate how will they know that it is not working and that they will need to manually install the fix ?
It will depend on the packages that they have installed in the past and may only affect those who have installed things by hand previously, and only then if it's one of those manually installed packages that's getting an update.
All of my boxes have auto-updated successfully.
Yours too by the look of it - it certainly got the tmenu update that prpr's box was failing on.
 
Last edited:
(It's a class instance so descr and latest are always guaranteed to be initialised and I don't want to arbitrarily overwrite the class variables).
OK, I should have checked further back for what descr was.
Making the third part of the regexp optional is the best solution, along with initialising xlatest just in case opkg produces something unexpected.
Agreed.
may only effect those
Cough!
s/effect/affect/
 
Yours too by the look of it - it certainly got the tmenu update that prpr's box was failing on.
tmenu ver 1.21-2 to 1.22 did not auto-update overnight...
Strange thing is that I used 'Update package list from the internet'. tmenu was identified but when I closed the download window the package installed without any intervention from me.

Edit: After looking at my other HDR I see that the tunefix-update installed okay but did not show in the activity log.
 
Last edited:
On my other HDR, which has auto-update installed, I clicked on upgrades and received the following:
Capture16-01-2017-10.18.03.jpg
which I have now upgraded...
 
Thanks but I am uncertain how a patch is applied - a quick pointer would be much appreciated.
Edit the file /mod/webif/lib/pkg.class by whatever means you are comfortable with (WebIf editor or command line editor e.g. nano).
Go to around the line mentioned - 22 - and remove the matching line in the patch which starts with a '-'.
Add the matching lines in the patch which start with a '+' (you do NOT put the + in the file - that is just telling you what to do). Save.
That block should end up looking like this:
Code:
               } else {
                       set xlatest $latest
                       regexp {^[^ ]+ - ([^ ]+)(?: - (.*))?$} $line x \
                           xlatest descr
                       if {[pkg vercompare $xlatest $latest] > 0} {
                               set latest $xlatest
                       }
 
Back
Top