SliTaz Repositories

     1.1 --- a/doc/cookopts.txt	Fri Jul 13 03:28:18 2018 +0300
     1.2 +++ b/doc/cookopts.txt	Fri Jul 13 18:43:25 2018 +0100
     1.3 @@ -168,9 +168,9 @@
     1.4  instant-pack
     1.5      Usual behaviour is to make the sources (when sources in the $src became
     1.6      files in the $install) and then pack the package (when files from $install
     1.7 -    split to one or another $fs, and then became the *.tazpkg archives).
     1.8 -    When multiple SETs used in the receipt, the default behaviour is to make
     1.9 -    all the sources for all the sets, and only then to pack all the packages.
    1.10 +    split to one or another $fs and then became the *.tazpkg archives).
    1.11 +    When multiple SETs are used in the receipt, the default behaviour is to make
    1.12 +    all the sources for all the sets and only then to pack all the packages.
    1.13      Presence of this option will pack the SET packages instantly before
    1.14      to switch to another SET. So, packages created in the first SET will be
    1.15 -    immediately available to use in the second SET, and so on.
    1.16 +    immediately available to use in the second SET and so on.

     2.1 --- a/lighttpd/index.cgi	Fri Jul 13 03:28:18 2018 +0300
     2.2 +++ b/lighttpd/index.cgi	Fri Jul 13 18:43:25 2018 +0100
     2.3 @@ -64,7 +64,7 @@
     2.4  fi
     2.5  
     2.6  
     2.7 -# Show the running command and it's progression
     2.8 +# Show the running command and its progression
     2.9  
    2.10  running_command() {
    2.11  	state="$(cat $command)"
    2.12 @@ -256,16 +256,16 @@
    2.13  
    2.14  # Proxy to the Repology
    2.15  # Problems:
    2.16 -# 1. Function "latest packaged version" widely used here, and it has no JSON API, but only SVG badge.
    2.17 -# 2. So, all version comparisons can be only visually and not automated.
    2.18 -# 3. When the thousands of badges present on the web page, many of them are broken (maybe server
    2.19 +# 1. Function "latest packaged version" widely used here and it has no JSON API, but only SVG badge.
    2.20 +# 2. So, all version comparisons can be only visual and not automated.
    2.21 +# 3. Of the thousands of badges present on the web page, many of them are broken (maybe server
    2.22  #    drops requests), while our server displays status icons well.
    2.23  # 4. Default badges are wide and not customizable.
    2.24  # Solution:
    2.25 -# 1. Make local cache. Update it on demand, but no more than once a day (Repology cached info
    2.26 +# 1. Make local cache. Update it on demand, but no more than once a day (Repology caches info
    2.27  #    on a hourly basis). Use cached values when they are not expired.
    2.28  # 2. Extract and save version(s) from the SVG badges. Values can be compared in the scripts as well
    2.29 -#    as custom badges may be provided.
    2.30 +#    as custom badges that may also be provided.
    2.31  
    2.32  repology_get() {
    2.33  	local found versions day=$(date +%j)		# %j is the number of the day in the year
    2.34 @@ -1149,7 +1149,7 @@
    2.35  				cat <<EOT
    2.36  <section>
    2.37  	<h2>For maintainers</h2>
    2.38 -	<p>Check your packages version, ${maintainer:-maintainer}.</p>
    2.39 +	<p>Check your packages version: ${maintainer:-maintainer}.</p>
    2.40  	<form>
    2.41  		<select name="maintainer">
    2.42  			<option value=''>--- select maintainer ---