| Age | Commit message (Collapse) | Author |
|---|
|
456fb55744a1acc6bd2f464b7656a9c33d0b7ac5 made tools/read-dependencies
and package/brpm distinguish between build dependencies and runtime
dependencies, however packages/redhat/cloud-init.spec.in expects all
the dependencies to be in the 'requires' list, thus missing some build
dependencies.
This change makes cloud-init.spec use 'buildrequires' too.
The build happens to succeed without python3-devel on the epel-8 copr
chroot as it pulls in the epel-rpm-macros package, which in turn depends
on python3-devel. In other words the dependency is satisfied by chance.
Packages building for Python 3 need to explicitly specify BuildRequires:
python3-devel, see: [1].
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
|
|
Since upstream cloud-init has dropped python2 support,
adapt remaining package build scripts and tools to python3 only
Changes:
* Do not template debian/rules as python3 is the only supported version
* Drop six from requirements.txt
* Makefile: drop everything related to Python 2
* run-container: install the CI deps only on ubuntu|debian
* read-version: update the shebang to use Python 3
* brpm: read_dependencies(): drop unused argument
* read-dependencies: switch to Py3 and drop the --python-version option
* pkg-deps.json: drop the Python version field and update the redhat deps
* pkg-deps.json: drop the unittest2 and contextlib2 renames
* Update RPM the spec file to use Python 3 when building the RPM
* bddeb: drop support for Python 2
|
|
LP: #1825444
|
|
|
|
This makes the necessary changes to patch the full packaged version into
the trunk maintained redhat and suse spec files.
|
|
In bash shells with bash_completion enabled, now the cloud-init
sub commands and parameters/flags will be shown.
|
|
Revert "centos: do not package systemd-fsck drop-in."
Revert "systemd: make systemd-fsck run after cloud-init.service"
The systemd-fsck drop-in caused regressions by introducing ordering
The change reverts the original commit that added systemd-fsck drop-in
and another commit that had removed that from the centos packaging:
1f5489c258a26f4e26261c40786537951d67df1e
8a5296c41db45be3a172862f324ad44e732a2250
The result is to no longer provide the systemd-fsck drop-in.
LP: #1717477
|
|
The change here fixes the build of CentOS 7 rpm.
The systemd 'drop-in' file systemd-fsck@.service.d/cloud-init.conf is
not expected to work on CentOS at the moment. There, the
cloud-init-local.service currently runs without DefaultDependencies=no.
That would likely cause a dependency loop.
The drop-in was added for bug 1691489. It may well be needed at a later
date in CentOS also.
|
|
Under el7, cloud-init systemd files need some unit tweaks to ensure
they run at the right time. Pull in current el7 downstream systemd unit
changes.
|
|
This change adds a couple of makefile targets for ci environments to
install all necessary dependencies for package builds and test runs.
It adds a number of arguments to ./tools/read-dependencies to facilitate
reading pip dependencies, translating pip deps to system package names and
optionally installing needed system-package dependencies on the local
system. This relocates all package dependency and translation logic into
./tools/read-dependencies instead of duplication found in packages/brpm
and packages/bddeb.
In this branch, we also define buildrequires as including all runtime
requires when rendering cloud-init.spec.in and debian/control files
because our package build infrastructure will also be running all unit
test during the package build process so we need runtime deps at build
time.
Additionally, this branch converts
packages/(redhat|suse)/cloud-init.spec.in from cheetah templates to jinja
to allow building python3 envs.
|
|
The typical rpm build process will examine the spec file to determine
which packages should be installed in the boot root. This requires
the specfile to declare that it needs system. Provide this information
by checking which version in which the rpm is being built and exporting
requirements for systemd.
|
|
Many changes here to get us able to build rpms on CentOS 5 or 6 and RHEL.
* add 'Requires' as 'BuildRequires' also.
This allows us to run cloud-init tools in the build environment, and
also will allow us to run tests in the build process.
* build for both systemd and upstart (centos 5) init systems.
* Add 'centos' as a variant
Adding the variant means we can use the 'centos' user as default on centos
rather than a 'fedora' or 'rhel'.
* drop argparse from the requirements.
On any system other than python 2.6, having a 'requirements' that mentions
argparse just causes problems. Instead we add that Requires to the spec
directly.
* list dependency on dmidecode (as redhat distro spec had)
* remove duplicate line in files section ({_unitdir}/cloud-*)
* Use rpm macros for init-system chunks and drop use
of init_system variable template
* Add el6 only build-req on python-argparse
* python-cheetah is not required in the build environment as the
the spec is already rendered. (We will soon move the spec to jinja).
|
|
This has been a recurring ask and we had initially just made the change to
the cloud-init 2.0 codebase. As the current thinking is we'll just
continue to enhance the current codebase, its desirable to relicense to
match what we'd intended as part of the 2.0 plan here.
- put a brief description of license in LICENSE file
- put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0
- simplify the per-file header to reference LICENSE
- tox: ignore H102 (Apache License Header check)
Add license header to files that ship.
Reformat headers, make sure everything has vi: at end of file.
Non-shipping files do not need the copyright header,
but at the moment tests/ have it.
|
|
Adjust the redhat spec file to fix errors found during a ./tools/brpm
on centos 6:
RPM build errors:
File listed twice: /usr/libexec/cloud-init/uncloud-init
File listed twice: /usr/libexec/cloud-init/write-ssh-key-fingerprints
Installed (but unpackaged) file(s) found:
/etc/NetworkManager/dispatcher.d/hook-network-manager
/etc/dhcp/dhclient-exit-hooks.d/hook-dhclient
|
|
For upstream version directly use the output of git-describe
(X.Y.Z-number.gHASH) rather than rather than changing it to
(X.Y.Z+number.gHASH).
The rpm version does not allow '-' in Version, so we create and use
rpm_upstream_version in the rpm spec file. That is of format:
X.Y.Z+number.gHASH
|
|
upstream snapshots are versioned in the format 'X.Y.Z+<distance>.g<commit>'
where X.Y.Z are major, minor, and micro. Distance is number of commits
since last annotated tag, and commit is the git commit.
bddeb and brpm will now create and use the "upstream version" like above.
Things changed here:
- tools/make-tarball
update cloudinit/version.py to contain the full version
support --output
support '--long' to always create the long format version string.
- bddeb:
- use quilt debian source format
- use read-version and long version in changelog.
- brpm:
- change to use read-version and upstream long version in the spec.
- flake8 changes
- tools/read-version
- read version from git or from cloudinit/version.
- provide --json output with more nicely formed data.
|
|
- Update HACKING.rst to include git instructions
- update MANIFEST.in and .gitignore to ignore git-related things
- replaced tarball generation scripts with git-based script
- have the spec files correctly identify themselves as cheetah templates
- make brpm work with git
|
|
These new files were not getting picked up during
packaging (and they need to, otherwise rpm building
fails).
- 66-azure-ephemeral.rules
- cloud-init-generator
|
|
|
|
|
|
|
|
- Use _libexecdir for the helper binaries
- Use _sharedstatedir instead of /var/lib
- Ensure _libexecdir/${name} exists
|
|
|
|
|
|
I'm not really sure what the function of tools/sudo was, and it was definitely
not required for fixing the rpm build.
|
|
|
|
|
|
|
|
|
|
differently in the rpm spec file template instead
of being joined with the release.
|
|
|
|
|
|
|
|
|
|
rpm builder utility.
|
|
In cherry picking the cheetah commit, I missed the rename of these files.
packages/debian/changelog => packages/debian/changelog.in
packages/debian/control => packages/debian/control.in
packages/redhat/cloud-init.spec => packages/redhat/cloud-init.spec.in
|
|
At this point there is a mixture of "double hash" cheetah comments and '#*'
cheetah comments.
|
|
output of 'make-tarball' now is tarball with name formatted as:
cloud-init-$VERSION~bzr$REVNO.tar.gz
Instead of
cloud-init-$VERSION-$REVNO.tar.gz
The former is desireable for apt at least as the '~' is understood
to mean less than.
This merges revno 569 and 570 from lp:~harlowja/cloud-init/rework
|
|
|
|
This brings with it other changes, and also makes an install
install all of the requisite init files. (ie, cloud-init needs the -local and
the non-local)
|
|
type
which then later affects the installation of certain config files, which then
can be extracted during package creation as needed.
|
|
packaging solutions handle these
2. Get the cloud-init specfile working for the init.d case (with the right postun and post and install sections)
a. It works!!!
|
|
and adjust the specfile that is generated to remove the unwanted config
files for the types which were not selected.
|
|
|
