DevHeads.net

Announcement: DNF port of livecd-creator

Hi,

remix authors rejoice: I have ported the old livecd-creator from yum to dnf
(in one night):
<a href="https://github.com/kkofler/livecd-tools" title="https://github.com/kkofler/livecd-tools">https://github.com/kkofler/livecd-tools</a>
(The other tools in the package were also ported away from yum and its
rpmUtils to dnf, but livecd-creator was the main user of yum stuff.)

So, if you are unhappy with livemedia-creator for whatever reason, e.g.:
* because of its heavy weight, requiring the whole Anaconda,
* because of its lack of persistent caching (which was the dealbreaker for
me),
* because of more stringent requirements on the kickstart (in particular,
livemedia-creator requiring more changes to your existing kickstarts),
* because livecd-creator "is more friendly when kickstarts are broken or
packages are missing" (quote from a Korora commit message),
or whatever, you will probably appreciate it.

Some caveats:
* It works for me, but of course there is only so much testing you can do in
only a few hours of work including the porting.
* It is still using Python 2, and thus needs python2-dnf (which nothing else
needs). If somebody feels like porting it to Python 3, that should be easy
now that it uses dnf, so please feel free. I would be happy to take a pull
request for that.
* The switch to dnf may change the dependency resolving in a way that may or
may not be an improvement.
* In particular, you will probably have to explicitly add these packages:
kernel-modules
kernel-modules-extra
to your kickstart to avoid getting the kernel-debug* versions dragged in.
For my KDE Fedora Remix Kannolo, I also had to explicitly add pinentry-qt
to my kickstart to avoid having pinentry-gnome3 dragged in instead.
These changes are completely backwards-compatible with the original yum
version of livecd-tools. (They should not have any effect there.)

Enjoy,
Kevin Kofler

Comments

Re: Announcement: DNF port of livecd-creator

By Brian C. Lane at 12/06/2016 - 15:55

Thanks to Kevin and Neal for their work on this. Builds for rawhide are
done. If folks could give 'em a test drive and see if there are any
glitches that'd be good. I'll backport the build to 25 and 24 later this
week if nothing serious shows up.

Re: Announcement: DNF port of livecd-creator

By Adam Williamson at 12/06/2016 - 19:41

On Tue, 2016-12-06 at 11:55 -0800, Brian C. Lane wrote:
Dennis has untagged this from Rawhide for now, as it broke ARM disk
image composes.

Re: Announcement: DNF port of livecd-creator

By Kevin Kofler at 12/06/2016 - 23:22

Adam Williamson wrote:
That is probably Neal's fix to make -foo actually exclude foo from the
compose. That is required to make -foo work with weak dependencies, i.e.,
for when something Recommends: foo or when foo Supplements something. (We
will also be submitting a similar fix to Anaconda/livemedia-creator.)
Unfortunately, it is a behavior change for when foo is actually Required by
something else in the compose: That now produces an error instead of
silently including foo anyway. We think, however, that this is the right
thing to do (it does not make sense to have -foo in the kickstart just to
have the compose tool include foo behind your back anyway), but existing
live-kickstarts do need fixing to remove bogus exclusions.

In particular, this snippet (from the minimization stuff):
# save some space (from @standard)
-make

and these from the KDE kickstart:
-scim*
-m17n*
-ibus*
-iok

are no longer valid nor necessary and should just be removed. (The former is
because OpenSSL now requires make. In the latter list, only -ibus* is really
invalid, because Plasma requires ibus-libs now, but the others just do
nothing and can be omitted as well. -@input-methods is sufficient in any
case.) These lines should not needed with livemedia-creator either, they are
just silently ignored there. So I think we should just remove them from the
kickstarts.

Kevin Kofler

Re: Announcement: DNF port of livecd-creator

By King InuYasha at 12/06/2016 - 23:26

On Tue, Dec 6, 2016 at 10:22 PM, Kevin Kofler <kevin. ... at chello dot at> wrote:
It was not that. It was because appliance-tools has a broken import
for python-imgcreate, and doesn't even properly pull it in.

Also, appliance-tools itself doesn't require python-imgcreate, so now
that livecd-tools uses python3 by default, it can't import anything
anyway.

