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
== 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:
* 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
* Desktops galore! Whether you like your bun covered in GNOME, KDE,
Sugar, or otherwise, we've updated it to the sauciest, tastiest version
* 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
* 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.
* Virtualization *
A a-bun-dance of virtualization features are ready for consumption in
* 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
* Virtualization sandboxing provides a new application development
library (libvirt-sandbox) to facilitate the embedding of virtualization.
* 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:
We also have nightly composes of alternate spins available here:
== 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
A shorter list of common bugs can be found here:
== 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,
To learn how to help us cook a better hot dog, visit:
Thank you, and we hope to see you in the Fedora project!
test-announce mailing list
2nd sentence reads: Note that you cannot install Fedora on UEFI-based AMD64 and Intel 64 systems from a USB flash drive, although you can use a USB flash drive to boot the Fedora installer on UEFI-based AMD64 and Intel 64 systems
This appears to say "you cannot install, but you can boot". It's quite confusing. I have used livecd-tools to create UEFI bootable LiveCD media on a USB stick and also installed it onto an Intel-64 system. So this portion of documentation appears to be incorrect. If so, I'll volunteer to file a documentation bug - however the bugzilla only has a documentation bug report version of "devel" so it's slightly unclear how to file such a doc bug report. If it's a bug.
I want to create a package for Fedora 16 but I'm struggling with the
systemd service/target files. I cannot get the various services to execute
in the right order. I have 4 services (they're actually scripts that just
execute and terminate) that need to run in the order described below. Any
of the services could fail but that shouldn't affect any of the other
1) Service A after the local filesystem is mounted.
2) Service B after the network is up and service A terminated.
3) At this point I'd like to create a reference point for other services to
4) Service C after the reference point and after syslog is up.
5) Service D after rc-local and after service C terminated.
What I have at the moment is the following:
[ 2.417488] systemd: Installed new job C.service/start as 80
[ 2.417494] systemd: Installed new job A.service/start as 82
[ 2.417504] systemd: Installed new job D.service/start as 86
[ 2.417533] systemd: Installed new job B.service/start as 100
[ 92.455037] systemd: About to execute: /usr/bin/C
[ 92.460087] systemd: Forked /usr/bin/C as 574
[ 92.460204] systemd: C.service changed dead -> start
[ 92.557292] systemd: About to execute: /usr/bin/A
[ 92.565167] systemd: Forked /usr/bin/A as 578
[ 92.565289] systemd: A.service changed dead -> start
[ 92.954627] systemd: Received SIGCHLD from PID 574 (C).
[ 92.954649] systemd: Got SIGCHLD for process 574 (C)
[ 92.954689] systemd: Child 574 belongs to C.service
[ 92.954696] systemd: C.service: main process exited, code=exited,
[ 92.964090] systemd: C.service changed start -> exited
[ 92.964103] systemd: Job C.service/start finished, result=done
[ 92.964231] systemd: Got SIGCHLD for process 578 (A)
[ 92.964272] systemd: Child 578 belongs to A.service
[ 92.964277] systemd: A.service: main process exited, code=exited,
[ 92.965076] systemd: A.service changed start -> failed
[ 92.975063] systemd: Job A.service/start finished, result=failed
[ 92.975085] systemd: Unit A.service entered failed state.
[ 92.976434] systemd: About to execute: /usr/bin/D
[ 92.983105] systemd: Forked /usr/bin/D as 642
[ 92.983177] systemd: D.service changed dead -> start
[ 92.983655] systemd: C.service: cgroup is empty
[ 92.983696] systemd: A.service: cgroup is empty
[ 93.012250] systemd: About to execute: /usr/bin/B
[ 93.020073] systemd: Forked /usr/bin/B as 649
[ 93.020168] systemd: B.service changed dead -> start
[ 93.228193] systemd: Received SIGCHLD from PID 642 (D).
[ 93.228217] systemd: Got SIGCHLD for process 642 (D)
[ 93.228259] systemd: Child 642 belongs to D.service
[ 93.228273] systemd: D.service: main process exited, code=exited,
[ 93.236088] systemd: D.service changed start -> exited
[ 93.236100] systemd: Job D.service/start finished, result=done
[ 93.236363] systemd: D.service: cgroup is empty
[ 117.429569] systemd: Received SIGCHLD from PID 649 (B).
[ 117.429614] systemd: Got SIGCHLD for process 649 (B)
[ 117.429683] systemd: Child 649 belongs to B.service
[ 117.429704] systemd: B.service: main process exited, code=exited,
[ 117.437134] systemd: B.service changed start -> exited
[ 117.437158] systemd: Job B.service/start finished, result=done
[ 117.437627] systemd: B.service: cgroup is empty
Do I really need 'RemainAfterExit=y'? Do I need any 'Wants' or 'Requires'?
Any help is greatly appreciated.
I already re-set it to Canada, and it seemed to make no changes, and I
mailed admin(a)fedoraproject.org a week or so ago.
What is generating these, and who to contact to fix these?
---------- Forwarded message ----------
Date: Sun, 26 Feb 2012 22:02:08
Subject: FAS Country Code
Dear Paul Wouters,
Your FAS account has an invalid country code, . Please update your account with a valid country code by logging into FAS at https://admin.fedoraproject.org/accounts/, editing your account details and selecting a new country code from the drop down list.
It's long time since PCRE (Perl-Compatible Regular Expression) library
has changed API or ABI. Version 8.30 is different. Besides UTF-16
support, the incompatible changes are described by upstream with these
. The pcre_info() function, which has been obsolete for over 10 years,
has been removed.
. When a compiled pattern was saved to a file and later reloaded on
a host with different endianness, PCRE used automatically to swap the
bytes in some of the data fields. With the advent of the 16-bit
library, where more of this swapping is needed, it is no longer done
automatically. Instead, the bad endianness is detected and a specific
error is given. The user can then call a new function called
pcre_pattern_to_host_byte_order() (or an equivalent 16-bit function)
to do the swap.
. In UTF-8 mode, the values 0xd800 to 0xdfff are not legal Unicode code
points and are now faulted. (They are the so-called "surrogates" that
are reserved for coding high values in UTF-16.)
Result is pcre library has changed SONAME from libpcre.so.0 to
libpcre.so.1. Other librararies (pcrecpp, pcreposix) delivered with this
package remain compatible.
Because pcre library is part of minimal build root I choosed following
strategy to avoid breaking Koji:
(1) pcre-8.30-1 will include both new libpcre.so.1 and old libpcre.so.0.
(This is done by copying old files from build root while building
this new package).
(2) Reverse dependencies will be rebuilt against this new library.
x86_64 repository returns 109 packages:
(3) pcre package will be rebuilt again without the old libpcre.so.0 library.
The usr-move of /lib*/libpcre.so* will proceede in this or another
Hey, folks. There's a new livecd-tools build which needs testing:
It should fix two bugs I came across in Alpha testing:
https://bugzilla.redhat.com/show_bug.cgi?id=796419 - "F17 Alpha RC4 DVD
written to USB with livecd-iso-to-disk --efi does not boot"
Also the bug where, if you write a DVD ISO to USB stick with l-i-t-d,
only the anaconda stuff gets written, not the packages - so the stick is
effectively just a boot.iso, you need another source of packages. That
one I didn't file yet, but it should be fixed.
bcl says it's a fairly big change, so he wants it to get some testing
before applying the change to f15 and f16. please test whatever you
usually use livecd-iso-to-disk for and make sure it didn't break
anything. Ideally we should re-run all the USB validation tests that use
anything from livecd-tools - the 'USB Stick' section on the installation
matrix - and make sure nothing got worse, at least. If it all goes well,
file positive karma. thanks! it'd be great to get this approved and
f15/f16 builds done ASAP so as to help people get Alpha written.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
-----BEGIN PGP SIGNED MESSAGE-----
I am Bas van den Dikkenberg,
I'm just a new comer, for fedora but use linux for many years now and Dutch is my first language. I'm Dutch, love Linux. And I've used some versions of Linux: Fedora, Ubuntu, Opensuse, and so on. First Linux I used is slackware, so classic.
Open Source is the future, and my live.
In personal live i am one of the orginaisers of the linux theme day in the neterlands
I want to be a package maintainer for fedora, because I notised like to package software and see it as a challenge.
I currently the maintairen for ptop en burp in fedora.
As my first project I want to add burb to fedoraproject.
Bas van den Dikkenberg
irc: nick basd82
KEY id : C9710323
FIngerprint: B7F2 A4B4 4758 A08D 6594 F776 2270 C518 C971 0323
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
-----END PGP SIGNATURE-----
Just a quick note - now that Fedora 18 development is open, we encourage
mantainers who are planning on orphaning or retiring their packages to do so
as early in the process as possible. That gives other maintainers a longer
runway to fix dependencies and possibly pick up maintenance if they so
devel-announce mailing list
1) Will /usrmove already be 'done' in the Fedora 17 test ISO's?
2) Will Rawhide have a simple 'do this step-by-step' for the already
existing Rawhide /usr/move?
3) Will /usrmove be painless for those updating Fedora 16 or Fedora 15
or will we be biried for weeks with complaints of failed upgrades?
"May your road lead you to warm sands."