Re: H.264 in Fedora 17!
On Tue, Mar 20, 2012 at 10:29 PM, Fedora Video fedoravi...@gmail.com wrote: On Tue, Mar 20, 2012 at 10:11 PM, Rahul Sundaram methe...@gmail.com wrote: Note that Debian does include a decoder by default for both MP3 and H.264 but they can only do so because they are a non-profit and the worst case scenario is a injunction until they remove the infringing parts so realistically noone is going to go after them because one cannot extract money from Debian. This is not true according to the debian social contract. http://www.debian.org/social_contract There is no mention of copyright on the page. It is not a page about copyright. Your argument is refuted most strongly by License Must Not Be Specific to Debian No Discrimination Against Persons or Groups No Discrimination Against Fields of Endeavor The document is quite clear that Debian will not distribute software which only they can distribute or which can only be distributed non-commercially. Debian distributes H.264 because it is free at least in the majority of the world which does not have a terrorist government. Put down your religion and look again. On Tue, Mar 20, 2012 at 8:46 PM, Kevin Kofler kevin.kof...@chello.at wrote: Avi אבי Alkalay אלקלעי wrote: What are the legal tools that Ubuntu uses so it can ship H.264 ? It's based on the Isle of Man, not in the USA. Ubuntu's parent company is headquartered in the UK just like RedHat is headquartered in the US. If the US's repressive laws are holding Fedora back, why not simply open a Fedora organization in the Isle of Man just like Ubuntu has done. In any case. This argument is moot. Fedora will distribute H.264 because it will be part of Firefox. Fedora will not ship h.264 support for the foreseeable future. Yes software patents are bad. No one here disagrees. Red Hat is not going to assume the risk of shipping h.264 support, just like they haven't assumed the risk of shipping MP3 support. And regardless of how effective the arguments, and how evil software patents are, that fact isn't going to change. So as fun as this thread is, lets save everyone some time and frustration and consider this thread closed. --David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fesco membership policies
On Mon, Nov 14, 2011 at 11:19 AM, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 14, 2011 at 4:15 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Something that was brought up at the last fesco meeting is that fesco membership is currently restricted to members of the packaging group. That's arguably overly restrictive - fesco is intended to be the body with technical oversight over the entire project, not merely packaging, and in that situation it seems odd to restrict membership to a subset of the people under fesco's pervue. There's a few things we can do here. We can keep the status quo. We can add new groups such as qa. Or we can open it to the entire project and just assume that the electorate will ensure that nobody inappropriate gets elected. Anyone have opinions on what we should be doing here? Sounds reasonable to me, is changes to FESCo something that needs to be approved by the Board? (adding f-a-b mailing list for clarification). This is an election policy - and traditionally those have completely been within the purview of the body to which they apply(e.g. this is all FESCo's bailiwick, no need for the Board to meddle) I would caution about imminent changes to an election policy now that the process has already begun. (e.g., nominations are now over, so changing the rules at this point about who is eligible should be carefully considered, perhaps any changes put in place could have an effective date after the current elections cycle.) ((actually - meta-note here - FESCo doesn't follow the same nomination period that the other elected bodies do, per their election policy they can nominate themselves up to 3 days before voting commences[0], so perhaps that isn't too painful to change - however, I don't think anyone has actually acted according to those guidelines in some time, perhaps that should also be considered for change by FESCo as well) --David [0] http://fedoraproject.org/wiki/FESCo_election_policy#Candidates -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 Final Release Criterion for Xen DomU
On Mon, Oct 10, 2011 at 2:09 PM, Tim Flink tfl...@redhat.com wrote: Since the beta criterion for running Fedora as a Xen guest (DomU) was removed for Fedora 16, there has been some discussion [1] [2] on test@ about whether or not we should add it back for Fedora 16 final. The old criterion read: The release must boot successfully as a virtual guest in a situation where the virtual host is running a supported Xen implementation As it stands, we are leaning towards accepting it as at least an NTH criteria for Fedora 16. This means that any Xen guest issues would become at least NTH (ability to update past code freeze, does not block release) for final. The reasons listed are: - If Fedora is not usable as a Xen guest at release time, it will not be possible to use the released install media to create Xen guests. This is not fixable through updates - Several cloud platforms (EC2, Linode etc.) use Xen in their platforms. It is possible that issues preventing the usage of Fedora as a Xen guest could affect the ability to use Fedora on those platforms. Are there any objections to moving forward with this? There seems to be no objections from the kernel maintainers who have been participating in the discussion on test@ but we wanted a bit more devel input before moving forward. Thanks, Tim [1] http://lists.fedoraproject.org/pipermail/test/2011-September/103127.html [2] http://lists.fedoraproject.org/pipermail/test/2011-October/103242.html So I'll disclaim that I am employed by Citrix - though not working on Xen/XenServer/XCP. I think that I'd have this opinion regardless of employer. I don't think we can dismiss the ability to have Fedora run on the hyerpvisor that powers (by most accounts) 80% of the public clouds. Amazon, RackSpace, Linode, Tata, IDCF, and virtually every other major compute cloud services provider is using Xen of some sort as their hypervisor. Even if that list was only Amazon AWS, I'd say it's still too large to ignore. Effectively if Fedora doesn't work on Xen it likely means it doesn't work in the cloud which hardly strikes me as a reasonable expectation. I'd personally argue that this should be more than a NTH, but my view tends to be pretty cloud-centric these days. --David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 Final Release Criterion for Xen DomU
On Mon, Oct 10, 2011 at 2:36 PM, Adam Miller maxamill...@fedoraproject.org wrote: On Mon, Oct 10, 2011 at 02:23:59PM -0400, David Nalley wrote: SNIP I don't think we can dismiss the ability to have Fedora run on the hyerpvisor that powers (by most accounts) 80% of the public clouds. Amazon, RackSpace, Linode, Tata, IDCF, and virtually every other major compute cloud services provider is using Xen of some sort as their hypervisor. Even if that list was only Amazon AWS, I'd say it's still too large to ignore. Effectively if Fedora doesn't work on Xen it likely means it doesn't work in the cloud which hardly strikes me as a reasonable expectation. I'd personally argue that this should be more than a NTH, but my view tends to be pretty cloud-centric these days. SNIP Do any of those cloud providers ever run the stock image or do they roll their own with a custom built kernel anyways? I don't have a lot of insight into this but was just curious what the landscape is looking like out there. I personally think it would be cool to have F16 boot/install as DomU out of the box, but I don't really have a dog in the fight either way... just an idle curiousity. Well at least for Amazon, what is there is what we (Fedora) push up, so it's all Fedora now, with our own kernel. I am sure Max Spevack and Justin Forbes can speak to this more intelligently than I can. I don't have visibility into a lot of the public clouds. I do get the impression that RackSpace uses their own kernel or at least has historically. For some of the others, I know they aren't rolling their own kernel, they are booting what ships, creating templates of it etc. --David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RPM] for Jokosher 0.11.5 (F15 noarch)
On Thu, Sep 15, 2011 at 5:50 PM, Manuel Escudero jmlev...@gmail.com wrote:
2011/9/15 Richard Shaw hobbes1...@gmail.com
On Thu, Sep 15, 2011 at 3:40 PM, Manuel Escudero jmlev...@gmail.com
wrote:
Hi there Fedora People!!
One of my biggest passions in life is audio editing, so when I started
using
Linux I found this friendly (yet powerful) audio editor called
Jokosher.
When I
installed Fedora 15, I realized that jokosher wasn't added to the F15
repos
and I missed it a lot, so I built an RPM using the lastest source code
the
jokosher developers have on their website:
http://www.jokosher.org/
and now I want to share it with you guys, so if someone wants to
add it to the official repos that might be awesome, the download
links are down here:
RPM -
http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm
SRC.RPM -
http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm
it's a noarch package so it can be installed in both 32 and 64 bit
systems,
Enjoy!
I pulled the SRPM and gave it a look over. Pretty good overall! I'm
not sure how much you've packaged before but I couldn't find much
wrong with it. Here's what I did find:
1. Why is the license GPLv2+ with exceptions?
2. I got rid of %clean and rm -rf %{buildroot} in %install. You
don't need those anymore.
3. I got rid of a lot of the white space in the description and fixed
one spelling error (rpmlint is your friend).
4. %exclude in %files for the Profiling.py file is not the way to go.
That works well for excluding files you want in a separate
sub-package. In this case because the file (nor the byte-compiled
versions) are needed at all, I used rm -f
%{buildroot}%{python_sitelib}/Jokosher/Profiler.py* in %install
instead.
5. I changed the release to 1 since it's from the stable source
instead of a pre-release checkout.
6. Added python2-devel as a build requirement[1].
Here's the updated SRPM:
http://hobbes1069.fedorapeople.org/jokosher/jokosher-0.11.5-1.fc15.src.rpm
So the question remains, instead of seeing if someone else will submit
it, why not submit it yourself?
Thanks,
Richard
[1] http://fedoraproject.org/wiki/Packaging:Python#BuildRequires
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hi Richard:
I'm not much of a packager, just learned the basics experimenting
with Kmess some time ago... What I did was pulling an old RPM from
F14 with pretty old Source code and then Rebuild a new package with
the lastest source code, making some very little changes to the spec file.
Humm I might be interested in pulling it into the repos if I knew how
to do that but I'm not informed about that topic very much, so Don't
Know how to submit it :S
We have a page for that:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re-introducing and package peer-review request
On Thu, Sep 15, 2011 at 7:48 PM, Al Reay alre...@gmail.com wrote: Hi everyone, I'm keen to help out with Fedora by helping to create RPM packages and do some testing when possible. I work for a television station in NZ and look after most of the RHEL systems around the place including their video on demand product. My interests include motorcycling and computer game development; I hope to release a MIT-licensed 3D game based on OGRE in a couple of years time. I'd also be interested in helping with the maintenance of packages like OGRE. The first RPM I've got is a TCP/IP load balancer. It's a really simple RPM and it should be all ready to go with a systemd service script included too. This request is kind of old as I still haven't managed to attract a proven packager to sponsor me. https://bugzilla.redhat.com/show_bug.cgi?id=679980 = the latest SRPM and SPEC file at the bottom of the comments I have so far only helped out by reviewing one other package https://bugzilla.redhat.com/show_bug.cgi?id=736717 but I've got more time now to share the love. Al, I'll pick up the review and take care of getting you sponsored. As I've asked in the package review itself, feel free to pick up a few more informal reviews. Thanks, --David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo and Board Election Questionnaires posted
Hi folks: The responses to the questionnaire are now posted: https://fedoraproject.org/wiki/F16_elections_questionnaire Responses are divided by elected body and then appear in the order the responses arrived in my inbox. Please take a moment to look over them to better prepare yourselves for the upcoming elections. I'd also like to thank the nominees who took the time to answer the questions. Cheers, David Nalley ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo TownHall Scheduling
Hi folks, Just announcing that there'll be an IRC town hall with the FESCo election candidates on Tuesday May 31st, at 1800UTC (2pm US/Eastern.) You can join #fedora-townhall-public to ask questions of the moderators, which will be posed and answered by the candidates in #fedora-townhall. More information is available here: https://fedoraproject.org/wiki/Elections#How_to_Join A summary and the irc log will be posted and linked from the wiki after the discussion, if you're unable to watch it live. Thanks, David Nalley ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo TownHall Scheduling
Hi folks, Just announcing that there'll be an IRC town hall with the FESCo election candidates on Tuesday May 31st, at 1800UTC (2pm US/Eastern.) You can join #fedora-townhall-public to ask questions of the moderators, which will be posed and answered by the candidates in #fedora-townhall. More information is available here: https://fedoraproject.org/wiki/Elections#How_to_Join A summary and the irc log will be posted and linked from the wiki after the discussion, if you're unable to watch it live. Thanks, David Nalley ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Board and FESCo elections soon - Nominations open imminently
Hi folks, Just a quick reminder that the nomination period for this election cycle will open on 7 May 2011, and will close promptly on 15 May 2011 at 23:59:59 UTC. This election cycle will fill 3 seats for the Board, and prior to the election the FPL will announce the first of two appointed seat in this cycle, with the second appointment announcement to follow after the election. For more information on nominations, and the process see: https://fedoraproject.org/wiki/Board_nominations https://fedoraproject.org/wiki/Board/Elections This cycle will also see 5 seats for the Fedora Engineering Steering Committee to be elected. For information on the nominations and elections: http://fedoraproject.org/wiki/FESCo_election_policy https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations Additionally the nomination period also serves as the time for the community to present questions to be posed of candidates. If you wish to ask questions to be answered by candidates, you can add them here: https://fedoraproject.org/wiki/F16_elections_questionnaire Candidates will have the questions posed to them and responses made available to the community. Please take time to consider yourself for one of these positions, and how you want to continue contributing to Fedora. --David Nalley ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: The new Update Acceptance Criteria are broken
On Sat, Nov 20, 2010 at 5:09 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2010-11-20 at 14:49 -0700, Kevin Fenzi wrote: On Fri, 19 Nov 2010 22:04:24 -0800 Adam Williamson awill...@redhat.com wrote: ...snip... https://fedorahosted.org/bodhi/ticket/277 hum, that wasn't well publicised, and I wasn't aware of it. (I should probably show up to more FESCo meetings...picture FESCo members going 'no, no, really, it's fine!') I'd disagree, for the reasons above. Well, my thought on it is: * As maintainer, shouldn't you be testing your updates already? Granted there's often no way you could test everything, but at least installing it and confirming the bug(s) you claim are fixed are fixed? I do. I don't believe all maintainers do. It's pretty hard to explain why updates that completely prevent the app in question from working, or even prevent the system from booting, got pushed in the past, if all maintainers actually test their updates. The advantage of doing it my way (allowing maintainers to test their own updates and file bodhi feedback, but requiring bodhi feedback) is that it leaves an audit trail: it requires the maintainer to effectively make an explicit public declaration that they tested the update and it worked, rather than just relying on the implied 'oh of course they must have tested it'. What this means is that if we come across cases where a maintainer builds an update, submits it, files bodhi feedback saying they've tested it, and it turns out to be completely broken in a way they should have caught if they tested it, we now have all the necessary evidence to take some kind of sanctions against that packager. Of course, the idea would be that we'd never have to do that, because the fact that the above is the case would be sufficient motivation to ensure that packagers really *do* test their updates properly. I think this is an interesting idea, but I'll also say I think it can be made simpler. Why not just hold package maintainers accountable period. Make them accountable to FESCo (which in theory they are to begin with) If I, as a package maintainer continuously want to 'push directly to stable' and continuously screw it up, I'd hope FESCo and my original sponsor would at least tell me I am doing it wrong. Having a +1 button click recorded in Bodhi strikes me as no more damning evidence than the fact that I committed the update and asked for it to be pushed to stable. (whether I wait 7 days, or push it immediately). I am curious to know a few things? How many updates submitted to bodhi since the policy has been in place? How many updates received any feedback? How many updates received only neutral or negative feedback? How many updates had an overall negative score. (assuming this is the number of 'problems' we can confidently confirm we caught - though more possibly exist) How many updates received no feedback - and of that group - how long were they queued up for in updates-testing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changes in FAmSCo and why it matters, or how to get stuff.
As you may know, FAmSCo among other things, is responsible for handling a portion of Fedora's discretionary budget.[0],[1]. We typically run under-budget, sometimes by a relatively large amount. FAmSCo recognizes that leaving money on the table every quarter is effectively a lost opportunity. There's also been talk recently of FAmSCo's role changing a bit to deal with more of Fedora's discretionary budget[2],[3], But enough background, my purpose in this message is to let you know that there are resources available to help you 'Get Stuff Done.' If there's something that helps your efforts in Fedora, be that attending a conference like LISA, Guadec, Akademy, or Pycon, or specific pieces of hardware to accomplish something, we want to help make that happen. FAmSCo is actively going to be looking for opportunities to help contributors, but honestly, Fedora's scope and contributor base is so large that we might never come across many of those opportunities without your help. So how do you get access to these resources? It's relatively easy - you can speak to a FAmSCo member, or preferably, create a ticket in FAmSCo's trac instance[4]. You may also want to review the reimbursement guidelines[5] If you have any questions, please don't hesitate to ask me or any other FAmSCo member. Thanks, David Nalley on behalf of FAmSCo [0] http://fedoraproject.org/wiki/FAmSCo_budget [1] http://fedoraproject.org/wiki/Accounting [2] http://lists.fedoraproject.org/pipermail/advisory-board/2010-August/009047.html [3] http://lists.fedoraproject.org/pipermail/famsco/2010-November/000402.html [4] https://fedorahosted.org/famsco/ [5] https://fedoraproject.org/wiki/Reimbursements -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urgent testing call: F13 kernel-2.6.33.1-24.fc13
On Tue, Apr 6, 2010 at 5:23 PM, Adam Williamson awill...@redhat.com wrote: Hi, everyone. We're looking at pulling kernel-2.6.33.1-24.fc13 into Fedora 13 Beta, quite late, because current Beta candidate builds include kernel-2.6.33.1-19.fc13 which is known to include a severe bug that breaks boot on systems with Broadcom wired ethernet adapters supported by the b44 module. However, -24 has other changes from -19, including to the nouveau (NVIDIA graphics) and iwlwifi (Intel wifi) drivers. We really need as many people as possible to test kernel -24, which you can get at http://koji.fedoraproject.org/koji/buildinfo?buildID=164598 , and confirm that it works okay on your systems. To install it, use 'rpm -ivh' for the kernel and -devel packages. If you have kernel-headers installed, 'rpm -Uvh' that first. Then reboot to the kernel and check that it boots up okay. Please reply to this thread with your results. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net Works fine on my X60 with: 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Board efforts: scope, concept, and permission?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 2, 2010 at 11:45 AM, Mike McGrath wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10) iEYEARECAAYFAktoWG8ACgkQkZOYj+cNI1d6MwCeOBegidrasLG6OgROhPdR1sRd MtUAnjMVImF7vKuZLX9Oi78Rvc+gDUo0 =5y4r -END PGP SIGNATURE- snip And to answer your question about what isnt' broken. I suggest you look at our http://fedoraproject.org/wiki/Statistics page. We've only seen growth in 2 of our last 6 releases. Think about that. Is that how we measure success?? I am not suggesting it should or shouldn't be, but what is the measure of success for Fedora? I'd likely argue that's probably about as varied as the goals of contributors. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
