The creation of the package changelog is based on a reference file.
However that reference file contained log information in a specific
timezone which requires to hardcode the region of that timezone
in the code to correctly run date/time calculations. This can
be done better from a conceptual point of view. This patch changes
the handling in a way that the reference file is a git log
excerpt including the dates as git log lists them. The dates
contains complete numeric time/date/zone information and can be
used for calculations. The changelog helper tool converts the
result data to match the requirements of rpm changelog files
and prints the time/date information localized to the callers
timezone or as UTC if the --utc switch is given. By default the
user local timezone settings applies. That way the setup of
the local timezone is immaterial to the changelog processor
and the workaround in the gitlab-ci rpm stage can be deleted
too.
Fix changelog entries for their encoding, author name and format
Also make sure commits are shown in reverse chronological order
of the author date. We intentionally don't use the commit date
because a commit can be older than the latest entry in the current
reference file and would then not be part of the git log
information
The current way of creating the changelog file for the package
is based on reading the entire history of the git repository and
turns that information into a changelog. The downside of this
approach is that any change in the code that creates this changelog
information will impact older entries and could cause a conflict
on the changes file of the released package. This usually leads
to declined package submissions and blocks us in fixing bugs
in the changelog generator. This commit changes the process in
a way that only changes related to the oldest entry of a reference
changelog file compared to the current branch are taken into
account. This Fixes#979
- build the documentation in the build_doc stage
- run tests for all supported Python versions in tox_check
- build an RPM for Fedora 29 & OpenSUSE Tumbleweed in RPM stage
In e33f53aa45, we switched to DNF when requesting YUM.
This now means we need to ensure DNF is installed for images where
we previously used YUM for that.
YUM v3 is no longer developed, having been superseded by DNF for
several years. With DNF now available as a usable package manager
in Red Hat Enterprise Linux 7 through the Extras channel and
SUSE Linux Enterprise 15 through PackageHub, there is no reason for
keeping support for YUM v3 around.
We are keeping support for requesting YUM because in Red Hat Enterprise
Linux 7, DNF is referred to as "YUM v4", and it is simply referred to
as "YUM" in Red Hat Enterprise Linux 8. To avoid confusion from people,
we're just going to leave it in place as an alias to the DNF package
manager.
As for why this is happening now, Fedora is retiring YUM v3 in
Fedora 31, so we might as well get it over with and cut over now.
Reference: https://fedoraproject.org/wiki/Changes/Retire_YUM_3
The completion can only be provided by one package if not
python version specific completion files are provided. Due
to the fix in #920 the completion file must be provided by
another sub-package. This commit moves it to the
kiwi-man-pages package. Actually kiwi man pages provides
more than just the man pages, but also the PDF documentation
and I think the completion information serves the purpose of
documentation to some degree too.
The bash completion file must match one of the alternatives links.
Otherwise the bash completion mechanism will not match. kiwi-ng is
the unique alternative link name compared to the still present
legacy kiwi version and should be used preferably
dracut-kiwi-live requires `partprobe` tool and this is provided by
parted package. Persistent overlay setup fails if parted is not
installed in the image.
This commit fixes the spec to properly build for Debian and Ubuntu.
More specific:
* update-alternatives path has been adapted
* python3-kiwi are now enabled for Debian 9 and Ubuntu 18.04
gfxboot is needed on the host for certain boot graphics
operations. It's used if the boot theme provides a gfxboot.cfg
In this case the tool is also required. The setup of the
boot themes is differently implemented in each of the
distributions we support. In addition on suse distributions
gfxboot is no longer in the core system. Given that we are
not able to find a common base on requirement of the package
we changed gfxboot from a required to a recommended package
and deleted the requirement on debian based distros
The spec file uses the %{_defaultdocdir} macro but the
corresponding Makefile target used a hardcoded path which
lead to inconsistencies on debian/ubuntu based systems.
This Fixes#838
btrfs tools are provided by btrfs-tools package and not by
btrfs-progs. In addition dracut-network is a separate package
on debian/ubuntu based distributions. This Fixes#837
Bundle a PDF version of the online documentation with the rpm package
build. Due to the complexity of getting a latex build environment into
the travis CI which does not take forever to install, the bundling of
a built PDF into the pypi archive has been skipped. Users installing
from pypi would need to install a latex env on their machine and
run make latexpdf from the installed bundle.
This Fixes#819
The dracut modules like kiwi provides it should not be part of the
default install target. If kiwi gets installed from source or via
pip all dracut code gets installed on that system which is unwanted
and in the worst case leads to boot trouble next time this system
rebuilds its initrd via dracut. Therefore an extra Makefile target
which is used in the spec of an rpm but not in the install target
of setup.py is provided in this commit.
As a consequence the installation from pip will not install any
dracut modules on that system which is intentional. Installing from
source requires to run make install_dracut which if called assumes
the caller knows what he/she does :)
In fate#323743 the decision was made to drop dmraid from
the distribution. Along with the low business case for those
controllers and the support for linux softraid via mdadm
we also drop the support in kiwi for oem-ataraid-scan
The custom kiwi boot descriptions has been moved into
the kiwi-descriptions github repo and builds the compat
package kiwi-boot-descriptions from there. The build
of the boot image(initrd) is done by dracut and the
dracut module packages provided by kiwi. The classic
custom boot descriptions can still be used as alternative
method if the above package is installed. Related to
Issue #576
This adds support for producing the main kiwi package as well as the
packages for the dracut modules to be used when building Debian-based
distribution images with KIWI.
The Debian/Ubuntu package is built using debbuild: https://github.com/ascherer/debbuild
lsblk should be called with -p because it's a mistake
to assume any device lives below /dev. There could also
be subtree devices in /dev/mapper or /dev/disk/..
We leave it up to lsblk to provide us the correct
information
Adapt package names for gdisk/gptfdisk and btrfs-progs/btrfsprogs
Install and require fdasd only on s390 architecture
Delete fbiterm requirement since the project seems unmaintained
and the use of the framebuffer terminal is an option in the code
but not mandatory. This Fixes#559
A new dracut module kiwi-repart used to be the successor of
the custom kiwi oemboot code to repartition the disk has
been added. Along with the module a dracut library kiwi-lib
will also be delivered.
