[ANNOUNCE] Aurora SPARC Linux Build 2.99 (Beta 2 for 3.0)
by Tom Callaway
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
15 years, 6 months
Bugzilla 'version' changes for Fedora this Friday!
by Will Woods
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
15 years, 6 months
updates-testing notification changes
by Luke Macken
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,testin...
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
15 years, 6 months
Outage of all Phoenix based systems
by Jesse Keating
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?
15 years, 6 months
Reminder: Get Early Testing of Features
by Jeremy Katz
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.
15 years, 6 months
Fedora Feature Process Rolls On
by John Poelstra
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
15 years, 6 months
kde-4.0(rc1) hitting rawhide Dec 1-7
by Rex Dieter
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
15 years, 6 months
Fedora Orphaned Package Removal: November 29th 2007
by Warren Togami
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
15 years, 6 months
Fedora 9 Bug Day-v0.1 :: Monday, November 19, 2007
by John Poelstra
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"
15 years, 6 months
