advisory and fonts
by Michael Larabel
FYI, There's nothing to report on in either list this week.
Happy Holidays,
Michael Larbael
16 years, 5 months
- 3
- 2
@fedora-devel newsbeat ready for FWN#112
by Oisin Feeley
Hi all,
Only eight topics this week. Again, if anyone wants to add something
please jump in.
Thomas, I have a weird issue with the title/heading of the fourth topic.
I cannot understand why it doesn't appear in the same style as the
others. Help appreciated. I looked at the head "Replacing Tail With
Inotify Aware Version" once or twice and cannot see what is causing it
to be ignored as a heading.
https://fedoraproject.org/wiki/FWN/Beats/Developments#preview
--
Oisin Feeley
oisinfeeley(a)imapmail.org
16 years, 5 months
- 2
- 1
YUM vs Smart vs Apt-Get
by Eli Wapniarski
I'm writing this in order to hopefully generate some genuine critical
discussion and to jar away some possible group think.
I would venture to guess that most of us that need to use Windows for whatever
reason do not accept the default browser installed with Windows and
Immediately download and use Firefox. Why? Because we feel it is the better
browser. Most Windows users seem to get get caught in the “because it comes
with the installation then I'm all set,” and away they go. My feeling is that
most Fedora users get caught in this mode of thinking as well. At least this
seems to be the case when it comes to my cursive discussions regarding the
primary way people seem to maintain their systems. That is, what defaults to,
YUM.
With Fedora 8 I've run into a few minor but irritating snags. With Fedora 8
one of these issues is currently irritating but, I can see this specific
problem generating a genuine discouragement for maintainers and users of 3rd
party repositories.
With no slight intended to Gnome users, I'm a KDE user. For us KDE user's
Redhat 8 was a real dud. It was frustrating that in an effort to unify the
users desktop experience Redhat broke an awful lot of functionality and it
was genuinely frustrating to feel that us KDE users were being coerced into
using Gnome. That's when I started experimenting with other distros. I
dropped Mandrake because installations were flaky. I dumped Debian because
hardware detection was flaky. I was disappointed by Suse because its
Administration tools were slow and confusing. At least what did work in
Redhat 8 worked. Even though I felt my desktop was crippled (using KDE). I
still preferred my working computer.
Then came Rex Dieter and KDE-Redhat and my introduction to Apt-Get. All I
could say was wow. All of a sudden my desktop came alive again; bright and
shiny. Everything started working the way it was supposed to. Menu editing,
configuration of my desktop and I did not have to go and recompile source
code to do the job. Thank you Rex.
This wonder of Apt-Get and 3rd party repositories made my life so much easier.
Then I became aware of Freshrpms and Livna and Rpmforge and ATRpms. I'm using
all of them for one application or another because, none of them including
Fedora provide everything that I need or use.
Once I became relatively proficient with Apt-Get and thanks to Freshrpms which
put under one roof, Fedora Core, Updates and Freshrpms I have not needed to
use a CD to update my computers since Fedora 4. I have successfully managed
to relatively smoothly upgrade my systems with Apt-Get from Fedora Core 4 to
Fedora 8. Except for a few minor conflicts which have been easily fixed by
manually forcing an upgrade of a few family of packages.
Now, because Matthias Saou of Freshrpms seems to be very busy with a new 3rd
party repository called Rpmfusion combining Dribble, Livna and Freshrpms and
the consequential disruptions that this is causing of the maintenance of
Freshrpms I have been prompted to re-examine my options regarding package
management.
After about a month of working with YUM and Smart, I have to conclude, at
least from a user's perspective, that Apt-Get is still the superior package
management solution. Allow me to explain.
YUM has come along way since its introduction including prioritized
repositories. This works if your configuration stays static. If you have had
packages installed from one 3rd party repository and then decide to switch
priority to a different one there does not seem to be anyway to enforce this
switch by automatically downgrading packages to conform to that decision.
What I mean by downgrading is that even though two different 3rd party
repositories might have the same application version packaged their filenames
will be different. If YUM decides that a package currently installed is newer
than the package from a newly prioritized repository YUM will not install the
package from the prioritized repository.
With Apt-Get and Smart, if priorities are configured correctly, then the
downgrade will occur. The nice thing with Smart is that it will do this with
repomd (YUM configuration) while Apt-Get still can not do this with repomd.
I did not try to upgrade a system using YUM because Fedora does not recommend
it. I did try to upgrade a system using Smart. Everything came in and
installed except for a couple of minor problems with post processing scripts
which left behind duplicate packages. One of these scripting issues was a
problem with the kernel that was to be installed with Fedora 8. Fortunately
my newly installed Fedora 8 did not panic with the Fedora 7 kernel. So I
issued an apt-get reinstall kernel and Apt-Get indicated that there were
duplicate packages because of post processing of scripts which left behind
Fedora 7 packages in the RPM database. The duplicate packages were not
indicated by Smart or YUM. Apt-Get instructed me to on how to fix the
configuration or fix my system. I elected to fix my system and then reissued
the apt-get reinstall kernel command. I rebooted by my computer and all was
well.
The current problem with Apt-Get is that while it supports repomd format of
YUM which most 3rd party repositories support exclusively it cannot
prioritize them. If you use one or two repositories then prioritizing them
does not seem necessary. However, if you are like me and you use multiple
repositories then enforced prioritizing becomes essential. It is the only way
to ensure predictable behavior from package management.
I am guessing that package managers use repomd because for them its easier
then Apt-Get. I'm only guessing. Apt-Get enforces priorities. So does Smart.
Smart also does this with repomd repositories as well as apt repositories
while While Apt-Get will only do this apt repositories even though it does
support repomd. YUM's priority feature is incomplete and does not handle apt
repositories at all.
All three applications once configured correctly excel at maintaining your
system; once the dust is settled and all the packages are coming from where
they're supposed to. However, only one of these applications allows me to
smoothly upgrade full release installations. This is Apt-Get.
The last point is, in my opinion, what makes Apt-Get the best tool for the
job. Why? Because, Fedora upgrades come fast and furious. For a lot us, 3rd
party repositories are essential to add features and applications that are
not included in Fedora's releases. If I were to rely only on removable media
I could not predict what would or would not be removed or stop working due to
the upgrade from one release to the next. Apt-Get is the only package manager
that allows for relatively smooth upgrades from one release to another
without giving up the benefits provided by 3rd party repositories.
And this becomes even more important if you need to maintain an older computer
in a remote location that you can only upgrade during non-business hours. It
can take all day, and this is a terrible way to spend the weekend. With
apt-get after proper prioritization I tell it to get the files from the new
release and then do the following
connect to remote computer with ssh
su -
backup any essential configuration files
apt-get update
apt-get -df dist-upgrade
(go do something else while everything downloads)
apt-get -f dist-upgrade
(fix conflicts)
apt-get -f upgrade
(go do something else while everything gets installed)
reboot
ta-da new release installed and working.
Recompile anything that I had to compile manually to have it work more
effeciently with the newly installed libraries.
I simply cannot do this with any other package manager and this is why I like
and rely on Apt-Get. I open the floor to everyone.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
16 years, 5 months
- 3
- 5
Fedora Weekly News Issue 111
by Thomas Chung
= Fedora Weekly News Issue 111 =
Welcome to Fedora Weekly News Issue 111 for the week of November 26th.
http://fedoraproject.org/wiki/FWN/Issue111
In Planet Fedora, we have "Free Creative Commons 5th Bday DEC 15 in
San Francisco", "Testing Needed: mkinitrd bash-branch", "The plan for
Xen kernels in Fedora 9", "Zagreb of Croatia Reporting" and "Official:
FUDCon, Raleigh, January 11-13 2008"
In Marketing, we have "IcedTea interview"
To join or give us your feedback, please visit
http://fedoraproject.org/wiki/NewsProject/Join.
1. Planet Fedora
1. Free Creative Commons 5th Bday DEC 15 in San Francisco
2. Testing Needed: mkinitrd bash-branch
3. The plan for Xen kernels in Fedora 9
4. Zagreb of Croatia Reporting
5. Official: FUDCon, Raleigh, January 11-13 2008
2. Daily Package
1. iotop - Display I/O Activity by Process
2. gimp-resynthesizer - Texture synthesis for the Gimp
3. Wednesday Why: Grub Boot Configuration
4. ManEdit - manpage editor
5. Super Tux Kart - Go-cart racing game
3. Marketing
1. IcedTea interview
4. Developments
1. RFC: Package Review VCS
2. Review Queue Cont.
3. Core Fonts Issues
4. Fedora 8 Boot-up Speed
5. WTF? Inaccessible Bug Reports?
6. Alpha/Beta Software In Fedora 8: Bind
7. TV Support In Fedora 9
8. Heads Up! Rpm Default Queryformat To Include Arch
9. Metacity Dependency Forced During Fedora 7 To 8 Upgrade
10. NetworkManager To Get UMTS/GPRS Support
5. Advisory Board
1. Fedora Board Elections
6. Fonts
1. Core Font Packaging Guideline Writer Wanted
7. Documentation
1. Works in Progress
2. Apache FOP in Rawhide
8. Translation
1. Translation Quick Start Guide
9. Infrastructure
1. Project SSL Usage
10. Security Week
1. Firefox 2.0.0.10
2. Insecurity Blues
11. Advisories and Updates
1. Fedora 8 Security Advisories
2. Fedora 7 Security Advisories
12. Events and Meetings
1. Fedora Board Meeting Minutes 2007-11-27
2. Fedora Ambassadors Meeting 2007-MM-DD
3. Fedora Documentation Steering Committee (Log) 2007-MM-DD
4. Fedora Engineering Steering Committee Meeting 2007-MM-DD
5. Fedora Infrastructure Meeting (Log) 2007-11-29
6. Fedora Localization Meeting 2007-11-29
7. Fedora Marketing Meeting 2007-MM-DD
8. Fedora Packaging Committee Meeting 2007-MM-DD
9. Fedora Quality Assurance Meeting 2007-11-28
10. Fedora Release Engineering Meeting 2007-MM-DD
11. Fedora SIG EPEL Meeting Week ??
12. Fedora SIG KDE Meeting Week 48
13. Fedora SIG Store Meeting 2007-MM-DD
[[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
=== Free Creative Commons 5th Bday DEC 15 in San Francisco ===
JonPhillips points out in his blog[1],
"CC is turning 5 and to celebrate we're throwing a community-wide
party. If you'll be in the San Francisco Bay Area on December 15, join
us for a night of celebrating the commons at a party generously
sponsored by Mozilla and Last.fm."
[1] http://rejon.org/2007/12/02/free-creative-commons-5th-bday-dec-15-in-san-...
=== Testing Needed: mkinitrd bash-branch ===
WarrenTogami points out in his blog[1],
"One of the things I've been working on is an experimental branch of
mkinitrd that uses bash to run the /init script instead of just nash.
Having a real shell allows more flexibility in what can be done in the
initramfs in shell scripting."
[1] http://wtogami.livejournal.com/21452.html
=== The plan for Xen kernels in Fedora 9 ===
DanielBerrange points out in his blog[1],
"This is a friendly alert of the major plans we have for Xen kernels
in Fedora 9 timeframe... Also syndicated on the fedora-xen mailing
list."
[1] http://berrange.com/personal/diary/2007/11/plan-for-xen-kernels-in-fedora-9
=== Zagreb of Croatia Reporting ===
DimitrisGlezos points out in his blog[1]
"So here I am, in beautiful Zagreb of Croatia in a big circle of
chairs where 40 people from more than 20 countries have come together
for the Open Translation Tools Convergence event."
[1] http://dimitris.glezos.com/weblog/2007/11/30/zagreb-reporting/
=== Official: FUDCon, Raleigh, January 11-13 2008 ===
GregDeKoenigsberg points out in his blog[1],
"If you've ever wanted to see Red Hat Global HQ, now you've got an
excuse. The Fedora User and Developer Conference will be held in
Raleigh NC. As we did last time: FUDCon Friday will be the
free-for-all BarCamp style event, and Saturday and Sunday will be
hackfest time."
[1] http://gregdek.livejournal.com/20235.html
[[Anchor(DailyPackage)]]
== Daily Package ==
The Fedora Daily Package is back after an extended hiatus! In this
section, we recap the packages that have been highlighted this
week[1].
[1] http://dailypackage.fedorabook.com/
Contributing Writer: ChrisTyler
=== iotop - Display I/O Activity by Process ===
''Productive Mondays'' highlight a timesaving tool. This Monday[1] we
covered itop[2]:
"System administrators have always relied on top for per-process CPU
and memory usage statistics, and vmstat (or sar) to analyze I/O -- but
there has been no easy way to analyze disk I/O on a per-process basis.
iotop is the missing tool. It shows the disk read and write rate,
swapins, and total disk I/O for each process. The process list is
sorted by I/O and updated once per second."
[1] http://dailypackage.fedorabook.com/index.php?/archives/150-Productive-Mon...
[2] http://guichaz.free.fr/misc/#iotop
=== gimp-resynthesizer - Texture synthesis for the Gimp ===
''Artsy Tuesdays'' highlight a graphics, video, or sound application.
This Tuesday[1] gimp-resynthesizer[2] was featured:
"Gimp-resynthesizer is a texture synthesis plugin for the Gimp. It can
be used to create additional quantities of a texture, make a tileable
texture, or remove objects from an image."
[1] http://dailypackage.fedorabook.com/index.php?/archives/153-Artsy-Tuesday-...
[2] http://logarithmic.net/pfh/resynthesizer
=== Wednesday Why: Grub Boot Configuration ===
The ''Wednesday Why'' article[1] was on grub bootloader configuration:
"Fedora, like most current Linux distributions, uses Grub as its
bootloader on 32- and 64-bit x86 systems. Grub's configuration file,
/boot/grub/grub.conf, typically looks something like this... "
[1] http://dailypackage.fedorabook.com/index.php?/archives/154-Wednesday-Why-...
=== ManEdit - manpage editor ===
''GUI Thursdays'' highlight a software that provides, enhances, or
effectively uses a GUI interface. This Thursday[1], ManEdit[2] was
discussed:
"For many years Unix and Linux systems have offered convenient online
documentation in the form of manpages. These documents provide short,
concise information about commands, applications, file formats, APIs,
and interfaces. They use a simple markup and can be easily processed
for display in a terminal or online help application, converted to
PDF, printed using PostScript, or posted to the web as an HTML page.
ManEdit is a graphical editor intended to simplify the task of
creating and maintaining manpages."
[1] http://dailypackage.fedorabook.com/index.php?/archives/149-GUI-Thursday-M...
[2] http://wolfpack.twu.net/ManEdit/
=== Super Tux Kart - Go-cart racing game ===
''Friday Fun'' highlights fun, interesting, and amusing programs. This
Friday[1] covered Super Tux Kart[2]:
"Super Tux Kart is a simple but fun go-kart racing game (similar to
some that you may have played on an older-generation game console)."
[1] http://dailypackage.fedorabook.com/index.php?/archives/155-Friday-Fun-Sup...
[2] http://supertuxkart.sourceforge.net/
[[Anchor(Marketing)]]
== Marketing ==
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
=== IcedTea interview ===
JonathanRoberts reports in fedora-marketing-list[1],
"The IcedTea interview is now up. ThomasFitzsimmons didn't have a
picture handy that
we could use so that bit's been left out."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00...
[[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
=== RFC: Package Review VCS ===
A request[1] from WarrenTogami for comments and suggestions on his
initiative to provide a VCS[2] to help manage the review queue
problem[3][4] seemed to garner mostly negative reaction. Warren's
proposal was to create a new CVS area, which parallels the
functionality of the existing /cvs/pkgs, in order to facilitate quick
test builds of non-packagers submissions. Warren listed the advantages
as faster and easier collaboration allowing input from both packagers
and non-packagers. This would in effect create "Level 0 Packagers"
who can obtain reviewer feedback, learn the ropes of the arcane CVS
procedures and contribute to packaging.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01683....
[2] http://en.wikipedia.org/wiki/Version_control_system
[3] FWN#110 "As Review Request Queue Lengthens Tempers Shorten"
http://fedoraproject.org/wiki/FWN/Issue110#head-8efe1733d34143a793ace16ad...
[4] FWN#109 "When Will CVS Be Replaced By A Modern SCM?"
http://fedoraproject.org/wiki/FWN/Issue109#head-e11f507ce98aaa21bf98ff712...
An initial concern raised[5] by TomCallaway concerned the submission
of material of dubious legality, but after Warren outlined[6] a
procedure for the prompt removal Tom seemed[7] satisfied and was going
to query "legal" about the issue.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01687....
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01690....
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01691....
The other main objections came from JoshBoyer and JesseKeating and
seemed to largely question the utility and purpose. Jesse seemed[8]
to have misunderstood that the primary thrust was to enable newcomers
to contribute (although existing packagers also have a significant
role to play in interacting with them).
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01772....
JoshBoyer was skeptical[9] about using CVS but thought keeping track
of changes in the specfile of the package during review had to be done
anyway. Warren acknowledged CVS's suckitude compared to e.g. "Bazaar"
but thought the exposure of new contributors to the existing CVS
workflow was important. Warren also argued[10] that keeping a history
during pre-review would be useful to enable collaboration at a
centralized, single point. Josh returned[11] to the argument that
there was no reason to introduce this new process because the existing
review procedure was useful in determining the responsiveness and
adaptability of packagers. He also argued that using CVS meant that
the history would have to be manually copied by the packager from the
proposed /cvs/pkgreview to the existing /cvs/pkgs repositories,
introducing extra work for little benefit. Warren disputed[12] that it
as that much more work and there the discussion seemed to rest.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01701....
[10] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01705....
[11] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01739....
[12] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01771....
=== Review Queue Cont. ===
Our last report[1] on the angst over the review process was filed
before the American Thanksgiving Break and our generous editor granted
a week off for the holiday. We now return to our regular programming
and finish up reporting on the discussion, which seems like an
important one.
[1] FWN#110 "As Review Request Queue Lengthens Tempers Shorten"
http://fedoraproject.org/wiki/FWN/Issue110#head-8efe1733d34143a793ace16ad...
NicolasMailhot raised[2] the point that it was irritating to spend
time following the guidelines and procedures and end up sidelined by
an executive decision being made apparently outside of that process.
The specific instance being raised by Nicolas involved[3] the addition
of an "OR" conditional operator and the "do nothing and return 0" BASH
builtin ":" to the parts of Nicolas' RPM scriptlets which attempt to
use fc-cache for packages which install fonts. This converted them
from failing with various error codes, to returning a zero. Nicolas
advanced some cogent reasons as to why his method was preferable,
especially that silently accepting the transaction meant that
fontconfig users would be misled into thinking that fontconfig was in
error as opposed to the font package. He added the information that
now only the affected package would fail.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01394....
[3] http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev...
An acknowledgment of Nicolas' position was posted[4] by TomCallaway
(who had made the changes to which Nicolas referred), but he added
that it was policy that "%post" should never fail for some time now
and he had been correcting an oversight. Tom asked Nicolas not to
take it personally and advanced the opinion that Nicolas' font
guidelines were rather good. MatthiasClasen thought that "sweeping the
failure under the carpet" instead of writing correct scriptlets was
incorrect and although Tom pointed out this was too much work for the
FPC argued[5] that maybe RPM should ignore the exit code of scriptlets
if scriptlets were "never, ever [allowed to] fail."
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01398....
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01421....
ThorstenLeemhuis flagged the absence of entities responsible for
realizing adjustments to package guidelines in the actual packages and
used[6] the specific example under discussion to show how a simple
script could make these changes. He noted that he could have all
affected packages brought into line with the changed guidelines in
thirty minutes, but that "[...] nobody does that, as modifying
packages that are owned by other people is frowned upon in Fedora
land." Strong agreement was expressed[7] by ColinWalters that this
sort of automation should be pursued to cohere with a broader goal of
"[...] a model based on peer review, collective ownership and
automation, not personal fiefdoms and manual integer increments in
text files." JesseKeating expressed his happiness with Thorsten's
proposed automated changes as long as the Fonts SIG had no objections.
NicolasMailhot responded[8] that while spoke as only one member of
the Fonts SIG he would insist that the author of the change defend the
proposal through the established channels of the SIG list. He
expressed a personal opinion that this was a fix in search of a
problem and seemed to think that this was a gratuitous change
motivated by the desire to make a point: "I don't mind people touching
my packages, but only if there are actual problems to fix." Nicolas
appeared to characterize making this type of change as "[being] a
bastard" (applying the epithet to himself, but also by extension
anyone else making such a change.)
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01445....
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01465....
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01571....
A summary from JesseKeating asked Thorsten whether he was trying to
fix a real problem or just trying to ensure guidelines were
implemented. Thorsten's response indicated[9] that he "[did not] much
care about [this particular font issue]" and was more concerned with
the general problem of changes in Packaging Guidelines not being
implemented efficiently merely because of the "nobody else is allowed
to touch [my package]" mantra. He asked FESCo to provide advice for
the specific example under discussion as well as more general advice.
PatriceDumas (who had earlier made clear[10] his agreement with
Nicolas that the FontSIG procedures should have been followed) agreed
with Thorsten that FESCo should take a lead and drew attention[11] to
package maintainer policies which imply that such changes are already
allowed in CVS. ''Doxygen'' was cited as an example of another
potential beneficiary from such automated updates unfettered by
consulting with each package maintainer. Thorsten thought[12] that
Firefox was a better example and emphasized again the need for FESCo
to take the lead especially because of ACLs which might prevent
automated changes to CVS. RalfCorsepius agreed[13] strongly with this
and added the splitting of PERL packages as another example
(TomCallaway responded to this latter example with the information
that he had fixed most of these weeks ago.)
[9] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01582....
[10] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01397....
[11] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01587....
[12] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01625....
[13] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01632....
The central problem of nobody actually doing the work of writing the
script which Thorsten proposed would "rebuild all packages that depend
on [Firefox] once it's built and in the buildroot" was
foregrounded[14] by JesseKeating. Jesse also commented that effort was
going into creating a situation where this "one-off won't be
necessary." RichiPlana disagreed[15] that it was a one-off or that
avoiding such situations was always desired. He suggested that it was
important for FESCo to take the managerial role which showed that
creating such a script was sanctioned and approved and that time
invested in it would not be wasted. Thorsten thought Jesse's sort of
response was a little de-motivating and scared people away. He
suggested[16] more positive alternatives and then donned the guise of
Knurd The Package Monkey to whip up an example script, which he argued
wasn't really that much of an effort.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01633....
[15] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01651....
[16] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01655....
Jesse, while acknowleging the potential usefulness of the script,
argued[17] that time would be better spent in transitioning to
xulrunner support (see FWN#110 "Gecko-libs Now Provided By
Xulrunner-devel"[18]), explained he had insufficient time to do
anything expect provided feedback in the Gecko-stack problem space.
Jesse suggested that a body be created to ensure the co-ordination of
updates from building, through to pushing out to repositories at the
same time. Thorsten disagreed[19] about the "one-off" nature, pointing
out that the twelve month lifetime of Fedora 8 probably justified at
least one or two months of work. He also volunteered to try integrate
the necessary changes with Bodhi, building on LukeMacken's work as
suggested by Jesse.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01659....
[18] http://fedoraproject.org/wiki/FWN/Issue110#head-f3cc877838b36ec87d5a37b92...
[19] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01720....
In a small side-thread, a query from Thorsten about specific
versioning in the path of the ''xulrunner'' package removing its
potential to solve the Firefox problem was answered[20] by
ChristopherAillon who explained that this rawhide version was in
pre-release with a non-fixed ABI and was subject to a great deal of
change.
[20] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01745....
=== Core Fonts Issues ===
An apparently slowly smoldering dispute over the treatment of older
"core fonts" flamed up in a couple a of places. This is linked in to
the larger dispute over the review queue and governance issues raised
within (see this same FWN#111 "Review Queue Cont.")
Nicolas forwarded[1] an email from @fedora-fonts from HansdeGoede
which was about the failure of post-install scriptlets to run for core
fonts rpms. Hans wondered why the files were generated this way
instead of being pre-generated and shipped in the package. Nicolas
noted that the packages which Hans was talking about followed the
provisional fontconfig guidelines and that he himself did not care
about the core font side of things. Due to the split nature of the
discussion over the two lists, it is a bit confusing trying to follow
the flow of the conversation, but it seems that BehdadEsfahbod
provided the information that fontconfig had not stored cache files in
/usr/share/fonts for some time, using /var/cache/fontconfig instead.
Behdad also wondered where Hans thought the files should be generated,
to which Hans replied[2] that this should be done at buildtime instead
of generating them with scriplets. Hans demonstrated[3] that
''urw-fonts'' and ''ghostscript-fonts'' had a problem because they did
not generate the ''fonts.dir'' and ''fonts.scale'' expected by older
applications such as ''xfig''. Hans suggested that some guidelines on
handling the core fonts were necessary and suggested two options, his
preferred one being to generate fonts.dir and fonts.scale at
buildtime.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01472....
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01486....
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01727....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01732....
Then NicolasMailhot explained[5] that the obsolete core fonts would
have to be maintained by those actually using them. He further
detailed[6] problems caused by shipping the fonts.dir and fonts.scale
files and suggested splitting the core fonts scriptlets into a
subpackage, or shipping pre-generated files would prevent a negative
impact on the majority of users, who do not use core fonts. Hans
agreed and suggested[7] the two main options of using pre-generated
files or conditionally running mkfontdir.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01730....
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01735....
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01741....
A restatement of the problem was posted[8] by Nicolas approximately a
week later in which he requested interested parties to take up the
burden of maintaining these fonts. While offering support for anyone
who was willing to take on the maintenance burden Nicolas made it
clear that he would not be responding to "strident" calls due to the
"level of abuse we've seen from core font users lately." He explained
that "dreaded can not find font 'fixed'" error message was one of the
problems done away with for ever by removing ''xfs'' from Fedora 8.
HansdeGoede apologized for any abuse but stated that those initiating
change had the onus to fix any breakage.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02502....
[9] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02507....
=== Fedora 8 Boot-up Speed ===
Although using hardware which should be adequate DimiPaun found[1]
that the total time taken to boot was excessive, taking over two
minutes. AdamJackson(ajax) agreed[2] and asked whether Dimi had
investigated the problem using ''bootchart''.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02557....
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02558....
Helpful suggestions to improve the situation followed: GaryThomas
recommended[3] trying with the latest kernel; EricSandeen reminded[4]
that Fedora 8 was not using ''readahead'' by default which might
improve the situation.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02559....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02560....
RudolfKastl drew attention[5] to his own work on ''initng'' which may
make it possible to get from start of init to GDM with NetworkManager
in fifteen seconds. Currently there are some complications with
SELinux.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02571....
KulbirSaini suggested[6] disabling unused services and delaying the
initialization of network services until after login. As a comparison
he posted that it took 50 seconds from GRUB to login on possibly(?)
inferior hardware.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02562....
MarkG85 posted[7] his bootchart, which appeared[8] to show a strange 7
second delay. BillNottingham responded[9] that this was possibly due
to either a problem with bootchart or an incorrectly initialized
driver in the initrd causing hotplug issues. For the remainder the
starting of X seemed to be where most of the problems were and this
was being actively addressed. AdamJackson added[10] to this that he
had taken care of the low-hanging fruit in this regard and the results
could be found in rawhide.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02567....
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02566....
[9] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02588....
[10] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02592....
DimiPaun was not convinced[11] by the bootchart-error hypothesis and
posted his own bootchart. JesseBarnes confirmed[12] this and echoed
BillNottingham's idea that it was due to hotplug events and suggested
contrasting with a non-initrd configuration. DavidZeuthen added[13]
the speculation that this was due to "some really ugly tricks to make
sure that the kernel names (e.g. sda, sdb etc.) for the devices are in
a specific order (scsi_wait_scan.ko etc.). Seems literally like a
waste of time; better fix the rest of the OS not to rely on things
like kernel names."
[11] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00002....
[12] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00003....
[13] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00004....
A follow-up post by MarkG85 contrasted[14] an init-ng bootchart with
the regular initrd one. There seemed to be the same initial delay,
but then a halving of the remainder of the time. MarkG85 requested
information on how to examine the scripts in initrd but then quickly
shared[15] an appropriate link and a new bootchart with reduced boot
time. He concluded[16] sadly that there was not much that could be
done to speed up the current initrd set-up.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00010....
[15] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00015....
[16] https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00032....
=== WTF? Inaccessible Bug Reports? ===
A non-authorized OlivierGalibert asked[1] why he was not authorized to
view the bugzilla entry which detailed why DavidCantrell had disabled
static IP when using kickstart.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01767....
As could be expected passions were high, but DanielBerrange
explained[2] that some bugs were embargoed for security reasons or
because they contained customer data which was sensitive. He advised a
polite request instead of a rant.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01779....
Later the thread diverged into a discussion[3] of large deployments of
Fedora in various environments and of the gradual drift of Fedora away
from a sparse "UNIX" background into a more Windows-like system[4].
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01989....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01911....
ChrisLumens answered[5] that no one was trying to make Olivier's life
"hell" and provided both details of why the change had been made and
how Olivier could determine what changes had been made and why (by git
sha1sums and bug numbers in the logs).
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01784....
=== Alpha/Beta Software In Fedora 8: Bind ===
ChuckAnderson queried[1] whether the inclusion of an alpha release of
bind (9.5.0a7) was acceptable as it was alpha/unstable software in a
stable release. A very long thread ensued. Chuck's specific problem
manifested[2] itself as a segfault. General reactions were split
between those who thought that software which was alpha should not be
included in a stable release tree and those who thought that relying
upon arbitrary labels such as "alpha" was pointless and that the
decision was up to the package maintainer.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02222....
[2] https://bugzilla.redhat.com/show_bug.cgi?id=400461
The maintainer, AdamTkac, responded[3] promptly with the explanation
that he had included this version of BIND because it had nice new
features. He added that some bugs were possibly the price to pay and
that additionally he did not believe that users installed the latest
Fedora on important servers. ToshioKuratomi, while he expressed
support for Adam's decision as maintainer to include software with new
features, stressed[4] that the latter part of his response was not a
valid reason. Adam agreed[5] that Fedora was not a testing ground for
RHEL. Dexter disagreed[6] on this point, citing an email from
MaxSpevack as evidence. JesseKeating[7] and JeremyKatz[8] interpreted
that email differently, arguing that "enterprise oriented" should be
seen in terms of what support is being added, rather than the
distribution being more stable. Jeremy cited his work on LiveCD ISO
installs as support being added for community-driven needs versus his
work on iSCSI install-time support being enterprise-driven.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02274....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02308....
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02341....
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02431....
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02438....
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02459....
MarkG85 argued[9] that because Fedora is used on servers there ought
to be core server components which are treated in a conservative
manner, as opposed to desktop-related applications which can be more
fluid. JefSpaleta[10] suggested that in addition to the desktop/server
axis it would be useful to add the dimension of maintainer-capability.
He added that more explicit signalling by maintainers of pre-release
(e.g. alpha) software might be useful so that concerned admins could
direct their testing efforts towards components essential for their
systems. AdamTkac pointed[11] out (as in several other places in the
thread) that this version had been in rawhide for over five months
without a single issue either being reported in bugzilla or
manifesting itself during his own testing. He suggested that a knee
jerk reaction to the alpha status might be occurring. TomasMraz was
sympathetic[12] to this observation as was AndrewFarris[13], citing
Evolution's non-alpha, yet buggy-as-hell track record.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02354....
[10] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02356....
[11] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02383....
[12] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02388....
[13] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02574....
Less impressed[14] was BillNottingham, who wondered what exactly were
the essential new features which justified an "*alpha*" version being
"pushed" onto users. MartinStransky supported[15] Adam's decision and
argued that the alpha/beta versions of bind were often more stable
than other projects' stable releases. When Bill replied that in effect
a maintainer shipping an alpha was claiming to know better than the
upstream project how stable the code was he met[16] with the
information that ISC (BIND's upstream) were very conservative due to
support issues for paying customers. Further, MartinStransky
argued[17] that the maintainer should be able to make "exactly" this
sort of decision instead of "blindly repeating what upstream
officially says."
[14] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02363....
[15] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02391....
[16] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02420....
[17] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02461....
ChuckAnderson's direct question about whether there were policies
regarding these situations was somewhat answered when JasonTibbitts
pointed[18] to a MaintainerResponsibilityPolicy which seemed to avoid
needless bureaucracy. TomCallaway agreed[19] that this seemed like the
appropriate approach of trusting the maintainer and could not be made
much more specific. JesseKeating suggested[20] an addition which
attempted to address the alpha/beta issue by drawing maintainers
attention to important considerations and yet reposing trust and power
in their hands.
[18] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02371....
[19] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02395....
[20] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02396....
SteveGrubb wondered about "unreleased snapshots" and cited[21]
''kdepim'' as a problem, he augmented[22] this with the information
that it had caused serious data loss and disruption to his work.
JesseKeating replied[23] that similar problems could happen with
"stable" releases and that maintainers and users had to catch problems
in ''updates-testing''.
[21] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02397....
[22] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02427....
[23] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02437....
=== TV Support In Fedora 9 ===
A desire for improved support of various TV tuner cards in Fedora 9
was expressed[1] by OttoRey. He noted that although he was technically
competent he failed to get hardware working with Fedora 8 and MythTV.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01970....
ArthurPemberton recommended[2] that installing a Hauppage card was the
easiest course, while KingInuYasha suggested[3] that any card with a
Theater200 chip might be supportable as ''elisa''[4] could obtain
MPEG2 codecs through ''gstreamer''. IgnacioVazquezAbrams thought[5]
that elisa was not ready for prime time and also cautioned[6] that not
all Hauppage cards were well supported.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01978....
[3] ttps://www.redhat.com/archives/fedora-devel-list/2007-November/msg01983.html
[4] http://elisa.fluendo.com/
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01997....
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01996....
The outlines of the general problem were provided[7] by BastienNocera,
who mentioned kernel-drivers, firmware and codecs for MPEG2 and MPEG4
as the main problems. VilleSkyttä mentioned that the last problem
might be solved because many cards had hardware decoders, and upon
request supplied[8] probable cards (Hauppage or Technotrend
"Full-featured" or "Premium") as did KingInuYahsi[9] (ATI Theater
200).
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02010....
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02053....
[9] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02036....
=== Heads Up! Rpm Default Queryformat To Include Arch ===
A potentially far-reaching change was announced[1] by PanuMatilainen.
This is the inclusion of package architecture in the default
queryformat. He asked for anyone that might be affected to "please
holler NOW!" and noted that fixing affected scripts could be done
trivially by using the explicit {{{ --qf
"%{name}-%{version}-%{release}"}}}
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01886....
CallumLerwick jokingly wondered why the default, which will be {{{rpm
-q --qf "%{name}-%{version}-%{release}.%{arch}\n"}}} would not also
include the epoch of the package, e.g.
{{{%{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch}}}} and
was answered[2] by "nodata" that this would encourage the usage of
epochs. Panu thought this was unlikely but pointed[3] out that, while
there were advantages in making epochs more explicitly visible, it
would mean having to add epochs into filenames. He added[4] that
upstream rpm.org was doing this.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02024....
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02064....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02234....
There was a lot more discussion about whether it was desirable to
display epoch numbers unconditionally with a default of "0" for
non-existent epochs. SethVidal was against the idea and pointed[5] to
Yum's handling of the situation. RalfCorsepius, MichaelSchwendt and
TomCallaway were also strongly against[6] the idea.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02142....
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02262....
Panu sought[7] reasons as to why it was bad and received[8] a compound
answer from TomCallaway that argued that both the use of the ":"
character as a separator and the use of epochs themselves were
hackish. Similar arguments were made by BillNottingham and
MichaelSchwendt.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02266....
[8] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02270....
=== Metacity Dependency Forced During Fedora 7 To 8 Upgrade ===
PeterLemenkov light-heartedly characterized[1] the installation of
"metacity" during his upgrade from F7 to F8 as the imposition of
someone's "evil will" as he had no need for either metacity or
nodoka-metacity-theme on his ''fvwm'' box. He wanted to know why he
could not remove metacity completely as in Fedora 7.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02092....
A brief investigation conducted[2] by MartinSourada tracked the
problem down to dependencies in ''system-config-display'' and
''firstboot''. But Peter showed[3] that the problem was perhaps a bit
more extensive, posting a long list of packages that were slated for
removal when he executed {{{yum remove metacity}}}. After
LubomirKundrak requested more information by upping the debug level
for yum {{{yum -d5 remove metacity}}} Peter posted[4] a link to the
log from this command.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02093....
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02097....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02099....
AdamJackson explained[5] why system-config-display need a window
manager and wondered if the alternatives of depending on gnome-wm or
requiring miniwm from anaconda were preferable. Upon prompting from
JeremyKatz it looked[6] as though Adam was willing to adjust s-c-m if
Jeremy were willing to subpackage miniwm and fix firstboot.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02153....
[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02159....
=== NetworkManager To Get UMTS/GPRS Support ===
An announcement[1] from RudolfKastl that a new wiki page had been
created to document the addition of UMTS support[2] to NetworkManager
prompted DanWilliams to comment[3] that work by TambetIngo adding
basic GSM/UMTS serial and cellular support was just about to land in
the subversion repository. Some interesting discussion followed
including an offer[4] of informational help from RandyWyatts.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02088....
[2] http://en.wikipedia.org/wiki/UMTS-TDD
[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02163....
[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02241....
[[Anchor(AdvisoryBoard)]]
== Advisory Board ==
In this section, we cover discussion in Fedora Advisory Board.
https://www.redhat.com/mailman/listinfo/fedora-advisory-board
Contributing Writer: MichaelLarabel
=== Fedora Board Elections ===
It's that time again for Fedora Board Elections. As MaxSpevack pointed
out in his message[1], there is one community seat open and the
elections run until December 6. More information is available on the
Fedora Elections Wiki[2].
[1] https://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00...
[2] http://fedoraproject.org/wiki/Board/Elections
[[Anchor(Fonts)]]
== Fonts ==
In this section, we cover discussion in Fedora Fonts.
https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Contributing Writer: MichaelLarabel
=== Core Font Packaging Guideline Writer Wanted ===
With the focus turning from core fonts to client-side fonts over the
past few years, in Fedora 8 the state of core fonts isn't so pleasant.
The core font change for Fedora 8 wasn't integrated properly and some
packages were left in a broken state. To fix for Fedora 9 and future
occasions, NicolasMailhot has called out to interested writers that
they join the font SIG (Special Interest Group), write the core font
packaging guidelines, discuss these guidelines, and audit existing
packages to ensure that they meet these new requirements.[1]
[1] https://www.redhat.com/archives/fedora-fonts-list/2007-November/msg00084....
[[Anchor(Documentation)]]
== Documentation ==
In this section, we cover the Fedora Documentation Project.
http://fedoraproject.org/wiki/DocsProject
Contributing Writer: JohnBabich
=== Works in Progress ===
BartCouvreur noted that the draft version of the Fedora Administration
Guide [1] is progressing nicely [2]. It is hoped that it will be ready
for publishing as an immutable document in
http://docs.fedoraproject.org in the near future. Future edits can
then continue on the wiki as usual.
The Fedora Desktop User Guide [3] has also come back to life, thanks
to some recent volunteers. We still need people to contribute more
content in the KDE and Xfce sections.
[1] http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide
[2] http://www.redhat.com/archives/fedora-docs-list/2007-November/msg00101.html
[3] http://fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide
=== Apache FOP in Rawhide ===
KarstenWade passed on the welcome news that FOP is now in the Rawhide
repository and available for testing [4]. Apache FOP (Formatting
Objects Processor) is potentially useful to the Docs Project as a tool
for producing PDF files from Doc``Book XML sources.
In the past, FOP contained encumbered code, making it unsuitable for
inclusion in a completely free tool chain, since one of the goals of
the Docs Project is to use only FOSS tools to produce FOSS
documentation. Apparently, the Rawhide version of FOP is now capable
of running using Iced``Tea. "The IcedTea project provides a harness to
build the source code from the OpenJDK project using Free Software
build tools and provides replacements for the binary plugs with code
from the GNU Classpath project." [5]
[4] http://www.redhat.com/archives/fedora-docs-list/2007-November/msg00186.html
[5] http://fedoraproject.org/wiki/Features/IcedTea
[[Anchor(Translation)]]
== Translation ==
This section, we cover the news surrounding the Fedora Translation
(L10n) Project.
http://fedoraproject.org/wiki/L10N
Contributing Writer: JasonMatthewTaylor
=== Translation Quick Start Guide ===
For those interested in helping out with the translation of the
various documents the Fedora Project has, there is an updated quick
start guide[1] that NorikoMizumoto among others have poured quite a
bit of effort into. If you use the guide and find some things you
think could be improved, let them know!
[1] http://docs.fedoraproject.org/translation-quick-start-guide/en_US/
[[Anchor(Infrastructure)]]
== Infrastructure ==
In this section, we cover the Fedora Infrastructure Project.
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: JasonMatthewTaylor
=== Project SSL Usage ===
ToshioKuratomi mentioned this week[1] some observations regarding the
Fedora Projects usage of SSL in its' web applications. He noted that
the Koji[2] build system, after setting a session cookie via SSL did
not require the cookie to be sent back to the server via SSL and that
the Turbo Gears[3] URL could be changed to a non-SSL URL thus creating
a security hole. He followed up with this post[4] which indeicated
that the above mentioned holes were fixed.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-November/...
[2] https://hosted.fedoraproject.org/projects/koji/
[3] http://turbogears.org/
[4] https://www.redhat.com/archives/fedora-infrastructure-list/2007-November/...
[[Anchor(SecurityWeek)]]
== Security Week ==
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
=== Firefox 2.0.0.10 ===
Firefox 2.0.0.10 was released last week. This of course means that
everyone should be upgraded to the latest and greatest version by now.
It's always extremely important to keep the web browser up to date
given it processes an amazing amount of untrusted content.
On the note of Firefox, I ran across this rather interesting study
regarding Mozilla security flaws:
http://www.st.cs.uni-sb.de/softevo/vulnerabilities.php
I'm tempted to attempt such an analysis over the Fedora codebase to
see how things fare.
=== Insecurity Blues ===
Jeremy Allison has writeup regarding his thoughts on the recent Samba
security issues.
http://www.tuxdeluxe.org/node/273
His words really do apply to most open source projects today.
Security in the open source world does indeed tend to be a well
orchestrated mess :)
[[Anchor(AdvisoriesUpdates)]]
== Advisories and Updates ==
In this section, we cover Security Advisories and Package Updates from
fedora-package-announce.
https://www.redhat.com/mailman/listinfo/fedora-package-announce
Contributing Writer: ThomasChung
=== Fedora 8 Security Advisories ===
* blam-1.8.3-11.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* liferea-1.4.8-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* htdig-3.2.0b6-13.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* galeon-2.0.3-16.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* ruby-gnome2-0.16.0-17.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* epiphany-extensions-2.20.1-4.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* blam-1.8.3-12.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* devhelp-0.16.1-4.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* firefox-2.0.0.10-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* openvrml-0.16.7-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* gnome-python2-extras-2.19.1-11.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* gtkmozembedmm-1.4.2.cvs20060817-17.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* yelp-2.20.0-6.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* kazehakase-0.5.0-1.fc8.2 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* chmsee-1.0.0-1.27.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* gnome-web-photo-0.3-7.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* epiphany-2.20.1-6.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* Miro-1.0-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* liferea-1.4.8-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
=== Fedora 7 Security Advisories ===
* blam-1.8.3-9.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* liferea-1.4.8-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* htdig-3.2.0b6-12.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* galeon-2.0.3-14.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* devhelp-0.13-12.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* openvrml-0.16.7-2.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* chmsee-1.0.0-1.27.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* firefox-2.0.0.10-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* liferea-1.4.8-2.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* gnome-python2-extras-2.14.3-7.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* ruby-gnome2-0.16.0-17.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* kazehakase-0.5.0-1.fc7.2 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* epiphany-extensions-2.18.3-6 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* Miro-1.0-2.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* blam-1.8.3-10.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* epiphany-2.18.3-5.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* yelp-2.18.1-8.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
* gtkmozembedmm-1.4.2.cvs20060817-14.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-November/msg...
[[Anchor(EventsMeetings)]]
== Events and Meetings ==
In this section, we cover event reports and meeting summaries from
various projects.
Contributing Writer: ThomasChung
=== Fedora Board Meeting Minutes 2007-11-27 ===
* http://fedoraproject.org/wiki/Board/Meetings/2007-11-27
=== Fedora Ambassadors Meeting 2007-MM-DD ===
* No Report
=== Fedora Documentation Steering Committee (Log) 2007-MM-DD ===
* No Report
=== Fedora Engineering Steering Committee Meeting 2007-MM-DD ===
* No Report
=== Fedora Infrastructure Meeting (Log) 2007-11-29 ===
* https://www.redhat.com/archives/fedora-infrastructure-list/2007-November/...
=== Fedora Localization Meeting 2007-11-29 ===
* http://fedoraproject.org/wiki/I18N/Meetings/2007-11-29
=== Fedora Marketing Meeting 2007-MM-DD ===
* No Report
=== Fedora Packaging Committee Meeting 2007-MM-DD ===
* No Report
=== Fedora Quality Assurance Meeting 2007-11-28 ===
* http://fedoraproject.org/wiki/QA/Meetings/20071128
=== Fedora Release Engineering Meeting 2007-MM-DD ===
* No Report
=== Fedora SIG EPEL Meeting Week ?? ===
* No Report
=== Fedora SIG KDE Meeting Week 48 ===
* https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02333....
=== Fedora SIG Store Meeting 2007-MM-DD ===
* No Report
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
16 years, 5 months
- 1
- 0
Next Issue of FWN
by John Babich
Thomas:
Are we back on the regular schedule?
When is the exact deadline in GMT? I missed the last 2 issues by a
few hours. I'm in GMT+3.
Best Regards,
John Babich
Beat Writer, Documentation project
16 years, 5 months
- 4
- 6
-trans and -infra beats
by Jason
The infrastructure and translation beats are ready for editors.
-Jason
16 years, 5 months
- 2
- 1
Development beat ready
by Oisin Feeley
Hi all,
Please find this weeks (FWN#111) development list beat ready for editing
here:
http://fedoraproject.org/wiki/FWN/Beats/Developments
Thanks,
Oisin Feeley
16 years, 5 months
- 2
- 1