Meat the Beefy Miracle: Announcing the release of Fedora 17 Alpha!
by Dennis Gilmore
Hot dog! The Fedora 17 "Beefy Miracle" Alpha Release is available! This
release offers a preview of some of the best and meatiest free and open
source technology currently under development. Relish in a glimpse of
the future:
http://fedoraproject.org/get-prerelease
== What is the Alpha release? ==
The Alpha release contains all the bunderful features of Fedora 17 in a
form that anyone can help test. This testing, guided by the Fedora QA
team, helps us target and identify bugs. When these bugs are fixed, we
make a Beta release available. A Beta release is code-complete, and
bears a very strong resemblance to the third and final release. The
final release of Fedora 17 is due in early May.
Frankly, we think Fedora 17 will be the best release ever, but we know
we can't do it without your help. Please take a moment of your time to
download and try out the Alpha and make sure the things that are
important to you are working. If you find a bug, please report it --
every bug you uncover is a chance to improve the experience for millions
of Fedora users worldwide. Together, we can make Fedora a franktastic,
rock-solid distribution. (Read down to the end of this announcement for
more information on how to help.)
== Condiments ==
When we said Beefy, we weren't kidding: an a-bun-dance of condiments,
err, features, are available to help you feed your hunger for the best
in free and open source software. We take pride in our toppings, and in
our fine ingredients; Fedora 17 includes both over- and under-the-bun
improvements that show off the power and flexibility of the advancing
state of free (range) software.
Check out our menu, certain to please a variety of appetites:
<https://fedoraproject.org/w/index.php?title=F17_Alpha_release_announcemen...>
* End Users *
End users will see numerous improvements in Fedora 17.
* GIMP has been updated to the long awaited 2.8 release, with an
a-bun-dant list of new features, such as the single window mode, layer
groups, and on-canvas text editing.
* Improved language and font support: A number of Lohit fonts, enabling
Indian script, have been added, as well as support for Inscript 2 for
keymapping; libpinyin increases pinyin input speed by adding predictive
intelligence.
* Desktops galore! Whether you like your bun covered in GNOME, KDE,
Sugar, or otherwise, we've updated it to the sauciest, tastiest version
available.
<https://fedoraproject.org/w/index.php?title=F17_Alpha_release_announcemen...>
* Systems Administrators *
Serving up hot dogs all day long? Increase your reliability and
versatility with the new enhancements to the clustering stack in Fedora
17. Load balancing and high availability improvements have been made,
allowing systems administrators to deploy Fedora in environments
requiring greater availability and clustered file systems; both Corosync
2.0 and the Pacemaker Cluster Resource Manager 1.1.7 are included. JBoss
Application Server (AS) 7 has also been added to Fedora 17; this fast,
lightweight, and modular application server allows you to run full Java
EE applications.
<https://fedoraproject.org/w/index.php?title=F17_Alpha_release_announcemen...>
* Developers *
Developers can cook up fresh code with the updates and additions of
numerous languages in Fedora 17. Java 7, Ruby 1.9.3, and PHP 5.4 are
just some of the latest-and-greatest; we've also got updates and
additions in the Haskell platform, Erlang, and D, as well as the
addition of the Opa programming language. GCC has been updated to 4.7,
and Fedora 17 has additionally been rebuilt with this new version,
resulting in compiled code improvements.
<https://fedoraproject.org/w/index.php?title=F17_Alpha_release_announcemen...>
* Virtualization *
A a-bun-dance of virtualization features are ready for consumption in
Fedora 17:
* Open vSwitch is a flexible, multi-layer software switch typically used
in virtualization environments as the network switching component in the
hypervisor, providing virtual machines their network connectivity.
* KVM improvements, including the addition of a virtualized PMU
(performance monitoring unit)for guests, and a live block copy features,
allowing an image backing a guest disk to be copied while the guest is
online.
* Virtualization sandboxing provides a new application development
library (libvirt-sandbox) to facilitate the embedding of virtualization.
<https://fedoraproject.org/w/index.php?title=F17_Alpha_release_announcemen...>
* Hot Dogs as a Service (HDaaS) *
Kidding! We couldn't resist jumping into the game with our own acronym.
Seriously, though, we have a frank-tastic variety of cloud technologies
coming in Fedora 17, including the fresh additions of some of the best
Infrastructure-as-a-Service (IaaS) platforms in free and open source
software -- Cloudstack, Eucalyptus, and OpenNebula. OpenStack gets
bumped in Fedora 17 to the Essex release, and other OpenStack features
have been added or updated as well, including Horizon and Quantum, and
the ability to use OpenStack with libguestfs and qpid.
These and many other improvements provide a wide and solid base for
future Fedora releases. This release increases the range of
possibilities for developers and helps Fedora to maintain its position
at the leading edge of free and open source technology.
Ketchup with the full list of features for Fedora 17 here:
http://fedoraproject.org/wiki/Releases/17/FeatureList
We also have nightly composes of alternate spins available here:
http://dl.fedoraproject.org/pub/alt/nightly-composes/
== Issues and Details ==
For more information including common and known bugs, tips on how to
report bugs, and the official release schedule, please refer to the
release notes:
http://fedoraproject.org/wiki/Fedora_17_Alpha_release_notes
A shorter list of common bugs can be found here:
http://fedoraproject.org/wiki/Common_F17_bugs
== Contributing ==
Ever wonder how sausage is made? Yeah, we didn't want to know either.
Hot dogs, on the other hand, are glorious creations, and the Alpha
release of Beefy Miracle is yet another fine example of a long line of
solid Alpha releases. We can't do it without you, though. Bug reports
are especially helpful as we move from the hot dog factory to the
finished Beefy Miracle. If you encounter any issues, please report them!
Mustard up the confidence to contribute? Don't worry -- we don't bite!
(Except... tasty, delicious hot dogs. Mmmmmm. Hot dogs.) Fedora is a
fantastic, friendly community, and we have many ways in which you can
contribute, including Documentation, Marketing, Design, QA, Development,
and more.
To learn how to help us cook a better hot dog, visit:
http://join.fedoraproject.org
Thank you, and we hope to see you in the Fedora project!
12 years, 1 month
Bring out your bid! The bidding process for the next FUDCon in North America is now OPEN.
by Robyn Bergeron
Allow me to tell a little story about this thing we do called FUDCon.
FUDCon is the abbreviated term for the Fedora Users and Developers
Conference, an event in which we gather together users and developers to
plan the future, share experiences, solve problems, hack on stuff,
spread the word of free and open source software, and let people get to
know about this fabulous community we know as the Fedora Project.
Many moons ago (approximately 91 of them), the first FUDCon was held, in
February, 2005. Legendary tales are now told of the event. Some are even
true. While I highly recommend you consult with Tom "spot" Callaway to
hear some of them, you can take a trip in the wayback machine and catch
a view of what happened, here:
https://fedoraproject.org/w/uploads/2/2c/FUDCon_FUDCon1Video.mov
We've had many FUDCons since then, to great success, in many locations
all over the world. At the same time, the event has evolved to one that
is community-organized and driven, from the selection of location via
bidding, and budget management, and shirt design, to event content. It
is a shining example of what makes Fedora so great: much like everything
*else* the Fedora Project produces, the success of FUDCon depends on the
community. We most recently saw these successes at the FUDCon in
Blacksburg, Virginia, in January[2], and I expect to see it again
elsewhere in 2012 -- in Venezuela, and in EMEA and APAC.
Okay, I'll stop waxing poetic and get on with the actual meat[1] of this
email: BIDDING FOR THE LOCATION OF THE NEXT NORTH AMERICAN FUDCON IS NOW
OPEN. And, incidentally, will close on March 23rd, 2012, with a decision
in early April.
What does this mean? For you prospective North American FUDCon planners,
a few things:
1: Make your wiki page, called [[FUDCon:Bid_for_<Your_Town>_2013]], with
the information outlined on the bid process page.
http://fedoraproject.org/wiki/FUDCon_bid_process
2: Join the fudcon-planning list and let us know that your bid page is
complete, or ask the list anything you'd like to know about bidding.
http://lists.fedoraproject.org/mailman/listinfo/fudcon-planning
Important to note: FUDCon for North America should occur between
December 1, 2012 and February 28, 2013, though ideally in December or
January, as February is the last month of the fiscal year, and, well,
expense reports need to get in, or Daddy Shadowman gets sad. The North
American FUDCon has approximately a $20k (USD) budget.
Not sure if you want to bid, or if your location is ideal? Here are a
few things to consider that are helpful to a bid:
* Reasonable travel, room, and board costs
* Free or inexpensive event space
* Local FOSS or related communities (think: hackerspaces, etc.) that
might be interested in attending
* This time of year can be somewhat hairy for travel, weather aside;
take into consideration timing of academic schedules for students,
holiday travel, and the like.
* Nice weather never hurts either. :)
Looking forward to seeing your proposals, and to seeing many of you
again, a little less than a year from now, at the next FUDCon in North
America.
-Robyn
[1] You didn't *really* think I could get through an email without a
Beefy Miracle pun, did you?
[2] http://fedoraproject.org/wiki/FUDCon:Blacksburg_2012
12 years, 1 month
Fedora Engineering "Open House" IRC Meeting - Thursday, February 23, 2012 - 1800 UTC
by Tom Callaway
Apologies in advance for the wide distribution of this message.
The Fedora Engineering team is holding an "Open House" IRC meeting on
Thursday, February 23, 2012 at 18:00 UTC (12:00 PM EST). This will be a
moderated meeting in which we will briefly present the upcoming projects
for the Fedora Engineering team, then take questions, suggestions, and
feedback from the Fedora Community. The meeting will take place in
#fedora-meeting on irc.freenode.net, and it will be logged.
We will be following the Fedora Meeting Protocol, which is documented
here: https://fedoraproject.org/wiki/How_to_use_IRC#Meeting_Protocol
In case you have not heard of Fedora Engineering, the short answer is
that we are the team at Red Hat made up of people who work full-time on
improving Fedora and ensuring it has a robust and useful infrastructure.
The longer answer can be found here:
https://fedoraproject.org/wiki/Fedora_Engineering
Our proposed projects and goals for the next year are documented here:
https://fedoraproject.org/wiki/Fedora_Engineering/FY13_Plan
In the spirit of transparency and community, we would like to encourage
all Fedora community members (whether users, testers, writers, artists,
translators, ambassadors, packagers, or any other type of contributor)
to come and meet the team and learn about our plans for the next year.
Thanks,
Tom Callaway
Fedora Engineering Manager
12 years, 2 months
Change in Fedora leadership
by Jared K. Smith
One of the things I like most about the Fedora Project is the
opportunity for people to move and grow in (and out) of different
roles and responsibilities. The position of Fedora Project Leader,
in particular, has never been a long-term leadership position, but one
that regularly invites new people to assume the role and bring new
ideas and new energy to the project. I would like to take this
opportunity to share some of my thoughts about being the Fedora
Project Leader, and inform you of upcoming changes in Fedora
leadership. Any time we make leadership changes in Fedora, we that
that challenge seriously, and do everything we can to make the
leadership transition as smooth as possible.
Although I've been using Fedora since the split from Red Hat Linux,
it's only been the past five of six years that I've really been an
active contributor. Sure, I was hanging out on the mailing lists,
trying out the pre-releases and reporting bugs, but I didn't really
consider myself a part of Fedora. It wasn't until I got started with
the Docs team and attended my first FUDCon that I truly caught the
spirit of the Fedora community. Since then, I've thoroughly enjoyed
rubbing shoulders with people who are infinitely smarter than me, and
I've learned a tremendous amount -- both about the technical bits and
bytes, and also about free software communities. And for the last
little while, it's been my honor and privilege to serve the community
as the Fedora Project Leader. The role of Fedora Project Leader isn't
an easy role, but I am proud of the things we've been able to
accomplish both within the distribution and within the community
during my tenure. We've had three solid Fedora releases during my
time as FPL, each one with a myriad of new features. I've worked hard
to expand our international outreach, and to get more international
representation on the Fedora Board. We've updated the Fedora website.
We've improved our quality assurance processes. We've been able to
deliver Fedora images for the Amazon EC2 cloud on release day. We've
improved our translation system. I'm thankful for all those who have
worked hard to help drive Fedora forward. Now is the time for me to
pass the torch to the next Fedora Project Leader.
As you probably already know, Red Hat employs the FPL to ensure
someone is accountable to Red Hat and the rest of the community for
the Fedora Project as a whole. After all, many Fedora leaders have
referred to the FPL as "the one throat to choke" when it comes to
Fedora. The FPL is still subject to the same process as any other Red
Hat hire, though, and ultimately Red Hat is responsible for that
decision. It is imperative that the decision be a good one for the
entire Fedora community, so the Fedora Board is consulted about the
selection. This process has continued to work well for several
previous FPLs, and the Board provided positive feedback about our
selection this time around, too.
I'm happy to announce that Red Hat has selected Robyn Bergeron to be
the next Fedora Project Leader. Robyn has proven herself in the
Fedora community over the last several years, and I have complete
confidence in her abilities to lead the Fedora Project. In addition
to planning FUDCon Tempe in 2011 and helping to lead the Marketing and
Cloud SIGs within Fedora, Robyn has been an integral part of many
other Fedora events and endeavors. Most recently, she has held the
role of Fedora Program Manager, helping to ensure that we all stay on
schedule and helping the Fedora feature process stay on track. Please
join with me in welcoming Robyn into her new role, and in giving her
your help and support in her new role. I'll be working with Robyn
over the next weeks and months to help her in the new role.
--
Jared Smith
Former Fedora Project Leader
12 years, 2 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
There have been quite a few approved changes to the Fedora Packaging
Guidelines since the previous announcement, but this is mostly because I
have not had time to actually apply the approved updates to the wiki
until recently. These updates actually were approved over a period of
several months. I will try harder to get updates written up and
announced in a more timely fashion going forward.
---
The Eclipse Plugin Packaging Guidelines were updated. The most major
change is the addition of a section discussing how to run the
reconciler. For the full updated guidelines see:
https://fedoraproject.org/wiki/Packaging:EclipsePlugins
---
t4k_common contains a forked copy of an older version of liblinebreak. A
temporary bundling exception has been granted until the t4k_common
upstream is able to port their code to use the newer system copy of
liblinebreak. The t4k_common package must include Provides:
bundled(liblinebreak) until the issue is resolved.
This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
Spring RTS includes a forked and bundled copy of Lua which has Spring
RTS specific patches applied, must link to streflop, and is configured
differently from stock Lua (most importantly it needs lua_Number to be a
float and not a double). Lua is particularly important because parts of
the game code may be written in it, which must yield exactly identical
results (also floating point operations!) on all platforms.
As a result, it has been granted a bundling exception for lua. The
Spring RTS package must include Provides: bundled(lua) = X.Y.Z (where
X.Y.Z is the base lua version), until the bundling issue is resolved (if
ever).
This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A section has been added to the Guidelines that limits which package
manager repositories are allowed to be configured in Fedora. Additional
repository configuration files are allowed as documentation provided
that they are legally allowable by Fedora.
https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Pack...
---
The MPI Guidelines have been clarified by adding this additional statement:
If the maintainer wishes for the environment module to load
automatically by use of a scriptlet in /etc/profile.d or by some other
mechanism, this MUST be done in a subpackage.
https://fedoraproject.org/wiki/Packaging:MPI
---
The Devel Packages section of the Packaging Guidelines has been
rewritten to be more comprehensive and clear:
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
In addition, the ReviewGuidelines have been simplified to state simply
that Development files must be in a -devel package.
---
An exception was granted which permits the bundling of binutils
libraries, (most notably, libbfd, libcpu, libopcodes, and libdecnumber)
but only to packages which share the same upstream as binutils
(sourceware.org). This is because the libraries are developed by the
application authors as common functionality shared between several
applications. Being developers of both, they'll be intimately aware of
both issues that arise in the libraries and know how to port to newer
versions of the library as needed. Note that, at the moment, all of
these applications and libraries come from sourceware.org but not all of
them are used in binutils.
Packages leveraging this exception must add: Provides: bundled(binutils)
= %{snap}, where %{snap} is defined in the package as the date that the
binutils checkout was made, until the bundling issue is resolved (if ever).
This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
The Packaging Guidelines section on Architecture Support has been
amended to clarify that all Fedora packages must successfully compile
and build into binary rpms on at least one supported primary
architecture, except where the package is useful only on a secondary
architecture (such as an architecture-specific boot utility, microcode
loader, or hardware configuration tool).
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
---
The "okjson" software has reluctantly been granted a bundling exception.
Packages which bundle okjson.rb must add: Provides: bundled(okjson),
until the bundling issue is resolved (if ever).
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
The section of the Packaging Guidelines covering /srv was amended to
include /opt and /usr/local. Specifically, the following sentence was added:
In addition, no Fedora package can have any files or directories
under /opt or /usr/local, as these directories are not permitted to
be used by Distributions in the FHS.
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directori...
---
A new section has been added to the Fedora Packaging Guidelines
regarding Network Support. Specifically, if an application contains
native and stable support for both IPv4 and IPv6, and support for IPv6
does not negatively affect IPv4 then both must be enabled in the Fedora
package.
https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support
---
As part of the /usrmove feature in Fedora 17, Fedora packages MUST NOT
place files or directories in the /bin, /sbin, /lib or /lib64
directories. Instead, the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64
directories must be used. Packages must assume that /bin, /sbin, /lib,
and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and
/usr/lib64 directories, respectively.
This is effective immediately for new packages, however, packagers are
not required to implement this change for distributions older than
Fedora 17.
https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout
---
A temporary bundling exception has been granted for libtdb_compat and
libccan, but only for samba4 packages. This exception will last until
F18 GA, or libtdb 2.x releases, whichever comes first.
Samba4 packages which bundle libtdb_compat or libccan must include
Provides: bundled(libtdb_compat) or Provides: bundled(libccan), until
the bundling issue(s) are resolved.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A bundling exception has been granted for libreplace, but only if the
package in question shares the same upstream as samba. This is because
the libreplace library is developed by the application authors as common
functionality shared between several applications. Being developers of
both, they'll be intimately aware of both issues that arise in the
libraries and know how to port to newer versions of the library as needed.
Samba packages which bundle libreplace must include Provides:
bundled(libreplace), until the bundling issue is resolved (if ever).
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
The Pre-Release packages section was improved significantly, with the
intent of making it more clear through the use of specific examples in
tables.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_pac...
---
The Icon Tag in Desktop Files section in the Packaging Guidelines has
been amended to include a link to the scriptlets to refresh the icon cache.
https://fedoraproject.org/wiki/Packaging:Guidelines#Icon_tag_in_Desktop_F...
---
The Emacs Packaging Guidelines have been clarified and simplified, with
much unnecessary duplication removed.
https://fedoraproject.org/wiki/Packaging:Emacs
---
A new section containing tips and best practices for writing scriptlets
for Fedora packages has been added.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Writing_script...
---
The Guidelines section on Handling Locale Files has been updated to
reflect the additional functionality in %find_lang.
https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
---
Ulrich Drepper's MD5 implementation, as found originally in gcc, was
added to the list of MD5 exception cases permitted for bundling exceptions.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A link to the No Bundling Libraries page, which contains the steps
necessary to request a Bundling exception, has been added to the
"Bundling of multiple projects" section in the main Guidelines.
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_of_multiple_...
---
The section on File and Directory Ownership has been updated to reflect
the fact that while in most cases, it should not be necessary for
multiple packages to contain identical copies of the same file, if it is
necessary, multiple packages may contain identical copies of the same
file, as long as the following requirements are met:
* The packages sharing ownership of the identical files are built from a
single SRPM.
OR
* The packages sharing ownership of the identical files are not in a
dependency chain (e.g. if package A requires package B, they should not
both contain identical files, either A or B must own the common files,
but not both.)
In addition, identical files are defined as files which are always
identical in content, checksum, permissions, and location on the
filesystem in each package.
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ow...
---
Announce Text:
A new section has been added to the PHP Guidelines, documenting the PHP
ZTS extension.
https://fedoraproject.org/wiki/Packaging:PHP#PHP_ZTS_extension
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Nick Clifton, Remi Collet, Frank R Dana Jr., Gilboa
Davara, Kevin Fenzi, Stephen Gallagher, Harald Hoyer, Jan Kratochvil,
Jussi Lehtola, Marcela Mašláňová, Panu Matilai, Vít Ondruch, Petr Pisar,
Michael Schwendt, Kay Sievers, Chris Tyler, Jonathan Underwood, Karel
Volný, Sami Wagiaalla, Christoph Wickert, and all of the members of the
FPC, for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
12 years, 2 months
