These patterns are being removed as they are not used or are going to
be reworked.
This change also removes support for multi-versioned packages which
were considered for go and cargo purposes.
Signed-off-by: William Douglas <william.douglas@intel.com>
When encountering patches prefixed with 'backport-' if they no longer
apply, remove them from the patch series and try to restart the build
without them. The goal is to avoid manual work removing patches known
to be obsolete in the next release.
Signed-off-by: William Douglas <william.douglas@intel.com>
The file_restart needs to be reset for the buildroot log if the
buildroot log is not clean the build log won't be parsed and so
file_restart won't be reset otherwise (causing build loops to occur
for packages that can't be found for instance).
Signed-off-by: William Douglas <william.douglas@intel.com>
Try to avoid doing a full rebuild when the build.log only has new
files in it.
This has a two downsides. The source buildroot needs to be distinct
from the binary buildroot. The built rpms are no longer installable as
rpmbuild flags them.
The upside is packages that take forever to build or don't have
build times improved by ccache will not need a duplicate round for
just adding the files.
The rpms can still be generated in an installable fashion with 'make
build' and the autospec generated rpms can be installed by force
installing if need be.
Signed-off-by: William Douglas <william.douglas@intel.com>
Autospec's DESCRIPTION file parsing for CRAN packages is working well
enough that I think we can unconditionally add the detected requirements
as both build and runtime dependencies.
Also remove the propagation of CRAN build->runtime deps via fail
pattern, since we no longer need it; the deps detected via fail pattern
are either Suggests (optional) or not listed in DESCRIPTION at all.
Either way, they are not required dependencies.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Due to more systems being added for automated runtime dependency
injection for subpackages, we need a way for manual overrides of the
default detected dependencies.
This change provides support for specifying which subpackage runtime
dependencies should be added or removed and consolidates some of the
custom configuration file detection along with it.
Many different components require the target download path and it is
needed early. Previously code existed to attempt to autodetect its
location and so defining the path was enforced later in the build
process. This created problems with ordering functions based on this
requirement but since the target path is now certain to be defined at
startup (due to previous changes) we can better align the location and
initialization of the data to the Config class.
As part of this change also avoid requiring the temporary working
directory to be setup as part of the Build class. This is done as a
cleanup due to the only real user of this location being the Content
class.
This also drops the stand-alone pkg_integrety main function that was
initially used as a one off test to avoid needing to run autospec to
validate the integrity of a package. This feature was seldom used and
doesn't function well without handling configuration so it was
dropped.
The build module had a number of globals that were referenced by many
other modules and has ordering dependencies with the config and
tarball module for some values. This made deciding on where certain
values get initialized difficult but before the initialization can be
addressed a refactor is helpful.
This change moves the global state (and functions that needed to act
on that global state) into a Build class. The goal of this work is
to better track what can be updated by a particular function, load
data in a sensible order and have it owned by a sensible component.
Some of this data is likely to be removed from the build class in the
future as initialization of download and base paths should take place
in other modules most likely.
The tarball module had a number of globals that were referenced by
many other modules and has ordering dependencies with the config
module for some values. This made deciding on where certain values get
initialized difficult but before the initialization can be addressed a
refactor is helpful.
This change moves the global state (and functions that needed to
act on that global state) into a Content class. The goal of this work
is to better track what can be updated by a particular function, load
data in a sensible order and have it owned by a sensible component.
I expect that future work will see the tarball, buildpattern and some
portions of the config moved around to better match what component
should own what data (and to better deliniate between the data that
has a similar use but comes from different sources).
The buildreq module had a large number of globals being touched across
many modules that would import it. This made changes to the buildreq
fragile.
It also made testing fragile due to certain globals needing to be
reset in order to properly test a change.
This change moves the global state (and functions that needed to act
on that global state) into a Requirements class. The goal of this work
is to better track what content can be updated by a particular
function and load data in a sensible order and have it owned by a
sensible component.
The config module had a large amount of globals that were being
touched across many modules that would import. This made changes to
config very fragile as figuring out what would be modified in any
given call chain was difficult to diagnose.
It also made testing fragile as one would need to reset a given
module's config import to the best of their knowledge before rerunning
another test.
To get away from that (and to try and reduce the number of globally
modified variablies in autospec as a whole), refactor the config
module to provide its state as part config class. The long running
goal of changes like this is to better track what content can be
updated by a particular function (if a function would have access
to the config instance is now the hint rather than the config module
getting imported).
Instead of autospec reserving buildroots on-the-fly to not collide with
buildroots that already exist, I would prefer for the developer (or
automation) running autospec to explicitly modify mock's `basedir`
config option whenever more control is needed, possibly combined with
other config options that modify state locations (like `cache_topdir`,
`root`, etc).
Considering only the `basedir` option, a developer could run these three
commands simultaneously to build the package `foo` and also avoid
buildroot collisions:
$ make autospec MOCK_OPTS="--config-opts=basedir=/var/lib/mock/dir1"
$ make autospec MOCK_OPTS="--config-opts=basedir=/var/lib/mock/dir2"
$ make autospec MOCK_OPTS="--config-opts=basedir=/var/lib/mock/dir3"
The build root names would be (assuming that
config_opts['root']='clear', as it is by default):
/var/lib/mock/dir1/clear-foo
/var/lib/mock/dir2/clear-foo
/var/lib/mock/dir3/clear-foo
(Note that a side-effect of this change is that all autospec unit tests
now pass in Github Actions; tests were failing because `sudo` was not
installed by default, and the unit tests required `sudo` via the
reserve_path() function.)
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Autospec currently doesn't handle /etc/, /opt/, /usr/etc/, /usr/local/
or /usr/src/ content paths so explicity warn and then fail when
content in these paths are detected.
- Change the prefix from jdk- to mvn- .
- Remove the use of xmvn.
- Add more artifacts to maven_jars file.
Signed-off-by: Athenas Jimenez <athenas.jimenez.gonzalez@intel.com>
The function was simply returning 'None' instead of a boolean. This bug
resulted in autospec never recognizing that no more build rounds were
needed when mock returns 0.
Add a unit test for this case and the other case for when mock failed
but the root.log contains no relevant errors.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Occasionally, packages will add new dependencies that are not yet
available in the repos, or autospec may add an invalid build dependency
for the next build round, etc.
To report these error conditions in a more meaningful way, scan the
root.log after a build whenever mock exits with a non-zero code. If mock
logged a missing dependency (or multiple missing dependencies), report
that information to the user. Otherwise, consider the root.log to be
"clean", and continue by scanning the build.log to determine how to
proceed.
Also, add a new unit test for the root.log parsing function.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Since moving output to a temporary directory, the "output" directory has
fallen out of use. Remove the output directory from autospec.
Signed-off-by: Matthew Johnson <matthew.johnson@intel.com>
Rename set_mock to get_mock_cmd, and return the value instead of
setting a global variable.
This patch should not change any behavior.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Use 'sudo' unless /usr/bin/mock points to consolehelper. This is a
simpler heuristic than checking for the group membership and will let
us use the group membership in Clear Linux to give sudo permissions.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
This prevents collisions when two instances are trying to build the same
package in parallel. Unit tests added as well.
Signed-off-by: Matthew Johnson <matthew.johnson@intel.com>
Some changes have recently been pushed to autospec sources without
updating the unit tests. This patch brings the unit tests up-to-date
again.
test_build.py: Remove go buildtool bits (was deprecated)
test_specdescription.py: Newline added to post-scripts
test_specfile.py: Reset license_translations dict
files.py: Check dict with get() in case of missing key
William Douglas