| Message ID | 20200417103508.5969-1-bage@linutronix.de |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Fix typos detected by Debian's lintian tool | expand |
On 17.04.20 12:35, bage@linutronix.de wrote: > From: Bastian Germann <bage@linutronix.de> > > This patch was posted by Alvin Chen under GPL-2-or-later as part of > https://salsa.debian.org/alvinch_chen-guest/swupdate/-/commit/934c3543c068. > > Signed-off-by: Bastian Germann <bage@linutronix.de> > --- > corelib/downloader.c | 2 +- > doc/source/building-with-yocto.rst | 4 ++-- > doc/source/encrypted_images.rst | 2 +- > doc/source/handlers.rst | 8 ++++---- > doc/source/overview.rst | 4 ++-- > doc/source/roadmap.rst | 8 ++++---- > doc/source/scenarios.rst | 2 +- > doc/source/suricatta.rst | 2 +- > doc/source/sw-description.rst | 6 +++--- > doc/source/swupdate.rst | 8 ++++---- > 10 files changed, 23 insertions(+), 23 deletions(-) > > diff --git a/corelib/downloader.c b/corelib/downloader.c > index 9cfb7ab..fc754fa 100644 > --- a/corelib/downloader.c > +++ b/corelib/downloader.c > @@ -30,7 +30,7 @@ static struct option long_options[] = { > {"url", required_argument, NULL, 'u'}, > {"retries", required_argument, NULL, 'r'}, > {"timeout", required_argument, NULL, 't'}, > - {"authentification", required_argument, NULL, 'a'}, > + {"authentication", required_argument, NULL, 'a'}, > {NULL, 0, NULL, 0}}; > > /* > diff --git a/doc/source/building-with-yocto.rst b/doc/source/building-with-yocto.rst > index c7b2171..ad87736 100644 > --- a/doc/source/building-with-yocto.rst > +++ b/doc/source/building-with-yocto.rst > @@ -37,7 +37,7 @@ What about libubootenv ? > ======================== > > This is a common issue when SWUpdate is built. SWUpdate depends on this library, > -that is generated from the U-Boot's sources. This library allows to safe modify > +that is generated from the U-Boot's sources. This library allows one to safe modify > the U-Boot environment. It is not required if U-Boot is not used as bootloader. > If SWUpdate cannot be linked, you are using an old version of U-Boot (you need > at least 2016.05). If this is the case, you can add your own recipe for > @@ -54,7 +54,7 @@ If you build for a different machine, SWUpdate will destroy the > environment when it tries to change it the first time. In fact, > a wrong default environment is taken, and your board won't boot again. > > -To avoid possible mismatch, a new library was developped to be hardware independent. > +To avoid possible mismatch, a new library was developed to be hardware independent. > A strict match with the bootloader is not required anymore. The meta-swupdate layer > contains recipes to build the new library (`libubootenv`) and adjust SWUpdate to be linked > against it. To use it as replacement for u-boot-fw-utils: > diff --git a/doc/source/encrypted_images.rst b/doc/source/encrypted_images.rst > index 781f484..fcb10a4 100644 > --- a/doc/source/encrypted_images.rst > +++ b/doc/source/encrypted_images.rst > @@ -1,7 +1,7 @@ > Symmetrically Encrypted Update Images > ===================================== > > -SWUpdate allows to symmetrically encrypt update images using the > +SWUpdate allows one to symmetrically encrypt update images using the > 256 bit AES block cipher in CBC mode. > > > diff --git a/doc/source/handlers.rst b/doc/source/handlers.rst > index 6c42d1e..74dbb73 100644 > --- a/doc/source/handlers.rst > +++ b/doc/source/handlers.rst > @@ -146,7 +146,7 @@ After u-boot.img is successfully installed into the volume "u-boot_r", > the volume "u-boot_r" is renamed to "u-boot" and "u-boot" is renamed > to "u-boot_r". > > -This mechanism allows to implement a simple double copy update > +This mechanism allows one to implement a simple double copy update > approach without the need of shared state with the bootloader. For > example, the U-Boot SPL can be configured to always load U-Boot from > the volume ``u-boot`` without the need to access the environment. The > @@ -165,7 +165,7 @@ However, please note the following limitations: > - Atomic renames are only possible and permitted for volumes residing > on the same UBI device. > > -There is a handler ubiswap that allow to do an atomic swap for several > +There is a handler ubiswap that allow one to do an atomic swap for several > ubi volume after all the images were flashed. This handler is a script > for the point of view of swudate, so the node that provide it the data > should be added in the section scripts. > @@ -338,7 +338,7 @@ returns. Chaining handlers, calling ``image:copy2file()``, or using > > > Note that although the dynamic nature of Lua handlers would > -technically allow to embed them into a to be processed ``.swu`` > +technically allow one to embed them into a to be processed ``.swu`` > image, this is not implemented as it carries some security > implications since the behavior of SWUpdate is changed > dynamically. > @@ -510,7 +510,7 @@ skipping over unchanged content is handled well by the rdiff algorithm. > ucfw handler > ------------ > > -This handler allows to update the firmware on a microcontroller connected to > +This handler allows one to update the firmware on a microcontroller connected to > the main controller via UART. > Parameters for setup are passed via sw-description file. Its behavior can be > extended to be more general. > diff --git a/doc/source/overview.rst b/doc/source/overview.rst > index dc82239..b446ac0 100644 > --- a/doc/source/overview.rst > +++ b/doc/source/overview.rst > @@ -336,11 +336,11 @@ Updating the boot loader is in most cases a one-way process. On most SOCs, > there is no possibility to have multiple copies of the boot loader, and when > boot loader is broken, the board does not simply boot. > > -Some SOCs allow to have multiple copies of the > +Some SOCs allow one to have multiple copies of the > boot loader. But again, there is no general solution for this because it > is *very* hardware specific. > > -In my experience, most targets do not allow to update the boot loader. It > +In my experience, most targets do not allow one to update the boot loader. It > is very uncommon that the boot loader must be updated when the product > is ready for production. > > diff --git a/doc/source/roadmap.rst b/doc/source/roadmap.rst > index 0f3e28d..ac1677e 100644 > --- a/doc/source/roadmap.rst > +++ b/doc/source/roadmap.rst > @@ -55,7 +55,7 @@ each of them solves a specific use case for a delta update. > SWUpdate is already able to perform delta updates based on librsync library. This is > currently a good compromise to reduce complexity. Anyway, this helps in case of > small changes, and it is not a general solution between two generic releases. > -A general approach could be to integrate SWUpdate with a storage to allow a delta upgrade > +A general approach could be to integrate SWUpdate with a storage to allow one a delta upgrade > from any release. > > Integration in Linux distro > @@ -98,7 +98,7 @@ Some ideas for new handlers: > Flash handler > ------------- > > -The flash handler for raw-devices (mainly NOR flashes) does not allow to > +The flash handler for raw-devices (mainly NOR flashes) does not allow one to > stream the image and an error is reported if "installed-directly" is set. > The handler can be extended to stream images. > > @@ -121,7 +121,7 @@ a unauthenticated handler cannot run. > Security > ======== > > -- add suport for asymmetryc encryption > +- add support for asymmetryc encryption > - add a way to share symmetric keys (similar as done in TLS) > > Support for evaluation boards > @@ -183,7 +183,7 @@ SWUpdate-GUI is released with a base set of features. The goal of this simple GU > is to have a low footprint compared to GUI developed with state of art frameworks. > This lets to still have a rescue that fits in small devices. > SWUpdate-GUI is already production-ready and delivered into final products. New > -features coud be developped. > +features coud be developed. > > Test and Continuous Integration > =============================== > diff --git a/doc/source/scenarios.rst b/doc/source/scenarios.rst > index 480778b..c1140c3 100644 > --- a/doc/source/scenarios.rst > +++ b/doc/source/scenarios.rst > @@ -1,7 +1,7 @@ > Update strategy examples > ======================== > > -SWUpdate is a building block and it allows to design and implementing its own > +SWUpdate is a building block and it allows one to design and implementing its own > update strategy. > Even if many projects have common ways for updating, it is possible to high customize > the update for each project. > diff --git a/doc/source/suricatta.rst b/doc/source/suricatta.rst > index fb7df23..74958fe 100644 > --- a/doc/source/suricatta.rst > +++ b/doc/source/suricatta.rst > @@ -53,7 +53,7 @@ tries to report the update status to its upstream server, e.g., > hawkBit, prior to entering the main loop awaiting further updates. > If this initial report fails, e.g., because of a not (yet) configured > network or a currently unavailable hawkBit server, SWUpdate may exit > -with an according error code. This behavior allows to, for example, > +with an according error code. This behavior allows one to, for example, > try several upstream servers sequentially. > If suricatta should keep retrying until the update status is reported > to its upstream server irrespective of the error conditions, this has > diff --git a/doc/source/sw-description.rst b/doc/source/sw-description.rst > index 1cfe6e2..86e2393 100644 > --- a/doc/source/sw-description.rst > +++ b/doc/source/sw-description.rst > @@ -399,7 +399,7 @@ the section with `-e stable,<rev number>`. > If each of them requires an own section, it is the way to do. Anyway, it is more probable > than revisions can be grouped together, for example board with the same major revision > number could have the same installation instructions. This leads in the example to 3 groups > -for rev1.X, rev2.X and rev3.X. Links allow to group section together. When a "ref" is found > +for rev1.X, rev2.X and rev3.X. Links allow one to group section together. When a "ref" is found > when SWUpdate searches for a group (images, files, script, bootenv), it replaces the current path > in the tree with the value of the string. In this way, the example above can be written in this way: > > @@ -559,7 +559,7 @@ Example: > This defines that the software is compatible with HW-Revisions 1.0, > 1.2 and 1.3, but not with 1.1 or any other version not explicitly > listed here. In the above example, compatibility is checked by means > -of string comparision. If the software is compatible with a large > +of string comparison. If the software is compatible with a large > number of hardware revisions, it may get cumbersome to enumerate all > compatible versions. To allow more compact specifications, regular > expressions (POSIX extended) can be used by adding a prefix ``#RE:`` > @@ -582,7 +582,7 @@ started. > partitions : UBI layout > ----------------------- > > -This tag allows to change the layout of UBI volumes. > +This tag allows one to change the layout of UBI volumes. > Please take care that MTDs are not touched and they are > configured by the Device Tree or in another way directly > in kernel. > diff --git a/doc/source/swupdate.rst b/doc/source/swupdate.rst > index 2b394ab..a3bb224 100644 > --- a/doc/source/swupdate.rst > +++ b/doc/source/swupdate.rst > @@ -295,7 +295,7 @@ Building a debian package > SWUpdate is thought for Embedded Systems and building in an embedded > distribution is the first use case. But apart the most used buildsystems > for embedded as Yocto or Buildroot, in some cases a standard Linux distro > -is used. Not only, a distro package allows to run SWUpdate on Linux PC > +is used. Not only, a distro package allows one to run SWUpdate on Linux PC > for test purposes without having to fight with dependencies. Using the > debhelper tools, it is possible to generate a debian package. > > @@ -425,13 +425,13 @@ Command line parameters > | -f <file> | string | SWUpdate config file to use | > +-------------+----------+--------------------------------------------+ > | -b <string> | string | Active only if CONFIG_UBIATTACH is set | > -| | | It allows to blacklist MTDs when SWUpdate | > -| | | searches for UBI volumes. | > +| | | It allows one to blacklist MTDs when | > +| | | SWUpdate searches for UBI volumes. | > | | | Example: U-Boot and environment in MTD0-1: | > | | | **swupdate -b "0 1"** | > +-------------+----------+--------------------------------------------+ > | -e <sel> | string | sel is in the format <software>,<mode> | > -| | | It allows to find a subset of rules in | > +| | | It allows one to find a subset of rules in | > | | | the sw-description file. With it, | > | | | multiple rules are allowed. | > | | | One common usage is in case of the dual | > Applied to -master, thanks ! Best regards, Stefano Babic
diff --git a/corelib/downloader.c b/corelib/downloader.c index 9cfb7ab..fc754fa 100644 --- a/corelib/downloader.c +++ b/corelib/downloader.c @@ -30,7 +30,7 @@ static struct option long_options[] = { {"url", required_argument, NULL, 'u'}, {"retries", required_argument, NULL, 'r'}, {"timeout", required_argument, NULL, 't'}, - {"authentification", required_argument, NULL, 'a'}, + {"authentication", required_argument, NULL, 'a'}, {NULL, 0, NULL, 0}}; /* diff --git a/doc/source/building-with-yocto.rst b/doc/source/building-with-yocto.rst index c7b2171..ad87736 100644 --- a/doc/source/building-with-yocto.rst +++ b/doc/source/building-with-yocto.rst @@ -37,7 +37,7 @@ What about libubootenv ? ======================== This is a common issue when SWUpdate is built. SWUpdate depends on this library, -that is generated from the U-Boot's sources. This library allows to safe modify +that is generated from the U-Boot's sources. This library allows one to safe modify the U-Boot environment. It is not required if U-Boot is not used as bootloader. If SWUpdate cannot be linked, you are using an old version of U-Boot (you need at least 2016.05). If this is the case, you can add your own recipe for @@ -54,7 +54,7 @@ If you build for a different machine, SWUpdate will destroy the environment when it tries to change it the first time. In fact, a wrong default environment is taken, and your board won't boot again. -To avoid possible mismatch, a new library was developped to be hardware independent. +To avoid possible mismatch, a new library was developed to be hardware independent. A strict match with the bootloader is not required anymore. The meta-swupdate layer contains recipes to build the new library (`libubootenv`) and adjust SWUpdate to be linked against it. To use it as replacement for u-boot-fw-utils: diff --git a/doc/source/encrypted_images.rst b/doc/source/encrypted_images.rst index 781f484..fcb10a4 100644 --- a/doc/source/encrypted_images.rst +++ b/doc/source/encrypted_images.rst @@ -1,7 +1,7 @@ Symmetrically Encrypted Update Images ===================================== -SWUpdate allows to symmetrically encrypt update images using the +SWUpdate allows one to symmetrically encrypt update images using the 256 bit AES block cipher in CBC mode. diff --git a/doc/source/handlers.rst b/doc/source/handlers.rst index 6c42d1e..74dbb73 100644 --- a/doc/source/handlers.rst +++ b/doc/source/handlers.rst @@ -146,7 +146,7 @@ After u-boot.img is successfully installed into the volume "u-boot_r", the volume "u-boot_r" is renamed to "u-boot" and "u-boot" is renamed to "u-boot_r". -This mechanism allows to implement a simple double copy update +This mechanism allows one to implement a simple double copy update approach without the need of shared state with the bootloader. For example, the U-Boot SPL can be configured to always load U-Boot from the volume ``u-boot`` without the need to access the environment. The @@ -165,7 +165,7 @@ However, please note the following limitations: - Atomic renames are only possible and permitted for volumes residing on the same UBI device. -There is a handler ubiswap that allow to do an atomic swap for several +There is a handler ubiswap that allow one to do an atomic swap for several ubi volume after all the images were flashed. This handler is a script for the point of view of swudate, so the node that provide it the data should be added in the section scripts. @@ -338,7 +338,7 @@ returns. Chaining handlers, calling ``image:copy2file()``, or using Note that although the dynamic nature of Lua handlers would -technically allow to embed them into a to be processed ``.swu`` +technically allow one to embed them into a to be processed ``.swu`` image, this is not implemented as it carries some security implications since the behavior of SWUpdate is changed dynamically. @@ -510,7 +510,7 @@ skipping over unchanged content is handled well by the rdiff algorithm. ucfw handler ------------ -This handler allows to update the firmware on a microcontroller connected to +This handler allows one to update the firmware on a microcontroller connected to the main controller via UART. Parameters for setup are passed via sw-description file. Its behavior can be extended to be more general. diff --git a/doc/source/overview.rst b/doc/source/overview.rst index dc82239..b446ac0 100644 --- a/doc/source/overview.rst +++ b/doc/source/overview.rst @@ -336,11 +336,11 @@ Updating the boot loader is in most cases a one-way process. On most SOCs, there is no possibility to have multiple copies of the boot loader, and when boot loader is broken, the board does not simply boot. -Some SOCs allow to have multiple copies of the +Some SOCs allow one to have multiple copies of the boot loader. But again, there is no general solution for this because it is *very* hardware specific. -In my experience, most targets do not allow to update the boot loader. It +In my experience, most targets do not allow one to update the boot loader. It is very uncommon that the boot loader must be updated when the product is ready for production. diff --git a/doc/source/roadmap.rst b/doc/source/roadmap.rst index 0f3e28d..ac1677e 100644 --- a/doc/source/roadmap.rst +++ b/doc/source/roadmap.rst @@ -55,7 +55,7 @@ each of them solves a specific use case for a delta update. SWUpdate is already able to perform delta updates based on librsync library. This is currently a good compromise to reduce complexity. Anyway, this helps in case of small changes, and it is not a general solution between two generic releases. -A general approach could be to integrate SWUpdate with a storage to allow a delta upgrade +A general approach could be to integrate SWUpdate with a storage to allow one a delta upgrade from any release. Integration in Linux distro @@ -98,7 +98,7 @@ Some ideas for new handlers: Flash handler ------------- -The flash handler for raw-devices (mainly NOR flashes) does not allow to +The flash handler for raw-devices (mainly NOR flashes) does not allow one to stream the image and an error is reported if "installed-directly" is set. The handler can be extended to stream images. @@ -121,7 +121,7 @@ a unauthenticated handler cannot run. Security ======== -- add suport for asymmetryc encryption +- add support for asymmetryc encryption - add a way to share symmetric keys (similar as done in TLS) Support for evaluation boards @@ -183,7 +183,7 @@ SWUpdate-GUI is released with a base set of features. The goal of this simple GU is to have a low footprint compared to GUI developed with state of art frameworks. This lets to still have a rescue that fits in small devices. SWUpdate-GUI is already production-ready and delivered into final products. New -features coud be developped. +features coud be developed. Test and Continuous Integration =============================== diff --git a/doc/source/scenarios.rst b/doc/source/scenarios.rst index 480778b..c1140c3 100644 --- a/doc/source/scenarios.rst +++ b/doc/source/scenarios.rst @@ -1,7 +1,7 @@ Update strategy examples ======================== -SWUpdate is a building block and it allows to design and implementing its own +SWUpdate is a building block and it allows one to design and implementing its own update strategy. Even if many projects have common ways for updating, it is possible to high customize the update for each project. diff --git a/doc/source/suricatta.rst b/doc/source/suricatta.rst index fb7df23..74958fe 100644 --- a/doc/source/suricatta.rst +++ b/doc/source/suricatta.rst @@ -53,7 +53,7 @@ tries to report the update status to its upstream server, e.g., hawkBit, prior to entering the main loop awaiting further updates. If this initial report fails, e.g., because of a not (yet) configured network or a currently unavailable hawkBit server, SWUpdate may exit -with an according error code. This behavior allows to, for example, +with an according error code. This behavior allows one to, for example, try several upstream servers sequentially. If suricatta should keep retrying until the update status is reported to its upstream server irrespective of the error conditions, this has diff --git a/doc/source/sw-description.rst b/doc/source/sw-description.rst index 1cfe6e2..86e2393 100644 --- a/doc/source/sw-description.rst +++ b/doc/source/sw-description.rst @@ -399,7 +399,7 @@ the section with `-e stable,<rev number>`. If each of them requires an own section, it is the way to do. Anyway, it is more probable than revisions can be grouped together, for example board with the same major revision number could have the same installation instructions. This leads in the example to 3 groups -for rev1.X, rev2.X and rev3.X. Links allow to group section together. When a "ref" is found +for rev1.X, rev2.X and rev3.X. Links allow one to group section together. When a "ref" is found when SWUpdate searches for a group (images, files, script, bootenv), it replaces the current path in the tree with the value of the string. In this way, the example above can be written in this way: @@ -559,7 +559,7 @@ Example: This defines that the software is compatible with HW-Revisions 1.0, 1.2 and 1.3, but not with 1.1 or any other version not explicitly listed here. In the above example, compatibility is checked by means -of string comparision. If the software is compatible with a large +of string comparison. If the software is compatible with a large number of hardware revisions, it may get cumbersome to enumerate all compatible versions. To allow more compact specifications, regular expressions (POSIX extended) can be used by adding a prefix ``#RE:`` @@ -582,7 +582,7 @@ started. partitions : UBI layout ----------------------- -This tag allows to change the layout of UBI volumes. +This tag allows one to change the layout of UBI volumes. Please take care that MTDs are not touched and they are configured by the Device Tree or in another way directly in kernel. diff --git a/doc/source/swupdate.rst b/doc/source/swupdate.rst index 2b394ab..a3bb224 100644 --- a/doc/source/swupdate.rst +++ b/doc/source/swupdate.rst @@ -295,7 +295,7 @@ Building a debian package SWUpdate is thought for Embedded Systems and building in an embedded distribution is the first use case. But apart the most used buildsystems for embedded as Yocto or Buildroot, in some cases a standard Linux distro -is used. Not only, a distro package allows to run SWUpdate on Linux PC +is used. Not only, a distro package allows one to run SWUpdate on Linux PC for test purposes without having to fight with dependencies. Using the debhelper tools, it is possible to generate a debian package. @@ -425,13 +425,13 @@ Command line parameters | -f <file> | string | SWUpdate config file to use | +-------------+----------+--------------------------------------------+ | -b <string> | string | Active only if CONFIG_UBIATTACH is set | -| | | It allows to blacklist MTDs when SWUpdate | -| | | searches for UBI volumes. | +| | | It allows one to blacklist MTDs when | +| | | SWUpdate searches for UBI volumes. | | | | Example: U-Boot and environment in MTD0-1: | | | | **swupdate -b "0 1"** | +-------------+----------+--------------------------------------------+ | -e <sel> | string | sel is in the format <software>,<mode> | -| | | It allows to find a subset of rules in | +| | | It allows one to find a subset of rules in | | | | the sw-description file. With it, | | | | multiple rules are allowed. | | | | One common usage is in case of the dual |