Fedora Weekly News Issue 114
Thomas Chung
tchung at fedoraproject.org
Mon Jan 7 09:57:35 UTC 2008
= Fedora Weekly News Issue 114 =
Welcome to Fedora Weekly News Issue 114 for the week of December 31st,
2007 http://fedoraproject.org/wiki/FWN/Issue114
In Announcement, "FUDCon Raleigh 2008" and "Fedora Unity announces
Fedora 8 Re-Spin"
In Planet Fedora, "Red Hat's New CEO", "bugz.fedoraproject.org" and
"Fedora Xfce Spin"
To join or give us your feedback, please visit
http://fedoraproject.org/wiki/NewsProject/Join.
1. Announcements
1. FUDCon Raleigh 2008
2. Fedora Unity announces Fedora 8 Re-Spin
2. Planet Fedora
1. Red Hat's New CEO
2. bugz.fedoraproject.org
3. Fedora Xfce Spin
3. Marketing
1. Is Red Hat still relevant? You bet
2. IcedTea 1.5 Adds PowerPC Java Port
3. Installing Fedora 8 on Hyper-V
4. Developments
1. SELinux Rants
2. Mass Rebuild Using GCC 4.3.0-0.4
3. Call For Maintainers Of TeXLive-Related Packages
4. Policy Proposal For New Compatibility Packages
5. GDB Messages Enhanced To Indicate Missing Debuginfo Files
5. Documentation
1. FDSCo results
6. Security Advisories
1. Fedora 8 Security Advisories
2. Fedora 7 Security Advisories
7. Events and Meetings
1. Fedora Board Meeting Minutes 2008-MM-DD
2. Fedora Ambassadors EMEA Meeting 2008-MM-DD
3. Fedora Documentation Steering Committee 2008-MM-DD
4. Fedora Engineering Steering Committee Meeting 2008-MM-DD
5. Fedora Infrastructure Meeting Log 2008-01-03
6. Fedora Localization Meeting 2008-MM-DD
7. Fedora Marketing Meeting 2008-MM-DD
8. Fedora Packaging Committee Meeting 2008-MM-DD
9. Fedora Quality Assurance Meeting 2008-MM-DD
10. Fedora Release Engineering Meeting 2008-MM-DD
11. Fedora SIG EPEL Meeting Week 01/2008
12. Fedora SIG KDE Meeting Week 01/2008
13. Fedora SIG Store Meeting 2008-MM-DD
14. Fedora SIG Astronomy Meeting Log 2007-12-28
[[Anchor(Announcements)]]
== Announcements ==
In this section, we cover announcements from Fedora Project.
In this issue, we've included all new announcements since last issue.
https://www.redhat.com/mailman/listinfo/fedora-announce-list
Contributing Writer: ThomasChung
=== FUDCon Raleigh 2008 ===
MaxSpevack announces in fedora-announce-list[1],
"Whether you are a new Fedora user who just started with Fedora 8, a
seasoned veteran who has been with Red Hat from the very beginning, or
somewhere in between, you are all invited to FUDCon Raleigh 2008.
http://barcamp.org/FUDConRaleigh2008
This year's FUDCon is a 3 day event, from Friday January 11th - Sunday
January 13th."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-December/msg00006.html
=== Fedora Unity announces Fedora 8 Re-Spin ===
JeroenVanMeeuwen announces in fedora-announce-list[1],
"The Fedora Unity Project is proud to announce the release of new ISO
Re-Spins (DVD and CD Sets) of Fedora 8. These Re-Spin ISOs are based
on the officially released Fedora 8 installation media and include all
updates released as of December 18th, 2007. The ISO images are
available for i386 and x86_64 architectures via jigdo starting Sunday,
December 23rd, 2007."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-December/msg00008.html
[[Anchor(PlanetFedora)]]
== Planet Fedora ==
In this section, we cover a highlight of Planet Fedora - an
aggregation of blogs from world wide Fedora contributors.
http://fedoraproject.org/wiki/Planet
Contributing Writers: ThomasChung
=== Red Hat's New CEO ===
MaxSpevack points out in his blog[1],
"Matt Asay interviewed Red Hat's new CEO, Jim Whitehurst. I thought
this was a great interview. A lot of the things that Jim says really
resonated with me, and I think that all of the Fedora folks out there
will find themselves nodding their heads as they read it too."
[1] http://spevack.livejournal.com/41708.html
=== bugz.fedoraproject.org ===
SethVidal points out in his blog[1],
"Toshio, Will Woods and myself came up with something a little while
back and each of us did a part in implementing it. It's
bugz.fedoraproject.org"
[1] http://skvidal.wordpress.com/2008/01/03/bugzfedoraprojectorg/
=== Fedora Xfce Spin ===
RahulSundaram points out in his blog[1],
"Fedora Xfce Spin is a variant of Fedora with a focus on low resource
systems and in particular Xfce users. It is a live cd image that you
can optionally install to hard disk or USB images."
[1] http://rahulsundaram.livejournal.com/17893.html
[[Anchor(Marketing)]]
== Marketing ==
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
=== Is Red Hat still relevant? You bet ===
RahulSundaram reports in fedora-marketing-list[1],
"Many Linux users don't seem to realize just how much Red Hat
contributes back to the Linux community. They are major software
developers on a number of projects not the least of which is the Linux
kernel. The Fedora Project site has a page entitled Red Hat
contributions to Free and Open Source software which lists most of Red
Hat's contributions."
[1] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00044.html
=== IcedTea 1.5 Adds PowerPC Java Port ===
RahulSundaram reports in fedora-marketing-list[1],
"The IcedTea project added a PowerPC Java port (both 32 and 64 bit) of
OpenJDK. IcedTea 1.5 now also tracks the mercurial repo, provides
better GNU/Linux integration by using standard system libraries
(libpng, libjpeg, zlib, giflib) and can be bootstrapped with the free
gcj/ecj/classpath toolchain. OpenJDK just accepted a new porters group
and Gary Benson wrote a guide to porting IcedTea that might be the
start of a lot of other Java ports."
[1] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00041.html
=== Installing Fedora 8 on Hyper-V ===
RahulSundaram reports in fedora-marketing-list[1],
"Microsoft developer's article about Fedora as a guest in a Windows
virtualized environment."
[1] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00037.html
[[Anchor(Developments)]]
== Developments ==
In this section, we cover the problems/solutions, people/personalities, and
ups/downs of the endless discussions on Fedora Developments.
http://www.redhat.com/mailman/listinfo/fedora-devel-list
Contributing Writer: OisinFeeley
=== SELinux Rants ===
SELinux[1] was the subject of three distinct threads. The first was
initiated when SteveGrubb responded[2] to the 22 Dec 2007 rawhide
report with the information that all kernels for x86_64 subsequent to
2.6.24-0.81.rc4.git7.fc9 were failing to boot. PatriceDumas was able
to confirm[3] the problem as was DavidZeuthen. A post from EricParis
suggested that ''selinux-policy'' might be responsible for the problem
and that manual (rpm) removal of the kernel followed by switching off
SELinux enforcing mode and then updating the kernel and then
re-activating enforcing mode might help. David stated[4] that he was
not running enforcing mode. When DimiPaun expressed regret at this
David produced[5] an "selinux rant, compressed version." In this David
drew attention to the problem that SELinux policy is too complicated
and requires a single maintainer, DanWalsh, to effectively know the
quirks of every piece of software. In David's experience as a
packager, user and developer SELinux had failed but he acknowledged
that it might be useful for tightly-controlled servers. As a possible
fix David suggested that policy files could be handled by rpm, but
thought that this would be dismissed automatically as an option.
[1] http://www.nsa.gov/selinux/
[2] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01500.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01677.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00199.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00219.html
JesseKeating countered[6] the assumption that the problem was rpm,
stating instead that SELinux itself prevented rpm from being able to
write files for which it did not yet have a context. Jesse wished that
SELinux upstream would get a clue. David argued[7] that SELinux were
not solely to blame and suggested that rpm and selinux could be used
together by installing the policy before the files were copied. He
suggested that a two-way conversation between the respective projects
would be useful. Jesse also touched[8] on the current necessity of
using permissive mode during installs to avoid failures.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00223.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00226.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00225.html
DanWalsh posted[9] a detailed rebuttal of David's contention that
devolving policy to individual maintainers would work. His main
points seemed to be assertions that maintainers would not do a good
job and also that it was necessary for someone to take an overview of
the complex interactions between many packages. Dan suggested that
David was more likely to run into problems than most because of the
frequent need for root permissions in his work. Dan also asked Jesse
for specific details of problems that required running in permissive
mode. Jesse's response indicated[10] the complexity of the problem
involving at least two chroots. David asserted[11] was in essence
confirming the idea that SELinux was too complicated and challenged
Dan to allow him to maintain the policy for hal and to open up to
other maintainers willing to help in this area. SteveGrubb
differed[12] and suggested that rather than blame SELinux for
complexity it was better to realize that it was describing the complex
interactions between different pieces of software. Steve wondered if a
tool to compare newly introduced syscalls with older versions could
help out.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00237.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00242.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00246.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00253.html
The second rant was posted[13] by EdSwierk in which he detailed the
problems he encountered when he tried to copy old user directories
into a fresh server installation. Ed noted that his solution was just
to switch SELinux off and commented "For me learning SELinux seems as
pointless as trying to remember iptables commands, or AFS trivia back
when I was a student--all cause me trouble just infrequently enough to
ensure I have to relearn them from scratch every time. If I were a
full-time sysadmin of course it would be a different story[.]"
EricParis asked how Ed had copied the files, and when it turned out to
be with ''tar'' TomaszTorcz suggested[14] that he should have used the
''--xattrs'' option. Tomasz explained that all that was important was
that the context labels were set correctly for the files and that file
location was irrelevant. JohnDennis drew[15] attention to the
''setroubleshoot'' and ''setroubleshoot-server'' packages which help
SELinux novices identify such problems and suggests resolutions for
them. The ''setroubleshoot-server'' package was explained[16] by John
to address the needs of those running headless servers.
[13] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00230.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00267.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00315.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00331.html
Ed expressed appreciation for JohnDennis's help but wondered why the
messages could be made clearer somehow. KonstantinRyabitsev
suggested[17] using ''audit2allow'' and ''audit2why'' and John
suggested {{{sudo sealert -a /var/log/audit/audit.log}}}.
[17] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00352.html
A less sanguine evaluation of ''setroubleshoot'' was expressed[18] by
JonathanUnderwood who thought that it taught novice users that many
problems were simply "due to bugs in selinux policy". TomLane
agreed[19] with RalfCorsepius that it might not be appropriate to
inform ordinary users about avc denials, but pointed out that at the
present the policies were a work in progress and that feedback on them
was essential.
[18] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00376.html
[19] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00414.html
The thread ended[20] amicably as discussion between Ed and
AndrewFarris made it quite clear that Ed was reporting his experience
as an insight into why some people disable SELinux. Closing posts
indicated that perhaps improving the error messages could help.
[20] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00259.html
The third related discussion was initiated[21] by LinusWalleij when he
asked why ''system-config-selinux'' or ''anaconda'' did not seem to
disable all the selinux related services and daemons upon request.
EricParis replied[22] that in general services were not coupled such
that stopping one stopped others, and that for the specific cases of
''auditd'', ''mcstrans'', ''restorecond'' and ''setroubleshoot''
mentioned by Linus there was no necessity for it as ''auditd'' can
work without the presence of ''selinux'' and vice-versa. Linus
investigated[23] the other users of ''auditd'' in Fedora and came up
with some non-default installed programs and the conclusion that "As
it stands now, a human can advise the user (in this case me) to turn
off auditd (and the other selinux services) on their travel laptop
[...] but the system itself cannot." A very interesting post from
SteveGrubb explained[24] the utility of auditd (which among other
things prevents the syslog from becoming cluttered. Steve pointed out
that the audit logs collected a large amount of information ranging
from failed logins to segfaulting applications, all of which could be
quickly eyeballed with {{{aureport --start this-week}}}. He also
pointed out that the new security audit tool ''sectool''[25] and
''aide'' and his own planned IDS plugin[26] would use this
information, so that turning off auditd was possibly not desirable.
EnricoScholz added[27] the caution that the local logging of auditd
limited its usefulness on compromised machines.
[21] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00243.html
[22] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00244.html
[23] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00279.html
[24] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00296.html
[25] https://hosted.fedoraproject.org/sectool
[26] See FWN#100 "Layering An IDS On Linux"
http://fedoraproject.org/wiki/FWN/Issue100#head-051ea9b1b3a45c4c8cae083db32214ee8682a1f8
[27] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00299.html
Linus thanked Steve for the detailed explanation and proved his good
intentions with a patch to add a better description to
/etc/init.d/auditd. The patch was accepted with minor changes by
SteveGrubb.
[28] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00372.html
=== Mass Rebuild Using GCC 4.3.0-0.4 ===
The results of rebuilding Rawhide using the newest GCC were posted[1]
by JakubJelinek. A snapshot of Rawhide dated 20th Dec 2007 contained
5118 src.rpms of which 1054 failed to build. In order to determine
which of those failures were due to the new GCC Jakub attempted to
rebuild using the older, stock GCC (4.1.2-36) and identified 547 that
failed, leaving 507 which failed solely due to the new GCC. Jakub
classified these failures in his post and listed the failing packages
for the benefit of maintainers. The bulk of the errors seemed to be
due to changes in the C++ Standard Template Library.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00128.html
Jakub answered a few queries from maintainers who needed further help
and one useful practical point that emerged[2] was that in order to
test the building of a package with the new GCC it is necessary to do
a scratch build in dist-f9-gcc43 as suggested by "drago01". It also
seemed that there was a problem with "gettext" depending on a newer
Java. Jakub clarified[3] that he had rebuilt gettext in his original
buildroots, but not for dist-f9-gcc43.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00149.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00277.html
Later ThorstenLeemhuis provided[4] a version of the list with package
owner names prepended to each line.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00145.html
HansdeGoede noticed[5] what seemed to be errors which were due to
''boost'' which was not itself on the list of packages failing to
build.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00162.html
The possibility that some failures are due to problems in rawhide at
the time that the snapshot was taken was highlighted[6] when
ChristopherWickert sought and received Jakub's help in interpreting a
cryptic error.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00154.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00163.html
Failures experienced by HansdeGoede for a package depending on
"allegro" and BradenMcDaniel for ''openvrml'' exposed[8] some problems
due to the use of ''extern "C" ''. TomTromey pointed out[9] that a
parameter list cannot contain a typedef to void instead of a type void
in C++. JakubJelinek echoed[10] this and emphasized that any included
header could only use the common subset of C and C++. Hans
expressed[11] the opinion that this was a bug of C++, which TomTromey
agreed with.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00262.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00264.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00278.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00327.html
JonCiesla added[12] his voice to the many thanks that Jakub received
and requested that the exercise be repeated before F9 Gold. The
specific errors that he, IgnacioVazquezAbrams and GianlucaSforna were
dealing with were in Python packages (eggs) which were failing to have
their info included in the specfile.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00285.html
=== Call For Maintainers Of TeXLive-Related Packages ===
PatriceDumas asked[1] for volunteers to help maintain packages which
had been bundled into TeXLive although they are not actually part of
it[2]. Patrice offered to review any packages but was too busy to take
on the burden of maintaining these programs.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00433.html
[2] TeXLive is a collection of software for working with TeX markup.
It replaces the older teTeX collection
Discussion centered around the ''xdvi'' document renderer, which
JonathanUnderwood suggested could be entirely eliminated if only
''evince'' had dvi support enabled. MatthiasClasen commented that the
dvi backend of evince was actually enabled in rawhide for some time,
which led Jonathon to ask[3] for the relevant bugzilla entry to be
closed. When Patrice commented that the removal of ''xdvi'' would be a
problem for him Jonathon concurred[4] after testing a local build and
finding that evince does not automatically refresh when the file
changes on disk.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00471.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00439.html
MamoruTasaka also thought that removing ''xdiv'' would be a problem
because users of Japanese pTeX needed it. Jonathon responded[5] that
he was hacking together a specfile to allow xdvi to be maintained.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00465.html
=== Policy Proposal For New Compatibility Packages ===
BrianPepple requested[1] feedback on a proposal concerning the
maintenance of compatibility packages which will be voted on at the
10th January 2008 FESCo meeting. The proposal attempts to describe the
limited conditions under which compatibility packages could be
maintained and the manner in which disputes could be resolved.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00052.html
The issue of whether there should be a time-limit on the maintenance
was raised by several people. NicolasMailhot made[2] a strong case
that it was necessary, and raised the specter of "the path of least
resistance" resulting in maintainers pushing such libraries for ever
with the result that upstream development would receive no pressure to
move to newer APIs. Although several others shared these concerns
there was also a desire to avoid bureaucracy and trust packagers as
expressed[3][4] by PatriceDumas.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00085.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00084.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00094.html
Patrice wondered why extra veto powers were being given to the primary
maintainers over those that wished to maintain compatibility
libraries. BrianPepple responded that it was due to the increased
work that would inevitably devolve onto the primary maintainer (due to
security problems and misfiled bugs). Patrice remained unconvinced
and stated[5] that the "asymmetry" introduced was unneeded as the
primary maintainer could already raise concerns. JoshBoyer thought[6]
that the emphasis on vetoes was misplaced and that the differences
between Brian and Patrice were more apparent than real. Patrice
finished[7] off with an examination of the language of the proposal
which pointed out that as current procedures allow any packager to
block a review with an escalation to FESCo there should really be no
need for this apparently redundant guideline.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00098.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00108.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00122.html
Support for Brian's proposal was expressed[8] by LinusWalleij on the
grounds that compatibility cruft would slow down the swift release
cycle of Fedora. When Patrice wondered how this would actually happen
JesseKeating suggested[9] that build failures and increased workload
on the primary maintainer were two likely mechanisms. A small exchange
between Linus and Patrice on the subject of breaking APIs versus
publishing compatibility packages ensued[10].
[8] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00155.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00166.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00170.html
An interesting reframing of the problem was posted[11] by
ThorstenLeemhuis. Thorsten argued that proprietary applications
frequently needed compatibility libraries. Rather than focusing on
compatibility libraries as the problem Thorsten suggested that
discouraging other non-proprietary applications from using the
compat-packages should be a priority. Some practical reinforcement of
the point was expressed[12] by "Alan". In response JesseKeating
drew[13] a distinction between compatible libraries (which made sense
to him) and compatible development packages (which did not).
[11] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00065.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00066.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00069.html
KevinKofler and LesMikesell argued the toss[14] over whether breaking
the API was a good idea and how this affected proprietary code ... or
not.
[14] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00072.html
=== GDB Messages Enhanced To Indicate Missing Debuginfo Files ===
A query from NealBecker asked[1] why running ''gdb'' on a program now
produced many warnings of the form "Missing the separate debug info
file: /usr/lib/debug/.build-id/XXXXXXX.debug". AndrewHaley
responded[2] that the problem was that the appropriate "-debug"
packages for the shared libraries were not installed and suggested
that the absence of specific information as to which libraries were
missing was a bug.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00300.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00302.html
While acknowledging that it was slightly awkward to find the
information MattMiller suggested[3] enabling the debuginfo repository
so that YUM could be used to install the missing filename's package.
JesseKeating added[4] that it was easier to use {{{debuginfo-install
<appname>}}} which would automatically enable the debuginfo repository
and install the requisite debuginfo packages. A very informative post
from JanKratochvil, a Red Hat employee primarily focusing on GDB,
followed[5]. Jan's post showed how to find the name of the library
missing debuginfo {{{ls -l /usr/lib/debug/.build-id/fa/XXXX.debug}}},
how to find the RPM package name to install the debuginfo {{{repoquery
-qf /usr/lib/debug/.build-id/fa/XXXXX.debug}}} and as suggested
previously by MattMiller how to simply install the missing debuginfo
package with {{{yum install
/usr/lib/debug/.build-id/fa/XXXXX.debug}}}. Jan cautioned that
''debuginfo-install <appname>'' method might not work due to multiple
simultaneous debuginfo versions present and he also encouraged
discussion on how to improve the output.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00306.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00307.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00308.html
Further discussion between AndrewHaley and Jan on how to improve the
ability of GDB to suggest the correct debuginfo packages uncovered
some constraints. Jan pointed[6] out that ''debuginfo-install'' will
have problems with dynamically opened libraries, that printing out a
suggested RPM package would unacceptably tie GDB to Fedora. These
debuginfo files are the result of work by RolandMcGrath and others on
BuildID, which is a Fedora 8 feature[7][8], which extended the
information in core files to include specific versions of binaries and
dynamic shared objects. This enables precise replication of a problem
for debugging. Implementing this required changes to the kernel[8a],
''ld'' and other parts of the compiler toolchain and so are of general
interest, non-exclusive to Fedora. AndrewHaley suggested[9] that a
local (to Fedora) patch could produce his version of perfection, which
would be to suggest a specific yum installation command. JamesAntill
thought[10] that if perfection and local patching were being
considered then tighter integration with rpm or yum could allow the
use of ''debuginfo-install <packagename>''.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00312.html
[7] http://fedoraproject.org/wiki/Releases/FeatureBuildId
[8] Section 15.2 of the gdb info file explains that a build-id is a
section of the executable file which is a unique identification hash
which remains constant across multiple builds of the same build tree.
[8a] http://www.uwsg.indiana.edu/hypermail/linux/kernel/0707.1/1702.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00317.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00339.html
When TomLondon experimented[11] with ''debuginfo-install'' and got a
large list of dependencies Jan asked[12] why debuginfo packages were
pulling in binary packages and suggested a patch to the redhat rpm
macros. RolandMcGrath responded[13] with a suggestion that
''redhat-rpm-config'' should also change.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00350.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00353.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00362.html
In closing DavidNielsen suggested[14] that PackageKit might aid in
figuring out which packages were missing and offering to install them
for the user.
[14] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00355.html
[[Anchor(Documentation)]]
== Documentation ==
In this section, we cover the Fedora Documentation Project.
http://fedoraproject.org/wiki/DocsProject
Contributing Writer: ThomasChung
=== FDSCo results ===
KarstenWade reports in fedora-docs-list[1],
"With a slight delay for the holidays to get the results :), the
following persons will be staying or joining the Fedora Documentation
Steering Committee (FDSCo): BartCouvreur, JohnBabich, JaredSmith"
[1] https://www.redhat.com/archives/fedora-docs-list/2007-December/msg00351.html
[[Anchor(SecurityAdvisories)]]
== Security Advisories ==
In this section, we cover Security Advisories from fedora-package-announce.
https://www.redhat.com/mailman/listinfo/fedora-package-announce
Contributing Writer: ThomasChung
=== Fedora 8 Security Advisories ===
* qt4-4.3.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00005.html
* wordpress-2.3.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00079.html
* libcdio-0.78.2-4.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00106.html
* asterisk-1.4.17-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00167.html
* python-cherrypy-2.2.1-8.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00240.html
* mantis-1.1.0-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00309.html
=== Fedora 7 Security Advisories ===
* libcdio-0.78.2-4.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00080.html
* wordpress-2.3.2-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00098.html
* qt4-4.3.3-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00131.html
* asterisk-1.4.17-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00166.html
* mantis-1.1.0-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00227.html
* python-cherrypy-2.2.1-8.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00297.html
[[Anchor(EventsMeetings)]]
== Events and Meetings ==
In this section, we cover event reports and meeting summaries from
various Projects and SIGs.
Contributing Writer: ThomasChung
=== Fedora Board Meeting Minutes 2008-MM-DD ===
* No Report
=== Fedora Ambassadors EMEA Meeting 2008-MM-DD ===
* No Report
=== Fedora Documentation Steering Committee 2008-MM-DD ===
* No Report
=== Fedora Engineering Steering Committee Meeting 2008-MM-DD ===
* No Report
=== Fedora Infrastructure Meeting Log 2008-01-03 ===
* https://www.redhat.com/archives/fedora-infrastructure-list/2008-January/msg00019.html
=== Fedora Localization Meeting 2008-MM-DD ===
* No Report
=== Fedora Marketing Meeting 2008-MM-DD ===
* No Report
=== Fedora Packaging Committee Meeting 2008-MM-DD ===
* No Report
=== Fedora Quality Assurance Meeting 2008-MM-DD ===
* No Report
=== Fedora Release Engineering Meeting 2008-MM-DD ===
* No Report
=== Fedora SIG EPEL Meeting Week 01/2008 ===
* https://www.redhat.com/archives/epel-devel-list/2008-January/msg00043.html
=== Fedora SIG KDE Meeting Week 01/2008 ===
* https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00216.html
=== Fedora SIG Store Meeting 2008-MM-DD ===
* No Report
=== Fedora SIG Astronomy Meeting Log 2007-12-28 ===
* https://www.redhat.com/archives/fedora-astronomy-list/2007-December/msg00047.html
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
More information about the fedora-announce-list
mailing list