updater issueshttps://gitlab.nic.cz/turris/updater/updater/-/issues2019-05-06T17:47:32+02:00https://gitlab.nic.cz/turris/updater/updater/-/issues/244updater.sh: ensure that updater waits for lock and runs2019-05-06T17:47:32+02:00Karel Kociupdater.sh: ensure that updater waits for lock and runsEnsure that if already one instance of updater is running that we run another instance after it exits.
We need this for foris because that should ensure us that if it request updater's run that we really run it with latest updated confi...Ensure that if already one instance of updater is running that we run another instance after it exits.
We need this for foris because that should ensure us that if it request updater's run that we really run it with latest updated configuration.
We might be able to somehow note that we want another updater's run and when updater.sh is exiting we should just check if we have that note and if so we should run updater in background again.https://gitlab.nic.cz/turris/updater/updater/-/issues/240Split package managing to its own separate library2019-07-08T11:02:55+02:00Karel KociSplit package managing to its own separate libraryOperations like single package installation, removal and journal feature should be in its own library. Then having program like opkg-trans (maybe rename it) should help us with low level packages manipulations. At the moment becase opkg-...Operations like single package installation, removal and journal feature should be in its own library. Then having program like opkg-trans (maybe rename it) should help us with low level packages manipulations. At the moment becase opkg-trans depends on heavy libupdater when libupdater is broken because of one of its dependencies (libcurl is prime example) it won't start and won't allow you to fix it. Fixing this without opkg would be nightmare. If we have posix only library and executable that is for this low level packages manipulation it would be much much more easier. This way we could also add at least one more layer of apis to updater.https://gitlab.nic.cz/turris/updater/updater/-/issues/239Set http user agent field2019-05-06T17:47:38+02:00Karel KociSet http user agent fieldWe should add user agent info to updater's http connections. Using libcurl it's just a single command.
https://curl.haxx.se/libcurl/c/CURLOPT_USERAGENT.html
The idea is to have something like `Turris Updater/VERSION` where version will ...We should add user agent info to updater's http connections. Using libcurl it's just a single command.
https://curl.haxx.se/libcurl/c/CURLOPT_USERAGENT.html
The idea is to have something like `Turris Updater/VERSION` where version will be appended from macro (there is a macro defined that contains string with updater's version).Boleslav BrezovskyBoleslav Brezovskyhttps://gitlab.nic.cz/turris/updater/updater/-/issues/237Implement some cleanup process2019-05-06T17:47:31+02:00Karel KociImplement some cleanup processCurrently in lua we have some sort of exceptions implementation but we have nothing hooked up to it do do real cleanup in most of the cases. And in C we in most cases just call die, specially in cases when we receive error from Lua. This...Currently in lua we have some sort of exceptions implementation but we have nothing hooked up to it do do real cleanup in most of the cases. And in C we in most cases just call die, specially in cases when we receive error from Lua. This is just bad, with any error small or big we do no cleanups and if we expect some sort of cleanup (like I don't know running postupdate hooks or closing status files and more) it is not executed and in most unexpected ways skipped.
So solution should be some global cleanup stack in utilities. Idea probably should be something where you can register (and unregister) functions that would be called when updater is going to exit. This should simplify for example main functions a lot (because right now it's just a pile of error handling shit) and should ensure that even if we trigger exit from some function that is no way relevant but should result to propper exit that we do propper cleanup and then exit.https://gitlab.nic.cz/turris/updater/updater/-/issues/236Report updater state on named socket2023-08-16T14:59:38+02:00Karel KociReport updater state on named socketWe want to be able to access state of running updater from gui (specially from Foris) and for that we need some common way to see what is updater doing no matter if we are running it directly or not.
We should dump to it informations ab...We want to be able to access state of running updater from gui (specially from Foris) and for that we need some common way to see what is updater doing no matter if we are running it directly or not.
We should dump to it informations about what packages are we downloading, installing, removing and so on at the moment.https://gitlab.nic.cz/turris/updater/updater/-/issues/230OPKG replacement2019-07-08T11:02:56+02:00Karel KociOPKG replacementWe want to do complete opkg replacement. Current state some what works but is not systematical as we are using one tool for updates and another for explicit packages installation. But simply removing opkg is also not possible as user are...We want to do complete opkg replacement. Current state some what works but is not systematical as we are using one tool for updates and another for explicit packages installation. But simply removing opkg is also not possible as user are used on interactive package installation. The idea is to add new application that would replace opkg in most of the features and wrapper script to simulate opkg.
To support opkg the new command has to support following features:
* [ ] Package installation
* [ ] Package removal
* [ ] Package upgrade
* [ ] Package reconfiguration
* [ ] Listing available and installed packages
* [ ] Listing upgradable packages
* [ ] Listing files belonging to some package
* [ ] Searching packages content
* [ ] Displaying packages info
* [ ] Querying for package status
* [ ] Possibility to download some package
* [ ] Querying for package dependencies
To do that we need to resolve following issues in updater it self:
* [ ] Possibility of considering installed packages
* [ ] Resolve package removal (should we add Uninstall command and in what priority)
* [ ] Lua configuration management (automatically managed file with lua syntax)
* [ ] Updater should use index and userlists cache to make execution faster and less demanding on network connection
Features present in opkg but probably not required by us:
* Multiple architectures support
* Destination names
* `--autoremove` because we are doing that automatically
* Flags settinghttps://gitlab.nic.cz/turris/updater/updater/-/issues/229What package is installed as provided from possibilities is decided alphabeti...2019-07-08T12:48:59+02:00Karel KociWhat package is installed as provided from possibilities is decided alphabeticallyIf we have more than one possible provided candidate for package then we decide
which one we use simply alphabetically by their name. This makes decision stable
but gives us no free hands and only way how to change that is to add `Instal...If we have more than one possible provided candidate for package then we decide
which one we use simply alphabetically by their name. This makes decision stable
but gives us no free hands and only way how to change that is to add `Install`
command but that has side effect that it won't be removed as soon as other
provided candidate is selected. Solution would be to add possibility for packages
to specify their own preference (`Package("pkg", {prefer={"apkg", "bpkg"}})`.https://gitlab.nic.cz/turris/updater/updater/-/issues/227Add support for relative uri2019-05-06T17:46:46+02:00Karel KociAdd support for relative uriIf we are in script and using new uri then it makes sense that we shouldn't care where this script is really running and we should be able to use uris relative to ours.
Also it would be nice to have current uri in some variable in scrip...If we are in script and using new uri then it makes sense that we shouldn't care where this script is really running and we should be able to use uris relative to ours.
Also it would be nice to have current uri in some variable in script it self or maybe even call trace.Turris OS 4.0https://gitlab.nic.cz/turris/updater/updater/-/issues/219Publish info about updater running instance to ubus2019-05-06T17:47:32+02:00Karel KociPublish info about updater running instance to ubusPosting informations such as what package are we downloading and what package are
we installing should be handy for Foris to be able to show some informative output
to user if updater is used trough it.Posting informations such as what package are we downloading and what package are
we installing should be handy for Foris to be able to show some informative output
to user if updater is used trough it.https://gitlab.nic.cz/turris/updater/updater/-/issues/213Check extra option 'version' that is has correct format2020-11-24T13:57:24+01:00Karel KociCheck extra option 'version' that is has correct formatCurrently extra option `version` is just checked that it's a string but we should
also check format of that string.Currently extra option `version` is just checked that it's a string but we should
also check format of that string.Turris OS 5.2.0https://gitlab.nic.cz/turris/updater/updater/-/issues/209Blink with routers leds while updater is running2019-07-08T13:06:14+02:00Karel KociBlink with routers leds while updater is runningUsers complains that updater doesn't explicitly informs you that it's running and
while it does some bigger update it's common that some packages restarts network
and result is that from users point of view router broke. Idea is to light...Users complains that updater doesn't explicitly informs you that it's running and
while it does some bigger update it's common that some packages restarts network
and result is that from users point of view router broke. Idea is to light up leds
in some pattern signaling phases in updater to inform user that router is updating
and that connection lost is just temporally and that router is not broken.https://gitlab.nic.cz/turris/updater/updater/-/issues/207Add option to notify user about new *-opkg files2019-06-06T15:51:41+02:00Karel KociAdd option to notify user about new *-opkg filesThese files are new versions of configurations. One of users requested to be
notified about those. And it makes sense to do so.These files are new versions of configurations. One of users requested to be
notified about those. And it makes sense to do so.https://gitlab.nic.cz/turris/updater/updater/-/issues/206Unit tests for localrepo2019-06-06T15:51:42+02:00Karel KociUnit tests for localrepoLocal repo is pretty complicated and we should test it too. So we should add some
unit tests for it.Local repo is pretty complicated and we should test it too. So we should add some
unit tests for it.https://gitlab.nic.cz/turris/updater/updater/-/issues/205Print warning on package version downgrade2020-06-25T15:05:42+02:00Karel KociPrint warning on package version downgradePrinting warning when we are downgrading is some what sensible request.Printing warning when we are downgrading is some what sensible request.Turris OS 5.1https://gitlab.nic.cz/turris/updater/updater/-/issues/204Default path of sign keys (`signkey`) so we don't have to fill then in every ...2019-06-06T15:51:42+02:00Karel KociDefault path of sign keys (`signkey`) so we don't have to fill then in every timehttps://gitlab.nic.cz/turris/updater/updater/-/issues/203Automatically approve fixup releases2019-06-06T15:51:42+02:00Karel KociAutomatically approve fixup releasesFixup releases are mostly harmless and some users wishes to have them installed
automatically but requests minor and major releases to be approved.Fixup releases are mostly harmless and some users wishes to have them installed
automatically but requests minor and major releases to be approved.https://gitlab.nic.cz/turris/updater/updater/-/issues/202Before installing we should check if we have enough space on target drive2021-03-01T15:01:54+01:00Karel KociBefore installing we should check if we have enough space on target driveWe are currently not checking if we have enought space. But we shoudl do that.We are currently not checking if we have enought space. But we shoudl do that.https://gitlab.nic.cz/turris/updater/updater/-/issues/199Add support for hooks as described in Language design2019-06-06T17:34:06+02:00Karel KociAdd support for hooks as described in Language designhttps://gitlab.nic.cz/turris/updater/updater/-/issues/198Store and print requests origin2022-06-06T14:34:32+02:00Karel KociStore and print requests originWe should store request origin (script and line) so we could report errors in configurations with reference. Currently it's impossible to locate from where request came and debugging problems is insanely hard because of that.We should store request origin (script and line) so we could report errors in configurations with reference. Currently it's impossible to locate from where request came and debugging problems is insanely hard because of that.https://gitlab.nic.cz/turris/updater/updater/-/issues/197Approvals notifications should contain list of changes to be approved2020-11-12T03:27:29+01:00Karel KociApprovals notifications should contain list of changes to be approvedNotifications about waiting approvals says nothing about changes to be approved. It's like a small suprise that have to be unpacked in Foris.Notifications about waiting approvals says nothing about changes to be approved. It's like a small suprise that have to be unpacked in Foris.Turris OS 3.8