Hans de Goede wrote: ... I agree with that. Do our users agree ? - can we count how many users we have ? - can we count how many updaters we have ? - could we get such info from the mirrors ? - before the above, do people consider getting such info out of web logs to be an invasion of privacy ? And for most serious packages, it is not a breeze to bang up a .spec and get it reviewed (mine took around a year from my first work on a spec until finally ready for inclusion). But I far prefer this than having a zillion app users configure, make, make install packages they find on the net. We do need to ensure that all reviewers do so in a positive frame of mind, rather than being abusive or dictatorial in their responses. We don't want the packager to be put off, neither do we want other readers of the review (eg from a mailing list archive when a user does a search for something) to think that being part of the RPM Fusion sounds bad / is a stress etc. We could look at this as "what would make rpmfusion the 'killer app' that essentially every user immediately enables after a fedora upgrade or install ?". - dvd playback ? - mp3 playback ? - closed source graphics driver support ? ... For me, I don't use centos/el anymore at work nor home, so I'm reluctant to build something for it, since I don't really know the differences, and (if we don't already) we should have some info regarding such differences, update mindset, stability mindset of the people that use EL. One way could be to give a time frame of say 60 days from the EL release or major update (or even maybe fedora release, since it seems common for about a gigabyte of Fedora and RF updates to be needed within a month or two of a Fedora release) to have completed integration repo testing and then what is ready becomes the rpmfusion release for that version. Other things I don't know about EL: - do the public have access to a continual stream of rawhide packages like fedora ? - do the public have access to beta releases ? Perhaps it is too easy to createrepo and publish somewhere on the web. I think there is also some kudos involved like - what experience do you have admining linux systems? - I built and maintained an rpm packaging repo for 20 packages. There is possibly also some issue of trust eg: if I am using EL for work, then I might need to guarantee any packages used are of sufficient quality and free from potential exploits etc. The only way I can do this is get the source and build it myself. ie there is no RedHat support saying this package is good. How would you build such a reputation for RPM Fusion ? I think the best bit about packaging for Fedora or RPM Fusion is the interaction with reviewers. This can help a packager go from 'this seems to work for me' to 'this works for at least two people possible on different architectures' to 'this is a much better package now that more eyes have been across it'. Even the comments from brand new packagers /reviewers are helpful to pick up things that I have missed. Not sure of http://www.answers.com/topic/sof but thinking you are meaning single point of failure ? ... Trustworthy is the key of course. We (both users and packagers) need to be confident that: - the key won't go missing - the key won't be used except as needed by rpm fusion signing process - the person(s) has actually checked the diffs of packages to ensure no skulduggery [1] is occurring. [1] http://www.merriam-webster.com/dictionary/skulduggery I usually take an interest in this - and am happy to update pages when rpmfusion-users or fedora-list people make mention of something specific, or needing attention. Agreed. In terms of the earlier mentioned issue of push time, would it make sense (or even save time?) to have an 'updates-bulk' (think of a better name) repo. This could once a month or so, take all 'updates' as we currently know them and split the repo into all changes from release to this point in time. Any new updates during the intervening month could be in an 'updates-recent' repo, so that user machines only have to download repo metadata of a size related to the changes within a smaller timeframe. Although, having more repos active seems to have a detrimental effect on yum/PK operation time, and it would likely confuse users. I haven't been on lists etc where users are having such trouble recently (actually one I did suggest going with RPM Fusion rather than a troublesome combination of 4 other external repos. Never noticed that, how wide spread is it. Does the issues lend themselves to improvement of packages or other areas. Isn't Stewart's work on this nearing completion ? Anyway, 'just works' for me on nvidia fx5600. a) The simplest solution is default use of --skip-broken, since it essentially delays the smallest conflicting part of the update until it is available, all your other security updates still get installed. I had suggested that --skip-broken (or perhaps another plugin) could understand that the fact that a potential download that is actually not currently downloadable should be treated as a 'broken' update, so that transactions can complete. b) mirroring could be a two stage process (or at least we could treat it as such from the supply point of view): - publish the rpms earlier, (potentially automatically from the build sys). Do not replace the earlier released rpm yet. - once enough time has gone by that a heap of mirrors have the packages (24? hours), build the repo metadata and publish it (possibly with both old and new packages visible). - after 24? hours remove the superseded packages from the master. Would that be workable ? Another one of those 'so much to do - never gets done' items. I wanted to take a look at it but never got the time. Stuff like this really needs multiple eyes (aka reviewers/testers) who can pass both a technical and critical eye over the remix and provide positive feedback to the developer. Keeping a 'supported' remix or two within the project, and potentially distributed on rpm fusion mirrors would be a good thing, even if only to centralize the work in this area (outside of the pure Fedora world). I also like the mantra of 'just works' for a user. It is interesting though that the more repo work that gets done that makes it easier for the user, the less likely that the user might be driven to find the time or energy to enage with the project/community in any other way other than consumer. (sort of like success may in fact be shooting yourself in the foot). Is no complaints a reflection of 'no problems' or can't be bothered (didn't work, too hard, don't want to subscribe) ? ... We don't really want to get users used to downloading and running raw apps from the internet - even our own. I suggest sticking to the signed repo, signed packages approach, but other wise this is a good idea. With some stats from download mirrors, we could become better informed in what users actually install / setup on their system. New: = Package suggestions = I like to keep an ear (eye) out for apps that the linux media is talking about, and I usually check out the home page, and put such into my 'when I get time' bookmarks. An 'In The News' or 'Recently Talked About' section could provide potential packagers with a list of suddenly publicized packages. - eg: a linux journal article runs on a topic like 'audio production'. It mentions 5 different apps, and how to configure/make/make install for those apps and get them going. Then talks about actual use of those apps. (This also applies to some threads on the fedora-list). Our response could be to: - as soon as possible get it in our list (just to keep track - it might eventually make it into fedora if it can). - hopefully quickly find an interested person to mark it as 'beginning packaging' - review, accept, import, build, release the package. - see that the referring article actually works with our packages. - create a page devoted to that application, with a link to the original article, the project page, additional information pertinent to fedora+RPM Fusion. - hopefully by the time fedora users are reading the article, they can yum install somecoolnewpackage and be on their way to following the rest of the article. = Goal of RPM Fusion = I would like to think that one goal could be: "reduction of fedora-list traffic" Let's say that shortly we have: - a super system for getting closed source drivers easily installed and optimized. - an easy way to ensure most multi-media stuff just works - an easy way to install some proprietary apps (vmware, flash, skype seem to be regularly discussed/need help with etc). {i'm thinking hal and PK integration) Maybe that would cut down on 10-20 % of that lists traffic ! = kmods in the repo = Do we want to store the complete set of built kmods forever ? These are sort of multiplicative - if they aren't already, it won't be long before released kmod variants exceed actual packages in number. Could we assume that all older kmod releases are redundant since they can be built on the user's system with akmod ? And hence remove them from the repo ? Maybe just keep the latest 2, plus the one from Fedora release time ? Cheers (hope I didn't bore you with this), David Timms.

On 26.01.2009 01:05, David Timms wrote: No, I only have access to the awstats from download1.r.c updaters? We might be able to check how many people hit mirros.rpmfusion.org, but - those are two or three machines as well - not everyone uses mirrormanager Don't think so. Checking the number of visitors shouldn't be a big problem. But in general: putting a privacy policy somewhere in our wiki (simply copy the one from Fedora?) might be a good idea. Related: What I'd really like to prevent is that our list of unassigned review-bugs gets to long... +1 No, there isn't something like a "EL-rawhide" In the past that was the case. Yes, definitely ;-) Agree to these. No, but that's not the case -- the signers in Fedora or RPM Fusion trust that the tarballs and patches that get uploaded by the packagers are good. We already have updates-testing, where new and updated packages normally stay for 7 to 14 days. That should be enough afaics. There was someone on fedora-list recently that had trouble, as he had atrpms and rpmfusion enabled. It afaics just works if you just stick to the defaults. nvidia-xconfig for example afaics doesn't work, but is something a lot of people would like to use. I'd call it a workaround and not a solution, but yeah, it would hide the proble That is to complex to realize -- especially as it would require support in Fedora. +1 +1 Well, I don't think that's a huge difference to what http://rpmfusion.org/Configuration already does. Users still would need top know what to do after enabling RPM Fusion to get a fully working system. And that's imho not good and not what we want. They have to trust us and our packages anyway already. So why not with a helpful installer? Isn't this something that should started in Fedora? Then we can handle the parts that Fedora can't. I'd prefer something like "Make it just work" ;-) That's not the case. I know and then remove old ones manually. But I need to be careful to not remove the akmod packages while doing that. I also cleaned the F8 repo when it went EOL. But I can clean more aggressively if people want. CU knurd