Two simple fixes, attached to this email.

Announcement: Python 3 port of livecd-creator (was: Re: Announce

By Kevin Kofler at 11/12/2016 - 19:37

Hi,

I wrote:
Now, after a 12-hour porting session with Neal Gompa (he did the porting, I
the testing), the code is finally working with Python 3 too!

<a href="https://github.com/kkofler/livecd-tools" title="https://github.com/kkofler/livecd-tools">https://github.com/kkofler/livecd-tools</a>

Python 2 is still supported. You need Python 2 ≥ 2.6 or Python 3 ≥ 3.3. I
tested with:
python-2.7.12-6.fc24.x86_64
python3-3.5.2-3.fc24.x86_64

The Python 3 port is of course based on the DNF port. (The old YUM does not
support Python 3.)

So this issue:
Enjoy,
Kevin Kofler

Re: Announcement: Python 3 port of livecd-creator (was: Re: Anno

By Kevin Kofler at 11/13/2016 - 00:03

Hi,

FYI, Neal Gompa has now put up a Copr with the DNF + Python 3 version of the
livecd-tools:
<a href="https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/" title="https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/">https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/</a>

Enjoy,
Kevin Kofler

Re: Announcement: Python 3 port of livecd-creator (was: Re: Anno

By John.Florian at 11/14/2016 - 13:17

Hi,

FYI, Neal Gompa has now put up a Copr with the DNF + Python 3 version of the
livecd-tools:
<a href="https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/" title="https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/">https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/</a>

This is interesting news for me. I'm a long time user (in an employed capacity) of livecd-tools and it sort of felt like the project was circling the drain. I've recently started playing with livemedia-creator and have found some aspects that look wonderfully powerful (e.g., the lorax templates) but have also found it frustrating to use when it doesn't like my kickstart. I'm past that frustration (for now), but have hit another bump. To make the spins from lm-c into what I need, I must modify the lorax templates and since our spins are done in our Koji there doesn't yet appear to be anyway to achieve that.

So I'm at a crossroad of enhancing Koji to support custom lorax templates or to maybe hold out for this breath of life in livecd-tools. Are you planning to get this work into the livecd-tools in the standard Fedora repos? What about Koji support? Would this work as is or will that require further work?

I'm just trying to gauge where to focus my efforts project-wise. Hopefully I can contribute something here.

Re: Announcement: Python 3 port of livecd-creator (was: Re: Anno

By King InuYasha at 11/14/2016 - 13:35

On Mon, Nov 14, 2016 at 12:17 PM, John Florian <john. ... at dart dot biz> wrote:
In order to use alternative templates, the livemedia-creator command
must have an additional parameter passed. Koji currently doesn't
support this facility, which makes it difficult to use when you need
to support custom layouts. If you'd like this capability, file a bug
against koji in bugzilla for it.

Kevin has already submitted a request to merge our work into the
canonical livecd-tools repository[1]. Once merged, we hope that
upstream will push a new release to supported releases with the new
code. The work we did shouldn't affect Koji support any, though if you
run Koji on something other than Fedora, you'll need to have the
latest DNF 1.1 version available on the system running Koji. With the
release of RHEL 7.3 and EPEL7 subsequently bumping up to it, the
version of DNF for EL7 can be bumped to the latest 1.1 release. Please
request that in bugzilla, if you want it.

I'm currently not providing EL7 packages because of the lack of DNF
1.1. With no CentOS 7.3 available yet, I cannot produce packages that
would be installable by the vast majority of people.

[1]: <a href="https://github.com/rhinstaller/livecd-tools/pull/37" title="https://github.com/rhinstaller/livecd-tools/pull/37">https://github.com/rhinstaller/livecd-tools/pull/37</a>

I would encourage you to try out our new livecd-tools and see how it
performs for your needs. Contributions are welcome as well. If
upstream doesn't pull it in, the code will be maintained on Kevin's
GitHub repository[2].

[2]: <a href="https://github.com/kkofler/livecd-tools" title="https://github.com/kkofler/livecd-tools">https://github.com/kkofler/livecd-tools</a>

Re: Announcement: Python 3 port of livecd-creator (was: Re: Anno

By John.Florian at 11/14/2016 - 15:56

Hi,

FYI, Neal Gompa has now put up a Copr with the DNF + Python 3 version of the
livecd-tools:
<a href="https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/" title="https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/">https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/</a>

This is interesting news for me. I'm a long time user (in an employed
capacity) of livecd-tools and it sort of felt like the project was circling
the drain. I've recently started playing with livemedia-creator and have
found some aspects that look wonderfully powerful (e.g., the lorax
templates) but have also found it frustrating to use when it doesn't like my
kickstart. I'm past that frustration (for now), but have hit another bump.
To make the spins from lm-c into what I need, I must modify the lorax
templates and since our spins are done in our Koji there doesn't yet appear
to be anyway to achieve that.

In order to use alternative templates, the livemedia-creator command
must have an additional parameter passed. Koji currently doesn't
support this facility, which makes it difficult to use when you need
to support custom layouts. If you'd like this capability, file a bug
against koji in bugzilla for it.

Done. <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1394933" title="https://bugzilla.redhat.com/show_bug.cgi?id=1394933">https://bugzilla.redhat.com/show_bug.cgi?id=1394933</a>

I'm willing to try tackling this. I code Python lots and have read plenty of Koji (to understand how to use it before the excellent <a href="https://docs.pagure.org/koji" title="https://docs.pagure.org/koji">https://docs.pagure.org/koji</a> came along ... or maybe that's been around for awhile and I just never stumbled onto it working only with "better than nothing" <a href="https://fedoraproject.org/wiki/Koji" title="https://fedoraproject.org/wiki/Koji">https://fedoraproject.org/wiki/Koji</a>). If that's acceptable, should this be planned on buildsys or koji-devel first or should I just go for it and show my work as a patch on the RFE I submitted or ... ?

So I'm at a crossroad of enhancing Koji to support custom lorax templates or
to maybe hold out for this breath of life in livecd-tools. Are you planning
to get this work into the livecd-tools in the standard Fedora repos? What
about Koji support? Would this work as is or will that require further
work?

Kevin has already submitted a request to merge our work into the
canonical livecd-tools repository[1]. Once merged, we hope that
upstream will push a new release to supported releases with the new
code.

Cool beans!

The work we did shouldn't affect Koji support any, though if you
run Koji on something other than Fedora, you'll need to have the
latest DNF 1.1 version available on the system running Koji. With the
release of RHEL 7.3 and EPEL7 subsequently bumping up to it, the
version of DNF for EL7 can be bumped to the latest 1.1 release. Please
request that in bugzilla, if you want it.

I'm currently not providing EL7 packages because of the lack of DNF
1.1. With no CentOS 7.3 available yet, I cannot produce packages that
would be installable by the vast majority of people.

Will do. I'll probably wait until CentOS 7.3 is out. Unfortunately I don't have any proper RHEL to play with. Then that always puts my brain in a spin as to where I *should* file such requests, CentOS BZ, RH BZ, github, etc. I feel wrong (and have been told so for other rpms) in filing in RH BZ when I expect to use it in CentOS, but if RH *is* upstream like with lorax, then anywhere else seems wrong.

[1]: <a href="https://github.com/rhinstaller/livecd-tools/pull/37" title="https://github.com/rhinstaller/livecd-tools/pull/37">https://github.com/rhinstaller/livecd-tools/pull/37</a>

I'm just trying to gauge where to focus my efforts project-wise. Hopefully
I can contribute something here.

I would encourage you to try out our new livecd-tools and see how it
performs for your needs. Contributions are welcome as well. If
upstream doesn't pull it in, the code will be maintained on Kevin's
GitHub repository[2].

[2]: <a href="https://github.com/kkofler/livecd-tools" title="https://github.com/kkofler/livecd-tools">https://github.com/kkofler/livecd-tools</a>

I will do that. It's always an immense relief for me to see things moving to Python 3 -- I jumped ship long ago, and of course, now I want everything else to do the same. Even if I do wind up using livemedia-creator eventually for composing the ISO, I'll still be using copy-iso-to-disk from livecd-tools for some time to come for the persistent storage support. I'll be more than happy to help test. Hopefully I can also contribute something as well, which is much more likely with Py3 code because it doesn't burn my eyes like Py2 does. [:-)] ​