vyos-cloud-init.git/packages, branch 20.1 (mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=20.1 2020-02-20T17:11:04+00:00 Update tooling for GitHub-based new releases (#223) 2020-02-20T17:11:04+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-02-20T17:11:04+00:00 urn:sha1:4ad5c5d058cc9501ef2f294cb6430d9ffe372e7d * tools/read-version: don't enforce version parity in release branch CI We have a bootstrapping problem with new releases, currently. To take the example of 20.1: the branch that bumps the version fails CI because there is no 20.1 tag for it to use in read-version. Previously, this was solved by creating a tag and pushing it to the cloud-init repo before the commit landed. However, we have GitHub branch protection enabled, so the commit that needs to be tagged is not created until the pull request lands in master. This works around this problem by introducing a very specific check: if we are performing CI for an upstream release branch, we skip the read-version checking that we know will fail. * tools/make-tarball: add --version parameter When using make-tarball as part of a CI build of a new upstream release, the version it determines is inconsistent with the version that other tools determine. Instead of encoding the logic here (as well as in Python elsewhere), we add a parameter to allow us to set it from outside the script. * packages/bddeb: handle missing version_long in new version CI If we're running in CI for a new upstream release, we have to use `version` instead of `version_long` (because we don't yet have the tag required to generate `version_long`). Make the RPM build use Python 3 (#190) 2020-01-24T20:12:11+00:00 Paride Legovini paride.legovini@canonical.com 2020-01-24T20:12:11+00:00 urn:sha1:c99cfb21164b24644fec56013449b2b1e3b54fb3 * packages/brpm: switch to python3 No changes needed other than changing the shebang interpreter. * pkg-deps.json: bump the redhat build dependencies to python36 CentOS 7 (our standard target for the COPR test builds) uses python3.6 as its default python3 interpreter, so let's bump the build dependencies accordingly. debian: add reference to the manpages 2019-12-12T15:13:12+00:00 Joshua Powers josh.powers@canonical.com 2019-12-12T15:13:12+00:00 urn:sha1:796f58081766c51cdb36e770541d32f84f595371 packages: update rpm specs for new bash completion path 2019-04-19T21:38:44+00:00 Daniel Watkins daniel.watkins@canonical.com 2019-04-19T21:38:44+00:00 urn:sha1:69251d5b4431204c1e768fdf6e9f268edceb2e96 LP: #1825444 Add cloud-id binary to packages for SUSE 2018-10-25T20:01:39+00:00 Jason Zions jasonzio@microsoft.com 2018-10-25T20:01:39+00:00 urn:sha1:744c42361317eaa23f860104f152432e5bb5b996 - Do not use the systemd_prefix macro, not available in this environment 2018-05-29T14:13:35+00:00 Robert Schweikert rjschwei@suse.com 2018-05-29T14:13:35+00:00 urn:sha1:ae02c367ea8a6ce8a9e6d97047edf31decd335b2 packages/brpm: Get proper dependencies for cmdline distro. 2018-05-23T19:29:09+00:00 Scott Moser smoser@ubuntu.com 2018-05-23T19:29:09+00:00 urn:sha1:32c485bdc6e1eee0ad1d92dcd633a4e7ac9ac7a6 When invoked with '--distro=suse', the packages that would be attempted for installation would be from redhat. We just were not pasing the args.distro through. That is fixed here. packages: Make rpm spec files patch in package version like in debs. 2018-05-23T18:41:11+00:00 Scott Moser smoser@ubuntu.com 2018-05-23T18:41:11+00:00 urn:sha1:2ab8960402677ab66583d56dcb7704369a1256f5 This makes the necessary changes to patch the full packaged version into the trunk maintained redhat and suse spec files. Update version.version_string to contain packaged version. 2018-05-22T20:06:41+00:00 Scott Moser smoser@ubuntu.com 2018-05-22T20:06:41+00:00 urn:sha1:5446c788160412189200c6cc688b14c9f9071943 This modifies version.version_string to support having the package build write the *packaged* version in with a easy replace. Then, when cloud-init reports its version it will include the full packaged version. Also modified here are upstream package build files to get that done. Note part of the trickery in packages/debian/rules.in was to avoid the 'basic' templater consuming the '$variable' variable names. LP: #1770712 tools: Support adding a release suffix through packages/bddeb. 2018-05-03T02:03:23+00:00 Scott Moser smoser@ubuntu.com 2018-05-03T02:03:23+00:00 urn:sha1:d24057adbc70e7b034b8aca36c5351938b5de74a bddeb already supported passing in a '--release' and that would get into the changelog line. If you used bddeb to build packages for a PPA, and built multiple releases, then you would get the same version for each release, and launchpad would reject your upload. The change here means we get a ~16.04.1 (for xenial) suffix on the dpkg version. If the distro-info-data package is not installed, or the release is not known (such as the default "UNRELEASED"), then you get no suffix.