| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without that fix, if the output directory is not the current directory
(. or ./), making the tarball fails:
$ ./make_source_tarball.sh replicant-6.0-0004 releases
Fetching projects: 100% (502/502), done.
Checking out projects: 100% (502/502), done.
repo sync has finished successfully.
tar: releases/replicant-6.0-0004: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
lzip: replicant-6.0-0004.tar: Can't open input file: No such file or directory
This is because the path that referred to the Replicant source
directory was relative to the directory that the user was in when
launching make_source_tarball.sh, instead of being relative to the
current directory, in the script, when running the tar command.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The xz format is not well adapted for long term archiving[1]
as the format has a lot of room for incompatible
implementations. In addition, the format is very fragile
which makes it harder to implement robust and easy to use
recovery tools.
In contrast the lzip format is designed to make it easy to
recover data from corrupted archives and a tool
(lziprecover[2]) already exists for that.
There are also several downsides of using lzip over other
compression formats (like xz, gzip or bzip2):
- The lzip package usually needs to be installed, and there
is no 'unlzip' command (users are expected to use
'lzip -d' instead), and for progression you need two -v
instead of one but at least once lzip is installed,
tar commands work out of the box[3].
- There is no option to use more than one thread in the most
popular lzip implementation (GNU lzip).
In addition, for the previous Replicant 6.0 source releases
tarball, xz -9e compresses more than lzip -9.
Here the size in bytes (retrieved with du -b <path>) of the
replicant-6.0-0001.tar source release:
13415884800 replicant-6.0-0001.tar
5732651960 replicant-6.0-0001.tar.xz
5927113267 replicant-6.0-0001.tar.lz
And for replicant-6.0-0004-rc5:
15629813760 replicant-6.0-0004-rc5.tar
6662406932 replicant-6.0-0004-rc5.tar.xz
6969502733 replicant-6.0-0004-rc5.tar.lz
[1]https://www.nongnu.org/lzip/xz_inadequate.html
[2]https://www.nongnu.org/lzip/lziprecover.html
[3]For instance 'tar xf replicant-6.0-0004-rc5.tar.lz' or
'tar tf replicant-6.0-0004-rc5.tar.lz' work out of the
box.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should improve speed a lot:
- Increasing the number of fetch jobs speeds up a lot the
downloads when resuming from a previously interrupted
download session as checking for new commits can have
a big latency, so checking many as repositories as
possible at the same time speeds up things a lot.
With Replicant 4.2 0004, using "-j 100" worked well for
me, however it didn't seem to have reached 100 parallel
download jobs, so using more would not improve
performance in my case.
- As for the number of compression threads, one has to consider
it carefully: xz -9e uses quite a big amount of RAM when compressing,
so using too much threads can result in xz being killed because
it used too much RAM. In another hand using 1 thread per core
seems to divide the amount of time spent compressing by the number
of threads.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
| |
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
The following text is part of the GPLv2:
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
Since we currently host images (which contains many executable or
object code) on ftp.osuosl.org, it would be best to also ship
the corresponding source code on the exact same server.
This way we could be pretty sure that the corresponding source
code is available at the same place.
This script can generate the corresponding source code tarballs
for all the Replicant 4.2 and 6.0 versions.
For that it simply downloads the Replicant source code of a given
tag (which corresponds to a release).
To save space it doesn't download the history (it uses --depth=1)
and it compresses the results with xz -9e, but we still kept the
git and repo information in case the build system uses it somehow.
Keeping the repo and git information also makes it compatible with
the current build instructions on the wiki.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