Michael Schwendt wrote: Do you think RPM Fusion packages should include conflicts or similar (with external 3rd party repos packaging) to stop an install that would cause the two styles of packaging to both be installed ? DaveT.

On Mon, 26 Jan 2009 15:59:43 +0100, Thorsten wrote: Bad idea, IMO. It's only possible to conflict with NEVR tuples, but not with repo ids. If packages from different repos share some package names, you've lost. Explicit "Conflicts" also cannot protect against unresolvable dependencies. The conflicts in ffmpeg/x264 apparently are older, btw, and reappear during dependency resolving: | http://dl.atrpms.net/all/ffmpeg.spec | | Obsoletes: ffmpeg-libs <= %{evr} | %lib_dependencies | | * Sun Nov 16 2008 Axel Thimm <Axel Thimm ATrpms net> - 0.4.9-28_r15845 | - ffmpeg-libs from a 3rd party repo generates conflicts.

On 25.01.2009 20:07, Hans de Goede wrote: Sure, I'm happy as well, I just had hopped for a bit more ;-) I think Xavier once offered to look into that -- I remember I then stopped to look closer into this myself. Getting it to work is likely not that much of a deal, someone with the proper rights on the buildsys likely just needs to sit down and do it. What I forgot to say: I'm willing to help with this. But someone else really needs to have the official hat on. That imho should also include to look at the usual channels and lists to watch out for problems users might run into. strong +1 thx I fear a bit that a new steering committee might revisit the libdvdcss issue immediately. That could bring the project into serious trouble, which I'd really like to avoid. It also would be kind of unfair if that decision would be changed quickly, as some people that invested a whole lot of time in RPM Fusion (like me) only did so because libdvdcss was left out. Sure, there are risks. But it could bring lots of new contributors and help to get 3rd party repos merged into RPM Fusion. Especially the latter is appealing IMHO. Sorry, I totally disagree here. If something requires docs to be used then it's IMHO partly broken already. Just Look at fedora-list, where especially in the october/november/december timeframe a lot of people run into problems with our drivers. Further: I also saw three of my colleagues (one quite familiar with Fedora; the other two not so, but they are real Linux experts) try to use the drivers. All of them failed somewhere and all ran into different problems. But yes, work is done to make things better. But there is still a lot of work to do afaics. No, this can't be fixed 100%, but it can be made a lot better, as most of the times things are on the servers -- yum just chose not-up2date mirrors. Maybe a yum plugin could do the trick and make it work in 99,9% of the cases. For the start enabling skip-broken would make things less problematic. In my experience having such things outside the project IMHO leads to confusion among the users; sooner or later others might start creating their own RPM Fusion spins, which often lead to competition instead of cooperation :-/ Well, a daemon might be best to work automatically and flawlessly. But maybe a yum plugin could work as well. IOW: Users should not have kick a tool to rescan the system; it should "just work" automatically, to make sure it works for people that are not familiar (yet) with Fedora. CU knurd

