Rawhide nodebug and the 3.12 kernel
We have a slight issue with the 3.12 kernel timing in that it is too late to push it into Fedora 20, but too far away from the Fedora 20 release to just ignore the 3.13 development cycle until we can push 3.12. As a result, we will be tracking 3.12 and stable updates for it in the rawhide-nodebug repository. This gives us a chance to keep it built and tested on all primary architectures, and make sure we are in good shape to push 3.12 out as an update as soon as possible. Once 3.12 can be pushed to releases, the rawhide-nodebug repository will return to doing non debug builds of rawhide, tracking Linus' tree upstream. I will let everyone know that is happening through the same channels with a couple of days notice. More information on the rawhide-nodebug repository can be found at: http://fedoraproject.org/wiki/RawhideKernelNodebug Thanks, Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 04, 2013 at 11:27:10PM +0100, Martin Sourada wrote: On Mon, 4 Feb 2013 16:34:18 +0100 Jan Kratochvil wrote: Still I believe it is probably true as I doubt Fedora QA tests compatibility with old hosts. Fedora QA AFAIK tests on their own hardware only + virtual machines. I don't know about kernel upstream QA/devs though. I'm running F18 on a 32bit machine as well. Actually, I am installing a 32bit F18 on my laptop today. Though to be honest, I haven't run 32bit outsideo of a guest since before FC1 GA. I have noticed a large number of kernel bugs that seem to trigger on 32bit only. I am guessing this is partly due to PAE being used much more than it used to be, combined with the fact that very few kernel developers actually run 32bit hardware. That said, I plan to investigate kernel issues with it, and will not be doing full QA checks accross software I do not use in day to day desktop use. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Help figure out the debug slowness
As mentioned in the FUDCon kernel talk, we are trying to figure out exactly what causes the massive slowdown for some people with debug kernels. At this point, debug is completely off in the rawhide kernel. Every update this week will turn on more debug options until we find out which one is causing the slowdown. For this to work, we need people testing rawhide proper (not rawhide-nodebug). So please, if you can update daily and give us feedback when you hit a wall, we would really appreciate it. Feedback should be sent to ker...@lists.fedoraproject.org Thanks, Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Announcing the rawhide kernel nodebug repository
It has been discussed in the past that we should have a repository of the rawhide kernels with debug turned off to encourage more users to run the latest upstream snapshots. That repository now exists. You can enable it by dropping http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo into /etc/yum.repos.d and doing a yum update. This will contain the (almost) daily rawhide updates built with debug turned off. Bugs against this kernel should be filed in bugzilla against the rawhide kernel. Any questions or comments about the repository itself should be sent to the ker...@lists.fedoraproject.org list. Thanks, Justin ___ kernel mailing list ker...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing the rawhide kernel nodebug repository
On Thu, Nov 08, 2012 at 07:30:53PM +0100, Pierre-Yves Chibon wrote: On Thu, 2012-11-08 at 11:02 -0600, Justin M. Forbes wrote: It has been discussed in the past that we should have a repository of the rawhide kernels with debug turned off to encourage more users to run the latest upstream snapshots. That repository now exists. You can enable it by dropping http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo into /etc/yum.repos.d and doing a yum update. This will contain the (almost) daily rawhide updates built with debug turned off. Bugs against this kernel should be filed in bugzilla against the rawhide kernel. Any questions or comments about the repository itself should be sent to the ker...@lists.fedoraproject.org list. Thanks! Could this be documenting somewhere on the wiki as well? Just so that someone can easily find it by a quick google search for 'fedora rolling kernel' or so. Indeed it is on the wiki as of this morning: https://fedoraproject.org/wiki/RawhideKernelNodebug This links directly from the kernel page as well. It has also been submitted to LWN, and appears on the planet. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Thu, Oct 18, 2012 at 11:34:00AM -0400, Josh Boyer wrote: On Thu, Oct 18, 2012 at 11:15 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote: At the moment though, all of this is just talk anyway. If something like this is to happen, someone actually has to do work. Start with an idea, discuss it, come up with a plan, find resources for that plan, and then implement. Sometimes things happen the other way around, but only when we happen to be lucky, and it often has consequences like extra ongoing work with no support. So, just talk is an important place to start. OK. So here's a more blunt response. I'm really against splitting the modules up into more subpackages, regardless of how many it is. I will not spend any time looking at how to do that. I won't spend time discussing further plans to do something I don't feel is maintainable. If you find someone willing to, great. Post patches to the kernel list and we'll review them. But I'm telling you now that it will be an uphill battle. Just to be clear on this, if someone feels it is worthwhile and wants to step up and do the work, it can't just be someone who will send patches to change the current kernel and leave. It has to be someone willing to sign up to maintain the solution in the rawhide kernel. Modules change, get added or removed, and/or have deps change pretty much every single release. 3.7 just moved the nat modules. This is why we are saying that it is much easier to do a different build of another flavor than to split out the modules into more subpackages. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
August 14th Kernel Regression Test Suite Virtual FAD
The kernel team is hosting a Virtual Fedora Activity Day to get the ball rolling faster on the kernel regression test suite and we need your help! We are looking to get new tests written, possible framework improvements, and generally make the test suite more robust. When: Tuesday August 14th Where: #fedora-kernel on freenode IRC Source: git://git.fedorahosted.org/kernel-tests.git All details are available at: https://fedoraproject.org/wiki/KernelRegressionTesting_Virtual_FAD_20120814 Thanks, Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange RPM versioning problem in qemu in Rawhide
On Tue, 2011-08-02 at 13:37 +0100, Richard W.M. Jones wrote: Below are two packages. The first one is installed, the second one is built for Koji. Yum refuses to upgrade the installed package to the second one, saying: Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: 2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64 qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed package. But I don't understand why, since it seems clear that the second package has a higher release than the first package. In any case, this appears to be a bug in the versioning of these packages, since the 0.2 part of the release string should have been changed to 0.3 when it was built. Indeed it should, though like you, I am not sure why. with the date change, the release is higher and should be a clear update. When I tried to submit the update to bodhi, I got the same thing. Though I am doing another update today. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 15 Virtualization Test Day -- Thu. April 14th
This is just a reminder that today, April 14 is Fedora Virtualization test day. Test plans and more information for the event can be found on the Fedora Project Wiki at: https://fedoraproject.org/wiki/Test_Day:2011-04-14_Virtualization IRC for the event on freenode in #fedora-test-day. Please come lend a hand, we can use as many testers as possible. If you cannot make it on Thursday, please feel free to run through test plans as you have time,the feedback is still relevant and helps to make Fedora a better platform for virtualization. Thanks, Justin ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
