Fedora Board IRC meeting 1800 UTC 2008-08-12
by Paul W. Frields
The Board is holding its monthly public meeting on Tuesday, 12 August
2008, at 1800 UTC on IRC Freenode. The public is invited to do the
following:
* Join #fedora-board-meeting to see the Board's conversation. This
channel is read-only for non-Board members.
* Join #fedora-board-public to discuss topics and post questions. This
channel is read/write for everyone.
The moderator will direct questions from the #fedora-board-public
channel to the Board members at #fedora-board-meeting. This shouldlimit
confusion and make sure our logs are useful to everyone.
The Board has set aside one meeting of each month as a public "town
hall" style meeting. We are *still* hoping to hold an audio-based
meeting at some point in the near future using some of the new resources
being developed by the Infrastructure team. More news on this will be
forthcoming. We look forward to seeing you at the meeting.
--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
15 years, 10 months
- 1
- 0
Updated Fedora Privacy Policy
by Tom Callaway
This is a notice that the official Fedora Privacy Policy has been
updated.
A brief notice can also be found on the main website
(http://fedoraproject.org).
Previously, Fedora was using the generic Red Hat Privacy Policy, which
did not make sense for a number of reasons. Fedora now has its own
Privacy Policy at:
http://fedoraproject.org/wiki/Legal/PrivacyPolicy
I would encourage everyone to read the new Privacy Policy. This policy
went through a public review process on the fedora-advisory-board
mailing list, and was approved by the Fedora Board on August 5th, 2008.
This new policy defines that more of your "Personal Information" is
public by default. This will make things much easier for the daily
workings of Fedora, however, if you wish for this "Publicly Available
Personal Information" to be kept private, it is possible to do so in the
Fedora Account System.
It also enables us to be able to generate useful statistics about
Fedora's ongoing progress. Last, but not least, it got rid of a lot of
useless wording and confusing text about transactions and Red Hat
services which are not applicable to Fedora.
If you have any questions about the updated Fedora Privacy Policy, feel
free to email me.
Thanks,
Tom "spot" Callaway, Fedora Legal
15 years, 10 months
- 1
- 0
Announcing Fedora 10 Alpha!
by Jesse Keating
In an ongoing effort to prevent premature kitten death, the Fedora
Project is ecstatic to present the availability of Fedora 10 (Cambridge)
Alpha. Test now, make it better now, keep Cambridge on schedule, and
protect the kittens in the future.
The Alpha release provides the first opportunity for the wider community
to become involved with the testing of rawhide:
* Alpha represents a sanitized snapshot of rawhide, Fedora's
development branch, which undergoes rapid changes before
becoming the next major release.
* The Alpha should boot on the majority of systems, and provides:
* A look at what new features are to be included in the
next release
* A way to provide feedback and bug reports to help ensure
that the next release is as good as possible
Fedora 10 features
Some highlights of Fedora 10 Alpha:
* Many improvements, bugfixes, and enhancements from upstream
* New graphical boot environment
* Wireless connection sharing
* Audio improvements to remove glitches
* Security audit tool
* Improved webcam support
* Better IR remote control support
* RPM 4.6
* OCaml
* Haskell
For more information:
http://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes
What to test
Test status is being tracked here:
https://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha
Check out this page before reporting problems, including looking through
the bug trackers as linked on that page.
For a more detailed list of installation tests:
http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install
Get the Alpha
The Alpha release is available both through the mirroring system and via
bittorrent.
For direct http access to a local mirror:
http://download.fedoraproject.org/pub/fedora/linux/releases/test/10-Alpha/
For a list of mirrors carrying the content and the various protocols
they support:
http://mirrors.fedoraproject.org/publiclist/Fedora/10-Alpha/
For bittorrent:
http://torrent.fedoraproject.org/
Join Fedora
To find ways you can help and participate, visit:
http://join.fedoraproject.org/
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
15 years, 10 months
- 1
- 0
Fedora Weekly News Issue 137
by Huzaifa Sidhpurwala
Fedora Weekly News Issue 137
=============================
Welcome to Fedora Weekly News Issue 137 for the week ending August 2, 2008.
http://fedoraproject.org/wiki/FWN/Issue137
Fedora Weekly News keeps you updated with the latest issues, events and
activities in the Fedora community.
We are pleased to present a new beat on Virtualization issues and
developments brought to you by beat writer Dale Bewley. In Developments
we report on "How Maintainers Can Help Reduce XULRunner Breakage". In
Announcements we reveal the Fedora 10 codename. In Artwork we examine
"The Blue Color of Fedora". In Security Advisories, another new beat
authored by David Nalley we run through the week's important updates. We
are also saddened to announce the departure of Thomas Chung from the
editorial chair, but heartened to be working as a new editorial team
consisting of Pascal Calarco, Oisin Feeley and Huzaifa Sidhpurwala.
If you are interested in contributing to Fedora Weekly News, please see
our 'join' page. Being a Fedora Weekly News beat writer gives you a
chance to work on one of our community's most important sources of news.
Ideas for new beats are always welcome -- let us know how you'd like to
contribute.
We are still looking for a beat writer to summarize the Fedora Events
and Meetings that happened during each week.
http://fedoraproject.org/wiki/NewsProject/Join
== Announcements ==
In this section, we cover announcements from the Fedora Project.
http://www.redhat.com/archives/fedora-announce-list/
http://www.redhat.com/archives/fedora-devel-announce/
Contributing Writer: Max Spevack
= Fedora 10 (Cambridge) =
Josh Boyer informed us[0] that "Cambridge" was the winning name in the
Fedora 10 naming election. Jeremy Katz wrote[1] on his blog that
"Cambridge" was the original Red Hat Linux 10 codename, which was the
release that eventually became Fedora Core 1.
[0]
https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00014.html
[1] http://katzj.livejournal.com/434986.html
== Ambassadors ==
In this section, we cover Fedora Ambassadors Project.
http://fedoraproject.org/wiki/Ambassadors
Contributing Writer: JeffreyTadlock
= Help Wanted: LinuxWorld San Francisco =
Karsten Wade put out a help wanted call [1] for the Fedora booth at
LinuxWorld San Francisco. If you are in the area and wnat to help out,
please check the mailing list post [1] for details or the wiki page [2].
[1]
https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg0041...
[2] https://fedoraproject.org/wiki/Events/LinuxWorld_SF_2008
= Event Report: Lindependence 2008 =
Karsten Wade reported [1] on Lindependence 2008 on the ambassador
mailing list. THis event was in Felton, California and was an attempt to
get an entire town to switch to FOSS alternatives.
[1]
https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg0038...
= Event Report: Palmetto Open Source Software Conference =
David Nalley posted [1] his event report covering the Palmetto Open
Source Software Conference. This was a first year event and included a
talk by Greg DeKoenigsberg and included an imprompt Fedora booth.
[1]
https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg0037...
== Developments ==
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
= How Maintainers Can Help Reduce XULRunner Breakage =
The recent breakage of many packages which depend on xulrunner (see
FWN#136 "XULRunner Security Update Breakage Stimulates Bodhi
Discussion"[1]) was addressed[2] in a post by Will Woods. Will reported
that a QA meeting involving Christopher Aillon (caillon), as
Firefox/XULRunner maintainer, had investigated the problem and produced
an explanation and some recommendations for other package maintainers.
As Christopher was unavailable for a week Will was relaying the
information in the hope that some fixes could be made in his absence.
[1]
http://fedoraproject.org/wiki/FWN/LatestIssue#XULRunner.Security.Update.B...
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01682.html
The reason that some xulrunner-dependent packages were affected and
others not was that xulrunner provides both a stable API gecko-devel and
an unstable API gecko-devel-unstable. Will noted that BuildRequires of
xulrunner-devel or xulrunner-devel-unstable should no longer be used and
instead that gecko equivalents should replace them.
Packages using the stable API were unaffected by the update of
xulrunner. Will stated that "[t]he unstable API could change at any
time, so if your app is using the unstable API it must be rebuilt *every
time* xulrunner is updated." It was recommended that packages that used
the stable API should use the following in their specfiles:
Requires: gecko-libs >= 1.9
BuildRequires: gecko-devel >= 1.9
and that those using the unstable API should use:
%define gecko_ver 1.9.0.1
Requires: gecko-libs = %{gecko_ver}
BuildRequires: gecko-devel-unstable = %{gecko_ver}
Lastly an important request was made of package maintainers: "if your
package uses the -unstable API, please send caillon redhat com a note,
and *please* consider adding him to the ACL (or opening it entirely). He
keeps tabs on all packages requiring the unstable API so they can all be
rebuilt for each security update."
Braden McDaniel wondered[3] why the same headers, but with different
pathnames, were provided by xulrunner-devel-unstable and xulrunner-devel
and Ville-PekkaVainio had[4] the same question.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01684.html
In response to the suggested BuildRequires Douglas Warner requested[5]
that a Provides: gecko-libs-api = 1.9 be added to xulrunner so that
dependent packages would break if xulrunner were bumped to a new version
which was not compatible: "For example, I can't do: Requires: gecko-libs
< 2.0 Because I'm not guaranteed that the next version will *be* 2.0 (it
might be 1.10, for example)." Rex Dieter independently came[6] to the
same conclusion. Denis Leroy begged[7] that xulrunner would use
"libtool-style soname versions like all other libraries in Fedora? So we
don't need to add the version numbers in the spec file in the first
place." Denis thought that xulrunner would fail a standard Fedora
package review.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01686.html
[edit] NEVR Again
Another report detailing broken upgrade paths was posted[1] by Jesse
Keating's script (see FWN#136 "Broken Upgrade Paths Due to NEVR"[2]).
This time it reported those packages which failed the path "f8-final ->
dist-f8-updates -> dist-f8-updates-testing -> dist-f9-updates ->
dist-f9-updates-testing -> dist-f10" and seventy-eight packages were
listed. Also included as per last week's discussion was an ordering of
the list per-builder as opposed to per-owner. Jesse requested[3]
feedback from recipients of the automated email warnings if problems are
encountered.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01525.html
[2]
http://fedoraproject.org/wiki/FWN/LatestIssue#Broken.Upgrade.Paths.Due.to...
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01526.html
Stephen Warren was concerned[4] that the upgrade path did not include
the GA release of dist-f9: "Shouldn't dist-f9-final (or whatever the
correct name is) be inserted in this path list between
dist-f8-updates-testing and dist-f9- updates?" This led to an
interesting exchange with Kevin Kofler who argued[5] that the converse
should be expected and it was desirable that updates to Fedora 8 would
have higher EVRs than the packages which were released for "dist-f9".
Stephen argued[6] that it would make it easier to backport fixes if
bumping of the release number rather than the version number were
preferred and suggested changing what he understood to be Fedora's
policies. KevinKofler disagreed[7] both with Stephen's description of
current Fedora practices and also with his desire to reduce version
bumps. He listed several situations in which these bumps would be useful
and suggested that it was such version upgrades which uniquely
distinguished Fedora from Debian "stable" or Red Hat EL.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01527.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01529.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01539.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01553.html
The possibility that simultaneous updates would be released to all
branches was discussed[8] by Kevin Kofler and Jesse Keating. Although
Jesse thought this was a corner case and that it was best to let the
maintainer decide Kevin was motivated[9] to write a patch as it was in
his experience a common problem. Kevin thought that if Jesse wanted to
avoid spamming maintainers with bogus reports then his patch would
remove about thirty-nine percent of the volume. Jesse was grateful and
excused[10] himself from looking at the patch for a week due to the
pressure of releasing the alpha of Fedora 10.
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01572.html
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01574.html
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01595.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01685.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01728.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01708.html
= Slimming Down Java by Sub-Packaging AOT =
A request to separate out the AOT[1] parts of Java packages into
sub-packages was made[2] by Caolan McNamara. He estimated that it would
be possible to remove circa 45 Mb (in /usr/lib/gcj) as OpenJDK tended to
be installed anyway due to the web plugin.
[1] AOT stands for Ahead-Of-Time. This refers to the static compilation
of the program to produce native code which runs without the potential
run-time performance hit imposed by JIT. JIT stands for Just-In-Time and
refers to dynamic compilation of each method of a Java program
immediately before execution. Although there are techniques to speed up
JIT, by identifying "hot" frequently called methods and caching
them[2a], in general it is believed to be sub-optimal for GUI-based
programs.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01763.html
[2a] http://en.wikipedia.org/wiki/HotSpot
Andrew Haley and Andrew Overholt expressed[3] skepticism that users
would realize that they needed the gcj AOT-compiled code in order to get
good performance. Andrew Overholt stated "one of the reasons we didn't
do this to begin with was because RPM has no notion of Suggests or
Recommends like dpkg does. Debian went this route, but I've seen reports
of people not realizing they needed to install the associated -gcj package."
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01769.html
The advantages of maintaining both AOT and JIT compilation were
argued[4] by Colin Walters. Among the reasons listed by Colin for
keeping a JIT were: "many apps will continue to load code at runtime
from sources that are not Fedora. Think unpackaged Eclipse plugins for
just a start" and that "[a] JIT also has a lot more interesting
information than a normal AOT model. Hotspot does a lot of cool things
there." Colin suggested that "profile driven optimizations",based on
work done in 2001 by JanHubicka (SuSE), Richard Henderson (Red Hat) and
AndreasJaeger (SuSE), might be a way to improve the performance of
JITted programs. On the other hand he recognized that AOT compilation
was useful "because having Hotspot re-profile and recompile the Eclipse
core on everyone's computer is a bit of a waste." Colin followed up[5]
with a putative infrastructure plan involving modifying Koji to create a
new repository of optimized versions of select applications and a YUM
plugin which feeds HotSpot profile data from individuals back to a
central server which in turn is used to further optimize the
compilations. Jeff Spaleta wanted[6] to know if this new repository
would be disabled by default. Toshio Kuratomi was concerned[7] that Koji
should maintain its ability to create a precisely audited build.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01774.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01775.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01792.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01795.html
= Rawhide Network Breakage Due to Wireless Drivers =
A puzzled Richard Jones asked[1] if anyone else had experienced bizarre
networking failures apparently due to DNS lookup failures for web
browsers but not for command line tools. Several confirmations were
posted and Dan Williams warned[2] that "all mac80211-based drivers (b43,
b43-legacy, iwl3945, iwl4965, ath5k, rt2x00)" were broken due to
upstream patching of multiqueue functionality.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01788.html
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01801.html
Ralf Etzinger asked[3] if failure to associate with an Access Point was
one of those expected pieces of "random weirdness." In response to a
follow-up question from Michael Solberg about a failure to associate
using kernel-2.6.25.10-47.fc8 Dan added[4] that only Rawhide kernels
should be affected.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00000.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00008.html
[edit] Possible Slippage of Fedora 10 Alpha?
A brief note from Jesse Keating on Friday requested[1] an IRC meeting
with spin owners, QA, Kernel and other concerned parties to discuss the
problem that "split media"[2] was not working currently. As the Alpha
release is scheduled[3] for August 5th it seems as though there is
little time to solve this problem.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00005.html
[2] The ability to break a set of RPM packages into media images to be
used by anaconda during installation is a difficult one. Currently it is
handled by the pungi module
https://hosted.fedoraproject.org/pungi/wiki/PungiDocs/PungiDocs
[3] http://fedoraproject.org/wiki/Releases/10/Schedule
In an aside Jesse referred to the problem that the "Alphas" are
currently hidden away from the general community and that he would like
to address this at a subsequent ReleaseEngineering meeting.
== Infrastructure ==
This section contains the discussion happening on the
fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: HuzaifaSidhpurwala
= Email aliases and new cvs requests =
Toshio Kuratomi writes for fedora-infrastructure-list [1]
Last week Seth implemented email aliases for the people who should be
notified of changes to packages. Toshio used this new functionality to
have getnotifylist, which looks up who to notify on cvs commits, stop
querying the pkgdb directly (a slow operation with multiple points where
it could fail) and instead just construct the alias from the packagename.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg0...
= YUM security issues...=
Toshio Kuratomi writes for fedora-infrastructure-list [2]
This is a re-post from Josh Bressers. Justin asked if the ability for
mirror admins to select a subnet where they'll serve all of the traffic
has been removed? There is a particular concern about this issue in the
short term. There is a paper about this also [3]
[2]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg0...
[3] http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
= cvsextras renamed to packager =
Toshio Kuratomi writes for fedora-infrastructure-list [4]
cvsextras has been renamed to packager. Any scripts that depends on
querying the "cvsextras" group will now need to query "packager".
[4]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg0...
= Server Monitoring - A replacement for Nagios? =
Nigel Jones writes for fedora-infrastructure-list [5]
While this was intended to be a primary discussion point for the
Infrastructure meeting there was a little bit of discussion first in
#fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like
Nagios that Nigel begun to setup for testing this week.
[5]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg0...
== Artwork ==
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
= New Posters Needed for Fedora =
Paul Frields asked[1] on @fedora-art-list about a new series of posters:
"'Infinity / Freedom / Voice' has been a powerful message and an
excellent way to characterize the themes that went into the Fedora logo.
The logo has become a completely identifiable brand for us, and the
original 'triptych' posters for these themes have allowed our brand to
grow throughout the community. Now, it's time for us to build a
revitalized message around the more concrete themes that characterize
the entire Fedora Project as a whole."
[1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00235.html
Mairín Duffy came up[2] with a concept fitting one of the Fedora 10
theme proposals: "I'm wondering if this could be tied into the F10
artwork theme.... I've been sketching up some steampunky doodles lately.
Maybe I'll do some along these lines. Here are some steampunk-inspired
ideas" (following with a list of ideas[2]) and after receiving positive
feedback even with a graphic sketch [3].
[2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00291.html
[3]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00002.html
= A T-shirt Design for the Upcoming FUDCon in Brno =
Max Spevack asked[1] on @fedora-art-list for a T-shirt design for the
Brno FUDCon: "Since you guys did such an awesome job on the FUDCon
Boston shirts, I was wondering if you'd be willing to make a few
mock-ups of what a FUDCon Brno shirt would look like. I like the idea of
trying to have a bit of design consistency for each year's FUDCon
shirts... so maybe we could keep the front the same (switching the name
of course) and doing something 'similar' on the back?"
[1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00259.html
The request was quickly followed[2] by a design by Nicu Buculei using,
as requested, the same template as the recent FUDCon in Boston, a design
which is generally liked. The discuss touched[3] on a hunt for usable
Brno photos and a number of pieces of technical advice[4] from Mairín
Duffy about vectorizing photos.
[2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00270.html
[3] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00271.html
[4] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00305.html
= The Blue Color of Fedora =
Paul Frields started an interesting debate[1] about the dominant color
used in Fedora graphics: "Does the Artwork team think, overall, that
using a blue palette for our desktop theme (background) helps Fedora
with its identity and branding? Do you want to continue that for Fedora 10?"
[1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00326.html
A large chorus of contributors to the Art Team expressed their support
for using blue, one of the most convincing arguments came from Max
Spevack[2]:"Blue = Fedora. Mix in some other stuff as appropriate, but I
believe that Blue is now 'our' color. We shouldn't give that up. Ubuntu
has brown, OpenSuse has green. Red Hat has red. We have blue.
Personally, I like that we maintain that general blue-ish feel. Play
with the shades if you like, mix in some spice and variety if you like,
but I think Fedora should always be identifiable with the color blue."
[2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00338.html
Of course there are different opinions, like the one voiced[3] by David
Nielsen: "As a user I would love to see us break free of the blue
prison, it looks dated and should be put down with all manners of mercy
possible. I think it hurts us to stick with the blue theme and unlike
other competing distros not work towards a unified look over several
cycles."
[3] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00333.html
== Security Week ==
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
Last week wasn't very exciting as far as security issues go. I have
nothing of interest to note. Next week should be quite busy though.
Black Hat[1] and DEFCON[2] are going on in Las Vegas. Things are
expected to be very busy[3].
[1] http://www.blackhat.com/
[2] https://www.defcon.org/
[3] http://www.networkworld.com/news/2008/073108-black-hat.html?hpg1
= Security Advisories =
In this section, we cover Security Advisories from @fedora-package-announce.
https://www.redhat.com/mailman/listinfo/fedora-package-announce
Contributing Writer: David Nalley
= Fedora 9 Security Advisories =
* filezilla-3.1.0.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00...
* pdns-recursor-3.1.7-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-July/msg0135...
* phpMyAdmin-2.11.8.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-July/msg0131...
* asterisk-1.6.0-0.19.beta9.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-July/msg0129...
* trac-0.10.5-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-July/msg0127...
= Fedora 8 Security Advisories =
* filezilla-3.1.0.1-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00...
* drupal-5.9-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00...
* phpMyAdmin-2.11.8.1-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-July/msg0123...
* trac-0.10.5-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-July/msg0126...
== Virtualization ==
In this section, we cover discussion on the @et-mgmnt-tools-list,
@fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora
virtualization technologies.
Contributing Writer: Dale Bewley
= Enterprise Management Tools List =
This section contains the discussion happening on the et-mgmt-tools list
= Virt-install Remote Guest Creation =
Cole Robinson took[1] a stab at implementing remote guest creation in
virt-install. The main unresolved issue was storage. How to detect it
and how to allow the user to specify it. Michael DeHaan was
interested[2] in teaching koan to install on remote hosts and also
focused on the question of storage specification.
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00277.html
[2] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00278.html
The discussion of storage specification dovetails with the concurrent
discussion of Storage Pool Discovery on @libvir-list (covered below) and
a previous thread[3] on libvirt storage xml.
[3] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00235.html
[edit] Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
= kernel-xen is Dead =
Mark McLoughlin wrote[1] to say the kernel-xen package is dead. That is
to say the kernel package can now support x86 and x86_64 domU guests and
kernel-xen will be dropped from Rawhide. Hiding between those lines is
the fact that there is currently no Dom0 kernel in Fedora 9 or Rawhide.
Without such a Dom0 kernel a domU must be booted via a paravirt_ops
kernel or with the KVM-based xenner.
[1] https://www.redhat.com/archives/fedora-xen/2008-July/msg00044.html
The conversation then turned to the matter of migrating away from Xen
and support for systems without hardware virtualization. Paul Wouters
asked[2] if there was a howto for migration to KVM. It seemed there is
not, but all are encouraged to provide one.
[2] https://www.redhat.com/archives/fedora-xen/2008-July/msg00046.html
Alain Williams realized that Fedora 9 has no Dom0 support after
installing it. When he asked why Mark McLoughlin pointed[3] out the
problems with kernel-xen being based on a much older kernel than kernel
creating a time sink, so the decision was made to re-base to the
upstream kernel which supports paravirt_ops. This decision was first
announced[4] back in Nov 2007 by Daniel Berrange. Mark McLoughlin also
stated[3] that Dom0 support at Fedora 10 launch looks unlikely.
Fortunately we have more positive news on that front below.
[3] https://www.redhat.com/archives/fedora-xen/2008-July/msg00048.html
[4] https://www.redhat.com/archives/fedora-xen/2007-November/msg00106.html
Dale Bewley bemoaned[5] the fact that he has no budget to upgrade to HVM
capable hardware and will have to stick on Fedora 8 until Fedora 10 has
Dom0 support. Stephen Smoogen pointed[6] out that RHEL5 and CentOS5 are
options for Dom0 on non-HVM hardware. Daniel Berrange expressed[7] some
empathy and the desire for such support, but reiterated it isn't viable
until Dom0 is ported to pv_ops.
[5] https://www.redhat.com/archives/fedora-xen/2008-July/msg00049.html
[6] https://www.redhat.com/archives/fedora-xen/2008-July/msg00052.html
[7] https://www.redhat.com/archives/fedora-xen/2008-July/msg00053.html
= State of Xen in Upstream Linux =
Pasi Kärkkäinen thoughtfully forwarded[1] a long detailed xen kernel
status message which was sent to the @xen-devel-list by Jeremy
Fitzhardinge. Jeremy pointed out that mainline kernel is at 2.6.27-rc1
and his current patch stack is pretty much empty after being merged into
linux-2.6.git.
[1] https://www.redhat.com/archives/fedora-xen/2008-July/msg00058.html
Jeremy stated that Fedora 9's kernel-xen package was based on the
mainline kernel even though it's been a separate package. Now that
kernel-xen has been dropped from rawhide there will be only one kernel
package in Fedora 10. Jeremy said his focus in the next kernel
development window will be obvious missing dom0 support with the hope it
will be merged into 2.6.28. That work will likely take place in a
xen.git on Xen.org. Jeremy then provided his long TODO list with a
request for help fullfilling it. In addition he asked what's missing.
Paul Wouters followed up[2] on Jeremy's question of "What's missing?"
with the answer of a lack of entropy in the guests. Daniel Berrange
mentioned Rusty Russell's VirtIO-RNG patch from this thread. Thorsten
Leemhuis provided a link to this LWN article on the subject of entropy
sources and showed that this patch is in 2.6.26.
[2] https://www.redhat.com/archives/fedora-xen/2008-July/msg00059.html
[3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00000.html
= Creating Multiple Xen Bridges =
Andy Burns asked[1] for a clean way to utilize the two NICs in a Dom0
server as multiple bridges. Kanwar Sandhu recommended[2] editing
xend-config.sxp to utilize a very small custom network-bridge-wrapper
script also provided in the post. Another option pointed[3] out on the
list was to short-circuit xend-config.sxp and configure all networking
by hand in /etc/sysconfig/network-scripts.
[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00004.html
[2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00005.html
[3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00008.html
= Libvirt List =
This section contains the discussion happening on the libvir-list.
= PATCH: Storage Pool Discovery =
David Lively refered[1] to a post[2] on "Storage Management APIs" by
Daniel Berrange when he posted a patch to implement
virConnectDiscoverStoragePools. As the API continues to be solidified,
this patch implements discovery for only logical and netfs storage pools.
Daniel Berrange pointed[3] to the Storage Management page on libvirt.org
as an appropriate place to document the XML used for srcSpec.
[1] https://www.redhat.com/archives/libvir-list/2008-July/msg00502.html
[2] http://www.redhat.com/archives/libvir-list/2008-February/msg00107.html
[3] https://www.redhat.com/archives/libvir-list/2008-August/msg00013.html
= PATCH: Fix Setting of Bridge Forward-delay =
Christoph Höger described[1] a problem which caused a bridge to not pass
traffic for a number of seconds after activation. Just a few minutes
later Daniel Berrange posted[2] a fix for a bug which caused libvirt to
ignore the forwarding delay when it was set to 0. The workaround in the
meantime is to set fd=1.
[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00017.html
[2] https://www.redhat.com/archives/libvir-list/2008-August/msg00020.html
Daniel Veillard plus-oned[3] that patch and expressed that with the last
release having been on June 25th, it may be time for a new release.
Daniel Berrange mentioned[4] that the Xen & QEMU refactoring needs more
testing, and the LXC and OpenVZ drivers need porting to the new XML
routines. Richard W.M. Jones wanted[5] to get virsh edit in. The last
word[6] was to delay another week.
[3] https://www.redhat.com/archives/libvir-list/2008-August/msg00025.html
[4] https://www.redhat.com/archives/libvir-list/2008-August/msg00030.html
[5] https://www.redhat.com/archives/libvir-list/2008-August/msg00034.html
[6] https://www.redhat.com/archives/libvir-list/2008-August/msg00036.html
= oVirt Devel List =
This section contains the discussion happening on the ovirt-devel list.
15 years, 11 months
- 1
- 0
bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage | August 2nd, 2008 - 9:00 AM EST - 11:00 PM EST
by Dave Lawrence
Update:
The bugzilla.redhat.com upgrade is now complete.
Note:
A database dump is currently running to allow us to update the
slave database for replication. So the system may seem sluggish
for a few more hours.
Please send any feedback/comments to bugzilla-owner(a)redhat.com. Please file
any bugs you find in Bugzilla against the Bugzilla product, version 3.2.
Thanks
Engineering Operations.
=====================================
O U T A G E R E Q U E S T F O R M
=====================================
Severity:
Severity Two (High)
Scheduled Date:
August 2nd, 2008
Scheduled Time:
9:00 AM EST - 11:00 PM EST
Estimated Time Required:
10 hours
Performed By:
Red Hat Engineering Operations
People/Groups Impacted:
Users of bugzilla.redhat.com and any services that rely on bugzilla.redhat.com
Site/Services Affected:
bugzilla.redhat.com Web UI, Database, XMLRPC
Impact:
bugzilla.redhat.com will be unavailable during the posted
time on August 2nd, 2008.
Description:
On August 2nd, bugzilla.redhat.com will go down for an
update to the latest upstream code base. During this time
the web servers will be reinstalled with the latest OS
updates as well as the latest Bugzilla code. Also the
database servers will undergo a data migration to be made
compatible with the latest Bugzilla code. The web UI,
database, and all XMLRPC services will be unavailable during
the migration. Services that rely on bugzilla.redhat.com may
not function properly during this time so please let your
users know about the outage as well.
Also please take time to point your services/scripts at our
test server https://partner-bugzilla.redhat.com to make sure
that they will still work with the new system once it goes
live. Care has been taken to make the new system backwards
compatible as much as possible with the old XMLRPC API but
still confirm that they work properly. If you encounter any
problems, please contact bugzilla-owner redhat com or file a
bug at
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=3.2
Signoff:
kbaker redhat com
--
David Lawrence, RHCE dkl(a)redhat.com
------------------------------------
Red Hat, Inc. Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606
15 years, 11 months
- 1
- 0