On 01.03.2009 00:05, Rahul Sundaram wrote: Well, from my point of view the whole process had a very bad start. Two reasons (among others) for that *option* of mine: (a) you tried to do many things own your own (e.g. presenting something nearly finished including a name for it) without getting the list properly involved *early* enough in the process; yes, I know, you tried to get it involved, but maybe not hard enough and/or to late; maybe it was simply bad luck (people on vacation maybe?); "(b)" is also part of the problem (b) seems many people are interested in a spin, but either found no time to participate or are not much more then "interested" (e.g. not willing to invest time for it, but would like it; that's a general problem in RPM Fusion afaics) Maybe putting everything aside and starting fresh might help; e.g. discuss what we want: name(s), target audience, gnome vs. kde (we should do both), free and nonfree, Live-Spin vs. regular install media, ...; that might help to get things rolling again (but maybe I'm wrong with that). Sure that is slower, but it might lead to what we all want ;-) I brought that topic up a few days already in a mail. Until that is solved: If you want to get something decided by the steering committee then ask it and I'm sure you'll get an answer. But right now there isn't much to decide afaik, as omega includes packages that are not part of Fedora and RPM Fusion. That IMHO makes it just as unacceptable for RPM Fusion as an official Fedora spin with a RPM Fusion package in it. Sounds good. That's for me sounds a lot like "my packages were not reviewed; there wasn't even a real reviewer, just a few random comment; so instead of trying harder or getting exchange reviews organized I start my own repo instead of participating to Fedora or RPM Fusion". Regarding that: For my option on that see above. CU knurd

