* Automatically compute the minimum size for the partitions
* Automatically resize the pmOS_root partition during the boot process
* Resize root partition only if there is unallocated space at the end of the device.
* Added more echos to make debugging easier while looking at the pmOS_init.log.
* Updated static_code_analysis.sh script to run shellcheck with `-x` option.
* Implemented checksum test in the travis script
* Added workaround for squashed forced pushes
* Made test possible to run locally
* Match multiple git versions for the working directory message
* Refactored `umount_all` to get the list of folders to be umounted from
`umount_all_list`, so we can test that function in a test case.
* Adjusted `umount_all_list` to return the deep folder levels first
* Added a testcase for that
* Remove redundant calls to `umount_all()` (which were from a time before
`pmbootstrap` was released, in which failing commands did not cause
`pmbootstrap` to raise an exception)
This is required for developing and testing the binary repository
scripts (see #64). Changes:
* When specified, the local folder gets mounted inside the chroots
as /mnt/postmarketos-mirror
* The apkindex_files() function outputs the correct path to the local
repository (it does *not* hash the URL in that case, which would
be wrong)
* /etc/apk/repositories: when the pmOS mirror is a local folder,
the path "/mnt/postmarketos-mirror" gets added to that file instead
of the outside path (so apk finds it properly inside the chroot)
TLDR: Always rebuild/install packages when something changed when executing "pmbootstrap install/initfs/flash", more speed in dependency resolution.
---
pmbootstrap has already gotten some support for "timestamp based rebuilds", which modifies the logic for when packages should be rebuilt. It doesn't only consider packages outdated with old pkgver/pkgrel combinations, but also packages, where a source file has a newer timestamp, than the built package has.
I've found out, that this can lead to more rebuilds than expected. For example, when you check out the pmbootstrap git repository again into another folder, although you have already built packages. Then all files have the timestamp of the checkout, and the packages will appear to be outdated. While this is not largely a concern now, this will become a problem once we have a binary package repository, because then the packages from the binary repo will always seem to be outdated, if you just freshly checked out the repository.
To combat this, git gets asked if the files from the aport we're looking at are in sync with upstream, or not. Only when the files are not in sync with upstream and the timestamps of the sources are newer, a rebuild gets triggered from now on.
In case this logic should fail, I've added an option during "pmbootstrap init" where you can enable or disable the "timestamp based rebuilds" option.
In addition to that, this commit also works on fixing #120: packages do not get updated in "pmbootstrap install" after they have been rebuilt. For this to work, we specify all packages explicitly for abuild, instead of letting abuild do the resolving. This feature will also work with the "timestamp based rebuilds".
This commit also fixes the working_dir argument in pmb.helpers.run.user, which was simply ignored before.
Finally, the performance of the dependency resolution is faster again (when compared to the current version in master), because the parsed apkbuilds and finding the aport by pkgname gets cached during one pmbootstrap call (in args.cache, which also makes it easy to put fake data there in testcases).
The new dependency resolution code can output lots of verbose messages for debugging by specifying the `-v` parameter. The meaning of that changed, it used to output the file names where log messages come from, but no one seemed to use that anyway.
* New commandline parameter --mirror-pmOS, where the binary repository
URL for postmarketOS can be specified (empty by default as of now,
this will be filled with the real URL once the repo works)
* Do not build packages, when they are in the binary repository and
the version of the package in the binary repository is up-to-date.
* Add a testcase for pmb.build.is_necessary().
* pmb/challenge/apk.py had to be renamed to pmb/challenge/apk_file.py,
so the "internal" functions of that file could be accessed, while
still providing the short notation pmb.challenge.apk().
* zap asks for each buildroot_* chroot, if you want to remove it, not
only for the one with the device arch
* add new pmb.chroot.tempfolder() function, that creates a temporary
folder, that belongs to "user" and deletes it, if it already exists.
this function gets used in a few challenge testcases.
* The supported architectures are inside the config now
* Symlinks get created for that list of supported architectures now.
* During initialization, the architecture from the selected device
gets checked against the list of supported architectures. When
it is not included, a meaningful exception gets raised.
* the aportgen and (cross-compiler) build tests make use of the
new variable now (they had armhf and aarch64 hardcoded previously).
* Fix hardcoded `armhf` in pmb/aportgen/binutils.py
* Generate aports: `binutils-aarch64`, `musl-aarch64`, `gcc-aarch64`
* Distccd: Remember the cross-compiler architecture (currently armhf
or aarch64), that the current distccd is running as, and restart
distccd with the correct architecture, in case a different arch
is needed than what it is currently running as. (Depending on the
cross-compiler arch, the PATH variable gets adjusted before
starting distccd)
* Testcases: add aport generation for aarch64, add cross-compiling
to aarch64
* pmb/parse/arch.py: Add aarch64 to the mapping
For some reason, it was not possible to create the .tar.gz
archives with Python 3.4, that are used to simulate broken
or malicious apk downloads. I've rewritten the testcase,
so it creates the .tar.gz files inside the native Alpine
Linux chroot.
* automatically find the chroot binary on Debian, even if it is not
in the user's PATH
* don't use subprocess.run anymore (remove related testcase, that explicitly
checked for subprocess.run usage, and used recursive globbing, another
post 3.4 Python feature, for the checks. A similar case can be added in the
future, but right now it's more important to get Debian 3.4 working and all
PRs are reviewed anyway.)
* pytest fixtures: don't use the newer "yield" feature, as this is only
supported in a newer version of pytest, than provided on Debian Jessie
From manually testing, most stuff works in Debian Jessie. However, the
testsuite does not run through - creating an empty .tar.gz with Python
fails for some reason (this is done in test_apk_static.py).
drebrez
Martijn Braam
Pablo Castellano
Oliver Smith