|
|
Welcome to Fedora Weekly News Issue 103 for the week of September 24th.
|
|
= Fedora Weekly News Issue 103 =
Welcome to Fedora Weekly News Issue 103 for the week of September
24th. http://fedoraproject.org/wiki/FWN/Issue103
In Announcements, "Cast your vote for the Fedora 8 Codename", "Fedora
Unity releases updated Fedora 7 Re-Spins".
After a month-long break, Fedora Weekly News is now back to our
regular schedule. Thank you for your patience and support.
To join or give us your feedback, please visit
http://fedoraproject.org/wiki/NewsProject/Join.
1. Announcements
1. Cast your vote for the Fedora 8 Codename!
2. Fedora Unity releases updated Fedora 7 Re-Spins
2. Ask Fedora
1. Compiz-Fusion in Fedora 8
2. Nodoka
3. Planet Fedora
1. Ohio Linux Fest
2. The Linux Hardware Database
3. Fedora 8 + Online Desktop
4. Daily Package
5. Marketing
1. Customized spins of Fedora
2. The 7 Most Influential GNU/Linux Distributions
3. Visual: Mirrors vs Users
6. Developments
1. RFC: /var or /srv?
2. YUM To Get Configurable Multilib Behavior In Fedora 9 ?
3. Rapid NetworkManager Development
4. System Entries In /etc/hosts
5. RPMFusion Spin
6. Mock Builds Of Rawhide
7. Updates Busted. Bodhi Fixed.
8. OpenGL Wrapper Preparation for Games Live DVD
9. Kmod (Kernel Module) Packages No Longer Permitted
10. Tickless x86_64 Kernels
11. Graphical Shutdown?
12. util-linux Missing From Build Root
13. Proposed Buildsys-build Group Changes
14. RPM Fusion
15. Root Login And Display Managers In Rawhide
16. Xulrunner
17. PlanetCCRMA Packages For Audio Creation To Be Integrated
18. Possibly Orphaned Lftp Spawns Bug Squad!
19. Disable IPv6 By Default
20. Udev Performance
7. Maintainers
1. End of fedora-maintainers-list
8. Translation
1. FAQ
2. Transifex Update
3. Online Translation
9. Infrastructure
1. DB2 Outage/Upgrade
2. Spins Directory
10. Security Week
1. Is a chroot secure?
2. Is SELinux really too complex?
11. Advisories and Updates
1. Fedora 7 Security Advisories
2. Fedora Core 6 Security Advisories
12. Events and Meetings
1. Fedora Board Meeting Minutes 2007-MM-DD
2. Fedora Ambassadors Meeting 2007-MM-DD
3. Fedora Documentation Steering Committee 2007-MM-DD
4. Fedora Engineering Steering Committee Meeting 2007-MM-DD
5. Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-09-26
6. Fedora Infrastructure Meeting (Log) 2007-09-27
7. Fedora Localization Project Meeting 2007-MM-DD
8. Fedora Packaging Committee Meeting 2007-09-25
9. Fedora Release Engineering Meeting 2007-MM-DD
[[Anchor(Announcements)]]
== Announcements ==
In this section, we cover announcements from various projects.
Contributing Writer: ThomasChung
=== Cast your vote for the Fedora 8 Codename! ===
JesseKeating announces in fedora-announce-list[1],
"We have two options for the Fedora 8 codename, and you get to help
decide which we use! Log in with your Fedora Account name and
password. As long as you belong to at least one group in the Fedora
Account System, you can cast your vote[2]. Voting will end and be
tallied at Oct, 5, 23:59:59 UTC."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-September/msg00003.html
[2] https://admin.fedoraproject.org/voting/vote.cgi
=== Fedora Unity releases updated Fedora 7 Re-Spins ===
BobJensen 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 7. These Re-Spin[2] ISOs are
based on Fedora 7 and all updates released as of September 12th, 2007.
The ISO images are available for i386 and x86_64 architectures via
jigdo starting Friday, September 28th, 2007. We have included CD Image
sets for those in the Fedora community that do not have DVD drives or
burners available."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-September/msg00004.html
[2] http://spins.fedoraunity.org/
[[Anchor(AskFedora)]]
== Ask Fedora ==
In this section, we answer general questions from Fedora community.
Send your questions to [e-mail:askfedora@fedoraproject.org] and Fedora News
Team will bring you answers from the Fedora Developers and
Contributors to selected number of questions every week as part of our
weekly news report. Please indicate if you do not wish your name
and/or email address to be published.
http://fedoraproject.org/wiki/AskFedora
Contributing Writer: RahulSundaram
=== Compiz-Fusion in Fedora 8 ===
Gideon Mayhak asks,
"I'm writing a brief e-mail regarding the state of Compiz-Fusion in
Fedora 8. The current offering is not what I would consider
acceptable. Without the libcompizconfig and ccsm packages,
Compiz-Fusion is not worth mentioning. The current configuration
offering is a joke at best. Can we expect a proper Compiz-Fusion
offering soon, or will Fedora 8 end up touting its
pseudo-Compiz-Fusion when it's released? It's obviously not a deal
breaker, but I don't see why it would be so hard for official package
maintainers to build a couple more packages. I know there are people
on the Fedora Forums who are packaging these things as they learn how
to package, so maybe you could recruit them. I just hope you can ease
my mind with news that they're working on it and we'll see the real
deal soon."
Fedora 8 is currently under active development and the release notes
in the last test release did mention that what was being offered is a
preview. They use glib and gconf instead of the other configuration
mechanisms you have mentioned although both the GNOME and KDE front
ends have been separated to integrate better with the respective
desktop environments. compiz-bcop has been introduced into the
repository recently and libcompizfusion is waiting on review at
https://bugzilla.redhat.com/show_bug.cgi?id=247406.
If you find bugs or want to request enhancements, you can report or
request them in http://bugzilla.redhat.com against the relevant
packages as usual. If there are interested people willing to
participating in maintaining or co-maintaining software in Fedora, you
are most welcome to do so. More information at
http://fedoraproject.org/wiki/PackageMaintainers. We also need people
doing package reviews to ensure the high quality of new packages being
introduced in Fedora. Review guidelines are available
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines. Reviews can
be done by virtually anyone.
=== Nodoka ===
Robert Myers asks,
"Is the new Nodoka theme going to be ported to KDE? If not, why isn't it?"
It can be ported as soon as someone with the interest, time and skills
show up to do it. Martin Sourada answered more questions on Nodoka
including this one in a recent interview available at
http://fedoraproject.org/wiki/Interviews/MartinSourada.
[[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
=== Ohio Linux Fest ===
MaxSpevack reports in his blog[1],
"We had a great day at Ohio Linux Fest. Jeff did a superb job as the
point person for the booth, and it was great to see a bunch of Fedora
folks in attendance. Karlie gave a really interesting talk about how
FOSS developers pay their bills, and apparently her kids had a good
time playing with Seth's OLPC."
[1] http://spevack.livejournal.com/29104.html
[2] http://www.ohiolinux.org/
=== The Linux Hardware Database ===
HaraldHoyer reports in his blog[1],
"Have you ever tried to find out, if a specific computer device (e.g.
laptop, sound card, wireless card) you want to buy, works with Linux?
If yes, you know how distributed all the information is over the net.
Here is the chance to build a solid, updated database[2]. Over the
wekend, I put together a Turbogears web frontend and glued it together
with a MoinMoin Wiki. Curious? Try it out!"
[1] http://www.harald-hoyer.de/fedora/the-linux-hardware-database
[2] http://hwdb.surfsite.org/
=== Fedora 8 + Online Desktop ===
JonathanRoberts reports in his blog[1],
"The third interview in the series of feature previews for F8 has just
gone up on the wiki[2]. This time it's with Colin Walters and he talks
about the work that's gone on to integrate a lot of the Gnome Online
Desktop work, particularly Bigboard. This includes the new GDM session
that is created after installing the online-desktop package - Online
Desktop - where a browser is launched immediately and the top panel is
replaced by Bigboard. As always there is also a cool screencast
showing some of the coolest features."
[1] http://blog.questionsplease.org/2007/09/30/fedora-8-online-desktop/
[2] http://fedoraproject.org/wiki/Interviews/ColinWalters
[[Anchor(DailyPackage)]]
== Daily Package ==
In this section, we recap the packages that have been highlighted as a
Fedora Daily Package [1].
[1] http://dailypackage.fedorabook.com/
Contributing Writer: ChrisTyler
Editor's Note: Sorry, no Daily Package has been posted for this week
since our editor for this beat is busy with teaching the good kids
this semester.
[[Anchor(Marketing)]]
== Marketing ==
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
=== Customized spins of Fedora ===
RahulSundaram reports in fedora-marketing-list[1],
"When Fedora 7 was released, one of the big features that we talked
about was the idea of customized spins of the distribution. Now that
Fedora 8 is on the way, it's useful to look and see how we have done,
and what sort of custom spins have been created.[2]"
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg00192.html
[2] http://www.redhatmagazine.com/2007/09/28/customized-spins-of-fedora/
=== The 7 Most Influential GNU/Linux Distributions ===
RahulSundaram reports in fedora-marketing-list[1],
"Fedora's main reputation is for being the first distro to include new
innovations. For instance, Fedora was the first distribution to
include tools that allowed average users to work with SELinux's
detailed security options. In the same way, Fedora 7 was the first to
include Smolt, a program for collecting hardware information about
users; Revisor, a program for creating custom install disks, and the
Liberation typefaces that provide the metrical equivalents of Arial,
Helvetica, and Times Roman in free fonts. Although some users on
Fedora mailing lists suggest that this innovation makes Fedora
unsuitable for servers and mission-critical operations, an increased
attention to testing is starting to make that generality obsolete.
After a slow couple of years, Fedora is also well on the way to
realizing its goal of creating a thriving community in which Red Hat
is important, but no longer completely dominates decision-making.[2]"
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg00180.html
[2] http://itmanagement.earthweb.com/entdev/article.php/11070_3701421_1
=== Visual: Mirrors vs Users ===
MikeMcGrath reports in fedora-marketing-list[1],
"I wrote a little call[2] to help post today as well as a comparison
of where our users are vs mirrors. This is using a small sampling of
people that have connected to our mirrors site. Not an exact science
but interesting none the less, thought I'd share."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg00173.html
[2] http://mmcgrath.livejournal.com/8797.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
Now that we're back from a break @fedora-devel beat has two sections.
This top one is the most recent and covers events from September 23rd
to September 29th. The material below it covers a selection of events
from earlier activity on the list while we were re-charging our
batteries.
=== RFC: /var or /srv? ===
CaseyDahlin touched off[1] a wide-ranging discussion about backup and
reinstall policies when he suggested that the ''/srv'' directory
should be populated with data currently in ''/var/www'' and
''/var/ftp/pub'' as apparently recommended by the FHS[2].
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01790.html
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
The status quo was summed up[3] by JesseKeating, who noted that the
FedoraPackagingCommittee had decided that the FHS was contradictory
about the uses of /srv and it had thus been decided to leave /srv
blank although some packaged applications were writing there.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01791.html
AlanCox argued[4] that Casey's proposal was a bad one for a
distribution because updates could result in the removal/modification
of files placed there by administrators, which was explicitly
prohibited by the FHS. Alan also was very straightforward in stating
that /srv was a mistake in the FHS specification, that the FHS in the
waning years of its life had created /srv on the basis of a vote
conducted by those "who had no clue about distribution building"[5].
Alan recommended that /srv should be obsoleted and the removal of "the
silly statements about /var (which mostly exist to try and force the
/srv stupidity into being)."
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01806.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01809.html
A response[6] from SethVidal suggested that while Alan had perfectly
good points about not using /srv in the distro it was nevertheless
widely used (either with that name or another) as a top-level
directory to simplify backups. There was substantial agreement on this
point from JesseKeating, and DavidCantrell added[7] that although he
favored leaving the directory and deciding that packages should not
install to it, it was worth considering a limit to the number of
top-level directories.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01821.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01833.html
RobCrittenden wondered[8] what Seth meant by saying that ''/var'' only
contained transient data which did not need backup. Further discussion
between NicolasMailhot and RalfCorsepius about the treatment of spools
in /var led ArthurPemberton to wonder[9] whether they were describing
current practice or what should be done. Scattered throughout the
long (over one hundred messages) thread were numerous examples of data
contained in /var which it wouldn't be nice to lose. These included
mail spools, databases and web server data.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01834.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01853.html
Attempting to draw some sense out of the mass of examples of current
practice and competing intents, RichiPlana enumerated[10] four
concerns which had emerged as considerations in determining a policy
governing the placement of data files.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01870.html
The need to backup efficiently without wasting space and time was
raised[11] by MattMiller after IanBurrell pointed out that ''/var''
contained a mixture of data that absolutely should be backed-up and
other non-important local writable data. LamontPetersen observed[12]
that it seemed to be common practice in medium to large-scale
enterprises to use the '/srv' directory to separate out the important
material. This theme was later re-visited in a slightly acrimonious
exchange between NicolasMailhot,LamontPetersen and KrzysztofHalasa.
Nicolas made the point[13], based on his experience, that for
enterprise purposes the current use of /var for a mixture of
"long-term and transient data, generic and implementation-specific
stuff, local and global data" was a problem. Lamont also provided
some good ballpark figures[14] to expand the point when Krzyzstof
would not accept this portrait of typical enterprise needs. Nicolas
explained[15] the typical strategy employed by large enterprises in a
further excellent post.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01876.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01882.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02290.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02391.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02423.html
JohannGudmundsson's strong opinion in favor of removing ''/srv''
entirely, with the expectation that sysadmins who want it would find
their way to the ''mkdir'' command prompted[16] a satirical reaction
from NicolasMailhot, portraying the possible Fedora config files which
could be supplied were this option chosen.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01850.html
A post from RichiPlana in which he volunteered[17] to modify the spec
files of either MySQL or Mailman to use /srv instead of /var raised
another pair of issues. JohnDennis pointed out[18] that SELinux
policies would have to be changed in tandem with the moving around of
any files contained in packages. John also noted that there are many
applications depending on the current locations and that advanced
notice of such changes were necessary.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02191.html
[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02192.html
A potential way out of this latter difficulty was suggested[19] by
KellyMiller(lightsolphoenix) in the form of "compat" packages which
create symlinks to the old location. AlexanderBostrom was skeptical
that this would be transparent and listed[20] some potential ways in
which it could fail, concluding that the release notes would need to
explain it, whatever was decided. CaseyDahlin agreed[21] with
Alexander that it might be necessary to create a "structure" within
/srv/lib, which to some extent mirrored the structuring within /var.
He sketched an interesting perspective of /var, which was that it
contained information which should be in RAM except for the reasons of
size or the need to persist across reboots.
[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02274.html
[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02278.html
[21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02284.html
The former difficulty was addressed[22] by SteveGrubb who confirmed
the need for SELinux to be made aware of a mapping between /srv and
/var. This led JesseKeating to tie[23] the two problems, pointing out
that as /srv was by definition a free-for-all there was no way to
prepopulate it without the danger of treading on the toes of the local
sysadmin. MattMiller then wondered whether the SELinux tools could be
modified to allow the local sysadmin to choose a particular policy for
/srv and DanielWalsh responded[24] that it could be done, but would
require changing the hardcoded default locations searched by regexes
in semanage commands.
[22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02197.html
[23] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02198.html
[24] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02221.html
LamontPetersen was sanguine about the potential change and
rebutted[25] Jesse's worries on all points, essentially pointing out
that sticking with the current /var setup had all the problems except
the SELinux one, which he asserted was trivial. SteveGrubb
countered[26] that although it might be possible to assign the correct
SELinux types to directories there would still be per-file problems.
RichiPlana asked why it was that the SELinux policies were not set by
the installation package and this led to an interesting post[27] from
KarlMacMillan, who explained that allowing a package to install a new
type and also to install files that should have that new type was a
chicken-and-egg problem. The post and responses from Jesse[28] and
PanuMatilainen[29](on whether RPM should/could record file contexts in
rpm headers) are probably worth reading.
[25] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02202.html
[26] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02217.html
[27] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02255.html
[28] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02266.html
[29] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02281.html
Finally, there were several[30][31] scattered suggestions throughout
the thread that recognized that the FHS should perhaps be changed and
the best policy was to submit patches upstream with regard to the
specific issue of /srv.
[30] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02234.html
[31] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02237.html
=== YUM To Get Configurable Multilib Behavior In Fedora 9 ? ===
A slightly disturbed SteveGrubb reported[1] that an x86_64 machine
with no i386 packages was unwantedly installing i386 packages for
NetworkManager during a ''yum update'', but that if ''yum update
NetworkManager.x86_64'' or ''yum update NetworkManager'' was used then
only the desired x86_64 packages were installed. Steve wanted to know
if this was a known problem, or if he should file a bugzilla report.
SethVidal asked for more detailed information and Steve supplied it,
noting that the problem seemed to be that if ''dhcdbd'' were deleted
by hand then there was no problem, but that if YUM made the deletion
then the problem was manifested. JesseKeating quickly surmized that
dhcdbd was being obsoleted by both the i386 and x86_64 packages in the
repository and Seth confirmed this and suggested[2] that to avoid this
problem ''/etc/yum.conf'' should have ''exclude=*.?86'' added to it.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01927.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01954.html
Steve still wondered why his ''exactarch=1'' had been ignored and why
''yum update '' was behaving differently to ''yum
update''. Seth replied[3] that obsoletes were allowed to cross
architecture boundaries, which provoked further questions[4] from
MattMiller concerning the handling of obsoletes when there are
potential competitors on either the installed or obsoleting ends.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01961.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01973.html
A suggestion from MichaelWiktowy that ''anaconda'' might add Seth's
fix to ''/etc/yum.conf'' by default along with a concern not to paper
over bugs led Seth to respond[5] that there was no bug as YUM was
doing exactly what it had been written to do. This provoked
DavidWoodhouse to state[6] his concerns with YUM's behavior and to
label it as "buggy". David, MattMiller[7] and VilleSkyttä[8] also
cautioned that Seth's fix did not work for the situation where the
desired state was a 64-bit only system with some small number of
specific exceptions.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01956.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01965.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01957.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01967.html
JesseKeating defended[9] YUM's behavior from David's accusation of
"bugginess", pointing out that it was implementing exactly the
mulitlib strategy which it had been asked to do. VilleSkyttä wanted
to know where the strategy was documented and Jesse did his best to
describe[10] it. David wasn't buying one of the important conditions
of the strategy, namely that "we want both runtime library and
development package availability of the secondary arch installed by
default" and suggested[11] that exactly the opposite was wanted by
users.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01970.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02003.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02009.html
A large part of the problem seemed to hinge around RPM's (as opposed
to YUM's) inability to use architecture specific dependencies (see
also earlier threads[12]). David was keen to disentangle[13] the
problem of the default installation of secondary architecture packages
(which he saw as undesirable) from whether multilib[14] should be
provided.
[12] http://www.redhat.com/archives/rpm-list/2006-August/msg00011.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02029.html
[14] http://www.redhat.com/magazine/009jul05/features/multilib/
JosVos argued[15] that a plurality of strategies should be enabled
through plugins to YUM and Jesse responded[16] that this was exactly
the plan for Fedora 9. A plan for a face-to-face meeting with some of
the principle architects (SethVidal, BillNottingham, Jesse and David)
looked like it was underway[17] for "some time in the future".
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01987.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02014.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02018.html
=== Rapid NetworkManager Development ===
MatthewSalzmann provided[1] a nice, compact report of a
''NetworkManager'' problem manifested since version 0.7. He had
eliminated possible SELinux problems by testing with it set to
permissive and reported that several kernels had shown the problem.
The wireless chipset was an iwl13945 (see FWN#89 "Status Of Support
for IWP3945abg Wireless In Fedora 7"[2]).
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02151.html
[2] http://fedoraproject.org/wiki/FWN/Issue89#head-3e38c7216e9a44e59750ac3ed823234b9d7178df
Matthew's worry that the problem might be due to user-error was
quickly dispelled[3][4][5] by a series of similar, confirmatory
reports. MattMiller posted a bugzilla entry[5] which seemed to
indicate that updating to the latest versions of NM and wpa_supplicant
would fix some issues for some people. Unfortunately although Matthew
was able to report some progress in terms of the menu appearing the
wireless options were grayed out.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02153.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02166.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02168.html
A raft of related, but individual problems were reported in the thread
once Jessekeating suggested updating to the latest versions of
NetworkManager and wpa_supplicant.
TomLondon reported that although scanning was working properly only
hex-keys were being accepted and ZackCerza added[6] that this would be
a problem with his AP which only allowed a passphrase to be set. A
workaround was suggested by DanWilliams (''/usr/sbin/wpa_passphrase
'') which did not impress RalfErtzinger, but
produced results[7] for Tom.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02277.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02327.html
A later kernel seemed to work nearly perfectly for Tom[8] and
DarrellPfeifer (who was using an iwl3945 but not wpa_supplicant).
Matthew reported no success with the latest versions of affected
software (NetworkManager*-0.7.0-0.3.svn2907.fc8,
wpa_supplicant-0.5.7-9.fc8, kernel-2.6.23-0.213.rc8.git2.fc8) and
agreed[10] with Tom that the issue was that if the AP did not
broadcast its SSID then the greyed-out menu items rendered the network
unusable.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02348.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02347.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02358.html
Matthew then listed[11] his current problems, including an inability
to choose the format for entering the passphrase, a tiny non-resizable
icon for the passphrase box, and finally greyed-out/inactive menu
items for "connect to" and "create new". Matthew concluded by asking
for step-by-step instructions to use wpa_supplicant. JesseKeating
addressed[12] Matthew's problems, including the information that the
UI hadn't been written yet for the greyed-out items and while it might
not make Test3 it was hoped to be done by Fedora8 Final.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02375.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02377.html
TomLondon wrote up a nice wpa_supplicant HOWTO which got Matthew
finally connected[13] and JeremyKatz noted that VPNC support[14] and
the tiny password box dialogue[15] would be fixed in the next build.
[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02393.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02402.html
The overall impression was that NetworkManager and associated tools
are going through a lot of needed changes and that flakiness abounded
as did the rapid fixing of bugs. KevinKofler queried[15] the strategy
behind this.
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02194.html
=== System Entries In /etc/hosts ===
HarryHoffman asked[1] when the hostname had stopped being added by
default to ''/etc/hosts''. His concern was that mail sent by
applications via a mail host should have an address from
"root@myhost.com" instead of "root@localhost.com".
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02222.html
DavidCantrell took the bullet[2], suspecting that he had made the
change by mistake while rewriting the guts of anaconda, he noted that
he had fixed this rawhide in and provided a bugzilla link. Almost
immediately SimoSorce begged him to reconsider as Kerberos would break
if the hostname did not reflect the public-facing IP address. David
then suggested[3] that the best course of action was to defer the
change until after Fedora 8 had been released. Harry took David's
recommendation and mused out loud[4] that his particular problem was
best solved by configuring his local MTA to use the FQDN.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02225.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02228.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02229.html
Meanwhile AdamJackson(ajax) reacted[5] to Simo's suggestion that GNOME
needed to be smarter about changing the hostname mapping when the main
network interface got an IP by suggesting that if it were true that
Kerberos/winbindd broke this way then they were buggy.
AlexanderBostrom admitted that he wasn't sure what happened in these
situations (which he had observed) but believed[6] that if a hostname
were mapped to 127.0.0.1 in /etc/hosts then DNS would be over-ridden
and Kerberos duly upset.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02247.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02317.html
A spate of testimonies followed from those who had no Kerberos
problems while the hostname was mapped to 127.0.0.1 in /etc/hosts.
JesseKeating thought[7] that expecting DNS-resolvable hostnames was
dated thinking. LamontPeterson argued[8] that the /etc/hosts file was
merely to enable the box to resolve itself without respect to the
network so that daemons depending on the hostname in their
configurations would not be confused.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02319.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02344.html
SimoSorce responded[9] that this would cause problems for a KDC and
that he agreed with Lamont's interpretation of /etc/hosts as long as
''dhclient'' or the network-config tools could enter the correct
hostname to IP mapping. Lamont thought[10] that the KDC point was
obvious, but that what was being discussed was laptop clients.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02350.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02372.html
=== RPMFusion Spin ===
The need for an RPMFusion spin was expressed[1] by JóhannGuðmundsson.
It was phrased in a confrontational style, wondering whether
"MaxSpevack [would] put his money where [h]is mouth is" and allow the
spin to be hosted on fedoraprojects.org. Simultaneously the post
implicitly admitted knowledge the presence of legal problems and the
need to host any such project outside of the USA. Jóhann expressed an
interest in seeing whether there were more downloads of the spin than
of "Fedora".
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02294.html
HansdeGoede made it clear[2] that this was not a post made on behalf
of the RPMFusion project.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02297.html
The initial response from JesseKeating answered[3] negatively the
suggestion that the spin could include Fedora artwork or the name.
Jesse also addressed the quote from MaxSpevack, pointing out that
remixing Fedora implied a lot more than the uninteresting project of
adding a few patent-encumbered packages and producing a work which was
not free for /everybody/.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02300.html
JoshBoyer answered some later questions, and confirmed[4] that the
hypothetical spin would be allowed to pull from the Fedora Project's
repositories, explained that it would not be possible to host even a
GPL licensed package which implemented a patented technique and
reminded that the "media problem" is not one solvable by the Fedora
Project.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02306.html
Further discussion unearthed[5] the information (from MattDomsch and
NicuBuculei) that the replacement of the artwork would not be
necessary apart from the trademarked logos due to recent work, and
that work has been done to provide non-logoed graphics to facilitate
this sort of derivative.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02310.html
RahulSundaram[6] and BillNottingham[7] also pointed Johann towards the
''generic-logos'' package in rawhide which is intended precisely to
allow easier rebranding by derivative distributions.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02311.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02320.html
Based on the answers received, Johann asked whether the FedoraUnity
respins could be hosted on fedoraproject.org and MikeMcGrath
supplied[8] a link to the current process-in-progress. Johann felt
that these should be given pride of place as they would save users a
lot of downloading of updates. JesseKeating expressed[9] admiration
for the respins but also cautioned that they should not replace the
gold images because they hadn't gone through the same QA. Jesse
further suggested that with a six-month release schedule it was hard
to see where the resources would come from to do such QA.
JeroenvanMeeuwen(kanarip) was skeptical[10] that the spins would be
blessed because of their respin tool being unapproved by
ReleaseEngineering.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02330.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02334.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02337.html
Johann then posted[11] a critique of how it seemed that the hosting of
spins would be handled, advocating a completely unreviewed, hands-off
provision of space for anyone that wanted to do anything. Reaction was
unfavorable and ranged from SethVidal's threat to create a FedoraPr0n
respin[12] to MikeMcGrath's observation[13] that the most interesting
spins would come from countries with different laws and that they
would not be called Fedora.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02351.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02359.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02363.html
Much later in the thread DouglasMcClendon posed[14] a hypothetical
way of evading the intent of the Trademark guidelines (by creating an
initrd) which elicited a long subthread of legal supposition. Rahul
also explained contributory infringement and other problems in
response to a demand[15] for a definitive settling of accounts from
Johann.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02394.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02383.html
=== Mock Builds Of Rawhide ===
MattDomsch posted[1] the results of the Fedora Rawhide-in-Mock x86_64
build with a list of 431 packages failing to build without a bug
filed.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02100.html
TomLane thought[2] that Matt was using a broken compiler based on the
reported failure of the MySQL builds.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02108.html
The results[3] for the Fedora Rawhide-in-Mock i386 builds were similar
with 433 out of 4740 packages failing to build with no bug filed.
BojanSmojver noted[4] the mock problem in resolving the localhost.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02101.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02107.html
A discrepancy between the lists provided and the individual logs for
mod_perl was observed by JoeOrton and Matt explained[5] that since
providing the lists he had re-run the failures overnight, some of
which were now resolved.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02140.html
JesseKeating was curious as to whether Matt's build set included the
latest glibc which should include warnings about potential buffer
overflows in C++ applications due to D_FORTIFY_SOURCE{,=2} being
enabled. The good news[7] was that there were no additional
warnings/failed-builds due to this.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02141.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02216.html
=== Updates Busted. Bodhi Fixed. ===
On Tuesday 25th September ThomasBaker asked[1] whether the Fedora 7
updates had gone down again. LukeMacken explained[2] that memory
issues were being manifested during the composition of the repository
and that he intended to write some sanity checks into Bodhi's masher.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02095.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02109.html
BojanSmojver saw[3] an opportunity (to grab the latest kernel) instead
of a problem.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02117.html
A problem still appeared[4] to exist on Wednesday 26th according to
BrunoWolff as he reported that updates were still missing although
files were present.
=== OpenGL Wrapper Preparation for Games Live DVD ===
HansdeGoede continued his pleasant practice of announcing exciting new
respins by asking[1] maintainers of OpenGL-using games to start using
a wrapper he had created. The wrapper is a bash script which checks
for DRI availability and upon failure pops up an error dialogue with
which it is simple to interact.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02055.html
The point of including OpenGL games, but not propietary drivers on the
DVD was questioned[2] by GérardMilmeister and DebarshiRay(rishi)
happily answered that it would provide a nice means of testing new
computers for available, quality FL/OSS drivers. RichiPlana quipped[3]
that maybe it should be renamed
"3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors"
and JefSpaleta embraced[4] that idea: "that is the WHOLE point. This
is what Fedora IS, as a project it is focused completely and utterly
on the open source software stack. We aren't sugar coating it or
hiding the fact that video driver coverage is a problem, by slipping
users proprietary pills. Video driver coverage IS a problem, its a
problem that needs to be stressed and not covered over in a very
shallow and vain attempt to boost our distribution numbers by sneaking
in addon drivers we don't support as a project."
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02058.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02082.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02084.html
Although it was hoped that the pre-5xx series ATI Radeon cards would
all work perfectly NilsPhillipsen was able to highlight[5] one
non-working example, leaving Intel as the current sole contender
although the situation is expected to change in the near future.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02339.html
JochenSchmitt reported[6] that although he could run ''stellarium''
with the rpm.livna.org supplied ''nvidia'' driver the wrapper
erroneously reported that DRI was disabled. Hans requested some moe
data to fix the problem.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02081.html
=== Kmod (Kernel Module) Packages No Longer Permitted ===
A long-expected and debated announcement of the removal of ''kmods''
from Fedora was posted[1] by TomCallaway.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01949.html
DennisLeroy pointed[2] out that it was ironic that VMware were opening
up their tools just now and that Fedora might be left without them
while Ubuntu and Gentoo worked out of the box. His post included a
link[3] to a bugzilla where Open-VM-tools was discussed extensively.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01968.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=294341
It seemed clear from the comments on the bugzilla review that the
kernel hackers were convinced that significant parts of the code were
never going to be accepted upstream and so would not be carried by
Fedora. Denis wanted to know how open-vm-tools could be incorporated
into Fedora and Jesse suggested[4] that he post to the fedora-kernel
list. DaveJones thought this was pointless and Denis responded[5] that
he knew this.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01971.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02041.html
DavidWoodhouse speculated[6] that due to the massive changes indicated
in the review it was far from likely that FESCo would have voted for
open-vm-tools as a package regardless of the new rules on kmods.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01982.html
=== Tickless x86_64 Kernels ===
After installing PowerTOP[1] AhmedKamal wanted[2] to install a
tickless kernel so that he follow the most promising path to reducing
power usage on his laptop. Ahmed wondered if he needed a patched
version of the kernel to enable hpet timers for his ICH6 chipset.
[1] http://www.linuxpowertop.org/
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01924.html
A response[3] from JoshBoyer wondered where Ahmed had obtained his
kernel (2.6.22.4-45_1.cubbi_suspend2.fc6) and suggested that if he
were running x86_64 then his best bet for a tickless kernel was to
upgrade to Fedora 8. ChristopherBrown confirmed[4] that this was the
case.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01926.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01937.html
All was not well, however, because Ahmed reported[5] that the ''hpet
force-enable'' patch was still needed because the BIOS on his laptop
was disabling ''hpet''. He asked whether Fedora 8 would contain that
patch.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01942.html
The following @fedora-development summaries cover a period stretching
from Aug 21st to September 22nd with an emphasis on more recent
material.
=== Graphical Shutdown? ===
JonathanRoberts wondered[1] if it would be possible to have a less
ugly means of shutting down Fedora 8.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01302.html
The idea was warmly received[2] by AdamJackson(ajax), although he
admitted to not having looked into it yet and thought it might be too
late for Fedora 8. Adam
advanced a rough model in which the X session would be able to stay up
until the computer halted. DavidWoodhouse agreed that X didn't need
to save state and pointed out[3] that probably nothing else needed to
either. He described what seemed like a fairly brutal method of
shutdown ''sync; reboot -f'' or ''SysRq-S-U-B'' as his preferred
speedy method of shutting down.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01367.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01369.html
There was a good deal of agreement that David was right, with the
exception[4] that unmounting filesystems could be a problem.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01406.html
ColinWalters provided[5] a link to the thinking of Ubuntu developers
about the same problem and reminded the list that most of the services
needing special handling on shutdown were server services usually
unused in the desktop scenario.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01401.html
A request for clarification was made by RichiPlana and JesseKeating
answered with a succinct explanation[6] of the problem/opportunity as
being that a system shutdown would kill the PID of running services
without going through the usual service script rigmarole of displaying
information to the console and then killing the PID.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01408.html
A possible problem with Samba, and with recovering databases was
identified[7] by SimoSorce and echoed[8] by ChrisAdams.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01463.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01476.html
=== util-linux Missing From Build Root ===
GérardMilmeister pointed out[1] that in addition to "awk" being absent from the
buildroot, "util-linux" was not there either, and JindrichNovy
found[2] that this meant that /bin/kill was unavailable.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02019.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02021.html
JesseKeating[3] and RichardJones[4] explained that "util-linux" had
become "util-linux-ng" and needed to be explicitly BuildRequire'd.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02025.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02023.html
This prompted MichaelSchwendt to lament the death of the minimal build
environment and JesseKeating to dispute[5] this with the assertion
that the buildroot packages were the same and anything depsolved from
there should never have been relied upon. Michael explained[6] that he
felt that having to BuildRequire packages which should be included in
the buildroot was not a good thing and Jesse pointed[7] out his
previous invitation to discuss the growth of the base packages. He
noted that dependency chains change and that the list of installed packages was
provided. Michael responded[8] that the bureaucratic burden was too
high and wondered why the list had changed.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02036.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02041.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02042.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02049.html
MikeMcGrath corrected[9] this by noting the difference between the
explicit list (which had not been changed and would require FESCo
approval) and the implicit list (of dependencies dragged in in the
past). This angered[10] RichardJones who felt it was rude, hence
offputting to outside developers essential to Fedora's growth.
PatriceDumas smoothed the situation over[11], explaining that
following the guidelines wasn't just arbitrary and unimportant, but
provided a means of making sure the buildroot installation was faster.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02051.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02103.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02110.html
After Jesse accused[12] Michael of "whining" about the situation
instead of coming up with a solution, Michael was moved[13] to suggest
merging the old minimal(explicit) list and the expanded(implicit)
list.
[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02053.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02054.html
Michael wondered[14] how, without a full list, it was possible to
check whether a BuildRequires would be installed implicitly. Ralf
responded[15] that the problem was due to using a list of packages
instead of a list of applications and libraries.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02061.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02084.html
NicolasMailhot and MichaelSchwendt debated this point for some time
with Nicholas advocating[16] Requires and BuildRequires which
explicitly named the absolute pathnames of required tools instead of
packages which contain them. Michael concluded[17] that many single
files would have to be be BuildRequired and that a well-defined base
environment would be easier.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02125.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02161.html
SethVidal wondered[18] whether it would be possible to use yum to
resolve a list of required libraries and applications, but had to
admit that it couldn't be expressed as a comps group.
[18] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02157.html
Michael argued[19] that it would be necessary to use mock, or else
many scratch builds in Koji, to figure out the list of new
BuildRequires.
[19] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02162.html
=== Proposed Buildsys-build Group Changes ===
Following on from the discussion of the minimal buildroot (see this
same FWN#103 "util-linux Missing From BuildRoot"), JesseKeating
requested[1] feedback on a proposal to add some packages to the
Explicit list of packages guaranteed to be in the buildroot. Jesse
noted that he'd also asked SethVidal to provide a yum-based utility
which would show what packages would be installed implicitly by the
minimal build root.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02226.html
Seth wanted to know what the desired output from the tool would be and
Jesse opened[2] the question up for input.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02232.html
PatriceDumas spotted some glaring omissions and Jesse responded[3]
that they were pulled in via rpm-build, but that it was a good idea to
list them. TomasMraz found it a little weird that binutils,
glibc-devel, glibc-headers and kernel-headers would now need an
explicit BuildRequire. PatriceDumas replied[4] that kernel-headers
should never be needed explicitly and that glibc-headers would be
brought in with glibc-devel.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02333.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02262.html
TillMaas thought[5] that the full exception list needed to be revived
as otherwise it would not be possible to make sure BuildRequires were
fully provided for in the spec by rebuilding in mock.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02260.html
=== RPM Fusion ===
HansdeGoede announced[1] that three previously separate RPM
repositories: Dribble, FreshRPMS and Livna had agreed to join their
efforts into one common project. This would provide two repositories:
Free; and non-Free with the latter containing Open Source Software
non-distributable in the USA due to possible patent problems. No
replacements of packages in RHEL/CentOS, EPEL or Fedora will be
carried, only add-ons including kmods.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00750.html
Congratulations, good-wishes and thanks rolled in, with a dominant
theme of sadness that ATrpms was not going to be part of the effort.
JarodWilson expressed[2] the opinion that most conflicts occurred
between ATrpms and Livna. ChristopherBrown reminded[3] him that it was
still an incremental improvement and that one major source of conflict
(nVidia drivers) may soon disappear.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00850.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00852.html
An interesting perspective was provided[4] by CaseyDahlin when he
described the ATrpms repository as more of a "service pack" than a
collection of applications. Casey was at pains to point out that he
wasn't diminishing the service which ATrpms provides. WarrenTogami
agreed and wondered[5] if it might even be described as a fork of the
Fedora distribution. RichiPlana was in agreement on the positive value
provided by ATrpms (availability of packages for MythTV and Asterisk
and the ability to install library versions in parallel easily), but
wondered about the conflict in package namespace with original Fedora
packages.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00833.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00834.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00848.html
ChristopherStone posted a link to an announcement[7] from Thorsten which seemed
likely to squash this hope though.
[7] http://lists.fedoraunity.org/pipermail/repo-merge-discussion/2007-May/000137.html
Attention was drawn to the split between Free/non-Free when
RahulSundaram thanked RPMFusion for it and hoped that Fedora would
thus be able to link to the Free part. KevinKofler was dubious[8]
about this because of the patent-encumbrance issue and JesseKeating
also doubted it, as the ability to reference (link) to such a
repository seemed to imply that just packaging the material in the
Fedora Project repositories would also be legal (which no one argues).
A longish thread developed in which Rahul stated[9] that referencing,
linking or pointing-to such packages is legally different from
including them. This had been discussed at length at the Fedora
Advisory Board (see FWN#99 "FESCo Approves CodecBuddy"[10]).
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00835.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00840.html
[10] http://fedoraproject.org/wiki/FWN/Issue99#head-8f0c339b91cb83b8c9626974b6ec53d3b19f64b9
The legal situation was frustrating to many participants who sought
creative technical ways to solve the problem. JeroenvanMeeuwen went
back and forth with Rahul over including yum repo configuration files
which he believed must have the same legal status as linking to the
information contained in them. Rahul asserted[11] the difference
between these two actions and suggested again that anyone interested
read the FAB discussions. RichiPlana thought that he finally
understood the legal distinction to be that documents could point to
places to get such packages, but that a configuration file to allow
downloading them was illegal. But Rahul replied[12] that the legal
situation used to be that even pointing in documents to a website
which hosted a repository of contentious material was not
allowed, but that the situation had changed (due to the Microsoft vs.
AT&T case). This had been discussed[13] on the FAB list.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00936.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01006.html
[13] https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00032.html
TomCallaway (spot) put it plainly[14] when he explained "contributory
infringement", which doesn't seem to leave much wiggle room. Tom also
passed[15] on to Red Hat lawyers the question raised by Rahul of
exactly what sort of information could be included on a linked page.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00959.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01041.html
LesMikesell suggested moving the repository out of the USA, but Tom
(as the new Fedora Legal contact) quashed that notion by pointing out
that the problem was where Red Hat was based, not the repository[16].
CaseyDahlin mooted[17] a solution similar to a bit-torrent tracker,
but Tom had to regretfully respond that it would almost certainly be
contributory infringement. KingInuYasha was led to rant[18] about the
awfulness of software patents and to wonder how on earth the problem
could be fixed.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00913.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00991.html
[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00997.html
An inquiry about how packagers can join RPMFusion was made[19] by
KellyMiller (lightsolphoenix) and HansdeGoede responded[20] with the
subscription address and the information that the review procedure
would only differ from Fedora's in using blocker bugs instead of flags
(subject to discussion).
[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01056.html
[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01113.html
Other suggestions in the thread included registering both fedora.us
and fedora.eu and hoping that users would find their way by
word-of-mouth/Google to the .eu site which would contain contested
software, or to providing a repository which contained packages which
would configure yum to look at a repository containing the contested
software. Neither gained much traction.
=== Root Login And Display Managers In Rawhide ===
A mammoth thread was initiated[1] by RahulSundaram when he requested
that all display managers follow the pattern set by GDM, which
disallows root logins.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01483.html
PatriceDumas thought that PAM might provide a way to do this and
TomasMraz agreed[2] that ''auth required pam_succeed_if.so user!=root
quiet'' would work. This suggestion worried BernardoInnocenti as it
seemed as though it would also prevent ssh and console root logins on
a server which ordinarily would not have any non-root accounts.
SimoSorce replied[3] that the directive could be put into
the specific ''/etc/pam.d/'' configuration file instead of the
univeral ''/etc/pam.conf''.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01485.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01492.html
The issue of the normality and sanity of such set-ups was raised
fairly forciblyat several points. The first strong objection was by
AlanCox who pointed out[4] that if one were using networked
authentication schemes, e.g. LDAP or NIS, and these fail then there
would be no chance of recovery if root logins were disallowed.
MattMiller drew[5] on his experience at Boston University to suggest
that
root logins could be allowed to a restricted custom rescue desktop
workspace providing, for example, a terminal and
''system-config-users'' and nothing else. This idea struck Alan and
others favorably, with RichiPlana highlighting[6] the problem of
ordinary GNOME/KDE sessions granting root privileges to myriad daemons
of uncertain[7] code quality.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01514.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01532.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01646.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01664.html
SimoSorce added[8], in response to Alan, that the proposal was merely
to disable root login via GDM, not via console or SSH and
RahulSundaram confirmed[9] this separately in answer to RexDieter's
direct question. Rahul also noted that users wishing to ignore the
proposed safeguard could always override this default. DenisLeroy took
issue[10] with the idea that root login via a display manager was
abnormal. He also wondered whether there would be a simple anaconda
option to enable root login via DM as it would seem to be impossible
to run ''gdmsetup'' without root access. Rahul didn't accept this
argument and explained[11] how gdmsetup could be run even when
root-login via DM was disallowed.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01576.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01516.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01519.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01528.html
A certain amount of confusion ensued when Denis replied that non-root
user creation was not mandatory in anaconda, and explained[12] that he
was trying to avoid a scenario where after a successful X installation
it would become impossible to log onto the system. Denis suggested
that anaconda should allow root logins if no other users were created
during installation. The confusion arose when AlanCox understood[13]
Denis to be saying that anaconda should make non-root user creation
mandatory. Alan explained again that single-sign-on, LDAP, NIS, YP
made the creation of non-root users meaningless. A second source of
confusion was generated when he added that the security argument was
flawed because all one had to do was Ctrl-Alt-F1 and login as root at
the console. RuiMiguelSilvaSeabra replied[14] that this was not the
security concern, which was rather that GUIs tended to have large
amounts of buggy code and running them as root was a risk.
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01533.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01537.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01719.html
After Rahul suggested that Denis file an RFE requesting that anaconda
enforce the mandatory creation of a non-root user Alan responded[15]
with a request to be kept advised of this so that he could file a
"violent disagreement". JesseKeating made a proposal[16] which seemed
to work around the problem.
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01538.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01550.html
ColinWaters argued[17] that this was a change only to the Desktop Live
image in order to improve the experience for creative users who would
be installing only on a laptop or home PC. Colin reminded Alan that
the traditional "choose your own adventure" DVD would be untouched.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01548.html
An attempt[18] by Alan to pinpoint his heartfelt disagreement
emphasized that he thought that "If [the user has] not ticked any of
ldap, nis [during installation] .. then its a very good idea to be
extremely clear to the user that they want a non root account." Colin
responded[19] that remote authentication shouldn't even be a
consideration as this spin was targetted at home users' laptops and
that anyone wanting to set up a lab could use the DVD and kickstart.
Things heated up when Alan then attempted to "insert clue"[20] with
the information that he didn't want to download multiple media in
order to cover both his laptop and desktops. Colin stuck to his guns
and offered[21] sympathy to Alan for running an enterpise network, the
information that only the boot.iso would be needed (instead of the
whole DVD), and a link to the Fedora 7 install guide.
[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01553.html
[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01557.html
[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01565.html
[21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01569.html
JohannGudmundsson agreed with Alan that too many options and too many
variants of install media would be a problem[22] and this was
amplified[23] by RudolfKastl who noted the support burden which might
be incurred.
[22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01597.html
[23] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01861.html
After DenisLeroy suggested[24] the Desktop SIG driving the changes
must have little experience with real-world GNU/Linux deployments and
should consult with RHEL customers MatthiasClasen tried[25] to stop
the thread hitting rock-bottom. This didn't entirely succeed as when
Rahul reminded the list that the discussion was solely for the Desktop
spin MattMiller floated the idea that this was the deliberate
introduction of a feature which would be unacceptable to RHEL
customers, thus forcing them towards purchasing RHEL. Matt later
recanted[26] slightly and made a different point, namely that
"features" deprecated by RHEL customers might also be ones which
Fedora users would not like.
[24] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01542.html
[25] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01545.html
[26] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01573.html
Rahul's request to discuss the (de)merits of the proposal for the
Desktop spin without reference to RHEL led RalfCorsepius to argue[27]
that the Desktop spin itself was the bad idea. Ralf further disputed
that Fedora and RHEL had different audiences citing the existence of
EPEL as evidence. A thread then developed where Rahul contrasted
Fedora/RHEL roles, while Ralf compared their installation
similarities. Ralf argued that the only significant differences were
non-technical and included support contracts, longevity, and the
"non-free"[28] nature of RHEL. This latter point was disputed by,
among others, Rahul and in turn Ralf accused[29] him of "spreading
vile propaganda". The general reaction was that this was incivil and
inaccurate. JesseKeating noted[30] that although there was some
non-free software available to RHEL customers it was not part of the
distribution.
[27] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01606.html
[28] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01706.html
[29] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01711.html
[30] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01727.html
PatriceDumas thought[31] that Rahul was over-stating the differences
between Fedora rawhide and CentOS, leaving aside update policy and
lifecycle, and also wondered if Ralf were talking about the use of
OpenMotif (whose licensing is not OSI approved). Further discussion
with Patrice and Ralf led Rahul to expand[32] on the point that there
were both technical differences and different audiences for the
distributions.
[31] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01716.html
[32] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01745.html
=== Xulrunner ===
A note[1] from JesseKeating cautioned that the appearance of a build
of xulrunner in the Fedora 8 buildroot was premature do to outstanding
issues including lack of ppc64 support and not matching the Firefox
build. The build was the first appearance and could therefore be made
unavailable by untagging it.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01588.html
DavidWoodhouse was startled[2] by the ppc(64) mention as it should all
JustWork and asked what, if anything, he needed to do. JeremyKatz
helpfully remembered[3] ChrisopherAillon mentioning missing Firefox
ppc pieces in the upstream Xulrunner trunk. David was sagnuine that
an existing patch for ppc64 should work and asked to be poked[4] if it
didn't. Further investigation allowed him to declare[5] that the
problem was in "xptc" (part of XPCOM[6]) and that although the build
still failed it could be seen to be non ppc64 specific.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01589.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01591.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01594.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01627.html
[6] http://developer.mozilla.org/en/docs/XPCOM
TomCallaway pointed out[7] that the error also occurred with x86_64
and appeared to be a GCC bug for C++ and JakubJelinek confirmed[8]
this and assigned a GCC bug[9] to himself.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01666.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01668.html
[9] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33506
JesseKeating posted[10] that ChristopherAillon had used an ExcludeArch
with no comments or changelog entry, but the cvslog entry from him
noted that xptcall might be missing on ppc64. DavidWoodhouse
wondered[11] when the "ExcludeArch must have bug filed rule (see
FWN#90 "Fedora Secondary Architectures Proposal"[12]) was going to be
enforced and also clarified that contrary to the cvslog supposition
the xptcall stubs had been implemented for a while on ppc64. David
declined Jesse's invitation to code up a means of "enforcing" the
rule.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01593.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01596.html
[12] http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8632cae42b1aa
=== PlanetCCRMA Packages For Audio Creation To Be Integrated ===
Some good news[1] was announced by HansdeGoede. He had been planning
with PlanetCCRMA's[2] FernandoLopez-Lezcano to improve the audio
creation experience in Fedora by taking the existing PlanetCCRMA
packages and modifying them to meet the FedoraPackagingGuidelines.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01421.html
[2] http://ccrma.stanford.edu/planetccrma/software/
The method by which this will happen is outlined at the wiki page for
the Audio Creation SIG[3], and boils down to Fedora contributors
identifying interesting SRPMS at PlanetCCRMA, whipping the spec files
into shape and then submitting them for review while CCing Fernando.
[3] http://fedoraproject.org/wiki/SIGs/AudioCreation
There were several early takers including NicolasChauvet (kwizart) who
had already[4] submitted "jack-rack" for review and also volunteered
to act as a reviewer. RichiPlana was interested[5] in whether the SIG
was solely going to integrate PlanetCCRMA packages (and hence should
change its title) or was going to address other audio-creation issues
in the future. Hans replied that for the immediate present work would
focus on using the pre-existing CCRMA packages, but that the future
was open to other activities.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01426.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01429.html
Richi wanted some further guidance as to which packages needed
attention and where interested contributors might find the SRPMS.
Fernando replied[6] with that information and also some great
background on the history of CCRMA. Following up on that Richi had
some more questions[7] about the potential of accumulating differences
between Fedora curated packages and PlanetCCRMA's packages, and also
about the need for a low latency kernel.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01635.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01640.html
According to Fernando[8] a low-latency kernel is not essential to run
any of the packages, although it is desirable for live performance
situations. Fernando noted that IngoMolnar's work on realtime
pre-emption won't be in the mainline kernel anytime soon and wondered
what Richi meant about "kmods" (see FWN#99 "Kmods Clarified"[9]).
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01679.html
[9] http://fedoraproject.org/wiki/FWN/Issue99#head-98170522fb95c1c25efc05a5f2f6367656a7f174
=== Possibly Orphaned Lftp Spawns Bug Squad! ===
An angry plea[1] from AlainPortal requested that the ''lftp'' package
should be orphaned because the maintainer MarosBarabas was not
tracking upstream releases and had left the package at an early
version (3.5.10) despite despite a request from Alain to update to a
new release and three subsequent upstream changes. The bugzilla entry
contained[2] a mix of frustrated speculation as to why this had not
happened.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01192.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=242112
When RichiPlana asked how packages get orphaned and how he might pick
one up for maintenance he was supplied with the necessary links by
RahulSundaram[3] and JefSpaleta[4].
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01202.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01272.html
Rahul recommended that Alain follow the AWOL policy and after thanking
him for the information Alain wondered[5] whether he could skip some
steps due to the age of his bugzilla request which was some months old
and awaiting response from the maintainer. Alain expressed willingness
to attempt to maintain the package, but also doubt as to his ability.
HansdeGoede responded with a generous and open
invitation to help with any C programming problems and encouraged[6]
Alain or anyone else to contact him with such C problems.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01199.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01210.html
JeffSpaleta floated[7] the idea of a larger "broken code response
group" where those skilled in programming areas could help out the
less skilled. This idea seemed very popular and several people
volunteered (possibly stimulated by the idea of tshirts!). Hans then
wondered[8] whether creating a specific mailing list for the purpose
of stimulating packagers to send out help requests would be useful.
There seemed to be general agreement that it would be better than
overwhelming @fedora-devel and Jef also suggested[9] enhancing
bugzilla to allow the bug owner to set a flag requesting help from the
code squad (whose members had swelled by this time to include
JonCisela, RichiPlana, PaulFrields, HansdeGoede, DenisLeroy and
JesseKeating).
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01213.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01221.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01231.html
The positive, productive note of the thread was continued when Alain
committed to maintaining the package if no response was heard in 72
hours and JeremyKatz noted[10] that this was a very short timeframe
over a weekend and did a "side channel ping" to alert the maintainer.
MattMiller agreed[11] that this timeframe was a bit hasty and also
pointed out that although the release version numbers had increased it
did not look as though anything very important was changing between
releases. ChristopherBrown disagreed[12] that this was a reasonable
maintenance strategy as "bugs are bugs".
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01240.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01252.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01260.html
Subsequently the bugzilla entry showed that the maintainer was dealing
with the issue and wasn't using age of a bug as the criterion of
importance.
=== Disable IPv6 By Default ===
A surprisingly good thread resulted from JohannGudmundsson
suggestion[1] that as IPv6 uptake had been slow it would be better to
disable it in Fedora by default.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01024.html
One group of posters wondered what exactly was the point of disabling
IPv6. ChuckAnderson asked[2] what specific problem was being solved
and thought that the chicken-and-egg nature of deploying IPv6 meant
that Fedora was to be applauded for being proactive and DennisGilmore
was a satisfied IPv6 user who wondered[3] why he should have to jump
through extra hoops when no harm was caused by having
both IPv4 and IPv6 enabled. Johann responded[4] that it was a "waste
of time and resources" and JohnReiser commented[5] that recommended
security policy was to turn off all unused services. He added that
several dozen pages of RAM were wasted if it was not used and
suggested adding ''alias net-pf-10 off'' to ''/etc/modprobe.conf''.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01025.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01028.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01030.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01037.html
DennisGilmore pressed Johann for further proof of the exact resource
burden and security threat and also informed[6] him that the
contractors to the government of the USA were mandated to use IPv6 by
2008. Johann was unimpressed with the needs of the USA and provided no
exact figures on the resources used, this was followed by
PeterRobinson providing[6] a crude estimate of a mere 312KB RAM and
also the information that MacOSX, Vista, Server2008 and others all
supported IPv6 out of the box and that the EU and Asia were using IPv6
(separately DennisGilmore noted that Asia was one of the largest IPv6
users).
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01048.html
Earlier in the conversation RichiPlana suggested that disabling IPv6
should be made a simple one-step process and asked[7] how he could do
this. Interestingly, throughout the thread there were a variety of
solutions offered: JohnReiser's solution above; ThomasSteenholdt's[8]
''install ipv6 /bin/true'' in ''/etc/modprobe.conf'' followed by
''chkconfig ip6tables off'' followed by a reboot; TillMaas's[9]
''IPV6INIT=no'' in ''/etc/sysconfig/network'' (which Till reported as
failing in FC6). The variety of these responses indicated that Richi
was onto something. DavidWoodhouse made an amusing suggestion[10] of
''echo blacklist ipv6 > /etc/modprobe.d/luddite''. Further discussion
led to Richi posting[10] a link which explained things clearly.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01043.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01298.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01122.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01080.html
In another part of the discussion DavidWoodhouse explained[11] how to
get IPv6 connectivity using tunnel brokers even if one only has an
IPv4 public address.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01301.html
ColinWalters overview[12] of the thread was that the wrong question
(should IPv6 be disabled) was being asked and instead it should be
what specific bugs need to be fixed if it is to be enabled. This
resonated[13] with DavidCantrell who had said[14] earlier that it was
a pain working with IPv6 due to so many Fedora users being afraid of
it. He commented that the module could be blacklisted by those that
wanted to disable it but that users shouldn't be bothered with
something which should just work.
[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01074.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01079.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01031.html
After RichiPlana outlined[15] a plan to modify system-config-network
to disable IPv6 but leave it on by default, Johann reminded[16] the
list that the discussion topic was whether and how to disable IPv6
during installation and asked "IPv6fanboys" how well their pure IPv6
WAN/LAN could communicate[16a] with the rest fo the world.
JesseKeating thought[17] that users should be allowed to disable IPv6
post installation using either s-c-n or NetworkManager but that bugs
appearing due to it being enabled but not actively used needed fixing.
OlaThoresen provided[18] personal testimony about how perfectly IPv6
worked for him. In a separate part of the thread ChuckAnderson
provided[19] a list of network operators using IPv6.
[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01193.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01206.html
[16a] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01224.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01207.html
[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01245.html
[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01315.html
RubenKerkhof's interest was so piqued[20] by the discussion that he
registered for an account with sixss.net and MattDomsch provided[21]
more details for anyone interested in experimenting with tunnelled
IPv6.
[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01317.html
[21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01142.html
JohnReiser provided a list of arguments[22] including anonymity and
expense as reasons why one would not wish to transition to IPv6.
[22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01128.html
=== Udev Performance ===
A response to concerns about ''udev'' performance was posted[1] by
HaraldHoyer. Harald had profiled udev activity and determined that it
spent the majority of its time with /sbin/modprobe due to parsing its
configuration/dependency files on each call[2].
[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00771.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00773.html
RalfErtzinger asked what udev could do except process the files each
time and HansdeGoede suggested[3] several alternatives including: a
daemon mode; a cached dump of the dependency tree; or splitting out
the modprobe code into a library which could be called by udev.
According[4] to Harald the daemon mode had also been suggested by
GregKroah-Hartman and KaySievers.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00777.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00778.html
Some very interesting ''systemtap'' results were supplied by
WilliamCohen, who noted that the current process of searching linearly
through 250K of modules.dep was inefficient. Harald responded[5] that
the problem was that most modprobes with a modalias were non-existent
and so each line was parsed.
JakubJelinek suggested[6] a hash table or other compact format might
solve this problem if the time taken really was significant.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00790.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00793.html
DavidHollis liked[7] Hans' last option of creating a libmodprobe.so as
it would avoid maintaining duplicate code and the security problems of
a pipe or socket.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00788.html
The daemon idea was also deprecated[8] by Ralf due to security issues,
while Jakubs suggestion was judged favorably. EricSandeen remained to
be convinced[9] however that the parsing of the modules.dep was what
was taking the time and provided an strace during boot to reinforce
this point.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00790.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00793.html
DavidHollis liked[7] Hans' last option of creating a libmodprobe.so as
it would avoid maintaining duplicate code and the security problems of
a pipe or socket.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00788.html
The daemon idea was also deprecated[8] by Ralf due to security issues,
while Jakubs suggestion was judged favorably. EricSandeen remained to
be convinced[9] however that the parsing of the modules.dep was what
was taking the time and provided an strace during boot to reinforce
this point.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00808.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00818.html
[[Anchor(Maintainers)]]
== Maintainers ==
In this section, we cover Fedora Maintainers, the group of people who
maintain the software packages in Fedora.
https://www.redhat.com/mailman/listinfo/fedora-maintainers
Contributing Writer: ThomasChung
=== End of fedora-maintainers-list ===
Editor's Note: FWN will not be covering fedora-maintainers in the future issue.
BrianPepple announces in fedora-maintainers[1],
"The plan is to close the fedora-maintainers-list on 2007-09-10. The
fedora-devel-list[2] will be the mailing that acts as the direct successor
for the fedora-maintainers-list."
[1] https://www.redhat.com/archives/fedora-maintainers/2007-September/msg00090.html
[2] https://www.redhat.com/mailman/listinfo/fedora-devel-list
[[Anchor(Translation)]]
== Translation ==
This section, we cover the news surrounding the Fedora Translation
(L10n) Project.
http://fedoraproject.org/wiki/L10N
Contributing Writer: JasonMatthewTaylor
=== FAQ ===
DimitrisGlezos posted[1] about his additions of a FAQ to help address
some translation questions. Comments/suggestions are always welcome.
[1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00147.html
=== Transifex Update ===
DimitrisGlezos had some updates for transifex this week, one of which
added support for system-config-printer.[1]
[1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00156.html
=== Online Translation ===
DimitrisGlezos wanted to start discussion about whether or not an
online translation tool would be useful and what features would be
good to have.[1]
[1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00171.html
[[Anchor(Infrastructure)]]
== Infrastructure ==
In this section, we cover the Fedora Infrastructure Project.
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: JasonMatthewTaylor
=== DB2 Outage/Upgrade ===
MikeMcGrath posted[1-2] that DB2 would be taken down to address disk
space issues. No problems with the upgrade were reported.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00066.html
[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00071.html
=== Spins Directory ===
MattDomsch posted[1] a suggestion to modify the mirror directory
structure to better facilitate respins. The idea being that respins
can be done and content can be moved back and forth between servers
without causing mirror breakage. After some discussion it was agreed
to be a good idea and will likely see some implementation in the
future.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00083.html
[[Anchor(SecurityWeek)]]
== Security Week ==
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
=== Is a chroot secure? ===
Kerneltrap has a nice summary of why a chroot is not a security
feature. This is an issue that comes up every couple of years. It is
likely this will continue to happen since there is quite a lot of
information available on the Internet that claims a chroot is a fine
way to keep something secure. The best advice if you wish to keep a
process in a cage would be to use SELinux.
http://kerneltrap.org/Linux/Abusing_chroot
=== Is SELinux really too complex? ===
Speaking of SELinux, this article takes a rather insightful look at
the technology.
http://enterpriselinuxlog.blogs.techtarget.com/2007/09/26/selinux-is-it-really-too-complex/
The article does point out that the OpenBSD mailing list is obviously
a rather biased place to find SELinux commentary, but many of the
points made about SELinux are good for someone who hasn't been keeping
an eye on the discussions.
[[Anchor(AdvisoriesUpdates)]]
== Advisories and Updates ==
In this section, we cover Security Advisories and Package Updates from
fedora-package-announce.
http://fedoraproject.org/wiki/FSA
Contributing Writer: ThomasChung
=== Fedora 7 Security Advisories ===
* elinks-0.11.3-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00335.html
* libsndfile-1.0.17-2.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00344.html
* fuse-2.7.0-5.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00367.html
* ntfs-3g-1.913-2.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00368.html
* kernel-2.6.22.7-85.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00375.html
* bugzilla-3.0.2-0.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00387.html
* php-5.2.4-1.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00397.html
* t1lib-5.1.1-3.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00431.html
* kernel-2.6.22.9-91.fc7 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00436.html
=== Fedora Core 6 Security Advisories ===
* httpd-2.2.6-1.fc6 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00353.html
* php-5.1.6-3.7.fc6 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00354.html
* kernel-2.6.22.7-57.fc6 -
https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00355.html
[[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-MM-DD ===
* No Report
=== Fedora Ambassadors Meeting 2007-MM-DD ===
* No Report
=== Fedora Documentation Steering Committee 2007-MM-DD ===
* No Report
=== Fedora Engineering Steering Committee Meeting 2007-MM-DD ===
* No Report
=== Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-09-26 ===
* https://www.redhat.com/archives/epel-devel-list/2007-September/msg00110.html
=== Fedora Infrastructure Meeting (Log) 2007-09-27 ===
* https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00078.html
=== Fedora Localization Project Meeting 2007-MM-DD ===
* No Report
=== Fedora Packaging Committee Meeting 2007-09-25 ===
* https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02152.html
=== Fedora Release Engineering Meeting 2007-MM-DD ===
* No Report
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
--
fedora-announce-list mailing list
[e-mail:fedora-announce-list@redhat.com]
https://www.redhat.com/mailman/listinfo/fedora-announce-list
|