Kevin Kofler wrote: Then build a KDE variant. What is stopping you? Rahul

On 02.03.2009 20:57, Kevin Kofler wrote: I'm well aware that I sometimes might have done that now and then -- especially in the phase to get RPM Fusion started, as I got the impression everyone waited for someone to drive things forward, so I did when everything seemed stuck. But I always try to announce things *early* in the process to give people a chance to influence stuff before I do it. But if I got to far somewhere: Sorry. Check the archives. It wasn't my decision alone; it was one of the decisions from the steering committee. In fact it were others that were against it in the beginning when I was still undecided. Reverting that decision now is hard. There are contributors that invested a lot of time in RPM Fusion just on the fact that we don't ship libdvdcss -- stating to ship it now might kick those people out, which imho would be a bit unfair. CU knurd

Thorsten Leemhuis wrote: You keep repeating the same thing over and over again and I am getting really tired of explaining this to you. Just drop it and move on. If you want to insist on a new name, go ahead and be my guest. If you find consensus, let me know. I am building on a desktop kickstart based live cd and that's all I have time for. If others want to build a KDE based live cd, sure, feel free to participate. I did inform Rex Dieter and others in the KDE SIG this. You already brought this up before and I repeat, there is nothing outside of Fedora and RPM Fusion packages in Omega. Nothing close to it. I wanted to host Omega in RPM Fusion mirrors. I asked on list a few times and no decision was ever made. The option was to drop all my work on the floor or host it elsewhere. I am hosting it elsewhere till people here decide on something since I did not want my work to be wasted. I will ask again, are you or the steering committee or whoever it is that is making the decision now willing to host Omega? Rahul

Thorsten Leemhuis wrote: It is already called as Omega Desktop. I don't have time to maintain another variant right now. Somebody interested should step up to do that if they want more. Again and I can only ask for feedback. What do I do if I don't get any? Does that mean livna libdvdcss cannot be included or that livna repository cannot be enabled by default? Then I don't really see the point. Rahul

On 03.03.2009 08:27, Rahul Sundaram wrote: Sounds really good, as it leaves room for other omega variants :-) I didn't mean you to do that. That why I wrote "ideally" ;-) We nevertheless IMHO once again should ask in public (blog and spins-list maybe?) if somebody want to do a KDE spin with RPM Fusion before we do one with Gnome -- then we can point users that complain "why don't you hvae a KDE spin" there and tell them "nobody volunteered". Note that there is a "ideally" as well. But again: We don't allow packages that haven't been reviewed. Why should we allow spins that haven't been reviewed? I'd say so, because the reasons for not including libdvdcss in a spin are the same as for not including them in the repo. Cu knurd

On 07.03.2009 15:48, Rahul Sundaram wrote: What do you mean? ftp://ftp.infradead.org/pub/spins/README.Omega-10-Release-Notes doesn#t contain the word "KDE" afaics. Or do you mean the "Do you plan on do other variants?" part? Whatever: If we want to do a spin as RPM Fusion project then I'd much prefer if we tell the world something like "hey, a RPM Fusion Fedora reminx with Gnome is prepared and we'd like one with KDE as well, but don't have anyone working on yet", just to make sure nobody yells at us later. I thought you wanted to make it a kind of official RPM Fusion remix? Isn't that the point of the whole discussion? I assume you do. Then we IMHO need to review it, similar to how spins are reviewed in Fedora afaics: https://fedoraproject.org/wiki/Spins_Process https://fedoraproject.org/wiki/Spins_SIG_Review_Checklist I for one think we should follow the fedora rules when it comes to spins (or remixes in this case) just like we follow the Fedora rules elsewhere as well. The reasons for that IMHO are similar as in Fedora: it's the projects reputation that rises or falls with the quality of spins we host. Not to mention legal aspects. The question """ - what to put on the servers aka *legal considerations*: What does it require from RPM Fusion? Do we need to host the SRPMs from Fedora to make sure we comply to the GPL even if the Fedora server drop of the net tomorrow? """ in http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-March/0040... wasn't answered yet afaics. You are free to do so and I really appreciate your efforts. CU knurd

