On Mon, 2016-11-14 at 12:35 -0500, Neal Gompa wrote:
On Mon, Nov 14, 2016 at 12:17 PM, John Florian <john.florian@xxxxxxxx> wrote:On Sun, 2016-11-13 at 05:03 +0100, Kevin Kofler wrote: Hi, FYI, Neal Gompa has now put up a Copr with the DNF + Python 3 version of the livecd-tools: https://copr.fedorainfracloud.org/coprs/ngompa/livecd-creator/ 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.
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 https://docs.pagure.org/koji came along ... or maybe that's been around for
awhile and I just never stumbled onto it working only with "better than nothing" https://fedoraproject.org/wiki/Koji). 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]: https://github.com/rhinstaller/livecd-tools/pull/37I'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]: https://github.com/kkofler/livecd-tools
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. 
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
