[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:

 

prpr

Well-Known Member
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.
 
OP
af123

af123

Administrator
Staff member
Could you please post the output of 'opkg list tunefix'?
xlatest was introduced recently but I've just checked and the code looks ok.
 

prpr

Well-Known Member
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
 
OP
af123

af123

Administrator
Staff member
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..
 
OP
af123

af123

Administrator
Staff member
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.
 

peterworks

Ye Olde Bowler
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 ?
 
OP
af123

af123

Administrator
Staff member
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:

prpr

Well-Known Member
(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/
 

peterworks

Ye Olde Bowler
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:

peterworks

Ye Olde Bowler
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...
 

prpr

Well-Known Member
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
                       }
 
Top