Re: ffmpeg-2.4 released
Hi On Wed, Oct 1, 2014 at 7:10 PM, Michael Cronenworth wrote: mplayer was built against ffmpeg 2.4, but you do not have ffmpeg 2.4 installed. Well, ffmpeg 2.4 is not available in the repository yet for some reason Rahul
Re: Mplayer and FLV files in Fedora 13
On 05/16/2010 06:39 PM, Dominik 'Rathann' Mierzejewski wrote: On Sunday, 16 May 2010 at 14:48, Rahul Sundaram wrote: Hi, It appears mplayer cannot handle play FLV files correctly in Fedora 13. I get no video at all. Totem works fine. Is this a known issue? Also gnome-mplayer always throws out the error Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory every single time in a dialog box even though my system has a Intel display. I'm guessing this is bug https://bugzilla.rpmfusion.org/show_bug.cgi?id=1205 and vdpau has nothing to do with this. Also, not all flv files are affected. It seems such a simple fix but I don't see a update yet. Has this problem been resolved? Rahul
No RPM Fusion announcement for Fedora 13?
Hi SSIA Rahul
Re: Non-commercial redistributable game data
On 05/17/2010 06:03 PM, Ralf Corsepius wrote: Do I understand this correctly? * FESCO has a approved an installer which circumvents rpm? * This installer is installing to /usr/share? That seems to be a misunderstanding. Autodownloader downloads data to your home directory. Not /usr/share. The discussion is about enabling it to check for pre-existing data under /usr/share so that it can be packaged in RPM Fusion and installed separately by the user and autodownloader won't redownload it all over again. Rahul
Re: Non-commercial redistributable game data
On 05/17/2010 06:13 PM, Ralf Corsepius wrote: On 05/17/2010 02:39 PM, Rahul Sundaram wrote: On 05/17/2010 06:03 PM, Ralf Corsepius wrote: Do I understand this correctly? * FESCO has a approved an installer which circumvents rpm? * This installer is installing to /usr/share? That seems to be a misunderstanding. Autodownloader downloads data to your home directory. OK, it opens up the gates to worms and viruses. Can you explain how? Autodownloader has a hash of the files that it downloads and verifies them. Rahul
Re: Non-commercial redistributable game data
On 05/17/2010 06:24 PM, Ralf Corsepius wrote: downloads and verifies them. Can you explain how? Autodownloader has a hash of the files that it $HOME == automated arbitrary access to arbitrary user data == arbirary option to install maliculous programs (viruses, spyware etc.). It is not arbitrary and the user is prompted to download the data. The data is verified against a hash. Did you even try out autodownloader and understand how it works? Doesn't seem like it at all. I highly recommend doing that. Rahul
Re: Non-commercial redistributable game data
On 05/17/2010 06:33 PM, Ralf Corsepius wrote: Did you even try out autodownloader and understand how it works? Doesn't seem like it at all. No, I haven't, and I certainly will not try it. . I don't disagree that RPM packaged data is better but claiming that it is a attack vector for trojans and viruses without any understanding of how it works cannot be taken seriously.You don't have to try it out to understand how it works. So that is not a valid reason either. Rahul
Re: Non-commercial redistributable game data
On 05/16/2010 06:10 PM, Dominik 'Rathann' Mierzejewski wrote: On Sunday, 16 May 2010 at 02:02, Kevin Kofler wrote: [...] IMHO the whole affected games should move to RPM Fusion Nonfree and autodownloader should be removed from Fedora. I really don't see why we're bypassing Fedora's licensing policies in this broken way when we could just offer a package that works out of the box in RPM Fusion Nonfree where it belongs. +1. If there's free game data available in the future, the game can be always moved back to Fedora. I am in agreement as well. The autodownloader model provides perhaps more exposure to the games but at the cost of every user having to download the same data repeatedly. Rahul
Mplayer and FLV files in Fedora 13
Hi, It appears mplayer cannot handle play FLV files correctly in Fedora 13. I get no video at all. Totem works fine. Is this a known issue? Also gnome-mplayer always throws out the error Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory every single time in a dialog box even though my system has a Intel display. Rahul
Re: rpmfusion-release
On 05/16/2010 06:08 PM, Dominik 'Rathann' Mierzejewski wrote: Hi, On Saturday, 15 May 2010 at 00:32, Rahul Sundaram wrote: Hi, In RPMFusion, we have two repos - free and non-free and from a end user perspective, they are very very likely to want both these repositories. Instead of having to install two separate release packages to get what they want, can we generate a sub package, say rpmfusion-release-all that covers both these repositories? Simpler: a metapackage that requires both -free and -nonfree. Wouldn't the user still be required to download and install two more packages? The idea of a single package with both the repositories is to make things simpler. If we build such a release package within Livna, maybe we can enable all three together. There's no Livna for recent Fedora releases. Which means there's no easy way for end-users to get libdvdcss in F-12, for example. Are there any active contributors who oppose adding libdvdcss to RPM Fusion directly at this point? Rahul
Re: Mplayer and FLV files in Fedora 13
On 05/16/2010 06:39 PM, Dominik 'Rathann' Mierzejewski wrote: On Sunday, 16 May 2010 at 14:48, Rahul Sundaram wrote: Hi, It appears mplayer cannot handle play FLV files correctly in Fedora 13. I get no video at all. Totem works fine. Is this a known issue? Also gnome-mplayer always throws out the error Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory every single time in a dialog box even though my system has a Intel display. I'm guessing this is bug https://bugzilla.rpmfusion.org/show_bug.cgi?id=1205 and vdpau has nothing to do with this. Also, not all flv files are affected. Pretty much every file I have tried to play does not work. I understand the vdpau issue is unrelated. It is just a different annoyance. I would prefer gnome-mplayer to just patch out that warning. Rahul
Re: Non-commercial redistributable game data
On 05/16/2010 06:40 PM, Chen Lei wrote: 2010/5/16 Kevin Kofler kevin.kof...@chello.at mailto:kevin.kof...@chello.at IMHO the whole affected games should move to RPM Fusion Nonfree and autodownloader should be removed from Fedora. I really don't see why we're bypassing Fedora's licensing policies in this broken way when we could just offer a package that works out of the box in RPM Fusion Nonfree where it belongs. Kevin Kofler +1 to move nonfree gamedata and affected game to rpmfusion. If autodownloader can exist in fedora, then we can add other nonfree software such as sunjdk, flash-plugin as well using autodownloader . No. Autodownloader is only permitted to download game data. Nothing else. Rahul
Re: rpmfusion-release
On 05/16/2010 06:45 PM, Thorsten Leemhuis wrote: I tend to thinks that the wrong direction in the long term, as that still doesn't solve problems like where do I get the flash-plugin for new users. I don't see that. If you agree that a single release package to install makes RPM Fusion more accessible then it is well worth the effort. If Flash is distributable, it can be packaged as well. Even if that is not the case, everything that we can do to improve usability is a step forward. Don't let perfect stop the good. I haven't thought this to the end, but maybe a small app that does everything needed would be the better solution. E.g. the app could ask do you want nonfree software yes/no do you want to install the flash-plugin yes/no and things like that. Yes, there are such small apps already. Last time I looked closer at them they did some things in a ugly or non-ideal way that often lead to problems sooner or later. But maybe we could talk to the author of one of those to clean one up and make it the official, RPM Fusion endorsed way to configure RPM Fusion and all the other stuff that a lot of people want. Someone submitted such a app for review and due to opposition were made to drop some of the non-free enablers making such an app not suitable for what you are talking about. Rahul
Re: Non-commercial redistributable game data
On 05/16/2010 06:44 PM, Jonathan Dieter wrote: While I agree the the sentiment, the problem is that the maintainers of these games would have to agree to drop them in Fedora and then either package them themselves in RPM Fusion or allow others to package them. I'm not sure we'll get the necessary buy-in from them. Hans led the effort and I don't really see any reason to assume that maintainers are not amicable to that idea assuming that Hans is willing to go along with this. Rahul
rpmfusion-release
Hi, In RPMFusion, we have two repos - free and non-free and from a end user perspective, they are very very likely to want both these repositories. Instead of having to install two separate release packages to get what they want, can we generate a sub package, say rpmfusion-release-all that covers both these repositories? If we build such a release package within Livna, maybe we can enable all three together.The split is useful for some people but it shouldn't be exposed as much as now. Rahul
Re: ogmrip plugin uses faac
On 01/12/2010 02:06 PM, Gianluca Sforna wrote: Ok, do I need a new review or just add a new CVS request in the former review ticket? I believe just a cvs request would do but I am not very familiar on the current practises here. Rahul
Re: ogmrip plugin uses faac
On 12/20/2009 04:19 PM, Gianluca Sforna wrote: On Sun, Dec 20, 2009 at 11:04 AM, Kevin Kofler kevin.kof...@chello.at wrote: Gianluca Sforna wrote: b. split the libogmrip-aac.so plugin to a subpackage, put this in non-free This makes more sense, but due to how RPM Fusion is set up, it will have to be built as a separate specfile/SRPM, not as a subpackage. I suspected this... any other realistic option? This is the best option you got. Rahul
Re: NVIDIA / nouveau thread branch [was Re: Fedora 12 QA retrospective - feedback needed]
On 11/26/2009 06:37 AM, Orcan Ogetbil wrote: I have an issue with the nvidia driver in KDE. Certain actions, such as - clicking on the K-menu - clicking on the clock - using an auto hiding panel - ... freezes KDE for 10 exact seconds. Afterwards things continue as if nothing happened. I also saw this reported in nvnews.net under the evdev thread. I didn't have time to locate the source of problem, although it's most possibly evdev. Please let me know if there is a solution or workaround. Refer to https://fedoraproject.org/wiki/Common_F12_bugs#Problems_when_using_the_proprietary_NVIDIA_graphics_driver_.28especially_with_KDE.29 Rahul
Re: waiting for CVS for a long time
On 09/23/2009 10:47 PM, Adam Williamson wrote: My review https://bugzilla.rpmfusion.org/show_bug.cgi?id=775 has been waiting on CVS for quite a long time now - is this normal? it's usually pretty fast for Fedora packages... It appears there is a need for more people working on RPM Fusion infrastructure side. Perhaps you can step up? Rahul
ElRepo
Hi These folks have a bunch of extra kmods essentially. Might want to invite them to join fusion http://elrepo.org/tiki/About Rahul
file conflicts in F11 updates-testing
Hi # yum update --enablerepo=updates-testing Transaction Check Error: file /usr/lib/gstreamer-0.10/libgstdeinterlace.so from install of gstreamer-plugins-good-0.10.15-1.fc11.i586 conflicts with file from package gstreamer-plugins-bad-0.10.11-4.fc11.i586 file /usr/lib/gstreamer-0.10/libgstflv.so from install of gstreamer-plugins-good-0.10.15-1.fc11.i586 conflicts with file from package gstreamer-plugins-bad-0.10.11-4.fc11.i586 file /usr/lib/gstreamer-0.10/libgsty4menc.so from install of gstreamer-plugins-good-0.10.15-1.fc11.i586 conflicts with file from package gstreamer-plugins-bad-0.10.11-4.fc11.i586 Rahul
delta rpm's for RPM Fusion?
Hi, Any plans to support this in RPM Fusion? Afaik, you just need to do, createrepo with --deltas argument on the server side. Bodhi does this for updates in Fedora but you can just do it with a cron job here. Rahul
EL repo dependency on PulseAudio library
Hi, EL repo (mplayer?) seems to have a PulseAudio library dependency. That doesn't make much sense as EL 5 doesn't include PulseAudio at all. Rahul
Re: Openmotif in RPMFusion?
Jeroen van Meeuwen wrote: Hi there, Just a quick question before I start doing the work involved; would RPMFusion ship openmotif? More details on why it's not in Fedora (anymore) are on https://fedoraproject.org/wiki/RexDieter/openmotif It is still distributable and should be just fine for non-free repo. Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: 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 They don't control the dozens and dozens of volunteer mirrors. 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. I already said so. Mirror the SRPMs for content in the remixes. Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: 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. Read my release notes. It already answers this question. But again: We don't allow packages that haven't been reviewed. Why should we allow spins that haven't been reviewed? There is no question of allowing anything. The remix already exists and people are using it. The only decision is to let the project use the rpmfusion volunteer mirrors or not. You still want to allow a staging repository for packages ( or Koji personal repos in Fedora land) because sometimes things have to happen first before others can participate. Again, anyone is welcome to participate. In the absence of participation, I still intend to continue to get things done. 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. I want the remix to be basically usable for me as it is and without libdvdcss, the benefit is much less and I bet everybody here is using it anyway but if there is interest in such a project, somebody else has to step up and do it. Omega can still use the Livna mirrors I guess. Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis 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? Latter. It clearly informs everyone that they are free to do additional variants and are welcome to do so. 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: I don't particularly care about officialness. It doesn't make any real difference to me but if you want to host a remix, Omega serves that purpose and more mirrors would be good for users using Omega. If we want to introduce process, we need people to participate. Who is stepping up to do the actual work of reviewing it? Endless discussions about this isn't leading to anything concrete here. In the absence of people helping out, what is the action plan? 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/004090.html wasn't answered yet afaics Fedora servers (and mirrors) dropping off the net isn't a realistic scenario but mirroring SRPM's for the binary content in the live cd(s) would be a good idea nevertheless. The FSF GPL FAQ answers the specific legal requirements. Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: 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 ;-) 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. 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. You already brought this up before and I repeat, there is nothing outside of Fedora and RPM Fusion packages in Omega. As long as decisions don't get done, I would have to continue hosting it outside this project. 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. 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
Re: Where we are and where do we what to go?
Kevin Kofler wrote: gnome vs. kde (we should do both) +1 The current Omega isn't of much use to KDE users. Then build a KDE variant. What is stopping you? Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: 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. 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
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: - ideally a KDE spin as well, as I would like to prevent RPM Fusion ignores KDE fame; related: the name discussion, as the basic name of our first spin should leave room for other spins, hence your spins would need to be something like Omega Desktop or Omega Gnome afaics 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. - ideally at least two people that take care of the spins that review the work from each other a bit (IOW: we should at least basically review spins just like we review packages); Again and I can only ask for feedback. What do I do if I don't get any? - Fedora and RPM Fusion packages only 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
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: [Catching up on this after a long time so excuse the delay] - no RPM Fusion Fedora remix maintained within the project; do we want one? Or even proper install DVDs that already contain packages from RPM Fusion? I was very happy to see Rahul do some work here, way to go Rahul! I don't care much if the remix is an official part of rpmfusion or not. 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 :-/ I have asked multiple times with no clear decision. There is theory a steering committee who is in charge but it doesn't seem active. If RPM Fusion as a project want to host the kickstart file, images and help review, test and provide feedback on anything related to the live cd, I would be happy to participate. As long as decisions don't get done, I would have to continue hosting it outside this project. I continue to point users to this mailing list for discussions and continue to post updates here whenever anything related to the live cd happens. A note on the live cd, I am including libdvdcss so you might want to consider the effect of that on hosting. Rahul
Re: Fwd: [Fedora-legal-list] xBill legal opinion required
Kevin Kofler wrote: Andrea Musuruane wrote: From: Tom spot Callaway tcallawa... Well, the issue is that the game is clearly disparaging Microsoft and its marks. I'm not sure any amount of artwork replacement will overcome that. WTF, since when is parody illegal? It's even an exception to copyright and trademark law. Tom Callaway already answered that in Fedora legal list. Note that simplistic ideas around parody don't really meet up to the legal constraints around the concept. Rahul
Re: apt and smart support for RPM Fusion and Livna
Kevin Kofler wrote: Conrad Meyer wrote: apt-rpm doesn't work in current Fedora anyways. To be more precise, command-line apt-rpm is completely broken in F10 and higher, Synaptic already in F9. So if somebody cares strongly about apt, they'll have to fix apt first! Kevin Kofler Has a bug report been filed? Shouldn't be in blocked from the mirrors till this problem is fixed? Rahul
Re: Problems making LiveUSB of Omega
Rohan Dhruva wrote: Hi, I downloaded the omega-10-desktop.iso which is the Omega 10 final release. The SHA1SUM matches. I tried to use the livecd-iso-to-disk utility to make a LiveUSB out of the ISO. However, I tried it twice, and both time it fails. The first time I tried, on booting from the pen drive my laptop said Missing Operating System. The second time, the SYSLINUX prompt came, but then a message was displayed saying linux: Can't find a kernel or something of that sort. Then I got a boot: prompt, and anything I typed there said foo is not a valid kernel image. The messages may not be exact. The same pen drive worked perfectly fine with Fedora 10. Please tell me how to make a LiveUSB out of the omega ISO. I frequently use LiveUSB's to test development snapshots and never had a problem. I just tried converting Omega 10 into a LiveUSB on a new key and it worked just fine. Not sure what the problem is. Are you trying with persistence? Can you give me the exact command you are trying? Might want to use --reset-mbr Rahul
Omega 10 Release Candidate
Hi, Omega is a Linux based operating system and a Fedora remix suitable for desktop and laptop users. It is a installable Live CD for regular PC (i686 architecture) systems. It has all the features of Fedora 10 and number of additional software including multimedia players and codecs by default. You can play any multimedia content (including MP3) or commercial DVD's out of the box. Download ftp://ftp.infradead.org/pub/spins/om...desktop-rc.iso ftp://ftp.infradead.org/pub/spins/omega-10-desktop-rc.iso Kickstart files: ftp://ftp.infradead.org/pub/spins/fedora-10-live-base.ks ftp://ftp.infradead.org/pub/spins/omega-10-desktop-livecd.ks Release Notes --- ftp://ftp.infradead.org/pub/spins/RE...-Release-Notes ftp://ftp.infradead.org/pub/spins/README.Omega-10-Release-Notes Testing -- I will be announcing the general release, formally in a short while so I wanted to make sure, there aren't any last minute bugs sneaking in. If a few people could download this ISO and give me some quick feedback, it would be very much appreciated. Please focus on multimedia players since that is the major chunk of differences. From the preview release, I have made some changes in the package defaults (added openjdk and other minor utilities, remove some other packages), fixed a branding issue and workaround some SELinux denials issues with Xine and other multimedia players. Rahul
Re: Omega 10 Preview Release
Thorsten Leemhuis wrote: On 04.12.2008 14:49, Rahul Sundaram wrote: Omega is a Linux based operating system and a Fedora remix suitable for desktop and laptop users. It is a installable Live CD for regular PC (i686 architecture) systems. It has all the features of Fedora 10 and a number of additional multimedia players and codecs. You can play any multimedia (including MP3) or commercial DVD's out of the box. Kickstart file is at ftp://ftp.infradead.org/pub/spins/omega-10-desktop-livecd.ks Some *minor* comments for you consideration (maybe they can be called nitpicks, but I tend to say it worth at least mentioning them once). Noted. I found a few bugs in the compose, fixed them and the new image is just being uploaded to the usual place. I won't be changing things right now but If I do a recompose for any other reasons or for future releases, I can take care of these issues. Okay, then we basically get all three major players. How about sticking to the Fedora way and just choose one app instead of confusing the users with multiple ones for the same task? Yeah, thought of that but people have deep attachments to these different players and in some cases, one video player does not play something or plays it erratically while the other ones works fine. I run into those issues many times to the point that I always install pretty much everything. Maybe, it is just me though. More feedback would be good. Rahul
Re: Livna-release depends on fedora-release
Rex Dieter wrote: Rahul Sundaram wrote: This was essentially the same issue with rpmfusion release packages as well. Please rebuild this package and depend on system-release instead of fedora-release, so that Fedora remixes can use livna-release correctly. Thanks. I was about to go fix this, but can't find livna-release scm anywhere. It doesn't seem to be in cvs.rpmfusion.org that I can find, and svn.livna.org isn't accessible. ?? The updated spec file I gave you offlist with the fix included was extracted from the srpm. I don't know where the spec files are located. Rahul
Re: latest kernel's gspca-kmod missing
Farkas Levente wrote: any change to skype work out of box without this workaround in the near future? You can report the problem to Skype and ask them to fix it. Rahul
Re: Hopefully a new member of the team
Dejan Lekic wrote: Hello Peter, frankly I did not think they would go into the main repository, at least not yet. If Fedora guys later on decide to put it there, I would not mind, naturally. :) I like the RPMFusion idea as I used all those repositories earlier, and I want to be part of it. Afaik, there is no problem with portable.net going into the Fedora repository. RPMFusion has a policy of letting software be in the primary Fedora repository unless it has to be excluded for legal reasons. So you are better off proposing the packages there. http://fedoraproject.org/wiki/PackageMaintainers/Join If you do have legal concerns, ask in fedora-legal list http://www.redhat.com/mailman/listinfo/fedora-legal-list Rahul
Re: Status of RPM Fusion for EL
Thorsten Leemhuis wrote: And I think it makes the most sense, as the Z-Streams/the Extended Update Support (EUS) (e.g. update support for 5.1 after 5.2 is out) are only done for certain releases, only for a shorter lifespan and only if you pay extra for them iirc. Hence the bulk of users always will be on the latest release of a RHEL family (RHEL4, RHEL5). Well, that's not true. Lots of customers stick to older point releases sometimes because they need to do a large amount of inhouse testing before deploying new updates (complex interactions between custom build software etc) and sometimes because ISV's certify against point releases and so on. However EPEL/ RPMFusion needs to weight the benefit of supporting such customers. Atleast, for a while, it probably is a good idea not to spread our resources too thin. Rahul
Re: Wiki Theme
Andrea Musuruane wrote: Hi, I've just stumbled upon CentOS Moin Moin theme. I like very much and I think that is more attractive than the one we currently have. http://wiki.centos.org/ArtWork/WikiDesign I wonder what you think about. If you like it too, I'd like to try to adapt it to RPM Fusion even though I'm not fond of Moin Moin. Help and suggestions are always welcome Although the scalability issue with Moin in Fedora are unlikely to affect RPMFusion yet, having a different markup from the mediawiki deployment currently in Fedora makes it harder to share content and infrastructure. Using a permissive license (something like 2-clause BSD) along with mediawiki, would mean that you can just copy and use the Fedora theme in this site as well. Rahul
Re: totem/gstreamer/ffmpeg issues
Ralf Corsepius wrote: Hi, I don't know what has changed (and whose fault it might be), but today's rpmfusion/rawhide update broke totem video play back badly for me on an F10/rawhide + rpmfusion-free + rpmfusion-nonfree system. E.g. I am observing * selinux alerts related toten-video-thumbnailer and totem itself having selinux problems with libavformat This one is fixed now at https://www.redhat.com/archives/fedora-selinux-list/2008-November/msg5.html As I noted in http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/001769.html we need more packagers to run in SELinux enforcing or atleast permissive mode to check and fix policy denial before pushing package updates. However the complete lack of replies, suggests disinterest. Rahul
Re: for users...
Andrea Musuruane wrote:
2008/11/1 Thorsten Leemhuis [EMAIL PROTECTED]:
P.S.: Who will actually send out the announcement and where do we send it
besides fedora-announce-list and fedora{-devel,}-list?
I'd say the more the better
http://fedoraproject.org/wiki/Marketing/SpreadingNews
Rahul
Testing with SELinux enabled
Hi, While running Fedora with rpmfusion packages enabled, I have been running into a series of SELinux policy issues which all result from changes in policy in rawhide and basically fall into the same category. It would be useful if rpmfusion packagers run with SELinux enabled or atleast in permissive mode and report these issues to http://www.redhat.com/mailman/listinfo/fedora-selinux-list Dan Walsh is usually very quick to resolve reported issues either in Bugzilla or to this mailing list. Even if you don't personally use SELinux, it is still enabled by default for Fedora (and RHEL which rpmfusion supports) and it would be good to give them a smoother experience out of the box. Thanks. Rahul
Re: Hosting the live cd
Thorsten Leemhuis wrote: And exactly that I in went ahead with a name I picked IMHO is totally unacceptable in a *community* project I can't force people to give me feedback. I did ask for suggestions before picking one. I did post the kickstart file as well for people to give input on the content and got zero feedback. Since you seem to be in agreement for the general idea of letting people doing the work making the decisions, in this case, that would be me. I don't really see the name choices as a big deal. I got work done and there was many things fixed for the benefit of everybody. Again, feel free to suggest alternative names (if there are strong opinions on that) or any content changes. I have carefully considered all the comments on those. If there is general consensus on anything such as not making even small configuration changes, I have went along with that. Which of the two wins depends on the answers to question that were in the mail you replied to. But you for some reasons avoided to answer them. So here it is again: One other important thing that was not discussed properly iirc: Do we want one or two official spins? I'd say (at least in the long term) two: one with only free packages and one that also includes nonfree packages The reason why I picked a different name (I have mentioned this in the list before) is because longer names as RPMFusion - free repository spin is unlikely to catch on. You really need something short and unique. I skipped the other question before because I didn't realize this question was directed at me and assumed you were asking for general opinion from others. I am personally uninterested in working on even more variants. It takes a lot of time to compose and test packages especially when it has to be done against a moving target like rawhide especially since I am following the Fedora release schedule aggressively - beta, snapshots et all. More importantly, the only common things people want from the non-free repository would be kernel drivers which are hardware specific and cannot be bundled together or installed by default (no package selection possible in live cd) without running into legal as well as technical issues. Distributions which tried to do that in the past have backed off for good reasons. http://en.wikipedia.org/wiki/Kororaa#Kororaa_XGL_Live_CD_and_the_GPL http://news.softpedia.com/news/Ubuntu-7-04-Will-Not-Include-Proprietary-Video-Drivers-47055.shtml (The second article is about default configuration. Not what is available in the repository) As I mentioned here before, the right solution IMO would be to use something like Jockey (https://launchpad.net/jockey). It is a better because it is opt-in and generic, lets the user pick and avoids the issues mentioned above. If it works well, it should be part of the rpmfusion repository and installed by default in Omega potentially. Is anyone willing to look into that? Rahul
Re: Hosting the live cd
KH KH wrote: What I don't like much with Omega, hosted here is that:RPMFusion is defined as an additional repository for Fedora.This means RPMFusion is not another distribution based on Fedora. As a RPMFusion contributor. I still want to think I'm contributing to Fedora via an additional repository, not a derived distro. If you are not interested in Omega, you can continue to contribute to just RPMFusion packaging. Omega would just be a sub project that you are not involved in, which is just fine. A rpmfusion spin was discussed in this list before and my efforts are directly in response to that. Although, if the consensus now is that you don't want a live cd at all, I can host it elsewhere. I would like to hear other's opinions on this. Knowing that, the only official iso from RPMFusion would be (IMO) an additional set of packages composed as a local repository aimed for post installation. (which remains untested/unworked until then). That would be the solution I would see to get pushed. These two different solutions cannot be done in parallel. There are different use cases for both. Why I see Omega as uneeded is that: When using an official Fedora LiveCD iso, you can still transfert it on a USB disk/key and activate persistence. That way you can add some packages from rpmfusion suitable for codec etc. But everything else fall under a customization process where there are million of possibilities. There are many reasons where a distributable live cd (especially combined with regular updated revisions) could be more convenient. That is validated by the amount of downloads and positive feedback I have been getting overall. Not everybody has the bandwidth, expertise or interest to do additional customizations. Even if they do, this can still be a better starting point for them. At this time Omega doesn't sort out why some packages are choosen and not others. From the discussions in this list, the consensus was that only packages from the free repository should be included. I posted a kickstart file with the typical set of packages that a end user would install and then proceeded to create a image based on that. If there is a different set of packages that needs to be installed, that is very open for discussions. I have been asking for feedback often. In my mind, I see Omega as a demonstration purpose and not a everyday life distro. that's why I see the distribution of the resulting ISO as an optional thing (but indeed, sometime needed, mostly for beginner). So, maybe the iso can be made available via bittorrent eventually. Without the resulting ISO being widely distributed and tested, we wouldn't know whether it worked or not. As I started using the tools to generate the Live CD, I have run into several issues which are being resolved iteratively. The result is useful for other derivative distributions that are going to consume bits from Fedora as well as RPMFusion. And I would like to see a page somewhere that describe the Omega LiveCD (goals, and howto re-create). Something like http://omega.rpmfusion.org/ or else ... Sure. Rahul
Re: Omega - 2008-10-08 build
KH KH wrote: There is one well known problem with vlc and selinux It only appears with F10 x86 and consist in a selinux denial for one mmx version of its plugin. (one libmpeg2 selinux problem has been (re)-fixed recently). I found a recent similar issue with mplayer. It is being discussed at https://www.redhat.com/archives/fedora-selinux-list/2008-October/msg00034.html If you have problems, I would suggesting posting there. Rahul
Omega - 2008-10-08 build
Hi, The latest rawhide snapshot + rpmfusion repos. This includes generic-logos and generic-release (since rpmfusion release packages now depends on system-release), fixes a number of issues: * Default user is simply liveuser instead of fedora * No more About Fedora menu item * SELinux is also enabled and in enforcing mode. A recent review mentions some issues with playing multimedia. Details at http://reddevil62-techhead.blogspot.com/2008/10/omega-10-live-cd-beta-fedora-with-added.html Is anyone interested in testing it more and sending some feedback? --- Download: ftp://ftp.infradead.org/pub/spins/omega-rawhide-20081008.iso Verify: # sha1sum omega-rawhide-20081008.iso 94ebab73f7076835fa846ec3ae20da6b80ead727 omega-rawhide-20081008.iso --- Rahul
Hosting the live cd
Hi, I would like to start hosting omega as part of rpmfusion infrastructure. A subdomain like omega.rpmfusion.org would be a good space. Thoughts? Anyone testing the rawhide snapshots? Rahul
Re: Hosting the live cd
Xavier Lamien wrote: I really appreciate the effort and the work done for this spin but I'd really see a _clear_ discussion about that project before start host anything (including the name of the future Official RPMFusion spin). We have already been discussing the details including the name for a while in this list. I am not sure who is equipped to make a final decision but do that and let me know. Rahul
Omega - Sudo for first user?
Hi, If I stuck this portion into the fedora-live initscript, it would enable sudo for the first user entered during firstboot. Does this seem like a sensible thing to do? Does anyone have the details handy on modifying consolehelper as well? - # check for the first user and add it to user wheel and then to sudoers USER=$( grep 500 /etc/passwd | cut -d: -f1 ) GROUPS=$( groups $USER ) if ! groups $USER | grep -q wheel ; then usermod -G wheel $USER echo %wheelALL=(ALL) ALL /etc/sudoers fi EOF Rahul
Re: Omega - Sudo for first user?
Neal Becker wrote: I prefer not putting user in wheel, but just putting: nbecker ALL=(ALL) NOPASSWD: ALL This is a possibility as well but If I have to make a choice, I would want to know not just what you prefer but also why. Rahul
Re: Omega - Sudo for first user?
Thorsten Leemhuis wrote: On 01.10.2008 16:43, Rahul Sundaram wrote: If I stuck this portion into the fedora-live initscript, it would enable sudo for the first user entered during firstboot. Does this seem like a sensible thing to do? Does anyone have the details handy on modifying consolehelper as well? The official RPM Fusion spin should IMHO be a Fedora + add-on packages and nothing else. Yes, we could do fancy things like enabling sudo by default and hundred other things where Fedora sucks. But that's somethings that is IMHO just as bad as replacing packages from Fedora (which we don't do) I kind of see your point but I think there is room for minor improvements such as these. There is a difference between replacing packages and doing these simple configuration changes. Replacement packages (often) break your upgrade experience. I would like to do a compose with sudo enabled like this and get feedback from more users. It might help/push Fedora to do it as well soon. Rahul
Re: Omega - Sudo for first user?
Jeroen van Meeuwen wrote: Rahul Sundaram wrote: Thorsten Leemhuis wrote: On 01.10.2008 16:43, Rahul Sundaram wrote: If I stuck this portion into the fedora-live initscript, it would enable sudo for the first user entered during firstboot. Does this seem like a sensible thing to do? Does anyone have the details handy on modifying consolehelper as well? The official RPM Fusion spin should IMHO be a Fedora + add-on packages and nothing else. Yes, we could do fancy things like enabling sudo by default and hundred other things where Fedora sucks. But that's somethings that is IMHO just as bad as replacing packages from Fedora (which we don't do) I kind of see your point but I think there is room for minor improvements such as these. I think that if this improvement is worth the trouble, it should go into the firstboot application (upstream), even if only as a configurable firstboot option. Sure, there is no disagreement on the ideal path. There has been RFE's (sometimes with patches) for similar things a long time. The traditional problem is a very diffused userbase where anything except status quo tends to meet with opposition. The recent change to add sbin to path being a recent example where somebody decides to go ahead and do it anyway. Hopefully that happens with sudo as well. Meanwhile I will do two different composes. One with configuration changes and another without to gather feedback from users. Rahul
Omega - latest rawhide + rpmfusion devel repos
Hi, I have done a new compose of the live cd with rpmfusion development repositories - both free and non-free enabled. Only a select few packages from the free repo is installed by default however. No additional configuration changes. Do test it and let me know what you think. The only package in the compose that we lost during the transition from livna to rpmfusion is libdvdcss. Not sure of the status of that. is it going to be made available? ftp://ftp.infradead.org/pub/spins/omega-rawhide-20081002.iso sha1sum omega-rawhide-20081002.iso c583566ad2b6d50a62d9a9c53fedb89ecf359e04 omega-rawhide-20081002.iso Known Bugs And Issues: * A cosmetic issue of missing install to hard disk icon option which has been fixed in rawhide. Subsequent composes shouldn't have this issue https://bugzilla.redhat.com/show_bug.cgi?id=464756. * About Fedora is hardcoded as a menu option under System' menu in GNOME. Suggestions on how to fix that? * Still using Fedora as the default user name and for some scripts as well. Potential solution is for the base ks files to adopt a more generic name https://www.redhat.com/archives/fedora-livecd-list/2008-October/msg2.html --- Rahul
Re: How to test RPM Fusion
Thorsten Leemhuis wrote: Hence my questions maybe might have been answered already, but - where does the name omeaga come from? http://en.wikipedia.org/wiki/Omega The word literally means great O Omega (the last letter of the Greek alphabet) is often used to denote the last, the end, or the ultimate limit of a set. http://www.quinapalus.com/gr0.1.html - will omega become the official RPM Fusion spin or just serve as base for one? I would like for it to be considered the official RPM Fusion spin. I posted the kickstart file for feedback before but everybody seemed busy with other things at that point so I just went ahead and got the ball rolling. The current version is at ftp://ftp.infradead.org/pub/spins/ I would like the name of the spin to be different from the repository just to identify what we are talking about quickly. - seems there are other people/groups/projects that have spins based on livna already; have any attempts been made to get all of them together at one table within the RPM Fusion project to bundle efforts? If you let me know which groups, I can get in touch with them. I am sure we can work on common issues such as https://bugzilla.redhat.com/show_bug.cgi?id=464756 Please don't take those questions as offense -- I like the idea with the spin. I just want to understand the long term goals and plans better. No offence taken. Rahul
Re: How to test RPM Fusion
Thorsten Leemhuis wrote: Add-on: We have no fully configured bug tracker yet for RPM Fusion. As such: please do *not* further distribute or link to above mail in Blogs, Forums or other Mailing lists for now. We'll announce a official testing phase for RPM Fusion once we have the important bits in place. tia! Is it useful to do a new compose of the live cd by replacing Livna development with RPMFusion development repository? I got precious little feedback but a lot of downloads on the last compose so I would like to hear more opinions. Rahul
Re: Omega 10 Beta released
مؤيد السعدي wrote: BTW: is it [omega] based on F10 or F9 Fedora 10. As the announcement says, it is roughly similar to Fedora 10 Beta. BTW: some people suggested lzma which will give us about 60MB RPM now accepts LZMA payloads as well as sources. Squashfs + LZMA patches would save some additional space if you want to go that route. Rahul
Omega 10 Beta released
We proudly present to you, dear users with Omega. Omega is a Linux based operating system suitable for desktop and laptop users. It is a Live CD for regular PC (i686 architecture) systems that includes a variety of free and open source software from Fedora and Livna repository. You can try it out on a computer or install it to the hard disk. This is a BETA release with a snapshot of the latest bleeding edge development packages for early testing and feedback. It is roughly similar to the upcoming Fedora 10 Beta release. Highlights -- * GNOME 2.23 Desktop Environment * Firefox 3.0 Web Browser * A variety of media players including vlc, mplayer and xine * Extra Gstreamer and xine multimedia codecs Get Omega - ftp://ftp.infradead.org/pub/spins/omega-desktop-livecd-10-beta.iso You can verify this ISO image using SHA1SUM available at ftp://ftp.infradead.org/pub/spins/SHA1SUM Participate If you have any feedback or wish to help, do let me know. Rahul
Re: RPM Fusion (EL - free) Package Build Report 2008-09-23
Xavier Bachelot wrote: [EMAIL PROTECTED] wrote: Packages built and released for RPM Fusion (EL - free) testing/5: 4 ... NEW xine-lib-extras-freeworld-1.1.15-2.el5 : Non-free extra codecs for the Xine library Just a note, non-free in the above summary looks wrong while the package name uses freeworld and the sub-repo is free Looks like the summary was not updated when the package was renamed. Confusion between Free but patent encumbered and proprietary/non-free software is harmful. Rahul
Re: RPM Fusion (EL - free) Package Build Report 2008-09-23
Rex Dieter wrote: Excellent points. I'll change that asap. Suggestions for new language for summary/description welcome. Summary: Extra codecs for Xine multimedia library Description: Extra codecs for Xine multimedia library. These are free and open source but left out of the official Fedora repository due to potential patent issues. Once installed, applications using the xine library will automatically recognize and use these additional codecs. Rahul
Re: rpmfusion based spin
Andreas Thienemann wrote: I'm a bit concerned that this will result in a lot of technically illiterate users installung our fedora because it just works!!!111!! and then come crying back to usthat it doesn't look like fedora, that we broke something or whatever else they can come up with. In the end we either ignore this resulting in a lot of frustration vented on digg or ./. Or alternatively, we spent lots of our limited time helping these guys. The artwork for the most part is going to be the same if we use generic-logos. Rest of the packages from Fedora are not modified and will work exactly the same. You only would have to deal with bugs from RPMFusion specific packages which you would have to do anyway. Ohhh right, the .*Kit madness. Does PackageKit works nowadays? Yes, it does and it is getting adopted by others like Opensuse, Mandriva, Ubuntu etc. If you have a actual problem, file a bug report. Hey, don't knock it. The time setting up a PXE server at home (takes what? 15min for the uninitiated?) is well spent... Not everybody has network access and spare systems. The audience for live cd's are entirely different from the end users who have the knowledge, inclination and infrastructure to setup pxeboot servers. Rahul
Re: rpmfusion based spin
Ralf Corsepius wrote: Define works. Works for me and I am using it on a regular basis for the usual tasks. I have bugs filed for some instances where it does not. So far, I am having a lot of problems with PackageKit as well as NetworkManager, ... Make sure you have the latest updates and file bug reports otherwise. Rahul
Re: rpmfusion based spin
Ralf Corsepius wrote: On Fri, 2008-08-29 at 10:00 +0530, Rahul Sundaram wrote: Ralf Corsepius wrote: Define works. Works for me and I am using it on a regular basis for the usual tasks. Single user desktop, I suppose? Yes and otherwise as well. Make sure you have the latest updates and file bug reports otherwise. I am using vanilla FC9 Without the updates? There was a number of issues fixed in the later updates. Anyway, if you aren't running it at all, no point discussing it. Rahul
Re: rpmfusion based spin
KH KH wrote: True. It is easier than I thought.. At least we can first works at the documentation step providing a .ks and a replacement package for the fedora-logos (outside of the RPMFusion repository?) You can only build a rpmfusion-logos package after you have enough artwork to do the rebranding. Otherwise we have to use generic-logos. Rahul
Re: rpmfusion based spin
Felix Kaechele wrote: If necessary I could try and help out with some artwork That would be great. Take a look at http://fedoraproject.org/wiki/Artwork/ThemingOverview If you have questions, post in fedora-art list or login to #fedora-art in freenode. Rahul
RPMfusion spin - kickstart file
Hi, I have attached the ks file to wiki page http://rpmfusion.org/spin This is a initial try based on livna repo. If anyone is willing to test it, feedback is welcome # yum install livecd-tools Drop this ks file into /usr/share/livecd-tools. Login as root. Customize the url to point to a local mirror if available. Set SELinux to permissive mode and run the following command. # mkdir /var/tmp/cache # livecd-creator --config=livecd-fedora-9-desktop-rpmfusion.ks --fslabel=rpmfusion-spin --cache=/var/tmp/cache/ Rahul # rpmfusion spin - Maintained by Rahul Sundaram [EMAIL PROTECTED] %include livecd-fedora-9-base-desktop.ks repo --name=development --baseurl=http://livna-dl.reloumirrors.net/fedora/9/i386/ %packages [EMAIL PROTECTED] @graphical-internet @graphics @sound-and-video @gnome-desktop nss-mdns NetworkManager-vpnc NetworkManager-openvpn # we don't include @office so that we don't get OOo. but some nice bits abiword gnumeric #planner #inkscape # add livna packages livna-release gstreamer-plugins-ugly gstreamer-ffmpeg gstreamer-plugins-bad libdvdcss xine gxine xine-lib-extras-nonfree gnome-mplayer vlc -totem-mozplugin gecko-mediaplayer -fedora-logos generic-logos # comment out language packs for now [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] # # The following locales have less than 50% translation coverage for the core # GNOME stack, as found at http://l10n.gnome.org/languages/ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] # These fonts are only used in the commented-out locales above -lklug-fonts -abyssinica-fonts -jomolhari-fonts # avoid weird case where we pull in more festival stuff than we need festival festvox-slt-arctic-hts # dictionaries are big -aspell-* -hunspell-* -man-pages-* -scim-tables-* -wqy-bitmap-fonts -dejavu-fonts-experimental # more fun with space saving -scim-lang-chinese -scim-python* scim-chewing scim-pinyin # save some space -gnome-user-docs -gimp-help -evolution-help -autofs -nss_db -vino -dasher -evince-dvi -evince-djvu # not needed for gnome -acpid # temporary - drags in many deps -ekiga -tomboy -f-spot %end %post sed -i -e 's/Fedora/RPMFusion/g' /etc/fedora-release /etc/issue cat /etc/rc.d/init.d/fedora-live EOF # disable screensaver locking gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-screensaver/lock_enabled false /dev/null # set up timed auto-login for after 60 seconds cat /etc/gdm/custom.conf FOE [daemon] TimedLoginEnable=true TimedLogin=fedora TimedLoginDelay=60 FOE EOF %end
Re: rpmfusion based spin
Stewart Adam wrote: That sounds fine - I think maybe a DVD spin with all the rpmfusion packages would be useful as well for offline installs. My experience (with xfce, games and other locale specific spins) is limited to the Live media spins. I haven't looked into Pungi much. If anyone else wants to help by maintaining a dvd spin, I would appreciate that. This is thinking way ahead, but while we're on the topic of spins do you think it's fair to say we should respin once every 2-3 months? That means we could have (roughly) the gold release + 2 respins along the way per release of Fedora. Until DRPM support gets into the build infra, I think this would be a good thing to do since another really annoying thing for users is having to wait 4 hours for a large DVD iso to download, then after installing they find they need some 150 updates! Yeah, we should be able to generate images very easily. Testing can be a problem since updates have before introduced regressions that affect the way the installation works (or does not for that matter). I hope others can help with that. Just to be on the safe(r?) legal side, maybe we should preinstall packages from only rpmfusion-free but have the rpmfusion-nonfree repo enabled. This is what I am going with as of now. freefusion sounds good, but I think the name might be a bit misleading if we enable or preinstall nonfree packages, or users might ask about a nonfreefusion spin. I looked a while back and realized freefusion.org is unavailable as well. Who wants to name the baby? Rahul
Re: rpmfusion based spin
KH KH wrote: I don't know if Thorsten ever mention such spin but having both rpmfusion and fedora on the same media is a very hard legal issue. Actually that's even not possible at all without removing the name Fedora from such spin. (meaning removing artworks and some others packages i don't remember) As Jeroen van Meeuwen, this is not a big deal technically as you make it out to be. Sure, we have to make some changes but generic-logos makes it easy to do the rebranding. If there are other issues, we will deal with them as we come across them. Part of my interest in this effort is as a test case for the tools and fleshing out new trademark guidelines in progress for Fedora. We can't use Fedora infrastructure or call the spin Fedora but that is already well known. Rahul
