Some of you may have already noticed, but for those who haven't,
livecd-tools and appliance-tools have a new maintainer now. I took
over the Fedora packages and the appliance-tools repository in
December, and formally took over the livecd-tools repository a few
## New project homes
livecd-tools has a new home, with a couple of mirrors:
* Main repository: https://github.com/livecd-tools/livecd-tools
* Primary mirror: https://gitlab.com/livecd-tools/livecd-tools
* Secondary mirror: https://pagure.io/livecd-tools
(Note: The only reason that Pagure is not a co-primary/alternate
mirror is because Pagure doesn't yet have the ability to do automatic
pull mirroring. I manually push to Pagure when I can.)
appliance-tools has a new home as well, and of course with a couple of mirrors:
* Main repository: https://pagure.io/appliance-tools
* Primary mirror: https://gitlab.com/livecd-tools/appliance-tools
* Alternate mirror: https://github.com/livecd-tools/appliance-tools
Contributions are preferred through the main repository of each
project, via pull requests. Patches are also accepted via the project
mailing list: livecd(a)lists.fedoraproject.org .
Please note that it is rather difficult for me to review and merge
large patch sets submitted by email, and if you absolutely wish to
email them rather than submit a pull request to the appropriate main
repository, please provide the patches as an attached archive of
patches. When sending smaller patch series, git send-email is the way
to go, as it will produce patches that I can use and apply. The
PulseAudio project has a nice quick tutorial on how to set up and use
git send-email. In either case, please provide a cover letter with
a nice diffstat (as if it was created by git send-email), as it helps
get some picture of the changes. Again, pull requests are *strongly*
For livecd-tools, I am considering switching the primary repository
from GitHub to either GitLab or Pagure. Most of my projects are on
GitLab, so I know it quite well and like it. I am using my experience
with appliance-tools as a means to evaluate Pagure for this purpose.
If you have any feedback, I would love to hear it. Please be cautioned
that I *have not* made any decision, and staying put is an equally
valid option for me.
The primary communication channels are via the mailing list (as
mentioned earlier), the issue trackers on the main repositories, and
the IRC channel (#LiveCD-Tools on Freenode).
## What's new
Since I have taken over, quite a few fixes have been contributed and
merged into livecd-tools, and a few pending fixes for appliance-tools
have been merged as well.
With livecd-tools v24.2, several exciting changes have occurred:
* livecd-tools now uses DNF as its dependency resolver.
* livecd-tools now natively operates as a Python 3 application.
* python3-imgcreate is now available from livecd-tools for
applications to take advantage of
* Encrypted home filesystems are now supported by livecd-iso-to-disk
* Multiple live images on a single disk is now supported by livecd-iso-to-disk
appliance-tools v008 has inherited the transition to DNF from
livecd-tools, but still remains a Python 2 application for now.
However, it has received fixes to make it run better on Raspberry Pi
systems. Unlike livecd-tools, appliance-tools remains Fedora-only for
Rawhide has been running on livecd-tools v24 and appliance-tools v008
for a while now, but now I've prepared an update to release
livecd-tools v24.2 and appliance-tools v008 to Fedora 25 and have
updated livecd-tools in Mageia to v24.2 in Cauldron (Mageia's
equivalent of Rawhide) for the upcoming Mageia 6.
## What's next?
### Integrating Mageia patches for livecd-tools
Currently, livecd-tools' support for Mageia comes in the form of a few
patches to fix binary paths and disable UEFI support (since lorax
is not available in Mageia). Fixing this situation is key for ongoing
support of Mageia with livecd-tools. I want to see Mageia has a
first-class citizen with livecd-tools, just as Fedora is today.
### Porting appliance-tools to Python 3
The only thing keeping official Python 2 support alive is
appliance-tools. Given the end-of-life of Python 2 is expected within
the next three years, it's critical to move appliance-tools to Python
The major blocker here is its usage of urlgrabber, which the
developers have thus decided to not port to Python 3 and suggest to
look for alternatives. This will need to be addressed to make a port
### Supporting Mageia in appliance-tools
Currently, RH/CentOS/Fedora is the only distribution family supported
by appliance-tools. I definitely want to see this change, and have
appliance-tools extended to support Mageia. Any assistance and
contributions would be very welcome.
### Removing unnecessary legacy cruft
There's plenty of dead code paths, especially related to initramfs
handling (support for nash+mkinitrd, etc.). Gutting this and cleaning
up the code will generally make it simpler and easier to maintain.
### Fixing bugs
## Now what?
Well, that's it, really. I hope that people who are users of these
tools would be willing to help in the development and the future of
livecd-tools and appliance-tools. I'm always around in some form, and
I'm hopeful that we can come together to help keep these tools moving
forward for those who want to use them.
Thanks to everyone who has worked on livecd-tools and appliance-tools,
as you've set the groundwork for this project, and your contributions
are well-appreciated. Literally hundreds of projects would not have
been possible without your work, and I hope to see that we can
continue moving forward.
真実はいつも一つ！/ Always, there's only one truth!