Fedora Week News, Issue 143
by Huzaifa Sidhpurwala
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fedora Weekly News Issue 143
============================
Welcome to Fedora Weekly News Issue 143 for the week ending September 7,
2008.
http://fedoraproject.org/wiki/FWN/Issue143
This week Announcements trumpets the arrival of a new version of Bodhi,
the freeze of Rawhide and some essential reading on the new package
keys. In Developments we shock you with "Non-X System Consoles to be
Removed". Virtualization alerts you to "Virt-manager 0.6.0 Released" and
dives into how developers are "Laying the Groundwork for Xen Domain 0
Support". The ever entertaining Artwork beat examines "How to Select a
Winning Theme" and SecurityAdvisories provides a handy list for your
perusal.
If you are interested in contributing to Fedora Weekly News, please see
our 'join' page[1].
[1] 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 8 and 9 Updates
Jesse Keating wrote more[0] about the status of updates on Fedora 8 and
Fedora 9. "We're in the final stages of testing a few corner cases, and
preparing the official builds of fedora-release, PackageKit,
gnome-packagekit, and unique (needed as a new dep for gnome-packagekit).
All existing updates in the old update locations will be purged, and
just these updates will be put in their place, signed with our old key.
Once you've updated to these packages, the next update attempt will
point you to our new locations with our new keys and you should be able
to process any further pending updates. You'll be prompted to import the
new key along the way."
Additionally, "these updates are designed to transition users from our
old repo locations to new locations that have all our updates re-signed
with a new set of keys[1]."
I encourage everyone to read both announcements, and also to visit the
information page on the Fedora wiki[2].
[0]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg000...
[1]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg000...
[2] https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key
Bodhi 0.5!
Luke Macken has been very active in Bodhi development lately[3].
"One of the most noticable changes is that bodhi is much more
responsive. Previously, bodhi was a single python process, running on a
single server. This single server was also responsible for composing the
updates repositories, and rawhide, among lots of other bodhi-related
churn. This lead to much pain and suffering for all.
The bodhi deployment has since changed. All bodhi requests are now load
balanced to a bunch of app servers, each running mod_wsgi with multiple
bodhi processes, each with multiple threads. All of the hard work is now
done on an isolated releng server. This separate bodhi "masher" is now
responsible for composing repositories, updating bugs, generating update
notices, sending emails, extended metadata generation, and calculating
metrics. I also added support for inter-bodhi communication, which
allows our bodhi web frontends to kick off push requests to our
bodhi-masher instance."
Plenty more new-feature discussion in the full email.
[3]
http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00...
Frozen for Fedora 10 Beta
Jesse Keating announced[4] that Rawhide is now frozen for Fedora 10
Beta. "Rawhide will compose from the frozen content so that we all are
aware of what Beta is going to be comprised of. Extra scruitiny and
testing of rawhide over the next week is greatly appreciated."
[4]
http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00...
=Developments=
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
External Repositories and the New Keys
As a result of the re-signing all the packages with a new key as a
security precaution[1] some problems with packages from third-party
repositories were reported[2] by Callum Lerwick. The specific example
was an update of the non-Free "xine-lib-extras-nonfree". Seth Vidal
suggested[3] a simple fix of yum --skip-broken update.
[1] https://fedoraproject.org/wiki/FWN/Issue142#Getting.Back.on.our.Feet
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01070...
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01072...
Jef Spaleta experienced[4] no such error and speculated that it was due
to some mirrors being temporarily out of sync, which Matthew Woehlke
agreed[5] was likely. Kevin Kofler disagreed[6] and diagnosed the
problem as a "chicken and egg" one in which it was impossible to get the
new repository key which in turn would enable the new, matching xine-lib
to be obtained. He suggested that while it was possible to use yum
- --skip-broken or yum --exclude for a selective update it would be better
for new users to "[...] use the PackageKit GUI, click on "Review
updates" and uncheck the xine-lib-extras-nonfree update, then apply."
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01073...
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01090...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01124...
Thorsten Leemhuis thought[7] that this was a general problem for the
livna repository in which they can only "push [too] early or [too]
late". He had outlined the problem previously (see FWN#138 "Solving the
Unsynchronized Release of Package Dependencies"[8]) but his suggested
solution of adding a brief time period during which yum keeps checking
for missing dependencies had not obtained traction. Thorsten explained
again: "[...] the problem happens each time when Livna/RPM Fusion
packages with deps on a specific Fedora packages get pushed in sync;
that creates a lot of trouble * I'd say once for 24 hours each two
weeks." He conceded[9] that yum --skip-broken was "[...] best answer,
but that's not enabled by default in Fedora. Livna/RPM Fusion could fix
that via its releasepackages, but that's not nice and I want to avoid
going that route."
On the foot of a suggestion made[10] by Harald Hoyer to add "More
Information button in PackageKit dialogs, which explains the situation
and that this might only just take some days to resolve[.]" Richard
Hughes asked[11] for specific suggestions to improve the current
dialogs. He added that "[m]y personal view is that by showing an error
dialog, we've lost, and should avoid doing it at all costs." Thorsten
responded[12] to Harald that he believed that it was best to "[...]
enable skip-broken by default, but show the error to the user if
security updates are involved *or* if the problem doesn't vanish within
72 hours after it had been hit on the client for the first time" and
that for the latter cases PackageKit could show some more information.
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01097...
[8]
http://fedoraproject.org/wiki/FWN/Issue138#Solving.the.Unsynchronized.Rel...
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01080...
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01143...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01149...
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01144...
Non-X System Consoles to be Removed
ArthurPemberton was concerned[1] about the best way to help debug the
many [PulseAudio] issues which he was experiencing on Fedora 9. He asked
"[w]hat information should I gather, how, and where should I present
it?" This innocent enquiry spawned several sub-threads which avoided
answering his question.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00982...
In the first Bill Crawford recommended[2] disabling PulseAudio and
although Ignacio Vazquez-Abrams listed features unique to it Karel Zak
was[3] skeptical that "ordinary" users would need them. Toshio Kuratomi
responded[4] that the network transport features were very useful for
thinclients.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01053...
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01107...
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01110...
Janina Sajka chimed in[5] to agree with Arthur that while the idea of
PulseAudio was appealing and "[...] holds great promise for
accessibility [...]" there appeared to be practical problems to sort
out. Janina referenced SpeakupModified.org, which provides repositories
for a Fedora-derived distribution tailored towards users that rely on
audio cues instead of visual ones, and noted that it was currently
necessary to disable PulseAudio because "[...] one gets no audio until
after a user logs in on the GUI. So, how are those who need screen
reader support supposed to use the a11y features of GDM? As it stands,
there seems no way to get console audio without that GUI login. Also a
nonstarter in the screen reader user community." She asked if anyone had
a "working init script for pulseaudio as a system daemon?" None of the
many message that followed appeared to have an answer to this question.
In part this appeared[6] to be because < Orca can handle the audio
rendering of the GDM login screen. Colin provided[7] references that
should make it possible to configure GDM to work this way out of the box
using GConf settings. It seemed[8] that this was a possible solution.
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01179...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01189...
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01213...
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01240...
At this point Colin Walters set off a firestorm of complaints and
queries when he announced[9], as an aside, that "[w]e're going to be
removing the legacy non-X system consoles by default in the long run."
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01180...
Jerry james listed[10] three scenarios in which he felt it would be very
useful to have text consoles. The advantages included faster startup
than with Xorg and independence from a damaged X session. Colin
rebutted[11] most of these with the argument that "login is slow" was a
bug which should be fixed and that the other scenarios also were
constructed on the basis of bugs which should be fixed (in the
applications themselves and in Xorg's ability to handle crashes.)
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01186...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01190...
Matthew Woehlke also wondered what would happen if Xorg itself was
broken and Colin asked[12] rhetorically "What happens when the linux
kernel is broken? What happens when /bin/sh is broken? What happens when
NetworkManager is broken?" He added that a compressed recovery image
should be included by default in a Fedora install. Matthew's response
suggested[13] that although it would be possible to recover it would
mean having to find a rescue disk and to reboot. He expressed a
preference for "[having] X fail to start and dump me at a normal console
from which I can fix the problem *without rebooting*, much less needing
to dig up a rescue disk :P" and compared the alternative to the
fragility of Windows. The issue then became a little clouded when Colin
stated "I believe we already do that today, and am not advocating
removing that functionality if possible. Anyways, I've said what I need
to, so hopefully people won't be surprised later." Further
requests[14][15] for clarification on the previous statement produced no
simple response, although later Colin did appear to confirm[16] the
impression that he saw this as an essential change for the evolution of
Fedora as a Desktop.
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01194...
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01197...
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01199...
[15]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01203...
[16]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01209...
make force-tag Gone
The removal of make force-tag was objected to[1] by Bastien Nocerra as
it forced bumping the Release of packages even for trivial changes. A
massive thread resulted with a good deal of agreement expressed with
Bastien.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00675...
Mike McGrath made[2] the case that if maintainers tested packages before
committing them and adduced the necessity of the current workflow in
producing an audit trail for licensing as a concrete reason. Jon Ciesla
had earlier mentioned using TAG_OPTS=-F make tag as a work around and
now asked[3] if "the Makefile can be modified to prevent it, so that
others who didn't know [that this invalidates the audit trail] stop
doing it?" Doug Ledford responded[4] that this would be unenforceable as
it would still allow the CVS command to be run by hand and "[i]f our
recent 'incident' showed us anything, it's that things like this need to
be enforced on the CVS server if they are going to be enforced at all."
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00725...
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00736...
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00904...
Jesse Keating argued[5] that the issue was more GPL compliance than an
audit trail and outlined why he would personally prefer to move away
from building from CVS tags. Jef Spaleta suggested[6] that Mike McGrath
had misspoken: "You are of course free to make 300 small separate
specfile changes between each build attempt. There is a desire to move
to a point where we can be reasonably sure that a cvs tag corresponds to
a specific build. Since we have no way of making only tags corresponding
to successfully built packages immutable, all tags must be immutable"
and like Mike asked for a way to mark as immutable a subset of CVS tags
corresponding to a successful Koji build.
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00740...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00786...
The thread is recommended reading for package maintainers and the brief
summary above misses many important points.
Graphics Modesetting Changes
A post by Dave Airlie reminded[1] the list that [KernelModesetting][2]
was going to be one of the notable features of Fedora 10 for recent
Radeon "r300 to r500 (and possibly r600/r700)" and Intel "from i830 to
GM45 (though it may end up i915 and up only)" GPUs . Adam Jackson
responded[3] to Bill Crawford that r200 class hardware would probably
not get modesetting in Fedora 10. Among other things this will have
cosmetic advantages such as removing flickers from the startup sequence,
reducing Xorg startup times and practical advantages such as oops/panic
messages while Xorg is running and improved suspend/resume support. Dave
cautioned that only a subset of the GPUs were working for the beta
release "[...] r300 to r500 class of hardware, while we await upstream
changes to the Intel driver" and noted that to disable modesetting one
should append nomodeset to the kernel command line via GRUB.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00991...
[2] https://fedoraproject.org/wiki/Features/KernelModesetting
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01019...
In response to Hans de Goede Dave welcomed[4] bug reports of the "output
doesn't light up" type and suggested using an ssh session to reboot to
runlevel 3 with nomodeset and then rmmod radeon drm; modprobe drm
debug=1; modprobe radeon modeset=1 and attach dmesg and an Xorg log to
the bugzilla entry. Following this recipe produced[5] no luck for
"Joshua C." as everything froze once he followed the last step.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01004...
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01018...
Skepticism about inserting the Intel driver code after the beta testing
period was expressed[6] by Jeremy Katz on the foot of such late changes
lacking both the visibility necessary for testing and the time to fix
any bugs revealed. Jeremy was mildly scathing: "Yeah, I've seen intel's
'mature' code before. Excuse me if this is anything but reassuring."
Jesse Keating and Christopher Snook seemed[7] to accept Jeremy's point
and leaned towards the idea of implementing the KernelModesetting
contingency plan[8] of including the modesetting code disabled by
default, but allowing users to enable it on the kernel command line.
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01036...
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055...
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055...
Adam Jackson wondered whether Jeremy was advocating removing all the new
code or testing it all and Jeremy suggested[9] the third option of only
enabling the radeon code for now and waiting for Fedora 11 to enable the
Intel code.
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01068...
When "Joshua C." asked[10] for a list of working radeon cards and
suggested applying the contingency plan because "f10 is just a month
away" he was corrected [11] by Paul Frields that it was approximately
two months away with a development freeze in six weeks. Dave asked[12]
Joshua to "[...] stop scare mongering[,] it's a beta release, if it
still doesn't work at devel freeze I'll blacklist all the broken
machines" which reaction surprised[13] Joshua a little.
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01077...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01115...
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01117...
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01147...
Root Login Disallowed on GDM
Surprise was expressed[1] by "Dr. Diesel" when he attempted to log in as
root via GDM[2] to a rawhide install. "Dr. Diesel" reported that it was
possible to log in via the console in runlevel 3. He asked if he should
file a bugzilla entry.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01205...
[2] http://www.gnome.org/projects/gdm/
Darrell Pfeifer quoted[3] the changelog as evidence that this
restriction was intentional to which "Dr. Diesel" responded that it
would be a good idea to change the prompt to "[...] something like 'Root
login disabled'[.]". Matthew Woehlke was disturbed and wondered "[...]
what exactly are we supposed to do when the user login gets hosed? Reach
for a rescue disk? (Seriously, what's with the sudden trend to make
fixing problems harder by making recovery modes inaccessible in an
apparent bid to hide the "confusing/potentially dangerous" bits of the
system from the user?)" The latter part of this apparently being a
reference to another recent thread (see this FWN#143 "Non-X System
Consoles to be Removed".)
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01206...
Benjamin Lewis presented[4] a straightforward, obvious way of fixing
such problems: "CTRL+ALT+F1, login as root, fix it, CTRL+ALT+F7 to get
back to GDM" and Martin Sourada added "[or] boot to runlevel 3, login as
root there and startx..."
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01225...
The discussion was moved on[5] by Nigel Jones with a suggestion that the
default setup should configure sudo to allow the first user configured
during firstboot to have "full access w/ password." Steven Moix
disagreed[6] as this all seemed like the "Ubuntu 'protect us from
ourselves' way" which removed the conscious choice to log in as root.
Martin Sourada was also filled[7] with dismay at the idea, but his
objection was that PolicyKit was a superior solution to sudo. This
preference was confronted[8] by Thorsten Leemhuis with a request to
"[...] please tell me how for example read /var/log/messages or other
log files from /var/log/ using PolicyKit from a -gnome,kde-terminal with
an easy to remember and fast to type command (like 'sudo') [.]" Thorsten
also suggested that firstboot could present a checkbox labeled "User is
the sysadmin for this system" that when checked would configure sudo
and/or PolicyKit or any other desiderata for allowing root privileges
for the user. Matthew Miller largely agreed with this and suggested that
"uncommenting the wheel group in /etc/sudoers, and having said checkbox
add the user to the wheel group" would be the way to do it, but Seth
Vidal raised[9] the problem of "[...] the wheel group, on systems which
are using some other form of nss than local files, can be mucked with
too easily."
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01222...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01224...
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01228...
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01233...
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01238...
All this was strangely reminiscent of previous discussions, e.g. FWN#103
"Root Login And Display Managers In Rawhide"[10] except that PolicyKit
now offers some possible new directions as Martin Sourada outlined[11:]
"What I am mostly against is having full access to sudo without password
by default by any user. I believe PolicyKit is designed to solve this
issue by granting rights (by admin) to user to do this and that and not
do other admin tasks [...] the implementation should IMHO be like
cat/nano/vi/whatever detects that you are trying to access some file you
don't have enough rights to access, then it asks PolicyKit whether to
allow it or not and PolicyKit handles the rest (i.e. checks whether your
admin already allowed that access for you, if not asks for root password
for allowing the access and if succeeded sends back that its OK for you
to access the file). Ideally it wouldn't require any additional command
(like sudo) [...] When I want to view logs (though I don't very much
understand why I cannot read them as normal user) I just log in as root
(in console/gnome-terminal only!). Yeah it's not pleasant to write root
password every time I want to do some admin task - and that's probably
one of the reasons why PolicyKit has been developed - but I think
allowing full access to sudo without password for normal user account is
a big security hole."
[10]
http://fedoraproject.org/wiki/FWN/Issue103#Root.Login.And.Display.Manager...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01237...
Missing Screen Locking Spurs Inquiry Into User-state Maintenance
When John Ellson enquired[1] why "[...] my userid, and only my userid,
has no Lock Screen menu item or applet?" a brief thread revealed the
many places in which user state is kept. The answer, for the impatient,
turned out[2] to be that John had experimented with Pessulus[3], which
allows administrators to enforce mandatory GConf settings on users.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01027...
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01108...
[3] http://live.gnome.org/Pessulus
John's first pass at the problem was to wipe out some dot files rm -rf
.gnome .gnome2 .gconf .gconfd .metacity and this failed to restore the
default. Chris Snook suggested[4] that he consider /tmp</cod> as another
location where "per-user state is kept" but John had investigated[5]
both <code>/tmp and /var/tmp.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01031...
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01034...
Jesse Keating wondered[6] if "[...] it's not a ConsoleKit interaction
making the session think your user isn't at the console?" John replied
that he had gone to the extraordinary lengths of "moving aside my home
directory, deleting my userid, removing everything in /tmp and /var/tmp,
rebooting creating a new userid with the same name (but different user
and group numbers), and it still has no Lock Screen!!!" Jef Spaleta
made[7] the disclaimer that he did not "[...] understand
PolicyKit/ConsoleKit well enough to help you track it down in the
filesystem with 100% confidence[...]" but suggested searching in
/var/lib/PolicyKit and /var/lib/PolicyKit-public for per-user
authorization rules. This was reported[8] as fruitless by John, as was
running polkit-auth. John wondered where the output of polkit-auth came
from as "Removing /var/lib/PolicyKit/user-ellson.auths doesn't change
the output."
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01040...
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01050...
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01059...
MatthiasClasen cut straight to the chase and suggested[9] a good,
old-fashioned backtrace "Why don't we stop all this blind guessing, and
attach a debugger to the panel instead ? It would be so much easier..."
Although John wondered[10] why gnome-panel sprang to Matthias' mind as a
culprit a later suggestion[11] to "[...] break in
panel_lock_screen_action_available [...]" gave him a clue as to the problem.
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01064...
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01074...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01076...
Pessulus has been around since Fedora 7 at least and the process above
was a bit of a wild goose chase, but what is interesting is how
difficult it is to solve such a problem due to the many places in which
such information is stored.
=Infrastructure=
This section contains the discussion happening on the
fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: HuzaifaSidhpurwala
More puppet training!
Mike McGrath writes for fedora-infrastructure-list [1]
Mike proposed that he is going to hold a couple of trainings for Puppet
on fedora-infrastructure. And asked if any one had questions etc to be
included in the training.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September...
Removal of old projects from fedorahosted.
susmit shannigrahi writes for fedora-infrastructure-list [2]
Susmit reminded the list that, Fedora has a policy to remove _any_
hosted projects that are not altered or updated for last six months. And
provided a list of projects, which falls into this category and they
will soon be removed.
[2]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September...
Beta Freeze
Mike McGrath writes for fedora-infrastructure-list [3]
Mike reminded everyone that the beta freeze is going to live and it will
end on 2008-09-24. This is the first pre-release freeze type the
infrastructure team has had [4]
[3]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September...
[4] http://fedoraproject.org/wiki/Infrastructure/SOP/Release#Change_Freeze
=Artwork=
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
How to Select a "Winning" Theme
MairinDuffy opened[1] a debate on @fedora-art about the best way to
select the final theme in a release: "We have not yet had a case where
more than one theme met this basic requirement. In case we do have
multiple themes that meet this requirement, we need a fair method to
choose which theme is selected as the default" and going further, she
proposed a solution and asked for opinions: "My suggestion is that we
have a vote within the set of active Fedora art team contributors. The
problem is how do we determine who is allowed in this vote - who is
active? "
[1]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00095.html
SamueleStorari opted[2] for a wide vote in the community "I think the
vote will be totally open to the whole community." arguing that "the
graphic it's made for all, think about art, think about expression, it
comes from the inside need of someone to express to other, to
comunicate.", an opinion endorsed by MariaLeandro[3] and IanWeller who
proposed[4] an alternate and complex system "Or, perhaps even better,
take a two-part voting approach; 50% of the vote allocated to current
Art Team members (recent contributions, 6 months, yada yada) and 50% for
the community."
[2]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00099.html
[3]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00105.html
[4]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00114.html
On the other hand, NicuBuculei opposed[5] the community vote invoking
the notion of competence "the trouble is that the large community knows
little about usability and good design", an opinion similar to that
expressed[6] by MatthiasClasen "Taste is not something that can be
decided with simple majority. Voting for the default theme would pretty
much devolve into 'which is the coolest looking background when glancing
at a bunch of screenshots', which is not at all what a good default
theme is about. This forum is the place for qualified and interested
people to work on the art that makes up the default theme. It should
also be the place where the default theme gets put together."
[5]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00101.html
[6]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00116.html
Another argument against a community-wide vote was raised[7] by
MairinDuffy "we don't really have time to plan for a Fedora-wide vote,
and since there's not much time to wait on people to vote and to get the
word out, we won't have a good representation of our base in the vote
results."
[7]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00106.html
- From his position as a Fedora Board member, JeffSpaleta came to the
conclusion "I consider the multiple rounds of discussion over the themes
as a prolonged 'community' decision. The final artwork decision is a
culminating event in a process. Are people encouraged to participate in
the earlier stages of that process as part of the art team? if they
choose not to participate in the previous rounds do they have the
context to make informed decisions at the final stage? Have they earned
the right to be a part of the final decision? I'm not sure they do."
[8]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00111.html
As a solution to get the themes as soon as possible into the hands of
the users and receive early feedback MairinDuffy issued a last-minute
call[9] for packaging the current proposals into Fedora 10 Beta "if we
could get a package put together with the wallpapers that are in the
running so far it could make the Beta." The call answered quickly by
MartinSourada [10], who created the packages.The packages were reviewed
and are already available in Rawhide.
[9]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00123.html
[10]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00137.html
=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
* amarok-1.4.10-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* libtiff-3.8.2-11.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* awstats-6.8-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* openoffice.org-2.4.1-17.6.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* Django-0.96.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* gnome-packagekit-0.2.5-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* fedora-release-9-5.transition -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* PackageKit-0.2.5-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bitlbee-1.2.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bluez-libs-3.35-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bluez-utils-3.35-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* rpy-1.0.3-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* R-2.7.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* samba-3.2.3-0.20.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wordpress-2.6.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* xastir-1.9.2-9.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* libxml2-2.6.32-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* xine-lib-1.1.15-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* adminutil-1.1.7-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* drupal-6.4-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* fedora-ds-base-1.1.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wordpress-2.6.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bitlbee-1.2.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* poppler-0.8.1-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* httrack-3.42.93-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* fedora-release-9-5.transition -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* tomcat6-6.0.18-1.1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wireshark-1.0.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* libHX-1.23-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* gnome-packagekit-0.2.5-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* pam_mount-0.47-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* PackageKit-0.2.5-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* ipa-1.1.0-7.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
Fedora 8 Security Advisories
* fedora-release-8-6.transition -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* Django-0.96.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* amarok-1.4.10-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* libtiff-3.8.2-11.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* libxml2-2.6.32-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* xine-lib-1.1.15-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* xastir-1.9.2-8.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* adminutil-1.1.7-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* rpy-1.0.3-3.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* R-2.7.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* yelp-2.20.0-12.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* drupal-5.10-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bitlbee-1.2.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* awstats-6.8-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* openoffice.org-2.3.0-6.16.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wordpress-2.6.1-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bitlbee-1.2.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wordpress-2.6.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* fedora-ds-base-1.1.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* httrack-3.42.93-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wireshark-1.0.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* libHX-1.23-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* pam_mount-0.47-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* ipa-1.1.0-4.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
=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-manager 0.6.0 Released
Cole Robinson announced[1] the release of virt-manager[2] 0.6.0.
Features include:
* Remote storage management and provisioning
* Remote VM installation
* Use Avahi to list libvirtd instances
* Virtio and USB options when adding a disk device
and many more.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00026.html
[2] http://www.virt-manager.org
Virtinst 0.400.0 Released
Cole Robinson announced[1] the release of virtinst 0.400.0. Features
include:
* New tool 'virt-convert'
* New tool 'virt-pack'
* Support for remote VM installation
* Use virtio disk/net drivers if chosen os entry supports it
and many more.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00027.html
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Laying the Groundwork for Xen Domain 0 Support
There are further developments in the state of Xen in upstream Linux
(see FWN#137[3]). Pasi Kärkkäinen forwarded[1] a patch announcement[2]
from xen-devel list. This set of seven patches begin to lay the
groundwork for Xen domain 0 support.
[1] https://www.redhat.com/archives/fedora-xen/2008-September/msg00001.html
[2]
http://lists.xensource.com/archives/html/xen-devel/2008-09/threads.html#0...
[3]
http://fedoraproject.org/wiki/FWN/Issue137#State_of_Xen_in_Upstream_Linux
Daniel P. Berrange said[4] these patches will make their way into
rawhide when they are merged into the LKML[5] dev tree line used by
rawhide at that time.
[4] https://www.redhat.com/archives/fedora-xen/2008-September/msg00003.html
[5] http://lkml.org
Libvirt List
This section contains the discussion happening on the libvir-list.
Libvirt 0.4.5 Released
Daniel Veillard announced[1] the release of libvirt 0.4.5. In addition
to a long changelog, the "main features are the improvement of OpenVZ
and LXC, the uniform XML handling (and hence format) th[r]ough all
drivers, improvements in devices handling for QEmu/KVM and storage pool
source discovery."
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00186.html
Segfault if no Qemu Emulator Passed
Cole Robinson patched[1] a bug that resulted in a segfault if a Qemu
domain is defined without an emulator value. Daniel Berrange
expressed[2] displeasure at letting this bug slip through and proposed a
"brown paper bag" release. Daniel Veillard advised[3] against rushing
the fix, and offered to push the patch to Fedora's build while other
distributions could pick up the fix in a week or two when libvirt 0.4.6
would presumably be released.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00199.html
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00202.html
[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00206.html
Daniel Berrange pointed out code test coverage reports[4] on the build
server, and highlighted the need to create a functional test rig for the
mass of code that is simply not possible to unit test due to
interactions with host OS state / functionality.
[4] http://builder.virt-manager.org/module-libvirt--devel.html
Ability to Nice KVM Processes
Henri Cook expressed[1] a desire to nice KVM processes, and proposed a
means to pass arbitrary command string parameters to the process startup.
As mentioned[2] in FWN #141, Daniel Berrange pointed out[3] the goal of
libvirt is consistent API representation across hypervisors. Fortunately
there is a 'schedular parameters' API in libvirt. All that's needed is
for someone to implement the schedular parameters driver API for KVM.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00209.html
[2]
http://fedoraproject.org/wiki/FWN/Issue141#Exposing_Unique_Hypervisor_Fea...
[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00210.html
RFC Thoughts on Open Source Hypervisor Management
Nathan Charles described[1] his ideal clustered VM provisioning system.
Features would include
* cluster administration is done from the command line
* cluster administration can be performed from any node
* a new node can join a cluster on a local subnet with one command
* local storage resources are presented to the cluster so there is
no need to have predefined NAS/SAN/iSCSI
* cluster will load balance vm instances from node to node
* a node shouldn't need more than one nic but adding additional
nic's provides failover and load balancing
Nathan acknowledged oVirt's virtues, but stated it requires a lot of
substantial changes and significant modification to work with an
existing provisioning infrastructure. Nathan requested comments on his
thoughts.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00195.html
The only reply[2] so far came from Stefan de Konink, who pointed to some
code[3] which seems[4] to be a "handler for libvirt using avahiclient".
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00196.html
[3] http://repo.or.cz/w/handlervirt.git
[4] http://kinkrsoftware.nl/projecten.html#virt
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
oVirt Source Repository Refactored
Perry N. Myers announced[1] the completion of the restructuring of the
oVirt source mentioned in FWN #142[2]. This reorganization resulted in
commits of numerous spec files and other changes making an RPM-based
install more feasible.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00145.html
[2] https://fedoraproject.org/wiki/FWN/Issue142#Renaming_oVirt_RPMs
oVirt Migration Status
Atsushi SAKAI asked[1] if the following assumptions were true. KVM
supports migration, while Qemu does not. Ovirt release supports
migration, developer version does not. Chris Lalancette clarified[2]
"there is live migration code in upstream kvm userspace, but not in
upstream qemu" and fully emulated guests can be live migrated as long as
the KVM binary is used to do it (which ovirt does).
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00107.html
[2] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00108.html
Atsushi inquired of the fake managed nodes, and Chris Lalancette
explained[3] the fake managed nodes are abstractions to allow
experimenting oVirt with limited hardware. Perry N. Myers added[4] there
is work underway to remove the 'fake node' concept.
[3] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00110.html
[4] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00111.html
Network Interface Bonding and Failover Work Continues
Darryl L. Pierce continued[1] work on NIC bonding and failover (see FWN
#142[2]) laying out the process a node will use to configure interfaces
on bootup and the selection of bonding type which must be selected on
the server. Types include
* Load Balancing
* Failover
* Broadcast
* Link Aggregation
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00243.html
[2]
https://fedoraproject.org/wiki/FWN/Issue142#Network_Interface_Bonding_and...
Daniel P. Berrange inquired[3] if those four options was a limit of the
bonding driver or a design choice, since more complex bonding
configurations are plausible. Darryl L. Pierce affirmed[4] it is a
design choice to keep things simple initially. Chris Lalancette
pointed[5] out there are many combinations of bridges, bonds, and VLANs,
and "we have to figure out which combinations are completely insane,
which are valid and make sense, and then make sure we can handle those."
[3] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00244.html
[4] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00245.html
[5] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00246.html
Related discussion occurred in another[6] thread on how to configure
multiple bondings for a host in the UI.
[6] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00262.html
Other Virtualization News
This section contains virtualization news which may not have been
directly discussed on the above mailing lists.
Red Hat Acquires Makers of KVM, Qumranet Inc.
On September 4, 2008 Red Hat acquired[1][2] Qumranet, Inc., the inventor
and key maintainer of KVM. Qumranet also develops Solid ICE[3] which
runs a user's desktop in a KVM virtual machine in the data center with
users connecting via thin client or other options.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFIzjJtzHDc8tpb2uURAt7cAJ4wbxy9uFmQ8YBiE4+4mhWr3ZVewgCdFbzR
EQCCTko6S8KVR4HASblGW+g=
=toBe
-----END PGP SIGNATURE-----
15 years, 7 months
Fedora 8 and 9 updates re-enabled
by Jesse Keating
In a few hours, updates for Fedora 8 and Fedora 9 will start hitting
mirrors. These updates are designed to transition users from our old
repo locations to new locations that have all our updates re-signed with
a new set of keys.
Most users will simply need to apply the offered updates, and later
apply any further updates, and verify/import the new GPG key.
The process to getting new updates is two stage.
Stage 1) Users configured to get updates from existing repos will see a
small set of updates available in the next few hours/days. These
updates include fedora-release, PackageKit, gnome-packagekit, and unique
(for Fedora 8, only fedora-release is offered). These updates should be
applied as soon as possible.
Stage 2) Once the above updates have been applied, your update tools
(yum, PackageKit, pirut) will see a new repository and a larger set of
updates available. This is your new standard flow of updates, that will
continue to see new updates as the lifetime of Fedora 8 and 9 progress.
There will be further milestones in the future that involve redirection
of release package repos to match that of updates, and removing of old
gpg key from rpm trust.
For more details and an FAQ, please see
https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
15 years, 7 months
Fedora 8 and 9 updates status
by Jesse Keating
As you well know, we have been working hard to get updates for 8 and 9
flowing again, complete with new package signing keys. Discussion has
been somewhat quiet on this front as we've all had our heads down and
have been working hard toward a solution, one that involves little to no
manual effort on behalf of our users.
Today we've reached a major milestone in this progress. We have done a
successful compose of all the existing and as of yesterday pending
updates for Fedora 8 and Fedora 9, all signed with our new keys. These
updates will soon hit mirrors in a new set of directory locations. What
we don't have quite yet is the updated fedora-release package in the old
updates location that will get you the new keys and the new repo
locations. The last mile testing of this update requires that new
updates be live on the mirrors.
Due to the size of the resigned updates, it may take a good while for
our sync process. This may delay getting the new fedora-release out
until tomorrow, but we'll be working hard on it.
While we're working on this update, we'll also be drafting a FAQ page to
explain to users what it is that we're doing, and hopefully answer some
of the questions that will come up. This document will be living
though, and as you encounter questions yourself, or questions via one of
our many avenues of support (email, IRC, forums, LUGS, etc..) please
help us in growing that document. Announcements regarding the location
of said document and how to help with content will be coming shortly.
We deeply appreciate the enormous magnitude of patience you the greater
community has shown us the Fedora project as we work though these
serious issues. It is a great testament to how wonderful it is to work
in and with the Fedora community.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
15 years, 7 months
Fedora Week News, Issue 142
by Huzaifa Sidhpurwala
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fedora Weekly News Issue 142
=============================
Welcome to Fedora Weekly News Issue 142 for the week ending September 7,
2008.
http://fedoraproject.org/wiki/FWN/Issue142
This week in Announcements we alert you to the "Fedora 10 Beta Freeze
Coming Soon" and the new "FESCo Issue Tracking". In PlanetFedora "Tech
Tidbits" contains some juicy morsels on evaluating package sizes and
Haskell. In Developments we examine the process of "Getting Back On Our
Feet" after the intrusions. SecurityAnnouncements finally has some
content. Artwork covers "Working on a Sound Theme" and the acceptance of
the "Echo Icon Theme as a Fedora 10 Feature"
Fedora Weekly News keeps you updated with the latest issues, events and
activities in the Fedora community. If you are interested in
contributing to Fedora Weekly News, please see our 'join' page[1].
[1] 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
Echo Monthly News, Issue 1
Martin Sourada announced[0] the availability of the premiere issue of
"Echo Monthly News[1]." Said Martin, "Since it's our first release it is
not perfect and therefore we will appreciate any feedback, suggestions
for improvement, etc. at the fedora-art-list and #fedora-art at
irc.freenode.net."
[0]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg000...
[1] https://fedorahosted.org/echo-icon-theme/wiki/MonthlyNews/Issue1
Fedora 10 Beta Freeze Coming Soon
Jesse Keating discussed[2] the Fedora 10 Beta schedule. "The new freeze
date is Sept. 9, which is in 7 days. This is a friendly reminder that
the freeze is coming up, and coming up quickly. I realize that rawhide
has been less than great lately, and we're working quite hard to fix the
issues."
[2]
http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00...
Fedora 8 and 9 Updates Status
Jesse Keating wrote[3] about the status of updates on Fedora 8 and
Fedora 9. "We have done a successful compose of all the existing and as
of yesterday pending updates for Fedora 8 and Fedora 9, all signed with
our new keys. These updates will soon hit mirrors in a new set of
directory locations. What we don't have quite yet is the updated
fedora-release package in the old updates location that will get you the
new keys and the new repo locations. The last mile testing of this
update requires that new updates be live on the mirrors."
For the full announcement, follow the link below.
[3]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg000...
FESCo Issue Tracking
Kevin Fenzi announced[4] the new FESCo issue-tracking tool. "In the
past, interested parties could bring matters to the attention of FESCo
in several ways: Mailing the chair, following up to the schedule posting
on the devel list asking for a new topic to be added, or attending
meetings on irc and bringing up the topic at the end of the meeting in
the Open Discussion phase.
While these methods work well for issues that simply need a bit of
discussion and a decision, longer term issues that should be tracked and
discussed further sometimes are forgotten."
[4]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg000...
=Planet Fedora=
In this section, we cover the highlights of Planet Fedora - an
aggregation of blogs from Fedora contributors worldwide.
http://planet.fedoraproject.org
Contributing Writer: Max Spevack
Cambridge
John Poelstra wrote[0] about the revised Fedora 10 schedule, which as
been moved to account for the infrastructure problems that we faced a
few weeks ago. "Last week the Fedora Engineering Steering Committee
(FESCo) ratified the updated schedule proposed by the Release
Engineering team. This resulted in feature freeze for Fedora moving to
2008-09-09 and GA to 2008-11-18. This three week change to the schedule
was to accommodate the recent infrastructure outages."
[0] http://poelcat.wordpress.com/2008/09/02/fedora-10-schedule-update/
Another Fedora Test Day is in the books, and James Laska wrote[1] about
it on his blog. "There was a really strong developer turn out for this
Test Day. In addition to David Huff, the appliance-tools developer, some
of the oVirt team showed up to help walk through oVirt's use of
appliance-tools. This was tremendously helpful to see how
appliance-tools can be used by other projects. Thanks to Alan Pevec,
Bryan Kearney and Darryl Pierce from the oVirt team for joining the
event. Having such a tight feedback loop with the developers during Test
Days has been very helpful, I hope we can continue with that format."
[1] http://jlaska.livejournal.com/1444.html
=Artwork=
Nicu Buculei posted[2] the latest iterations of some of the potential
Fedora 10 artwork themes. "The second round in the process of creating a
visual theme for Fedora 10 ended yesterday, those are the proposals
meeting the requirement and which will pass into the third (last) round
(listed in chronological order)."
Your beat writer is particularly fond of the Gears/Steampunk theme as
well as the Solar theme, but thinks that all four are fantastic pieces
of art, and should be carried over into Fedora 11's proposals.
[2] http://nicubunu.blogspot.com/2008/09/fedora-10-themes-round-2.html
Tech Tidbits
Yaakov Nemoy reported[3] on the state of Haskell in Fedora. "After
nearly 9 months, I am finally at the point I wanted to be regarding
Haskell. Last January i wanted to submit packages for my favourite
window manager to Fedora. I got blocked because of a lack of packaging
guidelines and familiarity with Haskell or the Glasgow Haskell Compiler."
[3]
http://loupgaroublond.blogspot.com/2008/09/finally-done-with-haskell-thin...
Continuing his habit of posting yum-related tutorials, James Antill
posted[4] a quick explanation of packages sizes in yum and rpm.
"It's pretty common to think that a specific thing always has a specific
size, and people tend to think of an "rpm package" as a single object
thus. the it's common to ask what is "the size of an rpm". However if
you have a 1MB text file, and gzip compresses it to 50KB which you then
upload to a HTTP server you now have at least 3 different sizes: text
size; compressed size and upload size (includes HTTP headers etc.) and
asking for the size. So it is with rpm packages, and their many sizes."
[4] http://illiterat.livejournal.com/6439.html
FUDCon Brno
FUDCon Brno is happening as Fedora Weekly News freezes, but there are a
bunch of photos online[5] and Max Spevack has been providing frequent
updates[6] about the event on his blog.
[5] http://flickr.com/groups/fudconbrno/pool/
[6] http://spevack.livejournal.com
=Developments=
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Getting Back on our Feet
On 05-09-2008 Jesse Keating posted[1] the good news that "[...] we have
done a successful compose of all the existing[,] and as of yesterday[,]
pending updates for Fedora 8 and Fedora 9, all signed with our new
keys." He cautioned that the size of this backlog of updates meant that
it would take some time to get them out to mirrors. The updates will be
in new directory locations and there will be an "[...] updated
fedora-release package in the old updates location that will get you the
new keys and the new repo locations."
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00329...
Jesse was keen to point out that there would be a FAQ to which we can
all contribute and that its location will be announced shortly.
Sean Darcy, after thanking Jesse for all the work he had put in,
asked[2] how he could get the new key for updates right now without
having to wait for the fedora-release package to be placed in the old
repository location. A variety of answers followed and the canonical one
appeared[3] to be that given by Todd Zullinger in which he suggested
obtaining fedora-release from CVS and then checking that the
fingerprints matched those published[4] on the FedoraProject website.
Some minor confusion followed[5] as the example presented on the web
page uses the old key signed by "fedora(a)redhat.com" but the new key is
signed by "fedora(a)fedoraproject.org". Similarly the use of "PUBKEY" as a
placeholder variable on the web page caused some difficulties which Todd
cleared[6] up again.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00392...
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00396...
[4] https://fedoraproject.org/keys
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00406...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00417...
Jeffrey Ollie made[7] the good point that using a GPG WoT would make it
easier for Fedorans to have confidence that they had obtained the
correct key and hoped that those at the Brno FUDCon could "arrange an
impromptu keysigning[.]"
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00411...
Early in the week on 02-09-2008 Stefan Grosse asked[8] politely when the
resigned Fedora 9 updates would be available. Bruno Wolff III
suggested[9] "If you are worried about something in particular, you can
look at bodhi to see pending updates and updates-testing and get rpms
from koji if there is something you want right now." A brief discussion
between Till Maas, Jesse Keating and Bruno Wolff explored whether it was
possible to download from Koji using SSL if one did not have a FAS
account. Bruno testified[10] "I needed certs (two from fedora and mine)
to get the bodhi client to work. I used this to grab a list of stable
updates last week [...] I didn't bother with ssl when grabbing them from
koji." Till was[11] using wget to grab the packages from Koji and found
it necessary to use certificates. Jesse showed[12] that it was possible
to do a koji download-build to get packages anonymously.
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00083...
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00086...
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00089...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00092...
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00096...
In a separate thread Jesse Keating announced[13] that the revised Fedora
10 freeze date would be 09-09-2008 and as part of a friendly reminder
that it was coming up quickly observed "I realize that rawhide has been
less than great lately, and we're working quite hard to fix the issues.
The installer images from the 30th may be of use in getting rawhide
installed and then updating to what is in the public repos. See
http://kojipkgs.fedoraproject.org/mash/rawhide20080830/development/
(please only grab the installer images from there, not the entire
tree)." Matt Miller reported[14] a successful net install from the
Fedora 10 alpha images using the rawhide repository.
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00091...
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00107...
Removing Packages with Long-standing FTBFS Failures
Matt Domsch posted[1] a list of ninety packages which "Fail To Build
- From Source" (FTBFS)[2]. Matt noted that some of these packages have
failed since 02-2008 and that "[...] packages with unresolved FTBFS bugs
immediately following the Alpha release will be removed from the
distribution" in line with a proposal passed by FESCo. He asked that
concerned parties help to resolve the problems and noted that several of
them had easy fixes.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00319...
[2] http://fedoraproject.org/wiki/FTBFS
Response was fairly quick and positive from both those listed as
maintainers and concerned parties that needed the packages in Fedora 10.
One interesting ramification of the removal of such packages was
mentioned[3] by Daniel Berrange who asserted "[t]his list is far from
complete - if you want to remove these 90, the dependency chain ripple,
will entail the removal of tonnes of other packages which depend on
these." He asked Matt to generate a report which "[...] shows the ripple
effect for each proposed package. If something is just a leaf-node, it
isn't very important to worry about, but if something triggers removal
of 50 dependant packages that's pretty damn important to fix. This info
would be useful in prioritizing which builds need fixing most urgently."
SethVidal modified[4] a script written by James Antill so that it did
exactly that and Matt posted[5] a link to the script and an example run.
Till Maas suggested[6] that it would be useful make sure that a src.rpm
responsible for several dependent packages is only counted once.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00320...
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00363...
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00361...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00371...
The practical consequence of neglecting such dependencies was
highlighted[7] by Matthias Clasen when he commented that
"djvulibre-devel is a BuildRequires for evince. If you remove djvulibre,
evince will become unbuildable." Jesse Keating responded that Daniel, or
his team should fix the package as "[i]f we have to do a chained rebuild
for various reasons, evince would fail due to this package not building
first."
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00323...
The inclusion of monodevelop in the list had the side effect of spurring
the Mono maintainers including Michel Salim, David Nielsen and Paul
Johnson to decide[8] to attempt a co-ordinated push of "Mono-2.0".
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00385...
MinGW on Fedora
The availability of a MinGW development repository was announced[1] by
Richard Jones. "MinGW" provides a GNU toolchain on Windows allowing the
development of Free native Windows binaries. Richard credited Daniel
Berrange with a good deal of the work.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00296...
In response to Farkas Levente's question, as to when it would be
available in Fedora, Daniel replied[2] that due to the need for
"infrastructure" to create a separate repository and dedicated build
root it was impossible to predict. Jef Spaleta seemed[3] to be trying to
move the process forward and published a draft which explained that
"[t]he initial impetus for this effort has been ovirt developers who
desire to more easily use Fedora installations as development
environments for the work they are doing to build open source
cross-platform virtualization tools." The possible impact on
FedoraProject resources appears to have led to the compromise of
creating a separate repository which could be strictly confined in size.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00298...
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00364...
Richard Jones encouraged[4] Farkas to try out MinGW without waiting for
official inclusion in Fedora "[...] if you want to download and play
with it, and send patches :-) It's currently buildable on Rawhide, and
possibly on earlier versions of Fedora too." Farkas then revealed that
he currently used an older MinGW on RHEL5 and Richard responded[5] that
although there were no srpms at this moment it should be possible to use
the specfiles and patches (both in the mercurial repository[6]) to
rebuild everything.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00300...
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00330...
[6] http://hg.et.redhat.com/misc/fedora-mingw--devel/
Dependency Loops Considered Harmful?
[[MiroslavLichvar|Miroslav Lichvar] raised[1] the issue of a
considerable number of packages (354 by his count) which are components
of dependency loops in the rawhide repository. Miroslav provided[2] a
list. In such loops two or more RPM packages require each other as
dependencies in their spec files with the result that it can become
confusing for users trying to remove selected packages manually with yum
or rpm. Miroslav wondered whether such loops were acceptable and
specifically "why games data depend on binaries?"
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00149...
[2] http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops
A substantial conversation resulted which exposed the different needs of
packagers and users, some possible limitations due to the design of rpm
and varied philosophies concerning the correct way to specify
dependencies. One of the central examples chosen were the game packages
which tend to be split into a "binary" or "engine" package and a
companion "data" package for graphics, sound and levels. The central
concerns expressed were that occasionally an install followed by a
remove will leave "orphaned" packages behind. Also in contention was the
specific case of developers experiencing the problem of maintaining a
stable environment when there is no easy way of tracking changes to
system libraries. The package manager aptitude was mentioned favorably
due to its ability to distinguish between packages installed
automatically to satisfy dependencies and those which are installed
manually.
On the one hand Chris Snook and Michael Schwendt advocated[3] that
instead of using Requires: foo >= X in their spec files packagers should
choose Conflicts: foo < X . The possible downside to this would be
installing game data yet having no game engine/binary installed. This
was seen as a non-serious problem.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00211...
On the other hand Jon Ciesla argued[4] that the advantage of having
games data depend on their binaries from a packagers perspective is that
it ensures that attempting to upgrade the binary Version without also
upgrading the data will fail. The case of allowing minor fixes without
forcing users to download a big bundle of data can be handled by bumping
the Release of the package. More concisely he answered[5] that the
reason for the dependencies was that "[...] so when you remove the game,
you remove the data." Michael responded[6] that Jon's example could be
handled by using a Requires: foo-data = X without exposing the increased
risk of needing to "bump'n'rebuld" the data package each time the engine
package incremented its Version while still working with the same data.
He characterized such dependencies as "superfluous [...] try[ing] to
enhance 'yum remove'."
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00150...
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00151...
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00161...
This was not accepted as accurate by Jon and he described the current
situation as "require on name and version" for game data which allows
Release to be changed without affecting the match on Name and Version
"If new data is required, it will change the version. If not, we only
increment the binary rpm's release, so the data rpm matches on version
and needs no rebuild." Michael responded[7] by laying out two cases, the
first of which illustrated the problem of having to update the data
package solely to keep in step with updates to the version so that yum
remove would function properly. His alternate case used non-versioned
dependencies in the data package and strict dependencies in the engine
package. Hans de Goede seemed a bit irritated and asked Michael to
"Please take an actual look at game spec files before making up all
kinds of BS, it's really easy" and argued that for games there was a
one-to-one mapping between the engine and the data. He added that just
because other cases resulted in dependencies being sucked in by an
install and left behind on a remove there was no reason to change the
way things were done for games.
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00167...
Stephen Gallagher suggested that the "groups" exposed through yum should
be used to bundle together the multiple packages for an application
instead of using looped dependencies to which Callum Lerwick replied[8]
that it was actually time to "implement the per-package 'explicitly
installed/pulled in as a dep' flag that has been discussed several times
in the past, and is already implemented (thus proven) in the 'aptitude'
apt front end." He followed this with an amusing piece of hyperbole
about "the looming dark future of closed DRM-laden content delivery
services[.]"
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00193...
Toshio Kuratomi raised[9] the problem faced by developers using system
libraries that could come and go due to packages being updated or
removed. Callum's suggestion was[10] that developers should be "RPM
packag[ing] your app. Apps on your system that are not tracked by RPM
are a ticking time bomb of dependency breakage whether or not the 'leaf
culling' is performed manually or is assisted by a 'pulled in as dep'
flag. A package or distribution update could very well break your app
too." Needless to say Toshio had[11] several objections to this
including the impact on developer workflow imposed by packaging up
everything and the inadvisability of forcing developers to become expert
administrators. He suggested that "If we implement this, it needs to be
at a low enough level that anyone installing packages on the system will
be storing the information. That could mean rpm (since rpm is
responsible for taking the package and turning it into files on the
filesystem) or that could mean yum since yum is the one that actually
knows whether a package is being installed due to depsolving or user
request. Doing this at a higher level means that information gets lost
(for instance, if you do this in PackageKit, there won't be any
information about what anaconda chose to install due to checkboxes being
clicked and which things were installed due to dependencies). With that
said, there needs to be a way for a developer to tell yum not to prune
away leaf packages if they want." A very detailed and amusing discussion
with (among others) Matthew Woehlke followed in which Matthew argued[12]
for a script which essentially produced a parallel iuserj rpm database
so that quick and dirty rpms could be produced locally for developers.
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00195...
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00209...
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00214...
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00278...
Jef Spaleta wondered[13] what actual examples revealed about the amount
of harddrive space being consumed by dependencies and remarked "I hope
the packagekit people are watching this discussion. The game data
subpackaging issue should be right up their ally in terms of end-user
ease of use issues." He discounted the polluting of the packagelist but
MichaelSchwendt pointed out[14] that as the packagelist increases then
"[because of] the frequent updates common in Fedora land, you need to
download and update more[.]"
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00162...
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00170...
The idea of keeping game data outside of any package management was
mentioned[15] by James Antill as an "obvious fix" and he discounted the
probability of PackageKit being able to do anything about the issue if
yum or rpm could not. Jef responded[16] that "[a]t some point someone is
going to have to wade into rpm itself for ease of use of removals to get
better" and pointed out that he was "[...] making sure that the people
with the right motivation and the right skills find the right way to
handle it. That's not going to happen just by telling the current
maintainers who are abusing the available requires syntax that they are
abusing the syntax and slapping their wrists." Richard Hughes showed[17]
that the PackageKit developers were indeed listening to the conversation
and mentioned that he had considered "[...] running through a large
"get-depends" output into the basename filter, so that the user only
sees the 'applications' by default, rather than a huge list[.]"
[15]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00184...
[16]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00185...
[17]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00212...
There is a lot more to this conversation than reported here, but the
main thrust is that the limitations of rpm have resulted in package
maintainers wrangling spec files to do what they want which in some
cases has undesirable effects.
Fedora Security Tools Spin
A suggestion was made[1] by Huzaifa Sidhpurwala to produce a Security
Tools spin similar to the "Knoppix Security Tools Distribution"[2] .
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00108...
[2] http://knoppix-std.org/index.html
Todd Zullinger responded[3] that there was already a spin similar to
this being curated by Luke Macken. The SecuritySpin[4] mentioned by Luke
seemed to be roughly what Huzaifa was searching for, except that he
thought it should have "more tools and [be] more bare bones".
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00110...
[4] https://fedoraproject.org/wiki/SecuritySpin
Adrian Pilchowiec mentioned[5] a free fork of nessus named OpenVAS[6] as
a desirable part of the spin. Luke drew[7] attention to the need for
more people to help out with packaging missing tools. Subsequently the
wishlist of the project recorded that Huzaifa was packaging up OpenVAS
and labrea.
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00275...
[6] http://www.openvas.org/
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00183...
=Infrastructure=
This section contains the discussion happening on the
fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: HuzaifaSidhpurwala
New Key Repo Locations v2
Warren Togami writes for fedora-infrastructure-list [1]
Warren sent out a mail enlisting the new repo locations. Also the repo
names have been changed so debuginfo and source are always at the end.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September...
archives on secondary1
Matt Domsch writes for fedora-infrastructure-list [2]
Matt asked if archives.fp.o is on secondary1.fp.o There are 2 separate
rsyncd.conf files in puppet, one for archives,one for secondary. Given
they land at the same place on the same machine, only the one for
secondary is actually in effect. If they're going to be on the same
machine, we need to merge them. On this Mike replied with an affirmative
saying that they need to be merged.
[2]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September...
=Artwork=
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
Art Schedule for Fedora 10
JohnPoelstra showed[1] on @fedora-art a tentative schedule[2]for the
Artwork activities and asked for help with it: "1) Which tasks no longer
apply and should be removed 2) New tasks which should be added 3)
Existing tasks that are wrong"
[1]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00388.html
[2] http://poelstra.fedorapeople.org/schedules/f-10/f-10-art-tasks.html
He received corrections about dates from MairinDuffy[3] and tasks from
NicuBuculei[4]
[3]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00390.html
[4]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00001.html
Working on a Sound Theme
ChrisNorman uploaded[1] a first preview of a new desktop sound theme
created for Fedora and he received[2] some feedback about length and
content from NicuBuculei: "I am not sure about speaking the English word
'attention' - some people not speaking English may not be that happy.
And maybe, just maybe, a few sounds, like 'window-close.wav' are a bit
too long".
[1]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00012.html
[2]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00013.html
Echo Icon Theme as a Fedora 10 Feature
LuyaTshimbalanga reported[1] about FESCO acceptance of the new Echo icon
set as a default in Fedora 10: "Fesco has accepted echo-icon-theme as
default icon theme for Fedora 10.[1] Which means we need to push harder
to include as many icons as possible using guideline and echo-artist
tool now available on rawhide and is waiting for people to get them on
both Fedora 8 and 9"
[1]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00028.html
MatthiasClasen outlined[2] the importance of having Echo as a default in
the upcoming beta release "I think we need to act quickly to make Echo
the default for the beta, to test the waters before F10" and soon after
that he operated the change[3].
[2]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00044.html
[3]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00056.html
MartinSourada noted that the feature depends on the icon coverage "Just
a note that Fesco (and many art team members as well) has some concerns
about coverage. Simply said if we don't achieve the Mist/gnome icon
themes coverage, we'll be rolled back to Mist and wait for another
release" and offered to mentor new contributors.
[4]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00031.html
[5]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00069.html
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
As we recover from the disruptions to the infrastructure Security
Advisories are starting to reappear. As of 07-09-2008 the following four
advisories are however just the results of testing a push after all
packages have been signed with the new GPG keys. Please see the
Announcements and Developments sections of FWN for more information.
=Fedora 9 Security Advisories=
* samba-3.2.3-0.20.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* wordpress-2.6.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
* bitlbee-1.2.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
Fedora 8 Security Advisories
* xastir-1.9.2-8.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/ms...
=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
Use Avahi to Discover Local Servers in Virt-manager
Cole Robinson committed[1] a patch[2] to add support for avahi polling
in the virt-manager 'Open Connection' dialog.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00000.html
[2] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00123.html
Virtio Support in Libvirt and Virt-manager
Emre Erenoglu asked[1] if virtio[2] would be supported in virt-manager.
Daniel P. Berrange said[3] libvirt supports it as of 0.4.4 and
virt-manager will soon automatically enable virtio for disks known to
include it.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00010.html
[2] http://kvm.qumranet.com/kvmwiki/Virtio
[3]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00011.html
The design paradigm[4] for virt-manager is to allow selection of OS Type
and Variant which informs the features to be enabled, rather than
exposing individual features toggles. Cole Robinson agreed[5] exposing
the option to enable virtio disks for an unknow virtio-enabled
distribution might not be a bad idea.
[4]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00013.html
[5]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00015.html
New Virt-manager and Virtinst Releases Pending
Cole Robinson announced[1] that with the pending Fedora 10 beta freeze
on Tuesday, September 9th new releases of virt-manager + virtinst are
imminent. Daniel P. Berrange concurred[2] that libvirt would roll out a
new release around that time as well.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00002.html
[2]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00005.html
Virt-install Patch for Disk Size and Sparse
Cole Robinson patched[1] virt-install's new --disk option to specify
size of new storage, and whether it be create it as a sparse file.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00004.html
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Nothing to report this week.
Libvirt List
This section contains the discussion happening on the libvir-list.
Libvirt vs XenAPI
Atif Bajwa asked[1] about the advantages of using libvirt over XenAPI
and what platforms libvirt supports. Atsushi Sakai pointed to a list[2]
of which libvirt calls work on which drivers / hypervisors. Daniel P.
Berrange replied[3] that libvirt is available for every major Linux
distro, and listed several benefits such as:
* avoids locking applications to a particular hypervisor
* provides a guaranteed stable API that can be used both locally and
remotely
* remote security options include SSL + x509 certificates, SSH
tunnel, Kerberos GSSAPI single sign on, and username + password
* works with every version of Xen 3.0.x or later while XenAPI is
only usable in Xen 3.1.0 and later
Richard W.M. Jones mentioned[4] that although there are no binaries yet,
libvirt client code can be compiled on windows.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00002.html
[2] http://libvirt.org/hvsupport.html
[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00008.html
[4] https://www.redhat.com/archives/libvir-list/2008-September/msg00016.html
Latest MinGW Patches
Daniel P. Berrange posted[1] patches to allow building on F10 of
libvirt-0.dll and virsh.exe which run successfully under Wine, provided
only 'test' and 'remote' drivers are turned on.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00065.html
Does Libvirtd Need to Always be Running
Yushu Yao asked[1] a basic question which may be helpful to point out.
Does libvirtd need to always be running? Richard W.M. Jones answered[2]
"yes and no". The local Xen hypervisor can be managed by direct
hypervisor calls and/or a connection to xend. Warnings that libvirtd
isn't running may be ignored.
Libvirtd must be running to support the following, however.
* remote access
* non-root access
* if you use the network or storage features
* managing QEMU and KVM instances
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00085.html
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00103.html
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
Renaming oVirt RPMs
Alan Pevec proposed[1] renaming the oVirt packages which turned into a
discussion with Daniel P. Berrange about how to organize the git repos
and how to continue support build-all after such a change.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00029.html
WUI Management of Underlying Hardware
Chris Lalancette posted[1] a series of patches to allow the Web User
Interface to manage the underlying hardware it is running on.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00081.html
Network Interface Bonding and Failover
Darryl L. Pierce began[1] a discussion on implementing support for
ethernet bonding multiple interfaces for load balancing and failover.
Special consideration for different hardware scenarios such as blade
servers lead Konrad Rzeszutek to ask how these extra parameters would be
passed in to the bonding setup. Darryl explained[2] that on boot the
node identifies itself to the oVirt server, and downloads a
configuration file to be processed by augtool[3]. The managed node then
restarts the network service to apply the network configuration that it
just retrieved.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00064.html
[2] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00075.html
[3] http://augeas.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFIxPNQzHDc8tpb2uURAtzRAKCTj5iymYizSAMtmu66r7pJ4mgRdwCbBs5T
omV746s+xUeo9Z9izdu6twg=
=dkej
-----END PGP SIGNATURE-----
15 years, 7 months
Fedora Board IRC meeting 1800 UTC 2008-09-09
by Paul W. Frields
The Board is holding its monthly public meeting on Tuesday, 9 September
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 should limit
confusion and ensure 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, 7 months
FESCo Issue tracking
by Kevin Fenzi
Greetings.
In the past, interested parties could bring matters to the attention of
FESCo in several ways: Mailing the chair, following up to the schedule
posting on the devel list asking for a new topic to be added, or
attending meetings on irc and bringing up the topic at the end of the
meeting in the Open Discussion phase.
While these methods work well for issues that simply need a bit of
discussion and a decision, longer term issues that should be tracked
and discussed further sometimes are forgotten.
To help solve this issue, and to make it easier for folks to bring an
issue before FESCo, I have asked Fedora Infrastructure to setup a trac
instance for FESCo to track tasks and handle new issues.
New issues for FESCo can now be filed at:
https://fedorahosted.org/fesco/
Please feel free to file issues there.
Note that FESCo (Fedora Engineering Steering Committee) handles the
process of accepting new features, the acceptance of new packaging
sponsors, Special Interest Groups (SIGs) and SIG Oversight, the
packaging process, handling and enforcement of maintainer issues and
other technical matters related to the distribution and its construction
Thanks.
kevin
15 years, 7 months
Echo Monthly News, Issue 1
by Martin Sourada
The echo-icon-theme development team just officially released its first
Echo Monthly News Issue [1]. In this release we cover these sections:
1. New Icons
2. "Huge" icons - 256x256
3. One Canvas Work-Flow
4. Automating the secondary jobs
1. Add a new icon set to Git
2. Setting up Git repository
3. Updating Git repository
4. Creating New Icon from Template
5. RPM package and other issues
5. Echo for Fedora 10?
6. Future plans
7. Request for feedback
Since it's our first release it is not perfect and therefore we will
appreciate any feedback, suggestions for improvement, etc. at the
fedora-art-list and #fedora-art at irc.freenode.net :)
References:
[1] https://fedorahosted.org/echo-icon-theme/wiki/MonthlyNews/Issue1
15 years, 7 months
Fedora Weekly News 141
by Huzaifa Sidhpurwala
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fedora Weekly News Issue 141
==============================
Welcome to Fedora Weekly News Issue 141 for the week ending August 30, 2008.
http://fedoraproject.org/wiki/FWN/Issue141
Fedora Weekly News keeps you updated with the latest issues, events and
activities in the Fedora community.
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.
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 Unity releases Fedora 8 Re-Spin
Ben Williams announced[0] that the Fedora Unity team has released a new
re-spin of Fedora 8. "These Re-Spin ISOs are based on the officially
released Fedora 8 installation media and include all updates released as
of August 14th, 2008. The ISO images are available for i386, x86_64 and
PPC architectures via Jigdo and Torrent starting Sunday August 24th,
2008. Go to http://spins.fedoraunity.org/spins to get the bits!"
[0]
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00014....
= Planet Fedora =
In this section, we cover the highlights of Planet Fedora - an
aggregation of blogs from Fedora contributors worldwide.
http://planet.fedoraproject.org
Contributing Writer: Max Spevack
Education
The Fedora Education Spin is progressing[0], having been "approved by
all necessary bodies - Spin SIG, Board, Rel-Eng", reported Sebastian
Dziallas. The spin has its own feature page. "Hopefully, we'll be able
to have a preview of the spin ready in the next weeks", added Sebastian.
[0]
http://sdziallas.joyeurs.com/blog/2008/08/status-report-on-fedora-educat....
Greg DeKoenigsberg reminded potential OLPC contributors[1] to surf over
to the contributors' program on the OLPC wiki in order to request their
own XO for development. Soon, Greg "will be sitting in on the weekly
call that decides how these laptops are disbursed".
[1] http://gregdek.livejournal.com/34240.html
Tech Tidbits
Michael DeHaan, holder of the coveted "best blogger on Planet Fedora"
title, as determined each week by your correspondent, has penned a
treatise[8] concerning the future of systems management software.
"Cobbler and Func are very fun, I think they are quite useful, but I'm
wondering what are next on the horizon for server management tech, not
in terms of a evolutionary improvement but how things can be
legitimately improved by fundamental, indeed 'paradigm-shifty' means."
Click the link below to read the entire post.
[8] http://www.michaeldehaan.net/?p=702
James Antill has written[9] a tutorial on the Python yum API, which is
incredibly useful if you have ever wanted to do stuff with yum, but
don't know where to start and are afraid to ask Seth.
[9] http://illiterat.livejournal.com/6254.html
Events
David Nalley shared some details about the upcoming Fedora Ambassadors
Day for North America[2]. The event will coincide with Ohio Linux Fest
in October. David said, "If you are a Fedora Ambassador, or want to be
one, you should try and attend."
[2] http://www.nalley.sc/david/?p=81
[[ChristophWickert|Christoph Wickert] attended FrOSCon 2008, along with
several other other Ambassadors, and shared his event report[3]. "Just
like on Linuxtag the Fedora booth was located close to the entrance, so
we had quite a lot of visitors. Unfortunately the booth was a little
small and we had lot of stuff to show: Two OLPCs, an eeepc, two ALIX
Machines and a couple of Laptops. Everything was running Fedora, the
Laptops were running Gnome and Xfce, mine also LXDE." Check out the link
below for pictures, and the full report.
[3] http://www.christoph-wickert.de/blog/2008/08/26/back-from-froscon/
Max Spevack reminded[4] everyone about the upcoming FUDCon Brno. "We
currently have 110 people registered for the event," and the list of
sessions and hackfests is on the Fedora wiki. Hans de Goede will be
attending FUDCon Brno. He wrote an update[5] about webcam support in
Fedora, which will be worked on at FUDCon, and also blogged[6] about the
session he will give on how to become a Fedora package maintainer.
[4] http://spevack.livejournal.com/62369.html
[5] http://hansdegoede.livejournal.com/5576.html
[6] http://hansdegoede.livejournal.com/5304.html
Fedora List
Fedora Board member Chris Tyler wrote[7] about the plans for changing
the scope and ownership of fedora-list. Chris says, it is "one of the
first lists that most Fedora users join, and therefore quite important
to the community. However, it's a high-volume list (and is sometimes
perceived to have a high noise level), so many veterans of the Fedora
community aren't subscribed... Paul Frields and I have taken on the
ownership of the list, and we'd welcome one or two experienced members
of the community to join us."
[7]
http://blog.chris.tylers.info/index.php?/archives/134-The-Scope-and-Owner...
= Developments =
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Approaches to a Minimal Fedora
Luya Tshimbalanga alerted[1] the list to a post on FedoraForum.org in
which a user "stevea" had produced a 67MB "minimalFedora" system. Jeff
Spaleta worried[2] that the bare-bones system was unable to receive
updates and that this was something which "we as a project might not
officially want to endorse." One way out of that suggested by Jef was
that interested parties could produce a derived distribution which
pushed out entire updated images. Recent changes in the trademark
guidelines make such a move easier.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01304.html
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01305.html
A parallel to the minimal OS appliance image used in the oVirt project
was discerned[3] by Daniel Berrange. Daniel reported their 'oVirt
managed node' as being less than 64MB and built entirely from the Fedora
9 repositories. Later Daniel posted[4] that the similarities ended with
the desire for a small image. The oVirt goal was to use only Fedora as
upstream whereas stevea's approach had been to substitute coreutils with
busybox. Daniel acknowledged "[...] finding the bits which aren't needed
is fun in itself & somewhat of a moving target. So wherever possible
we've been filing BZ to get some RPMs split up into finer grained
sub-RPMs" and included a link to his project's kickstart %post stanza.
Richard Jones suggested[5] that KDE's filelight was useful for finding
bloated files and Vasile Gaburici added[6] that there was a GNOME
equivalent called baobab. Vasile also included[7] a script which he uses
to "keep track of bloatware".
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01307.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01319.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01373.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01374.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01376.html
A follow-up post from Daniel concluded[8] that the only bits of upstream
Fedora actually used in stevea's approach were the kernel and busybox as
even glibc and initscripts had been ditched. Daniel wondered "So not
really much trace of Fedora left at all. Not sure why you'd go to the
trouble of doing the initial anaconda install at that point - might as
well just 'rpm *no-deps' install kernel + busybox RPMs into a chroot &
add the custom init script."
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01320.html
Doubt on the advantages of stripping down Fedora to make it run on
embedded targets was cast[9] by Patrice Kadionik when he argued that
using the Fedora kernel with all its patches and modules was too
bloated. Instead he preferred to use the vanilla kernel with busybox
with the result that "[...] you have a Linux kernel (about 1MB) with its
root [filesystem] (about 1-2 MB) adapted completely to the target
platform." Alan Cox replied[10] that the ability to receive updates and
benefit from the maintained and tested code was desirable if there were
enough extra space.
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01353.html
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01357.html
W. Michael Petullo added a link[11] to his "FedoraNano" project which
has the goal of reducing redundancies, identifying probable cases for
sub-packaging and documenting a method to install a small Fedora onto
solid state drives.
[11] http://www.flyn.org/fedoranano/fedoranano.html
Using PackageKit Without NetworkManager-Controlled Interfaces
A question from Martin Langhoff asked[1]: "[i]s there anything
preventing PK from connecting to the network over
non-[NetworkManager]-controlled network interfaces?" This question
appeared to be predicated on the assumption that PackageKit had a
dependency on NetworkManager.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01209.html
Jeremy Katz clarified[2] that PackageKit depended on NetworkManager-glib
and not on NetworkManager. He added that this was because PackageKit
attempted to determine the status of the network connection prior to
checking for updates. Dan Williams confirmed[3] that this was the case
and expanded on the explanation: "If talking to NM fails, the app should
either (a) assume a connection, or (b) could be more intelligent by
asking SIOCGIFCONF/netlink for interfaces, and if at least one interface
is IFF_UP | IFF_RUNNING and has an IP address, then try." Using
NetworkManager in this way allows PackageKit to be restricted to
sensible choices about the type of networks over which it is acceptable
to receive updates.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01210.html
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01213.html
A further point raised by Martin was that there were a surprising number
of dependencies and Dan pointed[4] to bugzilla entry#351101[5] while
noting that "[PackageKit] should only depend on NetworkManager-glib,
which itself should not pull in NetworkManager in the future." That bug
specifically affects multilib systems, that is x86-64 systems with i386
packages on them, and prevents the simple removal of the older version
of NetworkManager-glib and replacement with a re-factored one. This will
be fixed for Fedora 10 using the installer anaconda.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01214.html
[5] https://bugzilla.redhat.com/show.bug.cgi?id=351101
In a separate thread Martin asked[6] what debugging facilities were
available for network scripts beyond using bash -x. He detailed his
"hack du jour" by which /etc/udev/rules.d/60-net.rules invokes
net.hotplug.debugger which in turn uses bash -x net.hotplug with STDIN
and STDOUT redirected to a logfile. It appeared from the lack of further
suggestions that this is a good strategy. He also provided[7] a note
which explained that he was upgrading the "School Server" spin to Fedora
9 from Fedora 7.
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01263.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01207.html
Git-1.6.0 Commands to be Moved Out of PATH
A response by Todd Zullinger to a "cvsextras" commit[1] of changes to
git questioned[2] whether setting gitexecdir=%{_bindir} was a justified
deviation from upstream intent. According to Todd "[..] we've
effectively negated upstream's intent to present less binaries in the
users path". Currently there are 137 git-commands in the /usr/bin
directory. Todd suggested that it was better that individual users added
the output of $(git *exec-path) to their PATH environment variable. As a
precaution against breaking scripts upon update to git-1.6.0 Todd
suggested that this addition to PATH should be made by the package.
[1]
http://www.redhat.com/archives/fedora-extras-commits/2008-August/msg05593...
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01330.html
The package maintainer responsible for the change, James Bowes
replied[3] that he had recently attempted to do as Todd suggested and
that had resulted in complaints. He was worried that although Todd's
change made sense there had been no due diligence conducted to see what
would break if the git-* commands were moved in such a way. Josh Boyer
replied[4] that the original complaint had been about "yank[ing] out
commands [...] from a stable release [Fedora 9]". Todd Zullinger
discounted such complaints and dreamt[5] that "[...] a warning could be
hand delivered by a beautiful naked person of whatever gender the user
prefers and many would still scream when the change finally landed. :)"
He suggested that in order to achieve predictability and consistency
across distributions it was best to follow upstream and use the update
to 1.6.0 as a flag day.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01361.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01363.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01389.html
In response to queries as to whether there was a need to update Fedora 9
also Josh Boyer replied[6] that a security bug was fixed by git-1.6.0
but that he thought that this might have also been fixed by "a later
release of 1.5.6.x."
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01390.html
Resurrecting Multi-Key Signatures in RPM
Spurred on by the disquiet caused by the recent signing of Red Hat
packages (but not as far as is known any Fedora packages)[1] it was
suggested[2] by Bojan Smojver that multiple GPG signatures of RPM
packages would be a good idea. Distributing the signing could include
using alternate buildsystems "[...] with no public access [...] to
verify package checks before signing[.]"
[1]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012...
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01136.html
Andrew Bartlett thought that the checksum part would be a problem
because a build often includes hosts, build times and other specifics
and Chris Adams added[3] that even individual files within a package had
such information embedded. Bojan decided to find out how many packages
were so constrained and Seth Vidal suggested[4] a useful rpm command rpm
- -qp *dump pkg.rpm to list all available information about each package.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01140.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01146.html
Seth was dubious about the general idea and upon being pressed doubted
the security gain and noted the cost incurred on users trying to verify
that a package was signed correctly. Bojan expanded[5] upon the idea
that for a "[...] multi-key, multi-build system, an attacker would need
to get his hands on a lot of private key passwords, break multiple
independent build systems [...] It is similar to what a reporter does to
confirm a story. One source, not so reliable. Two sources, more
reliable. Many sources, most likely reliable." Stephen Smoogen
described[6] this a logical fallacy and argued that due to the number of
packages all signing would need to be automated and thus probably each
of the multiple sources would "[...] get their information from the same
top level source."
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01198.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01205.html
A useful post by Nils Philippsen laid out[7] four practical objections.
Prime among these was that there were additional pieces of data, besides
those mentioned above, embedded in a specific build even though the
source package may have the same tag. The possibility of making the
build system vulnerable to a DoS attack was also mentioned. A sub-thread
on German banking practices and the value of multiple credentials
developed[8] as did one[9] on the problems of determinism in producing
identical binaries.
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01156.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01275.html
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01329.html
Tom Lane was also among those that expressed[10] a general skepticism
that the increased burden of such a scheme was realistic: "Most of us
[packagers] are overworked already. We aren't going to jump through any
hoops for third-party signatories." Bojan argued[11] that if the system
were automated then it probably would be vulnerable but suggested that
it would be better if a community effort to absorb the extra
non-automatic work would be a solution in line with "open source"
practices. Reluctantly he concluded "[n]ever mind, it was just an idea.
Probably not even a good one. Back to the drawing board... ;-)"
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01141.html
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01215.html
Intrusion Recovery Slow and Steady
A politely phrased request[1] was made on 25-08-2008 by Mike Chambers
for information about when normal service would resume in the Fedora
Project after the disruptions[1a]. Enigmatically Dominik 'Rathann'
Mierzejewski observed[2] that there had been "some speculation on
fedora-advisory-board that might explain the information blackout, so
please don't jump to conclusions until you really know what happened"
This led Chris Adams to observe that the list archives appeared to be
offline and to restate the request for information "[...] in the absence
of information, rumors and speculation fill the gap (which is not good)."
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01102.html
[1a]
https://fedoraproject.org/wiki/FWN/Issue140#Mysterious_Fedora_Compromise
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01122.html
Several days later (on 28-08-2008) a similar request was made[3] by Alan
Dunn. He wondered whether bodhi was pushing updates out again, and Josh
Boyer responded[4] that planning and implementation of "how to revoke
the current gpg key used to sign RPMs" were in progress. Jesse Keating
cautioned[5] that the migration to a new key would be slow "I'm
currently re-signing all of the 8 and 9 content with these new keys so
that we can make them available along with the new updates with the new
key for these product lines. This is going to take some time due to the
nature of how our signing works."
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01308.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01309.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html
A proposal mooted[6] on @rel-eng by Warren Togami and others provided
some insight into at least the part of the plans that involve the
problem of how to distribute a new package signing key.
[6] http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html
"nodata" asked[7] whether the new plans included a means to push out
critical security updates even while there was a general outage. The
thinking behind this seems to be that an attacker could decide to knock
out Fedora infrastructure in order to gain some time to exploit a known
vulnerability even if a simple fix existed. Jesse Keating replied[8]
confidently that in such a scenario the Fedora Project would do
"whatever it takes [...] to get a critical update onto a public
webserver should the need arise" and cautioned against wasting time
trying to plan for every possible scenario. Toshio Kuratomi added[9]
that although it might be possible to speed up recovery "[...]
unfortunately if the infrastructure problem is bad enough, there's no
way we can push package X out until the problem is at least partially
resolved."
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01313.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01314.html
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01316.html
On 27-08-2008 Paul Johnson noted that it was possible to "compose and
build" and asked "when will updates via yum become available for
rawhide?" Jeremy Katz responded[10] that "[a]t the moment, the compose
is falling over for new reasons unrelated to the infrastructure changes.
Hopefully we'll see a rawhide make its way out to the masses real soon now."
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01249.html
Later Mike Chambers and Ola Thoresen reported[11] that updating from
Fedora 9 to Rawhide seemed to be working. Several Rawhide Reports also
appeared[12].
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01350.html
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01339.html
= Infrastructure =
This section contains the discussion happening on the
fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: HuzaifaSidhpurwala
Some noteworty praise
Paul W. Frields writes for fedora-infrastructure-list [1]
Paul forwarded a mail [2] send by Tim Burke, who is the Director of
Linux Development inside Red Hat, praising the efforts of fedorans who
rose to the occasion to bring things back on track after the recent
incidents in Fedora infrastructure.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01023.html
Maintaining a partial cvs workarea
Axel Thimm writes for fedora-infrastructure-list [3]
Axel described how he was keeping a partial check-out of packages, ie
the ones which he was maintaining. Now he would like to be able to cvs
up and have all updates flow in, but if he does do so cvs will want to
get all other thousand packages in. He is currently using a for loop
with pushd/popd, but this process is extremely slow. Axel asked if there
was a better way of doing this?
[3]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...
rawhide, /mnt/koji and /pub/fedora
Jesse Keating writes for fedora-infrastructure-list [4]
Jesse created a user "masher" to have the ability to write to
/mnt/koji/mash/ but not any of the other koji space. This is useful to
prevent too much damage from a horribly wrong rawhide compose. To make
things easier in the rawhide compose configs, they decided to run the
cron/scripts as the masher user. This is also good because it means
things run unprivileged. However he ran into a snag. They have another
user, 'ftpsync' that has write access to /pub/fedora/. Previously the
rawhide script was ran as root, and thus it was no problem to su ftpsync
for the rsync calls. The masher user does not possess the capability of
doing this.
[4]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...
New Key Repo Locations
Warren Togami writes for fedora-infrastructure-list [5]
Warren proposed the latest draft of New Key repo locations. Jesse
Keating points out that the deep levels are necessary because mirrors
exclude releases by directory name like "9/"
[5]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...
= Artwork =
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
The Echo icon theme and Fedora 10
NicuBuculei asked[1] on @fedora-art about the plans to use the new Echo
icon set as a default on Fedora 10: "considering the feature freeze, the
Beta release and as Echo is not a feature proposed for F10, is correct
the assumption that we won't have Echo as a default for F10, staying
with Mist [at least] one more release cycle?"
[1]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00328.html
In reply LuyaTshimbalanga pointed[2] out that it is still possible, due
to a slip in the release cycle: "Shall we try to make it as Fedora 10
feature. Thanks to, in some extend, the incident, feature freeze has
been moved on September 9th."
[2]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00329.html
MartinSourada shared[3] his experience "It seems like artwork things are
preferred to be decided by the Art Team rather than Fesco. I have a
feeling it might be same for Echo." and proposed that this decision
should be made together by the Art and Desktop teams "In this case I
personally think Echo should be put on evaluation by Art Team and
Desktop Team. If both agree it's ready for default we can roll it in
;-)" while NicuBuculei stressed[4] the importance of having Art features
listed "from a marketing POV, if we list it as a "feature" it will be
picked by more news source and help building the excitement around the
new release."
[3]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00337.html
[4]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00343.html
Automating the One Canvas workflow
In the last FWN[1] issue we covered 'One Canvas workflow', an innovative
way to create icons, this week it continued to be a topic on @fedora-art
and MartinSourada introduced[2][3] a script that makes the work easier.
"[It] greatly simplifies life for Echo artist, since all they need is to
make the Source SVG, run the script on it, select which branches they'd
like to push it to and write commit message(s) - i.e. it automates most
of the process". He also wrote a blog post[4] about this and created a
screencast[5] illustrating the process.
[1] http://fedoraproject.org/wiki/FWN/Issue140
[2]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00327.html
[3]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00368.html
[4]
http://mso-chronicles.blogspot.com/2008/08/echo-nodoka-one-canvas-ruby-an...
[5] http://mso.fedorapeople.org/screencasts/echo-add-icon-screencast.ogg
= 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
As there have been disruptions to the infrastructure of the Fedora
Project this week there are no Security Advisories to report. Please see
the Announcements and Development sections for more information.
Fedora 9 Security Advisories
None
Fedora 8 Security Advisories
None
= 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
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
virt-what Script Detects Running in a Virtual Machine
Richard W.M. Jones announced[1] version 1.0 of | virt-what which is a
simple shell script that detects if you are running inside a virtual
machine, and prints some "facts" about that virtual machine.
[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00039.html
Xen 3.3.0 Released
Pasi Kärkkäinen forwarded[1] from xen-devel an announcement of Xen
3.3.0. Pasi also followed up[2] on a thread from July where Daniel P.
Berrange said about Fedora 10, "Even though we don't have any Dom0 I'll
update it to 3.3.0 for the xen RPM and hypervisor. This will at least
let people build their own legacy Xen kernel from upstream's 2.6.18 xen
kernel"
[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00038.html
[2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00029.html
Testing LiveCD Distros as DomU Guests
jean-Noël Chardron posted[1] a howto for testing live cd images by
booting them in a DomU with virt-install.
[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00024.html
Libvirt List
This section contains the discussion happening on the libvir-list.
Daniel P. Berrange posted[1] a todo list for libvirt which was the
product of a brainstorming session at Red Hat. Daniel offered this list
as a good starting point for those wishing to assist in the development
of libvirt.
[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00718.html
Live Migration Sanity Checks
Chris Lalancette described[1] a feature that oVirt would like to see.
The feature would be a set of sanity checks a caller could make to
determine if live migration of a given virtual machine would be likely
to succeed.
[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00757.html
sVirt: XML Representation of Security Labels
James Morris continued[1] work on the sVirt project by investigating how
and when to label the resources accessed by domains and proposed an XML
representation of these labels.
[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00740.html
LXC: Making the Private Root Filesystem More Secure
After committing the private root filesystem code for LXC Daniel P.
Berrange noted[1] that cgroups supports device ACLs which could defend
against 'mknod' escapes into the host OS devices.
[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00734.html
Exposing Unique Hypervisor Features
Nguyen Anh Quynh asked[1] how libvirt can expose the unique features of
a given hypervisor such as the monitor interface of Qemu. Daniel P.
Berrange responded[2] by stating the policy for adding new APIs to
libvirt is that the conceptual representation has to be applicable to
multiple hypervisors and unique concepts may be exposed if they can be
represented in a way which would also make sense for other hypervisors
in the future. This goal is also stated in the libvirt architecture
document.
[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00693.html
[2] https://www.redhat.com/archives/libvir-list/2008-August/msg00701.html
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFIu8O/zHDc8tpb2uURArkzAKCZJprWqqb9prB84eXpqiSqvbrDDACgh50M
3H2qF1AMyoMPdcf1comVOwU=
=wk+7
-----END PGP SIGNATURE-----
15 years, 7 months