devel-announce November 2007

devel-announce@lists.fedoraproject.org

9 participants
13 discussions

[ANNOUNCE] Aurora SPARC Linux Build 2.99 (Beta 2 for 3.0)
by Tom Callaway 30 Nov '07

30 Nov '07

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

1 0

Changes to Fedora 9 Feature Page
by John Poelstra 28 Nov '07

28 Nov '07

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

1 0

Bugzilla 'version' changes for Fedora this Friday!
by Will Woods 28 Nov '07

28 Nov '07

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

1 0

updates-testing notification changes
by Luke Macken 28 Nov '07

28 Nov '07

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,… 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

1 0

Outage of all Phoenix based systems
by Jesse Keating 28 Nov '07

28 Nov '07

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?

1 1

Reminder: Get Early Testing of Features
by Jeremy Katz 26 Nov '07

26 Nov '07

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(a)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.

1 0

Fedora Feature Process Rolls On
by John Poelstra 26 Nov '07

26 Nov '07

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(a)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(a)redhat.com

1 0

kde-4.0(rc1) hitting rawhide Dec 1-7
by Rex Dieter 26 Nov '07

26 Nov '07

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

1 0

Fedora Orphaned Package Removal: November 29th 2007
by Warren Togami 19 Nov '07

19 Nov '07

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(a)redhat.com

1 0

Fedora 9 Bug Day-v0.1 :: Monday, November 19, 2007
by John Poelstra 16 Nov '07

16 Nov '07

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"

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce November 2007