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

Black Hole

May contain traces of nut
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.
All four of my active machines (HDR1,3,4;HD3) have stopped auto-updating, which I assume is the same thing and can be fixed by running a one-off manual update.

Before I do, is there anything you want me to check? I have compiled a list of the frozen state of the out-of-date packages (not all packages are installed on all machines, and I was surprised to find disable-ota not present on two of them!). Note there are a couple of anomalies, where one machine has a different package version than others (presumably due to when and in what order updates occurred):

arbookmarks 1.0.1
detectads 0.2.3-3
disable-dso 0.2
disable-ota 1.0.3
flatten 1.0.6
flatview 1.0.4-1
ir 1.12
rs 1.4.7
rsvsync 1.1.9
sweeper 2.1.4-2 (HDR4 2.1.3-1)
tmenu 1.12
tunefix 1.4.5
webif-channelicons 1.1.24
webif 1.3.4-10 (HD3 1.3.4-14)

Strangely, HDR1 reports stripts 1.2.5-4 installed, with 1.2.5-3 available (the other machines report 1.2.5-3 installed)!
 

Black Hole

May contain traces of nut
I tried this:
Code:
HDRFOX1# opkg --force-downgrade install stripts                                        
Package stripts (1.2.5-4) installed in root is up to date.
I can't uninstall it then reinstall, because it has so many dependencies.
 

Black Hole

May contain traces of nut
Code:
HDRFOX1# opkg --force-reinstall install stripts                                       
Removing package stripts from root...                                                 
Installing stripts (1.2.5-4) to root...                                               
Collected errors:                                                                     
 * opkg_download_pkg: Package stripts is not available from any configured src.       
 * opkg_install_pkg: Failed to download stripts. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package stripts.
stripts is now no longer listed as installed, but when I go to the available tab and try to install it I get similar to the above - it's looking for 1.2.5-4 instead of 1.2.5-3.

Help!

Code:
HDRFOX1# opkg --force-downgrade install stripts                                         
Installing stripts (1.2.5-4) to root...                                                 
Collected errors:                                                                       
 * opkg_download_pkg: Package stripts is not available from any configured src.         
 * opkg_install_pkg: Failed to download stripts. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package stripts.
 

prpr

Well-Known Member
Hmm, no that doesn't work either. I consider this a bug in opkg really. It seems it can be a bit dense sometimes.
I would hack at the version number in /mod/var/opkg/status to change 1.2.5-4 to 1.2.5-3 and then force reinstall.
That's how I've just tested it (make sure you do a backup first in case it all goes even more pear-shaped!).
 

Black Hole

May contain traces of nut
Bingo, thanks (I guess I could have taken out the whole stripts section as well). No, didn't bother with a backup, and once the status file was changed I just went into package management and installed it from there.
 
OP
af123

af123

Administrator
Staff member
Another alternative is:

Code:
humax# opkg list-installed stripts
stripts - 1.2.5-4
humax# opkg remove stripts --force-depends
Removing package stripts from root...
humax# opkg install stripts
Installing stripts (1.2.5-3) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/stripts_1.2.5-3_mipsel.opk.
Configuring stripts.
Yes, opkg (or at least the version we have) has a few limitations. I considered upgrading for the next firmware but the latest versions are much more complex with lots more dependencies; I decided it wasn't worth the effort.
 

Black Hole

May contain traces of nut
It seems to me there needs to be some kind of effort made to alert auto-update users that the system is broken until they do a manual update. I have no ideas how to do this though.
 

Black Hole

May contain traces of nut
Yes, opkg (or at least the version we have) has a few limitations. I considered upgrading for the next firmware but the latest versions are much more complex with lots more dependencies; I decided it wasn't worth the effort.
I don't think the limitations are a problem, as long a possible failings and what to do if they happen are documented somewhere.
 
OP
af123

af123

Administrator
Staff member
It seems to me there needs to be some kind of effort made to alert auto-update users that the system is broken until they do a manual update. I have no ideas how to do this though.
I /think/ that the affected people will largely be those who have manually installed packages or used the betas. Hopefully they are already aware or will spot it by themselves...
 
OP
af123

af123

Administrator
Staff member
Well, my guess definitely wasn't right. It seems people are still falling foul of this, three in the past couple of days have reported related problems.

So, I've spent some time trying to find a solution and Webif 1.4.0-13 hopefully contains a fix. Anyone with a system stuck in this state should be fixed within a minute of upgrading this package (its preinstall file adds an 'at' job to run the 'fixpkg' diagnostic a minute after installation).
I've been able to reproduce the problem and prove the fix on my test system so fingers crossed.
 

prpr

Well-Known Member
The latest version of auto-update now updates the mux. mapping list/database (which populates the Mux column on the WebIf's Diagnostics - Mux. Info page).
Previously it only did this if you did a manual "Check for updates" on the Package Management page, which almost never got done if auto-update was installed!
 
Last edited:

Black Hole

May contain traces of nut
The latest version of auto-update now updates the mux. database (which populates the list on the WebIf's Diagnostics - Mux. Info page).
Previously it only did this if you did a manual "Check for updates" on the Package Management page
No wonder I was confused!
 

MymsMan

Ad detector
The latest version of auto-update now updates the mux. database (which populates the list on the WebIf's Diagnostics - Mux. Info page).
Previously it only did this if you did a manual "Check for updates" on the Package Management page, which almost never got done if auto-update was installed!
Does this mean we will now have reasonably up to date signal strength and quality numbers?
By mux database do you mean /var/lib/humaxtv/freq.db since I don't see a mux.db in the database browser list?

Why is updating the Mux database tied into checking for package updates? There appears to be no logical connection.
Surely updating the database should be independently timer driven so that users who can't/ don't want automatic package updating also benefit


Silly Grandad as Molly would say
 
Last edited:
Top