DNF doesn't fall back to /var/tmp if it cannot write to the cachedir
location specified in dnf.conf (unlike YUM). Removing the explicit
cachedir setting in dnf.conf enables the fallback behavior, which we
will need for autospec use.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Since the user-setup script does not clone package repos by default
anymore, 'make pull' can be made more user-friendly by not printing
warnings if some/all/most of the package repos are not already present
in the packages/ directory.
Instead, only populate the package "pull" list with names from the
packages file that are currently present in the packages/ directory.
Package repos that are not present can be cloned as before: 'make clone'
to clone all missing package repos, or 'make clone_PKG' to clone a
selected package repo.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Not setting "keepcache=1" results to DNF removing cached RPMs after
every local build.
Also, naming the cachedir "/var/cache/dnf" is important for the cache to
stick around and be stored in /var/cache/mock/clear/dnf_cache.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
The new dnf.conf is very similar to the yum.conf, but because the
in-tree Mock config specifies to use DNF, we should track a dnf.conf
here as well and use it by default.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
The "image-creator" and "koji-client-files" subdirectories are named as
such to reflect their purpose from long ago. In the present, the names
are confusing, so I am shuffling files around a bit to reflect current
usage.
All conf files (or conf file templates) have been moved to "conf"
instead, and some documentation has been added to explain what the files
are used for, and how they can be customized.
Also, after moving the conf files, the last file remaining in one of the
old subdirectories is "start_qemu.sh", so move it to the toplevel dir.
We could eventually move the miscellaneous scripts into a dedicated
directory too, but I will save that for another time.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
The common tooling behavior changed a while back with respect to the
mock config usage, so update the user-setup script to reflect the
changes. Also add documentation about how to customize the mock config,
which can be leveraged to revert back to the original behavior as well.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
To enable future shared workflows between the common tooling and mixer,
create a directory named 'mix' within the tooling workspace.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
Support both absolute and relative paths for the cert options, instead
of relative paths only, by using realpath(1) to resolve the arguments.
(Note that the script cannot reference the path arguments verbatim
because much of the script operates in the workspace's toplevel
directory, which is a different location than where the script is
invoked. In that situation, relative paths would not resolve.)
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
After running 'make autospecnew', the freshly created repo only exists locally,
so the repo remote is not yet initialized. The 'git pull --rebase' (via 'make
koji') will then fail due to the uninitialized remote. Improve this case by
only rebasing when the remote is initialized.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
If the user tries to create a new package with 'make autospecnew', a
package repo will be created from scratch, even if a repo exists with
the same name at PKG_BASE_URL.
This problem stems from 'make autospecnew' assuming that all tracked
package repos are cloned already, but is a bad assumption, given the
recent change of behavior for user-setup.sh (not cloning package repos
by default).
Resolve it by first trying to clone the repo with "make clone_PKGNAME";
clone_PKGNAME targets are automatically defined for all packages listed
in the projects/common/packages file. As long as users have an
up-to-date packages file (i.e. are running 'make pull' regularly), then
this solution works well. The case not covered is when packages are
added, then later removed; package repos will already exist remotely in
this case. However, this is a relatively rare case, so I opted to only
handle the common case where a package is added and never removed from
the distro at a later point.
(Side note: I originally wanted to 'git ls-remote REPO' to check remote
repo existence, but this does not work well with Github, as Github
prompts for username/password for remotes that appear to not exist,
since they might be private repos. Prompting a Github username/password
in this case is not very user-friendly. Using the Github API looks
viable, but I would rather not special case the handling of Github repos
in the common tooling.)
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
The DOWNLOAD_MIRROR server, the SOURCES_URL server, and upstream
source tarballs may be hosted in many different environments.
Allow users to supply additional curl options via a config to use
whenever connecting to the DOWNLOAD_MIRROR and SOURCES_URL servers and
work better with their particular hosting environment. Because upstream
source tarballs can come from many different locations, do not offer a
global config and instead allow users to define this manually as needed
when the rule is used.
Signed-off-by: George T Kramer <george.t.kramer@intel.com>
Eventually developers - when they know what they're doing - want to
manipulate a little bit the mock arguments to i.e skip a few stages
in the mock build cycle while they're hacking a package.
One example is when developers are testing changes to a spec file but
not touching dependencies and they're [re]running the build multiple times
it would be nice to not cleanup before the build and run a rebuild
for example with: --rebuild --no-clean
With this patch one should only do:
make build MOCK_OPTS="--rebuild --no-clean"
Signed-off-by: Leandro Dorileo <leandro.maciel.dorileo@intel.com>
Users are encouraged to run the user-setup script as documented in the
"Automated setup" section. To clarify that the "Manual setup" section is
an alternative to "Automated setup", move those docs to the end of the
README instead.
Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