On 07.03.2009 21:39, Rahul Sundaram wrote: I'd do it for a official RPM Fusion spin if nobody else steps up. Then nothing happens. Sure it sounds unrealistic(¹); but that afaics doesn't matter at all afaics (see below). (¹) and I don't think it's that unrealistic; just for a moment think what could happen if <evil company> buys Red Hat tomorrow Where exactly? Sorry if I sound dumb, but I just want to make sure we do everything right from the start to prevent running into situations where we'd violate the GPL. Note that http://fedoraproject.org/wiki/Legal/Distribution explicitly says: """ The Fedora Project hereby explicitly states that it follows option a) above, accompanying the binary code with a complete machine-readable copy of the corresponding source code. The Source RPMs are placed on the Fedora download servers alongside and concurrent with the Binary RPMs. Anyone obtaining any executable form of Fedora by downloading from one of Fedora's download servers may also voluntarily download the corresponding Source RPMs. The Fedora Project hereby explicitly states that it does _not_ follow option b) or c) above. [...] """ Hence we can't distribute our remixes under 3c afaics and point people to Fedora, as that would require Fedora to be distributed under 3b. But I'm not an expert in things like that. Maybe I got something wrong and that's why I think it's worth the time to discuss this here. See also: http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/4277 And also: http://lwn.net/Articles/193852/ """ MEPIS has typically used binary packages straight from the parent repository for large parts of the system. They never carried the source code for these unaltered packages. [...] Sending people to the parent source repository is not good enough, although they got away with it for some time. """ CU knurd

Thorsten Leemhuis wrote: Not including libdvdcss kinda defeats the point of Omega. Kevin Kofler

Thorsten Leemhuis wrote: I will just add this: In my previous reply I said that only Fedora and RPM Fusion packages are included. There is however a single exception to this. libdvdcss from Livna is also included as I already noted before but I wanted to clarify that now as well just in case you missed that. Everything is covered in detail at ftp://ftp.infradead.org/pub/spins/README.Omega-10-Release-Notes Rahul

Stewart Adam wrote: <snip> Sounds like a good idea (I use something similar). <snip> <snip> +1 Regards, Hans

Hi, I agree too. IIRC Planet CCRMA is/was merging with Fedora. http://fedoraproject.org/wiki/AudioCreation For the latter question, please see below. IMHO this is not the main problem with other repositories not joining RPM Fusion. Some packagers don't want to learn/use Fedora guidelines. Some others use Fedora guidelines but do not want to cooperate with a (much bigger) project because they just want to mind their own business. Some others are willing to cooperate but they think that the infrastructure we and Fedora have is too complicated. In all these cases, they end up building their own repository. So, how can we attract other 3rd party repositories? I think we should invite 3rd party maintainers again and ask them to join. If they don't want to join, we should politely ask why. We should stress about our strengths and the benefits of joining (only one repo, very visible, peer review to improve quality, build system, cvs, etc). We already have a list of 3rd party repository. Can we fill it with the maintainer(s) info? BTW, which repositories have been invited in the past? I remember to have contacted Bruno Postle and he joined. We should ask Chris Nolan about this. The solution was ready. I think the only problem he still had was about the domain/certificate to use. I still think we need this ASAP. Even Fedora recently recognized that they want some kind of web CMS. BTW, I'd really like to thanks all the RPM Fusion maintainers. I think we are doing a good work. Bye, Andrea.

On Mon, Jan 26, 2009 at 6:18 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote: Kevin, I didn't say that there isn't a need for such repo, I just said that IMHO it is not our main problem in attracting 3rd party repositories. After all, you and kwizart already take part (an important part!) in RPM Fusion. If I may add, I do not oppose the creation of such repository. The only doubt about it is, because the packages in there wouldn't "polished" (i.e. not peer reviewed, not in good shape, etc), what will happen when users will have problems. Will they blame the quality of RPM Fusion? Bye, Andrea.

On Mon, Jan 26, 2009 at 8:22 PM, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; wrote: I think Hans could answer this. IIRC he took part in the talks to merge Planet CCRMA in Fedora. We already have a page in the wiki to track third party repositories. http://rpmfusion.org/FedoraThirdPartyRepos If all of us contribute a little to track down the maintainers, we could at least try to contact them, ask them to join, listen to their complains, guide them in the project. Bye, Andrea.

On Mon, Jan 26, 2009 at 10:52 PM, Hans de Goede <j.w.r.degoede(a)hhs.nl&gt; wrote: I have updated the wiki page adding many contact info. Plase add others if you /know them. Bye, Andrea.

On Tue, Jan 27, 2009 at 7:00 PM, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; wrote: You are welcome. You have a point here. But for now, I'd prefer to have to edit a single page instead of two. Later, when we'll contact maintainers, we can do the split. Does this sound fine? We can do it when we'll split the page. I think we should keep them, but in a different section. Usually maintainers (or maybe it is just me?) look for already (but eventually not up to date) Fedora packages. Bye, Andrea.

Andrea Musuruane wrote: Looks good to me. Regards, Hans

Andrea Musuruane wrote: Excellent work. I'd suggest a rpmfusion representative volunteer for each repo, particularly someone who has some familiarity with the repo or who runs it. In the meantime, I'll go adjust the wiki to move kde-redhat to the "compatible" section. :) -- Rex

Thorsten Leemhuis wrote: yes! -- Rex

On Sun, Feb 08, 2009 at 10:06:29AM +0100, Thorsten Leemhuis wrote: I think it would be great. Adrian

On 09.02.2009 14:28, Dan Horák wrote: Hmmm. kde-redhat is something special, so a dedicated repo for it makes a lot of sense afaics. But do you need to have your own dedicated experimental repo. Might a general experimental repo be a better solution? Not sure myself, just want to hear options... BTW: It's "RPM Fusion" (with space) ;-) Yes. Otherwise merging kde-redhat afaics wouldn't make much sense I'd say so. (As long term gnome user) I'm not familiar at all with kde-redhat, but I think that's what they also do now and then (like preparing kde 4.2 before it hit rawhide or 4.1 before it hit F9?) I'd say so. In general: I wouldn't want to many rules for those repos. But we need to be very careful. Having to many of those repos could be dangerous (for us), confusing (for the users) and time consuming (for infra and the people that take care of the infra). And we of course need to make sure that the main repo remains the repo that normally offers everything ordinary users want. CU knurd

On 10.02.2009 09:57, Dan Horák wrote: A dedicated "math" repo like really is not needed -- those packages are likely more suitable for a general experimental and/or staging repo. But I guess some sort of spits by area will be needed -- I guess that (for example) the kde-redhat users likely don't want to get highly experimental graphics drivers from the same repo when they run yum-update. Or how would you solve that? Excludes and includepkgs statements in the repo files are likely way to complicated... CU knurd

On 10.02.2009 11:48, Dan Horák wrote: Not sure yet if I like that scheme. But I'm not even sure if I fully understand it yet. You mean the normal free and nonfree repos we already have? Side note: Should we split free and nonfree for those experimental areas as well? I tend to say "no", as that might complicate things to much (CVS, pushing, configuration for users, yum overhead, ...) . /me tries to get the example Ahh, codeblocks is one of you Fedora packages! /me thinks he got it now Does the user actually care if it's a back- or forwardport? I'd say "not really". Rex, would you actually need "stable" and "testing" repos or could this work without "testing"? As I said, not sure yet. I'll think about it for a while longer ;-) Cu knurd

Rex Dieter píše v St 04. 02. 2009 v 07:00 -0600: I can take care of my own one :-) The content can be divided into 3 categories: 1 - packages not yet submitted for review, usually open for anyone to grab and submit 2 - experimental versions of Fedora/RPMFusion content 3 - backports of newer stuff to the Fedora release I am just using dtto for my repo Dan

One addition: On 26.01.2009 16:25, Thorsten Leemhuis wrote: Ohh, and it would be nice if the tool could have a command line interface as well, so people can use it in the %post section of their kickstart file for normal installs or spin creation. Yes, it's a detail, but an important one I'd say. CU knurd