The way kiwi uses setup.py assumes that pip runs this script
like a spec file in rpm is processed. However this is not the
case given that pip implicitly creates a static zip file called
wheel which looses all the code logic done in setup.py. Therefore
setup.py should not contain code that needs to run at install
time. Of course this change comes with an effect which is that
the following files will not be available when installing kiwi
from pip:
* man pages: /usr/share/man/man8/...
* command completion: /etc/bash_completion.d/kiwi-ng.sh
* kiwi default config file: /etc/kiwi.yml
* package docs: /usr/share/doc/packages/kiwi-ng/...
(kiwi.pdf, LICENSE, README)
kiwi stays fully functional without this information. It is
expected that the installation of kiwi as a service will
be done by a package and its package manager. When using kiwi
from pip it is designed to provide a python module but not
a complete user application. The way pip and wheels interact
with each other seems to demonstrate that pip is not a
package manager but more a python module manager.
This Fixes#1415
This commit adds support for pacman package manager and, in
consequence, support for Arch Linux images. It also adds
the package definition for Arch Linux.
Python2 is announced to be unmaintained from Jan 2020.
KIWI supports Python 2.7 and it should not support any python version that
is not maintained upstream. This Fixes#1036
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.
In addition to create changelog information since the
latest date of a reference changelog, also allow to create
changelog information until the latest data of a reference
changelog
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
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
The default `setup.py clean` command does not clean `dist` and
`*.egg-info` folders. This commit makes sure those are cleaned and
also ands a `setup.py clean` command in the `clean` Makefile target
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
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 :)
The kiwi build process mostly does the right thing in terms of executing
with the correct Python interpreter throughout the build process, with
the exception of the Makefile not correctly locating the versioned Python
interpreter executable path, and the bash completion generator being executed
using '/usr/bin/python' without regard for what the target environment was.
This is a problem when a build environment complying with PEP 394 as it
stands today does not have Python 2 installed, such as when kiwi is being
built as a Python 3-only package in Fedora. Thus, the Makefile has been
adjusted to not only correctly locate the versioned Python interpreter, but
to also execute 'completion_helper' with the correct interpreter.
Additionally, a trivial change to the shebang to 'completion_helper'
was made to be consistent with other Python-based build helper scripts.
This is part of the overall effort to eliminate the dependencies on
Python 2 in Fedora.
Reference: https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
Add python 3.6 target and activate it for the travis
and the local make targets
Use major python version for the check(flake) and doc
targets where the interpreter minor version is not
primarily important
This references #641
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
Prevent strict call of a specific version of the python
interpreter. All code has been written to work with py2
and py3 thus the venv environment setup should decide
what version a call of python is. Fixes#424
The data structures are auto generated by the generateDS
tool which works nicely except for the arch-name xsd pattern
used in the RelaxNG schema. For some reason the used regular
expression is translated by generateDS into a python
expression not matching the original expression from the
schema. The result is an invalid python warning message after
the schema has successfully validated the arch string.
The problem has been reported to the generateDS developer.
As long as their is no fix available in generateDS the
following workaround in kiwi applies: The original xs:token
pattern validation will be disabled on the generateDS
level and applies only to the schema. This Fixes#347
In an effort to distribute kiwi on pypi it should not be
required to call make targets for a complete installation.
Therefore the compilation of the C tools as well as the
installation of the man pages and the bash completion
has been added to setup.py. The spec file to build an rpm
package has been changed to use setup.py exclusively
Sphinx is not available on all platforms and required only to
build the manual pages. Thus the make build target can build
the man pages and pack the result into the source tarball
A change in kiwi/schema/kiwi.rnc triggers the build of the
schema rng version as well as an auto update of the data
structures via python's generateDS. The intermediate xsd
schema format is only relevant for the data structure
creation process
Any time the version.py is changed and committed the git ident
will be reset by git. After a checkout of version.py the ident
will be updated in version.py to the git commit id of version.py
Whenever we relase a new kiwi version the process is as follows:
1. run bumpversion to set the version for the release
2. run tox to create the source tarball for the release
We have to make sure tox calls a git checkout of
version.py
As we are going to switch to tox the Makefile setup should be
cleaned up. The make targets to build xsd and rng schemas has
been moved to the master Makefile