updater issueshttps://gitlab.nic.cz/turris/updater/updater/-/issues2020-11-12T02:24:09+01:00https://gitlab.nic.cz/turris/updater/updater/-/issues/60Support for the internal URI scheme2020-11-12T02:24:09+01:00Ghost UserSupport for the internal URI schemeThe support for the `internal` URI scheme, as described in the language design document, is missing from the URI manager (it has been forgotten). Implement embedding of the resources and extraction into a lua variable and wrap it into a ...The support for the `internal` URI scheme, as described in the language design document, is missing from the URI manager (it has been forgotten). Implement embedding of the resources and extraction into a lua variable and wrap it into a new scheme.https://gitlab.nic.cz/turris/updater/updater/-/issues/59Validation of data sources2020-11-12T02:24:10+01:00Ghost UserValidation of data sourcesThe uri manager needs to perform the validation, described in the language design document. That means obtaining the certificates and signatures and applying them when everything is done. Consider if we allow the certificates to be downl...The uri manager needs to perform the validation, described in the language design document. That means obtaining the certificates and signatures and applying them when everything is done. Consider if we allow the certificates to be downloaded (because then we have a problem with events for the download of the certificate needs to be waited for before the real download starts).
Consider doing it in more generic way, so it can be shared between all the uri schemes.https://gitlab.nic.cz/turris/updater/updater/-/issues/58Get table of all available packages2020-11-12T02:24:11+01:00Ghost UserGet table of all available packagesAggregate info from all the repositories into one table, producing list of candidates for each package. Merge the package requests with these candidates somehow and filter only the packages that fulfill the criteria.
- [x] Depends on #...Aggregate info from all the repositories into one table, producing list of candidates for each package. Merge the package requests with these candidates somehow and filter only the packages that fulfill the criteria.
- [x] Depends on #57 (Download repositories)https://gitlab.nic.cz/turris/updater/updater/-/issues/57Download the mentioned repositories2020-11-12T02:24:13+01:00Ghost UserDownload the mentioned repositoriesGo through the repositories mentioned in the configuration files and download them. Parse each of them to produce a package list.
- [x] Depends on #39 (URI manager)Go through the repositories mentioned in the configuration files and download them. Parse each of them to produce a package list.
- [x] Depends on #39 (URI manager)https://gitlab.nic.cz/turris/updater/updater/-/issues/56Make sure data survives reboot2020-11-12T02:24:13+01:00Ghost UserMake sure data survives rebootLook through the backend code and make sure we don't get any zero-length data somewhere (including status files) or recover from that situation.
Look at the rename guarantees, etc:
https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_t...Look through the backend code and make sure we don't get any zero-length data somewhere (including status files) or recover from that situation.
Look at the rename guarantees, etc:
https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_overwrite-by-rename.3Fhttps://gitlab.nic.cz/turris/updater/updater/-/issues/55Handle flags in /usr/lib/opkg/status2020-11-12T02:24:11+01:00Ghost UserHandle flags in /usr/lib/opkg/statusThere are status flags and they may be something different than the usual `install user installed`. Try to find out more about what they mean.
Notice that they can obviously be used to store info about modified orphaned config file with...There are status flags and they may be something different than the usual `install user installed`. Try to find out more about what they mean.
Notice that they can obviously be used to store info about modified orphaned config file with `not-installed`.
Handle the flags.https://gitlab.nic.cz/turris/updater/updater/-/issues/52Make it possible to disable updater2020-11-12T02:24:13+01:00Ghost UserMake it possible to disable updaterIt should be possible to disable Updater in Omnia. A checkbox for this should be then shown in Foris.
Blocks turris/foris#8It should be possible to disable Updater in Omnia. A checkbox for this should be then shown in Foris.
Blocks turris/foris#8https://gitlab.nic.cz/turris/updater/updater/-/issues/50Include command support2019-05-06T17:47:04+02:00Ghost UserInclude command supportSupport the `Include` command.
- [x] Depends on #39 (URI manager)Support the `Include` command.
- [x] Depends on #39 (URI manager)https://gitlab.nic.cz/turris/updater/updater/-/issues/49Updater interface2019-05-06T17:47:04+02:00Ghost UserUpdater interfaceInterface wrapper to emulate the old updater.
- [ ] Depends on #46 (The updater binary)Interface wrapper to emulate the old updater.
- [ ] Depends on #46 (The updater binary)https://gitlab.nic.cz/turris/updater/updater/-/issues/48Opkg interface simulator2019-05-06T17:47:04+02:00Ghost UserOpkg interface simulatorSimulate the command line of opkg (replace it with a script or something).
- [ ] Depends on #47 (Commands to remove or install a package)Simulate the command line of opkg (replace it with a script or something).
- [ ] Depends on #47 (Commands to remove or install a package)https://gitlab.nic.cz/turris/updater/updater/-/issues/46The updater binary2019-05-06T17:47:04+02:00Ghost UserThe updater binaryWrap the above stuff into a binary that can be called.Wrap the above stuff into a binary that can be called.https://gitlab.nic.cz/turris/updater/updater/-/issues/45Feed the installation backend with desired actions2020-11-12T02:24:13+01:00Ghost UserFeed the installation backend with desired actionsDownload the needed packages and feed it to the current transaction backend. Get the list of actions from #44.
- [x] Depends on #44.Download the needed packages and feed it to the current transaction backend. Get the list of actions from #44.
- [x] Depends on #44.https://gitlab.nic.cz/turris/updater/updater/-/issues/44Compare the desired and installed list of packages2020-11-12T02:24:11+01:00Ghost UserCompare the desired and installed list of packagesCompare the lists and produce a list of packages to install and remove.
- [x] Depends on #43.Compare the lists and produce a list of packages to install and remove.
- [x] Depends on #43.https://gitlab.nic.cz/turris/updater/updater/-/issues/43DFS dependency traversal2019-05-06T17:47:02+02:00Ghost UserDFS dependency traversalGo through the dependencies of installation requests, get list of all the relevant packages.
- [x] Depends on #41 (Repository object)
- [x] Depends on #42 (Installation request)Go through the dependencies of installation requests, get list of all the relevant packages.
- [x] Depends on #41 (Repository object)
- [x] Depends on #42 (Installation request)https://gitlab.nic.cz/turris/updater/updater/-/issues/42Installation request2020-11-12T02:24:10+01:00Ghost UserInstallation requestCommand requesting installation of a package, producing the package match object from #40 and storing it somewhere in a global table.
- [x] Depends on #37 (Morphers)
- [x] Depends on #40 (Package object)Command requesting installation of a package, producing the package match object from #40 and storing it somewhere in a global table.
- [x] Depends on #37 (Morphers)
- [x] Depends on #40 (Package object)https://gitlab.nic.cz/turris/updater/updater/-/issues/41Repository command and object2020-11-12T02:24:13+01:00Ghost UserRepository command and objectImplement the repository command, downloading of the repositories and parsing it. Provide some list of parsed packages.
- [x] Depends on #41 (Morphers)
- [x] Depends on #40 (Package object)Implement the repository command, downloading of the repositories and parsing it. Provide some list of parsed packages.
- [x] Depends on #41 (Morphers)
- [x] Depends on #40 (Package object)https://gitlab.nic.cz/turris/updater/updater/-/issues/40Package object2020-11-12T02:24:11+01:00Ghost UserPackage objectCreate an object representing packages.
Actually, there should be two different objects. One describing concrete package from a repository, with all the information available. The other is just a description how the package should look ...Create an object representing packages.
Actually, there should be two different objects. One describing concrete package from a repository, with all the information available. The other is just a description how the package should look like when it is ready. Be able to morph the second into the first or link them somehow (would meta tables help? Or write it in C with some meta-table magic?).
- [x] Depends on #37 (Morphers)https://gitlab.nic.cz/turris/updater/updater/-/issues/39URI manager2020-11-12T02:24:13+01:00Ghost UserURI managerAdd an event to get any supported URI. This would either load it from corresponding local source or call a download.
Consider if the caller is allowed to get the URI as per the context.
Note that, in case .sig is to be checked, it may ...Add an event to get any supported URI. This would either load it from corresponding local source or call a download.
Consider if the caller is allowed to get the URI as per the context.
Note that, in case .sig is to be checked, it may need to download/acquire another resource.
Consider if it would be easier to be accessible from lua only, or if we use some hybrid mode.
- [x] Depends on #36 (Sandboxes)
- [x] Depends on #38 (Download event)https://gitlab.nic.cz/turris/updater/updater/-/issues/38Download manager2019-05-06T17:47:00+02:00Ghost UserDownload managerExtend the events interface (both C and lua) to be able to download a http or https file. Use wget or curl for now. Do https certificate validation.
Limit the number of parallel downloads somehow.Extend the events interface (both C and lua) to be able to download a http or https file. Use wget or curl for now. Do https certificate validation.
Limit the number of parallel downloads somehow.https://gitlab.nic.cz/turris/updater/updater/-/issues/37Morphers2020-11-12T02:24:15+01:00Ghost UserMorphersProvide support for the „morpher“ functions (see docs/morpher.html). Be able to generate them into the environments of #36.
- [x] Depends on #36 (sandboxes).Provide support for the „morpher“ functions (see docs/morpher.html). Be able to generate them into the environments of #36.
- [x] Depends on #36 (sandboxes).https://gitlab.nic.cz/turris/updater/updater/-/issues/36Lua sandbox & contexts2020-11-12T02:24:13+01:00Ghost UserLua sandbox & contextsPrepare the contexts for running the configuration scripts. They should inherit some parameters from parent contexts, with the ability to override stuff. Also, prepare the environments to run the chunks inside.Prepare the contexts for running the configuration scripts. They should inherit some parameters from parent contexts, with the ability to override stuff. Also, prepare the environments to run the chunks inside.https://gitlab.nic.cz/turris/updater/updater/-/issues/34Integrate opkg update2020-11-12T02:24:13+01:00Ghost UserIntegrate opkg updateCurrently, there's a cron job that does opkg update. But it sometimes collides with the updater. Integrate it into updater itself (and get rid of that cron job), so it is run sequentially.Currently, there's a cron job that does opkg update. But it sometimes collides with the updater. Integrate it into updater itself (and get rid of that cron job), so it is run sequentially.https://gitlab.nic.cz/turris/updater/updater/-/issues/32Logging configuration2020-11-12T02:24:14+01:00Ghost UserLogging configurationMake it possible to configure how much is logged (all debug, just errors, etc) and where it goes (stderr, syslog, multiple locations). It seems nice if we could make the amount of logging configurable per destination.Make it possible to configure how much is logged (all debug, just errors, etc) and where it goes (stderr, syslog, multiple locations). It seems nice if we could make the amount of logging configurable per destination.https://gitlab.nic.cz/turris/updater/updater/-/issues/29Reinstall everything flag2019-05-06T17:46:58+02:00Ghost UserReinstall everything flagWe need to be able to reinstall all packages in case one given package is installed (in our case, musl).
- [x] #143 Support abi_change package optionWe need to be able to reinstall all packages in case one given package is installed (in our case, musl).
- [x] #143 Support abi_change package optionhttps://gitlab.nic.cz/turris/updater/updater/-/issues/27Harness for system-level tests2020-11-12T02:24:14+01:00Ghost UserHarness for system-level testsAdd some support for tests (like, running everything under some root directory with a `-P` flag, or such).
Write some basic tests to install a package, to remove it, etc. Also, run that thing in valgrind.
- [x] Depends on #25Add some support for tests (like, running everything under some root directory with a `-P` flag, or such).
Write some basic tests to install a package, to remove it, etc. Also, run that thing in valgrind.
- [x] Depends on #25https://gitlab.nic.cz/turris/updater/updater/-/issues/26Handle config files2020-11-12T02:24:10+01:00Ghost UserHandle config filesWe need to handle config files specially. This means checking their hashes (note that newer opkg seems to use sha1 instead of md5), and don't overwrite if they are changed. Also, don't delete them if they are not changed.
Think what hap...We need to handle config files specially. This means checking their hashes (note that newer opkg seems to use sha1 instead of md5), and don't overwrite if they are changed. Also, don't delete them if they are not changed.
Think what happens if we remove a package, leave a modified config file in place and a new package comes with the same config file. Should we overwrite it? If not, how do we know it has been modified and has been a config file, if no package currently claims it? We should probably be able to handle this at least during a single transaction.https://gitlab.nic.cz/turris/updater/updater/-/issues/25Integrate transaction.perfom into the main app2020-11-12T02:24:14+01:00Ghost UserIntegrate transaction.perfom into the main appSomehow collect what needs to be fed into the transaction, load the packages into memory and fire it. Check for the result and provide some output.
This would make opkg-trans actually do some stuff.Somehow collect what needs to be fed into the transaction, load the packages into memory and fire it. Check for the result and provide some output.
This would make opkg-trans actually do some stuff.https://gitlab.nic.cz/turris/updater/updater/-/issues/23Lint-style checks2019-05-06T17:46:57+02:00Ghost UserLint-style checksIntegrate some static check analyzers (into `make check`). Something for C definitely exists (and choosing the best one is part of the task), there's luacheck and luac for lua (the second being just compiler, but we do want to check for ...Integrate some static check analyzers (into `make check`). Something for C definitely exists (and choosing the best one is part of the task), there's luacheck and luac for lua (the second being just compiler, but we do want to check for syntax errors).https://gitlab.nic.cz/turris/updater/updater/-/issues/22Coverity scan for the updater2019-05-06T17:46:56+02:00Ghost UserCoverity scan for the updaterThere are some non-trivial parts of updater-ng written in C, therefore it might benefit from a coverity scan. Automate the submission through jenkins.There are some non-trivial parts of updater-ng written in C, therefore it might benefit from a coverity scan. Automate the submission through jenkins.https://gitlab.nic.cz/turris/updater/updater/-/issues/21Restart updater even in offline mode2019-05-06T17:46:56+02:00Michal HruseckyRestart updater even in offline modeMake it possible to restart updater even if it is run after boot in offline mode. Implementation in merge request !14 Make it possible to restart updater even if it is run after boot in offline mode. Implementation in merge request !14 Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/updater/updater/-/issues/20Logging support2020-11-12T02:24:16+01:00Ghost UserLogging supportProvide at least basic logging functions, eg:
- die
- error
- warn
- dbg
Provide lua interface as well.
It doesn't have to be configurable or output to multiple locations (yet). We just need a way to print stuff from the code.
-...Provide at least basic logging functions, eg:
- die
- error
- warn
- dbg
Provide lua interface as well.
It doesn't have to be configurable or output to multiple locations (yet). We just need a way to print stuff from the code.
- [x] Depends on #1https://gitlab.nic.cz/turris/updater/updater/-/issues/19Updater NG2019-05-06T17:46:55+02:00Ghost UserUpdater NGThe current hair ball of shell scripts is slowly but surely reaching its limits. Consider some newer approach that does real dependency tracking and such.
- [x] Subtask #14 (Transactional backend for the old updater)
- [x] Subtask #...The current hair ball of shell scripts is slowly but surely reaching its limits. Consider some newer approach that does real dependency tracking and such.
- [x] Subtask #14 (Transactional backend for the old updater)
- [x] Subtask #1 (Integrate lua interpreter)
- [x] Subtask #2 (Parse current package state)
- [x] Subtask #3 (Event loop)
- [x] Subtask #20 (Logging support)
- [x] Subtask #4 (Process manager)
- [x] Subtask #5 (Unpacking to temporary location)
- [x] Subtask #6 (Merging files to live system)
- [x] Subtask #7 (Running pre/post-install/remove scripts)
- [x] Subtask #8 (Saving package state)
- [x] Subtask #9 (Locking)
- [x] Subtask #10 (Journal manipulation)
- [x] Subtask #11 (Using journal through the installation)
- [x] Subtask #12 (Journal recovery)
- [x] Subtask #13 (Integrate the backend in the old updater)
- [x] Subtask #25 (Integrate `transaction.process` into opkg-trans)
- [x] Subtask #26 (Config file handling)
- [x] Subtask #27 (System level tests)
- [x] Subtask #32 (Logging configuration)
- [x] Subtask #35 (Field test)
- [ ] Subtask #15 (LibC replacement support)
- [ ] Subtask turris/openwrt#9 (Turris packages with musl)
- [x] Subtask #29 (Reinstall everything flag)
- [ ] Subtask #31 (Testing the migration)
- [ ] Subtask turris/openwrt#10 (static libraries for dependencies, maybe not needed
- [ ] Subtask #30 (static linking), maybe not needed
- [x] Depends on #148 (Replace curl command with libcurl)
- [x] Depends on #149 ( Integrate busybox to updater)
- [x] Subtask #16 (Replacement for the old updater)
- Language support:
- [x] Subtask #36 (Sandboxes)
- [x] Subtask #37 (Morphers)
- [x] Subtask #50 (Include command)
- [x] Subtask #76 (Allow missing)
- [x] Subtask #86 (Unknown parameters)
- [x] Subtask #91 (Complex deps)
- [x] Subtask #92 (Flags)
- [x] Subtask #93 (State variables)
- [x] Subtask #97 (Errors from sub-scripts)
- Data sources:
- [x] Subtask #38 (Download event)
- [x] Subtask #39 (URI manager)
- [x] Subtask #59 (Verification of resources)
- [x] Subtask #60 (internal: schema)
- [x] Subtask #103 (Restricted security level)
- Situation description:
- [x] Subtask #40 (Package object)
- [x] Subtask #41 (Repository object)
- [x] Subtask #42 (Installation request)
- Postprocess info from configs:
- [x] Subtask #57 (Download repositories)
- [x] Subtask #58 (Get table of available packages)
- Dependency tracking:
- [x] Subtask #43 (DFS through dependencies)
- [x] Subtask #44 (Compare list of desired and installed packages)
- [x] Subtask #45 (Feed the package list into the transaction backend)
- [x] Subtask #109 (The „provides“ header)
- UI
- [x] Subtask #46 (The updater binary)
- [ ] Subtask #47 (Command to remove or add a package)
- [x] Subtask #48 (Emulation of opkg)
- [x] Subtask #49 (Emulation of the old updater)
- [x] Subtask #67 (Send logs of transaction to user)
- [x] Subtask #69 (Better error reporting)
- [x] Subtask #77 (Nuci integration)
- [x] Subtask #80 (List collisions)
- [x] Subtask #83 (CRL error)
- [x] Subtask #84 (Missing repo error)
- [ ] Subtask #136 (Describe why critical requests failed in error message)
- Misc
- [x] Subtask #61 (Hide context)
- [x] Subtask #68 (Access to system libraries)
- [x] Subtask #62 (Replan)
- [x] Subtask #63 (Reinstall)
- [x] Subtask #96 (Later reinstall)
- [x] Subtask #64 (Reboot)
- [x] Subtask #65 (TODO/FIXME)
- [x] Subtask #66 (Deploy)
- [x] Subtask #72 (Don't fail on prerm)
- [x] Subtask #74 (Lock during the whole run)
- [x] Subtask #75 (Config overwriting)
- [x] Subtask #81 (Blocking write)
- [x] Subtask #87 (Auto-run resilience)
- [x] Subtask #88 (Generator of the configs)
- [x] Subtask #89 (Userlist definitions)
- [x] Subtask #95 (Lockup on poll)
- [x] Subtask #18 (Rules for dependency calculation)
- [x] Subtask #122 (SAT structure, stage 1)
- [x] Subtask #124 (Satisfiable requests)
- [x] Subtask #125 (Eliminate unneeded packages)
- [x] Subtask #127 (Order packages according to dependencies)
- [x] Subtask #128 (Produce list of tasks to execute)
- [x] Subtask #123 (SAT structure, stage 2)
- [x] Subtask #126 (Alternative elimination)
- [ ] Subtask #17 (Full support of the requirements)https://gitlab.nic.cz/turris/updater/updater/-/issues/16Replacement for the old updater2019-05-06T17:46:55+02:00Ghost UserReplacement for the old updaterBring the updater to a state where it can read the language, resolve dependencies, and install packages. In this phase we could replace the old updater, but we wouldn't have all the new fancy stuff, like complex dependencies.
- [x] Dep...Bring the updater to a state where it can read the language, resolve dependencies, and install packages. In this phase we could replace the old updater, but we wouldn't have all the new fancy stuff, like complex dependencies.
- [x] Depends on #14
- Language support:
- [x] Subtask #36 (Sandboxes)
- [x] Subtask #37 (Morphers)
- [x] Subtask #50 (Include command)
- [x] Subtask #97 (Errors from sub-scripts)
- [x] Subtask #76 (Allow missing)
- [x] Subtask #86 (Unkown parameters)
- [x] Subtask #91 (Complex deps)
- [x] Subtask #92 (Flags)
- [x] Subtask #93 (State variables)
- Data sources:
- [x] Subtask #38 (Download event)
- [x] Subtask #39 (URI manager)
- [x] Subtask #59 (Resource verification)
- [x] Subtask #60 (internal: uri scheme)
- [x] Subtask #103 (Restricted security level)
- Situation description:
- [x] Subtask #40 (Package object)
- [x] Subtask #41 (Repository object)
- [x] Subtask #42 (Installation request)
- Request post-processing
- [x] Subtask #57 (Download repositories)
- [x] Subtask #58 (Get table of all packages)
- Dependency tracking:
- [x] Subtask #43 (DFS through dependencies)
- [x] Subtask #44 (Compare list of desired and installed packages)
- [x] Subtask #45 (Feed the package list into the transaction backend)
- [x] Subtask #109 (The „provides“ header)
- UI
- [x] Subtask #46 (The updater binary)
- [ ] Subtask #47 (Command to remove or add a package)
- [x] Subtask #48 (Emulation of opkg)
- [x] Subtask #49 (Emulation of the old updater)
- [x] Subtask #67 (Post the log of installed packages)
- [x] Subtask #69 (Better error reporting)
- [x] Subtask #77 (Nuci integration)
- [x] Subtask #80 (Collision reporting)
- [x] Subtask #83 (CRL error)
- [x] Subtask #84 (Missing repository error)
- Misc
- [x] Subtask #61 (Hide context)
- [x] Subtask #68 (Access to system libraries)
- [x] Subtask #62 (Replan)
- [x] Subtask #63 (Reinstall)
- [x] Subtask #96 (Late reinstall)
- [x] Subtask #64 (Reboot)
- [x] Subtask #65 (TODO/FIXME)
- [x] Subtask #66 (Deploy)
- [x] Subtask #72 (Dont fail on prerm)
- [x] Subtask #74 (Lock for the whole run)
- [x] Subtask #75 (Config overwrining)
- [x] Subtask #81 (Blocking write)
- [x] Subtask #95 (Lockup on poll)
- [x] Subtask #87 (Auto-run resilience)
- [x] Subtask #88 (User-list definitions)https://gitlab.nic.cz/turris/updater/updater/-/issues/14Transaction backend for the old updater2019-05-06T17:46:55+02:00Ghost UserTransaction backend for the old updaterImplement the backend part of the new updater and replace opkg with this in the old updater.
- [x] Subtask #1
- [x] Subtask #2
- [x] Subtask #3
- [x] Subtask #4
- [x] Subtask #5
- [x] Subtask #6
- [x] Subtask #7
- [x] Subtask #8...Implement the backend part of the new updater and replace opkg with this in the old updater.
- [x] Subtask #1
- [x] Subtask #2
- [x] Subtask #3
- [x] Subtask #4
- [x] Subtask #5
- [x] Subtask #6
- [x] Subtask #7
- [x] Subtask #8
- [x] Subtask #9
- [x] Subtask #10
- [x] Subtask #11
- [x] Subtask #12
- [x] Subtask #13
- [x] Subtask #20
- [x] Subtask #25
- [x] Subtask #26
- [x] Subtask #27
- [x] Subtask #32 (Logging configuration)
- [x] Subtask #35 (Field test)https://gitlab.nic.cz/turris/updater/updater/-/issues/13Integrate the backend in the current updater2020-11-12T02:24:16+01:00Ghost UserIntegrate the backend in the current updaterGather all the packages to install or remove and perform the whole removal/installation at once by the opkg-trans backend.
- [x] Depends on #35 (Field test)Gather all the packages to install or remove and perform the whole removal/installation at once by the opkg-trans backend.
- [x] Depends on #35 (Field test)https://gitlab.nic.cz/turris/updater/updater/-/issues/12Journal recovery2020-11-12T02:24:16+01:00Ghost UserJournal recoveryBe able to recover installation when an incomplete journal is found. Implement journal abortion in possible cases (when merging hasn't started yet).
- [x] Depends on #11Be able to recover installation when an incomplete journal is found. Implement journal abortion in possible cases (when merging hasn't started yet).
- [x] Depends on #11https://gitlab.nic.cz/turris/updater/updater/-/issues/11Using the journal through installation2020-11-12T02:24:15+01:00Ghost UserUsing the journal through installationUse the journal when we install or remove packages ‒ write what is being done, etc, to ensure we can recover.
- [x] Depends on #10Use the journal when we install or remove packages ‒ write what is being done, etc, to ensure we can recover.
- [x] Depends on #10https://gitlab.nic.cz/turris/updater/updater/-/issues/10Journal manipulation2020-11-12T02:24:15+01:00Ghost UserJournal manipulationBe able to read and write the journal. Writing needs to be atomic in some way, reading might need to handle damaged or incomplete journal. Decide on the format, but don't act on what is being read.Be able to read and write the journal. Writing needs to be atomic in some way, reading might need to handle damaged or incomplete journal. Decide on the format, but don't act on what is being read.https://gitlab.nic.cz/turris/updater/updater/-/issues/9Locking2020-11-12T02:24:11+01:00Ghost UserLockingPerform some kind of locking (on the journal? On the package state? See what opkg locks, if anything?) to prevent parallel runs. Decide if we want to wait (with timeout?) or abort.Perform some kind of locking (on the journal? On the package state? See what opkg locks, if anything?) to prevent parallel runs. Decide if we want to wait (with timeout?) or abort.https://gitlab.nic.cz/turris/updater/updater/-/issues/8Saving package state2020-11-12T02:24:16+01:00Ghost UserSaving package stateBe able to store the package state and use it after the installation (or prepare it in the temporary location before merging?).
- [x] Related to #6
- [x] Depends on #2Be able to store the package state and use it after the installation (or prepare it in the temporary location before merging?).
- [x] Related to #6
- [x] Depends on #2https://gitlab.nic.cz/turris/updater/updater/-/issues/7Running pre/post-install/remove scripts of packages2020-11-12T02:24:16+01:00Ghost UserRunning pre/post-install/remove scripts of packagesRun the necessary scripts. Decide if we want to run them before and after the whole merging of files #6 , or during. But we probably don't want to abort the merging in the middle because of a failed script.
- [x] Depends on #6
- [x] ...Run the necessary scripts. Decide if we want to run them before and after the whole merging of files #6 , or during. But we probably don't want to abort the merging in the middle because of a failed script.
- [x] Depends on #6
- [x] Depends on #8https://gitlab.nic.cz/turris/updater/updater/-/issues/6Merging files to live system2019-05-06T17:46:51+02:00Ghost UserMerging files to live systemMerge requests to install files from the unpacked packages (in the temporary location) and requests to remove files by updated or removed packages into live system. This doesn't yet contain modifying the package state database, but it sh...Merge requests to install files from the unpacked packages (in the temporary location) and requests to remove files by updated or removed packages into live system. This doesn't yet contain modifying the package state database, but it should check for package collisions from other packages (either already installed or being installed now) and correctly identifying what needs to be removed.
- [x] Depends on #5
- [ ] Related to #8https://gitlab.nic.cz/turris/updater/updater/-/issues/5Unpacking packages to a temporary location2020-11-12T02:24:16+01:00Ghost UserUnpacking packages to a temporary locationHave a mechanism to unpack the content of a given package into a given place and extract the control files somewhere.
Consider feeding it with a buffer instead of a file name.
- [x] Depends on #4Have a mechanism to unpack the content of a given package into a given place and extract the control files somewhere.
Consider feeding it with a buffer instead of a file name.
- [x] Depends on #4https://gitlab.nic.cz/turris/updater/updater/-/issues/4Process manager2020-11-12T02:24:16+01:00Ghost UserProcess managerImplement a process manager, inspired by perl's AnyEvent::Util::run_command (but simpler). It needs to be able to run the command provided, specify callbacks or buffers for its stdio and run a callback when all the IO is done and the com...Implement a process manager, inspired by perl's AnyEvent::Util::run_command (but simpler). It needs to be able to run the command provided, specify callbacks or buffers for its stdio and run a callback when all the IO is done and the command terminated.
Provide some interface to lua.
- [x] Depends on #1
- [x] Depends on #3https://gitlab.nic.cz/turris/updater/updater/-/issues/3Event loop2020-11-12T02:24:16+01:00Ghost UserEvent loop - Integrate libevent
- Handle registration of children and call callbacks for them (can we reuse the libevent's events for that?)
- Some kind of „wait“ mode ‒ list events that must stop being pending or active to stop, while still exe... - Integrate libevent
- Handle registration of children and call callbacks for them (can we reuse the libevent's events for that?)
- Some kind of „wait“ mode ‒ list events that must stop being pending or active to stop, while still executing the rest of eventshttps://gitlab.nic.cz/turris/updater/updater/-/issues/2Parse current package state2020-11-12T02:24:16+01:00Ghost UserParse current package stateParse the info in /usr/lib/opkg and provide it as some data structures in lua. Make sure it is easily tested.
- [x] Depends on #1Parse the info in /usr/lib/opkg and provide it as some data structures in lua. Make sure it is easily tested.
- [x] Depends on #1https://gitlab.nic.cz/turris/updater/updater/-/issues/1Integrate the lua interpreter2020-11-12T02:24:15+01:00Ghost UserIntegrate the lua interpreterMake sure the opkg-trans builds with a lua interpreter, the interpreter is properly initiated, etc. We need a way to inject functions to lua.Make sure the opkg-trans builds with a lua interpreter, the interpreter is properly initiated, etc. We need a way to inject functions to lua.https://gitlab.nic.cz/turris/updater/updater/-/issues/193It should be possible to add Provides from updater configuration2020-01-14T14:11:21+01:00Karel KociIt should be possible to add Provides from updater configurationWe can specify Provides in packages but to have as much liberty as we want in configuration we should also have Provides field in configuration it self.We can specify Provides in packages but to have as much liberty as we want in configuration we should also have Provides field in configuration it self.https://gitlab.nic.cz/turris/updater/updater/-/issues/272Add support for PKG_UPGRADE variable in package scripts2020-01-29T14:50:07+01:00Karel KociAdd support for PKG_UPGRADE variable in package scriptsThis variable seems to be set to `1` when package is updated. Up to my knowledge we are not doing that (although I haven't looked in to the code).
We should probably introduce it. There is small problem with it that we do not know if it...This variable seems to be set to `1` when package is updated. Up to my knowledge we are not doing that (although I haven't looked in to the code).
We should probably introduce it. There is small problem with it that we do not know if it is a new installation or not in location where we generate those variables, we know only that we have to install it. It should not be hard to see if package is already installed but it is not directly accessible in that code location.https://gitlab.nic.cz/turris/updater/updater/-/issues/289Change how approvals work to instead call hook2020-10-15T15:11:16+02:00Karel KociChange how approvals work to instead call hookCurrently approvals generate to provided path file that requests approval. Next run user can use hash from that file to approve those changes.
This is not ideal I feel and much less complicated and direct would be to just use hooks. We ...Currently approvals generate to provided path file that requests approval. Next run user can use hash from that file to approve those changes.
This is not ideal I feel and much less complicated and direct would be to just use hooks. We could have approval hooks that are called to decide if update is approved. There can be more than one approval script so approve can be done by more than now one fixed way.
Updater should provide hook with list of changes and expect it to exit in specific way to signal one of three states:
* undecided
* deny
* approve
When at least one script provides deny or approve than such action is performed. No other script should be executed after that. Undecided result forwards updater on to another hook.https://gitlab.nic.cz/turris/updater/updater/-/issues/294Check collisions between Alternatives and files/links2022-06-06T14:25:05+02:00Karel KociCheck collisions between Alternatives and files/linksWe should check for collisions between alternatives and other files. Right now we just overwrite any existing link in place but that is not ideal.
The collision checking should discover following problem: https://gitlab.labs.nic.cz/turr...We should check for collisions between alternatives and other files. Right now we just overwrite any existing link in place but that is not ideal.
The collision checking should discover following problem: https://gitlab.labs.nic.cz/turris/turris-build/issues/122
We should also handle the same way all links. We can insert links from packages with priority 0. That way we can fallback on them if Alternatives package is removed and no other alternative (over just original package) was left in system.https://gitlab.nic.cz/turris/updater/updater/-/issues/300Detect broken Internet connection2023-08-16T14:59:54+02:00Vojtech MyslivecDetect broken Internet connectionWhen a WAN is down and Internet connection is not available, updater "spam" Foris notifications with:
```
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz'
```
which is a bit cryptic, espec...When a WAN is down and Internet connection is not available, updater "spam" Foris notifications with:
```
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz'
```
which is a bit cryptic, especially for new Turris users.
It would be really nice to enhance user experience and lower "false issues" [like that](https://forum.turris.cz/t/nemohu-resolvovat-repo-turris-cz/12907) (that's really not unique).Turris OS 5.1https://gitlab.nic.cz/turris/updater/updater/-/issues/302Allow (or check if possible) replan on virtual package2020-06-15T12:15:06+02:00Karel KociAllow (or check if possible) replan on virtual packageDoing replan on specially immediate one on virtual package turns out to be pretty useful. The point is that you can just line all package you want to update once before you reexecute updater without needing to select one of them to be th...Doing replan on specially immediate one on virtual package turns out to be pretty useful. The point is that you can just line all package you want to update once before you reexecute updater without needing to select one of them to be the root of three and inserting others as additional dependencies. The reason is that might not be always possible such as if that creates cycle that just can't be broken. With such cycle updater possibly won't allow update as updater is critical package.
I am convince that using virtual packages do not work at the moment with replan as those are ignored when plan is created. This means that with routine cutting away plan in case of replan won't cut it simply because there is not package to cat plan at.https://gitlab.nic.cz/turris/updater/updater/-/issues/306Preserve modified orphan config files for even installed packages2023-05-30T14:39:37+02:00Karel KociPreserve modified orphan config files for even installed packagesAt the moment when package is removed and it contains configuration file we keep it in database to track modified config. Problem is that we do not do the same if package is upgraded and removes configuration. We just remove modified con...At the moment when package is removed and it contains configuration file we keep it in database to track modified config. Problem is that we do not do the same if package is upgraded and removes configuration. We just remove modified configuration in such case.
The reason why we should not do it is to on one side preserve configuration modifications by users even if that might mean keeping around no longer used files. The second reason and more important one is that this might be just an issue in package and new version can revert to it as well as some other new package can take ownership of it. We should not reset config in such case.https://gitlab.nic.cz/turris/updater/updater/-/issues/312Reinstall check should also tak in to consideration other fields2022-06-06T14:15:04+02:00Karel KociReinstall check should also tak in to consideration other fieldsAt the moment we reinstall when one of these fields change: `"Version", "Architecture", "LinkSignature", "Depends", "Conflicts", "Provides"`. We should reinstall also on other fields.
These fields are used in OpenWrt and make sense to t...At the moment we reinstall when one of these fields change: `"Version", "Architecture", "LinkSignature", "Depends", "Conflicts", "Provides"`. We should reinstall also on other fields.
These fields are used in OpenWrt and make sense to trigger reinstall on them:
* Essential (although we do not use this)
* Conffiles
* Alternativeshttps://gitlab.nic.cz/turris/updater/updater/-/issues/313Add FilesSignature2021-06-11T08:24:02+02:00Karel KociAdd FilesSignature`FilesSignature` should be same extension as `LinkSignature` but assembled from list of files.
Originally I thought that we do not need this but it turns out that sometimes patches do not bump version but add/remove files. This can caus...`FilesSignature` should be same extension as `LinkSignature` but assembled from list of files.
Originally I thought that we do not need this but it turns out that sometimes patches do not bump version but add/remove files. This can cause collision but only in existing installations. This can be in the end pretty hard to detect. We should cover this even when this does not happen so often because of that.https://gitlab.nic.cz/turris/updater/updater/-/issues/314Take in to considerations priorities in plan ordering2022-06-06T14:11:02+02:00Karel KociTake in to considerations priorities in plan orderingWe have priority of packages and they should be installed in that priority. It is weak order requirement we should include. It also improves update in general.We have priority of packages and they should be installed in that priority. It is weak order requirement we should include. It also improves update in general.https://gitlab.nic.cz/turris/updater/updater/-/issues/324Add another updater mode: approvals with good update confirmation2022-02-14T23:43:41+01:00Martin PeckaAdd another updater mode: approvals with good update confirmationHi, regarding to the occasional reports on forum from people with failed updates of routers they can't physically access, I think implementing another updater mode would help them a lot.
You’d basically install a cron job to revert the ...Hi, regarding to the occasional reports on forum from people with failed updates of routers they can't physically access, I think implementing another updater mode would help them a lot.
You’d basically install a cron job to revert the update before executing it, and the user would need to manually connect to the router and click a button in Reforis to confirm the update went well. If not, the router would automatically revert the update and reboot after some time. Of course, that’s not the best idea with MOX, but on Omnia, it could be pretty useful (I’m myself doing something similar manually).
This way, I could update the remote Omnias much quicker without fear that there will be undesired downtime. The downtime would be limited to tens of minutes max if the update fails.