From notting at redhat.com Thu Nov 1 18:56:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Nov 2007 14:56:49 -0400 Subject: Fedora Core 6 EOL, new branch restrictions Message-ID: <20071101185649.GB30240@nostromo.devel.redhat.com> As stated: https://www.redhat.com/archives/fedora-announce-list/2007-November/msg00000.html Fedora Core 6 will EOL on Friday, December 7. After this time, no more updates will be accepted. Note that after the release of Fedora 8 (scheduled for Thursday, November 8), new Fedora 6 branches will no longer be created for packages. Bill From jkeating at redhat.com Thu Nov 8 18:41:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Nov 2007 13:41:19 -0500 Subject: After Fedora 8 comes Fedora 9! Message-ID: <20071108134119.4653a86b@redhat.com> The development cycle of Fedora 9 will begin in earnest tomorrow. This will mark the first attempt at composing Rawhide with package builds that target Fedora 9. There is quite a number of them built up already, over 800. This will be a bumpy ride at first as we start to see where all these builds gets us. In the next couple of weeks we the project will work on setting a schedule for Fedora 9, start reviewing proposed Features, and come up with an overall idea of what we'd like to accomplish this time around. For those of you that were early adopters of Fedora 8 and joined the Rawhide bandwagon, but want to get off at the Fedora 8 stop, I suggest that you ensure your 'development' yum repo is disabled. For those of you that wish to continue to enjoy Rawhide, I suggest you ensure that your 'fedora', and any updates repos are disabled, and make sure that your development repo remains enabled. During the development of Fedora 8 we experimented with a few things to help users and developers of Fedora have a smooth ride through the development cycle. Those experiments have worked out pretty well and have been incorporated into the overall development strategy, as oulined here: http://fedoraproject.org/wiki/ReleaseEngineering/Overview As we look forward to Fedora 9 we hope to make the experience even more enjoyable and at the same time even more beneficial to all involved. I welcome suggestions and discussion on how to improve things, which is always a constant goal of mine. So lets all sit back, relax, and enjoy a day of rest for Fedora 8. Tomorrow it starts up all over again! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lmacken at redhat.com Tue Nov 13 04:49:52 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 12 Nov 2007 23:49:52 -0500 Subject: bodhi-client Message-ID: <20071113044952.GV11043@crow.myhome.westell.com> The bodhi-client package should be making its way to an updates-testing repository near you! (and a newer version is already queued up for tomorrow). Not only does this command-line tool give you easier access to bodhi, but also provides some new features to help people get more involved with testing updates and providing useful feedback. I wrote up some documentation on various usage examples of the tool, which can be found on the wiki[0]. I also submitted a Makefile.common patch[1] that, once applied, will allow you to run `make update` from your package branch. This will drop you into a new update template, and will then submit your update straight to bodhi. Some noteworthy features in the bodhi-client, aside from the normal bodhi functionality: ? Ability to view all updates-testing packages that you currently have installed on your local machine, that you *could* be testing and providing useful feedback for: ? bodhi --testable ? Ability to view your update candidates (this is a fairly expensive operation -- please use sparingly): ? bodhi --candidates I also upgraded our production bodhi instance today, which pulled in a ton of bugfixes and some new features, such as: ? Updates by default will now get submitted to into testing. This can easily be modified when using the web form, the bodhi client, and `make update`. ? Thanks to the new security bug tracking policy[2], we're now tracking CVEs using Bugzilla, thus bodhi no longer will ask you for CVE IDs. The less information that the developer has to type, the better. Read the policy for more details. Bodhi is not yet 100% compliant to the proposed changes, as it does not know about parent/tracking bugs, but should be soon. ? If you try and submit an update that is older than something already pending/testing, you will be prompted with a dialog that will give you the ability to instantly obsolete those updates. As always, patches/questions/criticisms/comments are welcome. You can file tickets in the usual place[3]. Happy hacking, luke [0]: https://hosted.fedoraproject.org/projects/bodhi/wiki/CLI [1]: http://lmacken.fedorapeople.org/patches/Makefile.common-bodhi.patch [2]: http://fedoraproject.org/wiki/Security/TrackingBugs [3]: https://hosted.fedoraproject.org/projects/bodhi/newticket From poelstra at redhat.com Sat Nov 17 04:01:27 2007 From: poelstra at redhat.com (John Poelstra) Date: Fri, 16 Nov 2007 20:01:27 -0800 Subject: Fedora 9 Bug Day-v0.1 :: Monday, November 19, 2007 Message-ID: <473E6797.9050208@redhat.com> Greetings, This is an invitation to all community members to join us for our first "Bug Day" of the Fedora 9 release cycle! Fedora 8 is hardly a week old and as is always the case--people around the world are reporting problems they encounter to make Fedora better. Help make Fedora 9 a great release by joining us to review the outstanding bugs against Fedora. We will meet on freenode in the #fedora-qa channel from 0:00 UTC to 23:59 UTC, on Monday, November 19, 2007. Join as for as little or as much as you can in your local timezone. Lurkers are always welcome too. What happens at a "Bug Day" you ask? We review and triage as many open bugs as we can by helping them along to their next state--ideally fixed or closed :-) You don't have to be a Fedora guru or hold a PhD in reading stack traces--in most cases you do not even have to run a program or attempt to reproduce the reported issue. It is nice if you can, however often the most value able service you can provide is your eyes--reading the contents of a bug to see if enough information is present for the package owner (developer) to take the next step. Sometimes that means requesting that the reporter attempt to reproduce the bug against the latest version or provide more information. By doing this you can help package owners focus their time on the bugs that matter. And if you are not sure what to do we can help you on IRC. Some helpful links from the wiki for getting started are: http://fedoraproject.org/wiki/TriagingGuidelines http://fedoraproject.org/wiki/BugZappers http://fedoraproject.org/wiki/KernelBugTriage This is the first time I've organized a bug day (proposed two days ago at Wednesday's QA meeting) and I don't believe we have had one in a while. It is possible some of the wiki pages about triaging bugs need updating or clarifying so if we use part of Monday to work on that it will be time well spent as it better prepares us for future bug days. And don't forget you don't have to wait for an official Bug Day to triage bugs--they don't mind being triaged by anyone at any time :) See you Monday, John aka "poelcat" From wtogami at redhat.com Mon Nov 19 23:24:37 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Nov 2007 18:24:37 -0500 Subject: Fedora Orphaned Package Removal: November 29th 2007 Message-ID: <47421B35.4080006@redhat.com> Fedora Engineering Steering Committee is considering removal of packages from rawhide who have been without owners since prior to Fedora 8 sometime after the next FESCO meeting on November 29th. The Fedora Project routinely removes unmaintained packages from future distributions in order to responsibly scale the growth of maintenance burden with developer resources available within the project. http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt Packages listed on this page are scheduled for removal unless an existing Fedora maintainer claims ownership. http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt A Fedora package developer may use their Fedora Account in PackageDB to claim ownership of an orphaned package. Removal of an orphaned package entails "blocking" it in the buildsystem so it does not appear in the rawhide repository, and files in CVS of the "devel" branch being replaced with an empty "dead.package" file. At a later date if a Fedora package developer wishes to revive a dead package they may do so by claiming ownership in pkgdb then requesting the koji block to be removed. It is however a bit easier if ownership is claimed prior to orphan removal, so please claim packages now if possible. IMPORTANT NOTE: These removals do not effect prior releases, including and up to Fedora 8. Please send any questions to fedora-devel-list. Thank you, Warren Togami wtogami at redhat.com From rdieter at fedoraproject.org Mon Nov 26 14:27:55 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 26 Nov 2007 08:27:55 -0600 Subject: kde-4.0(rc1) hitting rawhide Dec 1-7 Message-ID: <474AD7EB.80807@fedoraproject.org> Now that the KDE 4.0 RC1 is available (and development churn has slowed), the KDE SIG will be working towards incorporating as much of kde-4.0 (rc1) into rawhide the week of Dec 1-7. The gory outline of making all of this work are detailed on http://fedoraproject.org/wiki/Releases/FeatureKDE4 The challenge will be replacing the current kde3-based desktop with a kde4-based one, while at the same time still providing a kde3 development platform (ie, so one can still build/run kde3 applications). This announcement serves two primary purposes: 1. Serve notice to expect kde-related borkage the week of Dec 1-7. 2. Inform kde(3)-based package maintainers that spec-files that currently include constructs like: BuildRequires: kdelibs-devel BuildRequires: kdebase-devel will need to be updated to BuildRequires: kdelibs3-devel BuildRequires: kdebase3-devel instead. These kde*3 virtual Provides are in place now (without Epoch's too, btw), so there's no need to wait to make this change. Likewise, kde4-based applications can/should include constructs like BuildRequires: kdelibs4-devel (avoiding references to just kdelibs-devel which can be ambiguous). -- Rex From katzj at redhat.com Mon Nov 26 18:22:27 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Nov 2007 13:22:27 -0500 Subject: Reminder: Get Early Testing of Features Message-ID: <1196101347.15904.5.camel@localhost.localdomain> While it's still early, just a reminder that if you're working on a feature for Fedora 9 and you are to a point at which you feel the feature is "testable" and will give you useful feedback, please contact rel-eng so that we can arrange to get a test spin[1] created and advertised. Note that this doesn't at all need to be "complete", but you'll need to be able to describe what's changed and what sort of testing feedback you're looking for. Requests to rel-eng at fedoraproject.org and we'll go from there Jeremy [1] Probably a live image unless there's a reason why that isn't sufficient for your testing needs. From poelstra at redhat.com Mon Nov 26 18:02:31 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 26 Nov 2007 10:02:31 -0800 Subject: Fedora Feature Process Rolls On Message-ID: <474B0A37.1010803@redhat.com> As we head into the third week since the release of Fedora 8 lots of great Fedora 9 features are already being proposed. See http://fedoraproject.org/wiki/CategoryProposedFedora9 Starting at this week's FESCo meeting (Thursday, 2007-11-29) we will start the first round of feature reviews. New features will be reviewed accepted until Feature Freeze (Tuesday, 2008-03-04). FESCo met on 2007-11-15 to review the Feature process and make some minor changes o The updated process is here: http://fedoraproject.org/wiki/Features/Policy o All the discussion related to the changes is here: http://bpepple.fedorapeople.org/fesco/FESCo-2007-11-15.html o Details of the changes made to the policy page from this discussion are below along with minor changes I added for clarity. John Changelog for http://fedoraproject.org/wiki/Features/Policy o Substitute use of "Approved Feature" with "Accepted Feature" --As mclasen and f13 pointed out, we want to be in the business of 'accepting' new features into the release--not 'approving' them. o Reduced Feature Page update requirements. The new requirements are: 1. Updated at: a. Alpha freeze b. Beta freeze c. every two weeks after beta freeze until ''final development'' freeze 2. At final development freeze all feature pages should be at 100% completion, and if necessary, the feature page adjusted to reflect everything completed. o Clarified first qualification of a feature to read "consistent with the goals and policies of Fedora while within the laws governing the corporate entity sponsoring Fedora--Red Hat." o Major vs. Major features--Enhancements --Discussion centered around tracking improvements in Fedora that are not captured in a feature page. Instead of distinguishing between "major" and "minor" I have referred to undocumented features (not to be confused with bugs) as "enhancements" as suggested by someone in the meeting. --Enhancements will be added and reported in the Release Summary o Clarified section on dropping features that are not complete --All features must be complete or in a testable state by "feature freeze" --Added guidance as to what "testable" means o Mailing list usage --Reminders to developers about upcoming feature deadlines will be sent to fedora-devel-announce at redhat.com --Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on fedora-devel-list at redhat.com From jkeating at redhat.com Wed Nov 28 17:39:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Nov 2007 12:39:24 -0500 Subject: Outage of all Phoenix based systems Message-ID: <20071128123924.1f9e1d84@redhat.com> Many of our systems just experienced a service blip due to a router restart. We are currently working to bring services back online. These services include but are not limited to; koji, bodhi, dist-cvs, hosted.fedoraproject.org, mirrormanager, wiki, transifex, and more. I will send another notice when services are back in order. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Nov 28 18:03:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Nov 2007 13:03:11 -0500 Subject: Outage of all Phoenix based systems In-Reply-To: <20071128123924.1f9e1d84@redhat.com> References: <20071128123924.1f9e1d84@redhat.com> Message-ID: <20071128130311.7d3ef890@redhat.com> On Wed, 28 Nov 2007 12:39:24 -0500 Jesse Keating wrote: > I will send another notice when services are back in order. The outage is over. All services should be operational again. Please let us know (either by replying to this on fedora-devel-list, or pinging us on IRC on freenode, #fedora-admin). Thanks! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lmacken at redhat.com Wed Nov 28 18:30:48 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 28 Nov 2007 13:30:48 -0500 Subject: updates-testing notification changes Message-ID: <20071128183048.GA4765@crow.redhat.com> As decided during last weeks QA meeting[0], bodhi will no longer spam fedora-test-list with updates-testing notifications. Bodhi now has RSS feeds that support querying updates using any combination of release, status, or type: https://admin.fedoraproject.org/updates/rss/rss2.0?status={pending,testing,stable}&release={F8,F7}&type={security,bugfix,enhancement} If you want to see a list of updates-testing packages that you have installed on your local system, install the bodhi-client[1] package and run `bodhi --testable`. From here, your testing feedback is encouraged and will help ensure that we don't push any broken packages out to our users. I also added support for anonymous access and feedback, so discussions about test updates can now be held inside of bodhi. At the moment, anonymous feedback is able to effect an updates karma. This is subject to changing in the future, so if anyone notices this feature getting abused, please let me know. http://bodhi.fedoraproject.org luke [0]: http://fedoraproject.org/wiki/QA/Meetings/20071114 [1]: https://hosted.fedoraproject.org/projects/bodhi/wiki/CLI From wwoods at redhat.com Wed Nov 28 21:47:50 2007 From: wwoods at redhat.com (Will Woods) Date: Wed, 28 Nov 2007 16:47:50 -0500 Subject: Bugzilla 'version' changes for Fedora this Friday! Message-ID: <1196286470.8146.3.camel@metroid.rdu.redhat.com> Hi folks! To help make Bugzilla easier to use and understand, we're going to make two changes to the 'version' field: 1) Stop using the fNtestX versions, and 2) Rename "devel" to "rawhide". We're doing this because of two facts about Fedora development: First, test releases are just rawhide snapshots, so they shouldn't be tracked as their own special versions. Second, everyone calls the development tree "Rawhide", so Bugzilla should reflect that. So here's what's happening. This Friday, all bugs filed against Test versions of Fedora will be moved to the corresponding final release - for example, fc6test2 bugs will be moved to fc6. The testX versions will then be removed from the version list in Bugzilla. Finally we'll rename "devel" to "rawhide". NOTE: this MAY BREAK scripts or links that used "devel". If you have any such scripts, make sure you update them as soon as possible! Thanks! -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Wed Nov 28 22:12:28 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 28 Nov 2007 14:12:28 -0800 Subject: Changes to Fedora 9 Feature Page Message-ID: <474DE7CC.8000605@redhat.com> re: http://fedoraproject.org/wiki/Releases/9/FeatureList Greetings from Featureland, In anticipation of tomorrow's FESCo meeting, the feature dashboard http://fedoraproject.org/wiki/Features/Dashboard is up and running again for Fedora 9. Here you'll find the status of all the features targeted for Fedora 9. I have also contacted each of the feature owners individually as needed. During the lead up to Fedora 8 GA, the Fedora 9 feature list page: http://fedoraproject.org/wiki/Releases/9/FeatureList#proposed became somewhat of a white-board for ideas people had for Fedora 9. After tomorrow's FESCo meeting I will clear this page out to correctly reflect features that have a wiki page in CategoryProposedFedora9 and are being formally targeted for Fedora 9. Thank you, John From tcallawa at redhat.com Fri Nov 30 20:28:55 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Nov 2007 15:28:55 -0500 Subject: [ANNOUNCE] Aurora SPARC Linux Build 2.99 (Beta 2 for 3.0) Message-ID: <1196454535.3432.18.camel@localhost.localdomain> The Aurora SPARC Linux project is proud to finally drag Build 2.99 kicking and screaming into the light. Took us long enough, huh? Beta 1 was in April. Barring some sort of miracle, Aurora 3.0 will be the last sparc32 supporting release. So, if you're still clinging to your sparc32 systems, please test this beta out. After 3.0, we're not even going to think about sparc32 (unless well bribed). This is a BETA release, for what will become 3.0. In fact, we're going to give this release a short period of time to uncover any really nasty bugs, and then we're going to call it 3.0. Here are some of the key features in this release: - Fedora Core 6 based tree of packages (some things are newer) - Support for Niagara hardware (Sun T1000, T2000) - gcc-4.1.1 - gnome 2.16 - KDE 3.5.5 - kernel 2.6.23.1 (with patches!) - Full support for LVM at installtime (no more crashes!) Like all BETAs, this one has some bugs. Here are the ones we know about: - Installs on sparc32 hardware usually work, but they're very touchy. If you're installing to a sparc32 system, use text mode. If it fails to find the cdrom, try: linux expert text - Smartd seems to make systems using the esp.ko SCSI driver very very unhappy. If your system is esp based, we highly recommend that you disable the smartd service in single-user before fully booting after install. - cpuspeed seems to hardlock some sparc64 systems (the V120 is an example). Again, if your system locks up at cpuspeed, we suggest that you disable the cpuspeed service in single-user mode. - Parted was doing incorrect things in previous Aurora releases. This is the source of the odd cylinder-head error messages that have popped up in the past. Sometimes these error messages are harmless, sometimes they are not. Either way, you can get rid of them by booting to rescue mode, then, at the shell prompt, run: dd if=/dev/zero of=/dev/$DRIVE bs=1M count=1 Where $DRIVE is your harddrive, likely sda or hda. Then, reinstall. The errors will vanish (for good!). Be aware that running this command will wipe out all the data and partitions on that disk. - E10000 systems are not yet supported. :/ - Most IDE based SPARC systems need to boot with ide=nodma. Specifically, Ultra 5/10 and Sun Blade 100s need this for sure. - Systems that boot off qlogic attached disks are not supported, because there is no working firmware loader in anaconda, and the qlogic driver needs firmware. - The graphical installer on some sparc32 systems doesn't enable the mouse. Post installation, the mouse works fine in X. - We haven't spun the security updates into this yet. We'll do this before 3.0 final. - Upgrades from 2.98 might not work. We found more errors in how we were handling partitions at installtime, and unfortunately, the best way to fix them is to destroy the partition tables entirely and reinstall from scratch. If you find other bugs, please report them at http://bugzilla.auroralinux.org/ If you install 2.99 on a system, success or fail, we wanna know! Please take a moment and add your system to the table on our wiki: http://wiki.auroralinux.net/wiki/Build2.99TestMatrix You can download the files from our primary location: ftp://ibiblio.org/pub/linux/distributions/aurora/build-2.99 http://distro.ibiblio.org/pub/linux/distributions/aurora/build-2.99 The mirror sites should pick it up in a few hours/days, depending on whether they still remember that we exist. :) Many thanks to the folks in #aurora on freenode for their help in getting this release out. ~spot