m (1 revision(s))
m (added category)
|Line 553:||Line 553:|
* No Report
* No Report
Latest revision as of 10:57, 14 April 2009
 Fedora Weekly News Issue 106
Welcome to Fedora Weekly News Issue 106 for the week of October 15th. http://fedoraproject.org/wiki/FWN/Issue106
In AskFedora we have "Mobile Phone Internet Dialer" and "Just Thanks."
To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join.
In this section, we cover announcements from Fedora Project.
Contributing Writer: ThomasChung
No Official Announcement was made for this week.
 Ask Fedora
In this section, we answer general questions from Fedora community. Send your questions to askfedora AT 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.
Contributing Writer: RahulSundaram
 Mobile Phone Internet Dialer
Balaji Kumar <kkc_balaji AT rediffmail.com> : I am C.Balaji, A Fedora user and promoter(chosen by myself to be) for past 3 years. i am in remote area of India. so i can have internet access only through gsm phones gprs modem.the connection provider was from airtel. almost 35 friends of mine were having internet access only with this type of connection but i cant connect to internet without windows through my mobile. i found an application called gprs easy connect for linux which support many phones. I believe without internet linux will be boring. also it must provide every way to connect to internet. so if you add that 6 mb program as default for fedora that would be more interesting so that more than 1000 people in my own town will have access to internet in linux platform. Since I am being a open source promoter i can assure them with most useful tool to connect to the Internet.
Taking a quick look at this software, it is under the GPL license which is acceptable for Fedora and I have added it to the wishlist . It is however too late for us to evaluating this software and go through the process of integrating and testing it in time for Fedora 8 but we can look into this before the subsequent release. Note that, due to space constraints, only the main software packages is available in the Live images. The rest of the software will be available in the Fedora online software repository.
 "Just" Thanks
Don Smith <dmsmith AT tru.eastlink.ca> : I just wanted to say thank you to all the developers that work on Fedora. I recently installed Fedora 7 on my Toshiba laptop that came with Vista pre-installed. I'm NOT a Vista fan. I'm am totally impressed with Fedora 7 and feel it is miles ahead of Vista. Fedora 7 is excellent!. Thanks for the great work folks!
 Planet Fedora
In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.
Contributing Writers: ThomasChung
 What Fedora 8 feature am I excited about today?
Jesse Keating points out in his blog ,
"Working wireless out of the box. Intel 4965 firmware is in, works well, and NetworkManager rewrite leaves me with some pretty damn good software to manage it."
 Codec Buddy in Fedora 8
RahulSundaram points out in his blog
"Codec Buddy (Codeina) is the wrapper in Fedora 8 which helps educate the users on the advantage of open formats or optionally install multimedia codecs when you click on any multimedia content that is not supported by Fedora out of the box. To know more about how codec buddy works and see some screenshots, take a look at the codeina page ."
 Frozen for Fedora 8. Brace for impact!
WillWoods points out in his blog
"Hoorj. So, yeah, we are definitely frozen for F8. Now comes the time when I spend every day staring at the blocker list and poking the bugs there (and the people responsible for them) and trying to make them die. The bugs, not the people."
In this section, we cover Fedora Marketing Project.
Contributing Writer: ThomasChung
 Distrowatch on Fedora Artwork
RahulSundaram reports in fedora-marketing-list
"The Fedora project has been on the forefront of these initiatives, which resulted in some of the most eye-catching desktop art and themes available in any distribution. How do they do it? Learn more in this interview with Fedora art team lead Máirín Duffy"
 Ohio Linux Fest Follow up
KarlieRobinson reports in fedora-marketing-list ,
"Sorry it's been so long getting it published. It's been a really crazy couple of weeks around here. Todd's article about the Fest."
 The Linux Foundation's desktop Linux survey
RahulSundaram reports in fedora-marketing-list ,
"The survey will take only few minutes of your time, and your feedback is essential in helping us to focus our development efforts and accelerate the global adoption of Linux desktops and clients. For example, past surveys highlighted the need to address printing and wireless issues, so we set up focused workgroups and conferences to help developers and vendors work out common solutions to these requirements."
In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.
Contributing Writer: OisinFeeley
 Rawhide Now Friendly To Babies
A proposal to change the way in which the release cycle is managed was posted as an RFC by JesseKeating. The intent of the proposal was to shorten the amount of time during which developers are unable to share code due to "freezes" of the always-current development CVS (known as "rawhide"). A freeze is the temporary removal of the ability of contributors to check-in newly built packages. This is necessary to obtain a stable aggregation of packages as a release. The proposal would see the renaming of "Test1 - Test3, Final" as "Alpha, Beta, Release Candidate, Final" with no rawhide freeze for "Alpha".
Substantial early feedback from HansdeGoede and ThorstenLeemhuis welcomed the discussion but challenged many of the assumptions. Hans declared himself in favor of the current model of early mass branching but avoiding adding the extra overhead of contributors having to ask release-engineering to pull specific builds from this branch into the release.
Jesse responded to Hans objections from the perspective of development ceasing for a release once the request candidate (RC) is being composed and that from that point development work should be in preparing material for the updates-testing repository for that release, or if there were a compelling reason then release-engineering would upon request move the update from the branch into the RC. Hans thanked Jesse for this explanation but returned to his central objection that maintainers were the people with the expertise (rather than release-engineering) to decide whether their package should enter the RC, or stay in the branch. He also argued that there were only two exit points from Jesse's proposed algorithm: the release branch; or the devel branch. Hans on his part split the decision into three parts: benign simple fixes (release branch); non-disruptive updates (updates-testing); next development cycle. Hans rhetorically wondered "Isn't our new slogan "freedom is a feature", then I say no to a small club making the decisions, thats an autocracy. I say power to the people (power to the maintainers)."
Hans' objection to the bottleneck was answered by MikeMcGrath with a request for suggestions of who could make the decision about whether the build would go down any of these paths. Hans argued again for leaving the decision in the hands of the actual maintainer and when NicolasMailhot expressed the opinion that "[the maintainer will always put his package before the distro as a whole" suggested that he might start looking for another community. Nicolas thought that it was just a description of human behavior and pointed to the Linux kernel development model. MikeMcGrath and JefSpaleta also tried to defend the necessity of a single release-engineering team co-ordinating the changes. Jef drew the analogy of writers and editors to attempt to point out that conflicting priorities do not equate to ill-will, malice or disregard.
Separately JesseKeating responded that there was evidence that broken trees would result if release-engineering were not there to check that individual maintainers' decisions were sane for the whole tree. Jesse also acknowledged that while there were many excellent maintainers capable of these decisions there were many that only had the time to do a blanket "build for new upstream release". He argued that there were three exit points and added that he would be happy to see more people added to the release-engineering team.
Hans made a detailed reply in which he argued for the greater trusting of maintainers, with several examples from his own expertise. He suggested that if there automated checks for the disappearance of Provides: for packages and consequent tagging of the package requiring the maintainer to explain the problem or fix it before it can be pushed. Hans also objected to Jesse's use of the phrase "joe random builder". A response from JesseKeating detailed the constraints under which the build process and release-engineering is working, apologized for any offense taken by the phrase, and emphasized that a knowledge of, and facility with, package building did not necessarily translate into appreciating the details of the release process. Jesse agreed that while Hans' hypothetical automated checking was a good idea he simply "lacked the bandwidth" to do anything more than he was doing right now. MikeMcGrath suggested that Hans produce a proposal.
ThorstenLeemhuis was also appreciative of Jesse's effort to address this problem and raised some fresh issues. Thorsten argued for more frequent test releases, while acknowledging the potential impact on mirrors. He also commented that there was a lack of users testing rawhide because of the perception that "rawhide eats babies." Thorsten sketched out a potential release schedule which would lead to more stable rawhide in the five weeks before a release. He also suggested better documentation of ways in which testers can smoothly transition from rawhide to a stable release. While Jesse was doubtful that mirrors would be willing or able to cope with rapid cycling of test releases he agreed that getting test-releases out earlier was necessary, but should be achieved by ensuring that the tree was more stable. A detailed discussion of potential release problems followed.
The issue of being able to upgrade was addressed when RahulSundaram pointed to the wiki page about updating from one release to another and Thorsten added information about running the YumShell in rawhide.
 Ensuring SELinux Contexts Track Changed Executable Locations
On October 13th DanielWalsh posted a heads-up to maintainers to the effect that if the location of an executable had changed then they needed to ensure that the SELinux context was correctly reset. Failure to do this could result in a security vulnerability.
ArjanvandeVen wished that the build system could notice this sort of thing and send warning emails to which JesseKeating responded with a "patches accepted" link.
A suggestion was made by KarelZak that it would be better to maintain a default SELinux label in a similar manner to file attributes, e.g. %attr(4755,root,root) %selinux(foo_t) /bin/foo. LubomirKundrak agreed that this was "more elegant and maintainable than restorecon in scriptlets".
Skepticism was expressed by TomasMraz about the ability to update file_contexts to prevent loss on the next filesystem relabel and Karel responded with the suggestion of using more policies and using a label database. GianlucaSforna and ChristopherBrown both suggested that having non-experts (w.r.t. SELinux) muck about with contexts in spec files would not scale well and introduced unwanted complexity.
 SELinux Wipes Smile Off GDM Facegreeter
LouisGarcia asked why GDM did not display a picture when he apparently had followed the correct steps of placing it in the About Me "capplet" and had a .face file in his ~.
A first stab at the problem was taken by BastienNocera when he suggested checking the permissions of the .face and home directory. DavidZeuthen pointed out that this shouldn't be a problem because the master GDM process runs as root and pipes the faces to the GDM greeter, but KostasGeorgiou added a twist when he pointed out that the home could be mounted over the network and that root would thus not necessarily have access.
When Louis added the information that he was seeing an AVC denial SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to (home_root_t) he was asked by LubomirKundrak whether he was logged-in as root. Lubomir also requested the location of the picture and asked if he had tried to run restorecon (to reset the security context ).
 See DanielWalsh's excellent article http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/
Louis clarified that he was not "running as root" and listed the extended attributes of the .face file. DanielWalsh suspected that the file was not in the usual home directory because it had a context of home_root_t instead of user_home_t. Further investigation showed that Louis whole home directory needed to have the file contexts restored with restorecon -R -v /home.
 Proprietary GoogleEarth Craps Out
A query was posted by ThomasBaker as to whether anyone had run GoogleEarth successfully on Fedora 8. He observed that it hung randomly without passing the server login.
Initial suspicion focused on the hardware but LubomirKundrak pointed out that hangs occurred for both fglrx (ATI's closed-source driver) and Intel's driver. He suggested the alternative explanation of it being a "pile of proprietary crap", a suggestion that was not challenged. BenjaminLewis acknowledged that his own kind provision of an strace was possibly not of too much use as both fglrx and GoogleEarth were proprietary, but noted that the instability seemed to parallel the introduction of the star-viewing features.
DaveAirlie was torn between blaming glibc or bits of X11 and asked if anyone could narrow down when it last worked. He then went ahead and pulled in the latest Fedora 7 glibc into a directory on his Fedora 8 box and ran the GoogleEarth binary against this older library with LD_LIBRARY_PATH=.:/home/airlied/test/lib /home/airlied/test/lib//ld-2.6.so ./googleearth-bin, thus confirming that the problem appeared to be in glibc.
A response from JakubJelinek identified a bug in GoogleEarth and also one in glibc itself.
DouglasMcClendon raised the question of who was working on providing an alternative by packaging NASA's worldwind and also wondering if KMarble could run on GNOME. KevinKofler answered that it should run if Qt4 was installed but cautioned that "It doesn't have all that fancy 3D stuff though".
 Provides Or Obsoletes?
SteveDickson asked for help in using Provides: and Obsoletes: in a specfile to resolve file conflicts on a common configuration file. The problem arose in the specific context of renaming libgssapi-0.11-2.fc8 to libgssglue-0.1-2.fc8.
Because Steve had provided an extract from his specfile and also a cut-and-paste of the error from the command line he quickly received multiple answers helpfully pointing out that his error consisted in trying to install (using yum -ihv <packagename>.rpm) instead of upgrading (using yum -Uhv <packagename>.rpm). DanielBerrange pointed out that the install would attempt to proceed in parallel resulting in a clash on files.
Steve confirmed to JosVos that this was indeed the problem.
MichaelSchwendt was sharp-eyed enough to notice that the NVR of the package was not sufficient because the presence of a %dist tag would throw out the comparison. LubomirKundrak expressed strong agreement and requested that Obsoletes: tags should _never_ contain "<=". JosVos suggested that just comparing the Versions and leaving out the Release would be a minimal improvement. In an aside Jos also wondered why gaim had been obsoleted by pidgin using gaim < 999:1 instead of simply obsoleting gaim. MichaelSchwendt replied that versioned obsoletes kept the door open for re-introducing a package with the name.
Closing off the thread, SteveDickson thanked everyone for their help and posted his now fixed specfile.
 Deploying Noarch Builds To Specific Arches
A report of a problem in building a package dependent on IcedTea(an unencumbered hybrid of Sun's OpenJDK and GNU Classpath) was posted by DeepakBhole. Deepak noted that Koji allowed "Noarch" to be chosen and attempted to build the package for x86, x86_64 and also ppc. The problem was that IcedTea itself only exists for x86 and x86_64, resulting a failed build on ppc.
AndrewHaley's immediate interest was in finding out why the failure was happening, and a short exchange with AnthonyGreen explored whether using ecj would allow the building of IcedTea on ppc, but the conclusion was to simply avoid the problem: "Just don't BuildRequire icedtea and all is good."
The recommendation offered by JesseKeating was to use "ExclusiveArch: i386 x86_64" in the spec and to comment this. Deepak objected that this would fail to produce packages for the ppc architecture which could run on it in interpreted mode. AndrewHaley referenced an IRC discussion in which Deepak had explained the problem as a disjunction between Fedora policy (allowing building noarch with IcedTea and shipping all archs) and what the buildsystem allows. He suggested that the policy be adjusted to fit the buildsystem capabilities.
A slightly separate issue was raised by CaolanMcNamara when he showed that IcedTea generated by default bytecode which was targeted to a later version than 'gij' can handle. AndrewHaley responded that it was essential that all packages built with IcedTea use -target 1.5 and this needed to be Fedora policy. JasonTibbitts asked for someone to write packaging guidelines concerning Java.
The situation was re-assessed by JesseKeating who summed up with the information that it was not possible to build all packages with IcedTea at present. Instead everything could and should be built with 'gcj'. These packages then have the possibility to run using either IcedTea(on selected architectures) or 'gcj'.
 Bootable USB Stick Containing LiveCD ISO (PPC)
The ability to automagically set up a USB stick (containing the contents of the LiveCD ISO) as a boot device was announced by JarodWilson. He cautioned that it currently only worked on PPC Macintoshes and required some manual repartitioning and specification within Open Firmware.
RalfErtzinger suggested that hard coding the device name into the script was a bad idea and Jarod agreed and changed this detail.
The script is available for testing and Jarod subsequently reported booting a MacMini successfully with it.
 Opinions Canvassed On Firefox Interaction With Compiz
The recent acquisition of improved notifications by Firefox had led JesseKeating to become irritated at the automatic rotation of the compiz desktop to the cube face containing the Firefox window whenever an URL was clicked. Jesse modestly admitted to being "strange at times" and wondered whether other users agreed with him that it would be nicer not to do this. Instead he suggested that a pulsing Firefox icon should appear on each face and only when it was clicked would the face containing Firefox be rotated into view.
The bug number was requested by ChuckAnderson and supplied by EmmanuelSeyman.
Although RalfErtzinger was not using compiz he had recently noticed behavior which also irritated him: the foregrounding of Firefox whenever he clicked a link in another application. JohnDennis agreed and wanted this behavior off by default.
DavidZeuthen added that when using Metacity workspaces would be ruined by Firefox jumping into them, but noted the existence of a patch and Jesse answered that he had built Metacity with the patch and it would be in Fedora 8.
A further post from KevinKofler wondered what would happen with KWin and RoddClarkson opened a new can of worms by suggesting that behaviors should be consistent across desktop managers.
 Mock Rebuild Status
MattDomsch's regular posting of the results of rebuilding Fedora in Mock (for x86_64) contained a list of 199 packages which had failed to build. Matt thanked Spot (TomCallaway) for fixing approximately one hundred and fifty PERL packages. He also pointed out that the version of Mock in which the builds had been done was MichaelBrown's pre-release of version 0.8.
PanuMatilainen spotted a fairly simple problem a missing "Requires" which had caused one of his packages to fail and IgnacioVazquezAbrams was puzzled as to why one of his packages which used an "ExclusiveArch: i386" was showing up in the list.
 Two Mass Branches
On Thursday October 18th JesseKeating announced the first mass branch for Fedora 8 (see discussion in this same FWN#106 "Rawhide Now Friendly To Babies".) He stated that CVS commits would be disabled until he announced their re-opening. The next day an announcement of the re-opening of CVS carried the additional information that the operation had stalled due to a failure to request all the branches from PackageDB.
Later the same day (Friday 19th) Jesse announced that he was ready for another go and that CVS was again going to be disabled during the procedure. On Saturday 20th Jesse followed up with the information that all was going well, albeit a little slowly. He noted that this was the first trial of using PackageDB completely for branching and that some areas had been identified as likely candidates for speeding things up. Meanwhile Jesse unreasonably snatched a few hours of the weekend to do some housework.
A suggestion was made that the CVS error message during this period should be changed to something a bit more informative.
 Advisory Board
In this section, we cover discussion in Fedora Advisory Board.
Contributing Writer: MichaelLarabel
 Fedora Board Recap
JohnPoelstra has recapped their recent Fedora Board meeting . Discussed at this meeting were licensing concerns for SPEC files, the Google start page in Fedora 8, and the future of PowerPC support. Red Hat Legal had chimed in on the SPEC file licensing and has stated these files needed to build RPMs should be as open and licensed just like everything else. The SPEC files should be licensed the same as the package itself or in "something extremely permissive". The Google start page is progressing, but no agreement has yet been signed. The PowerPC ISOs for Fedora 8 will be released in the same fashion as previous Fedora releases, but for future releases, the PowerPC support will be dependent upon the Fedora PPC developer community.
In this section, we cover discussion in Fedora Fonts.
Contributing Writer: MichaelLarabel
 Developing Open Fonts
After the creation of the fedora-fonts-list , AnneWilson has asked how to start creating a new free font based upon her favorite closed-source font . This question was answered by checking out some resources such as the Open Font Library Wiki and Font Forge Tutorial .
This section, we cover the news surrounding the Fedora Translation (L10n) Project.
Contributing Writer: JasonMatthewTaylor
 Release Note Deadline
Well, it's here. The deadline for translation of the Fedora Core 8 release notes is 22-Oct-2007 at 2359. Translations at or greater than 90% complete will be included, there will also be a zero-day build for those that are close but are still working.
In this section, we cover the Fedora Infrastructure Project.
Contributing Writer: JasonMatthewTaylor
So after much discussion this week about what to do about Moin (the wiki software) as its performance has been somewhat lacking the infrastructure team came up with a temporary fix. MikeMcGrath and MattDomsch came up with a patch that backgrounds the email notification so the wiki isn't waiting on the email, it just saves and then the email subsystem takes care of its end. While this is a temporary fix (until ToshioKuratomi completes a database backend) it seems to be doing the trick. Thanks guys from all the wiki users!
 Security Week
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
 Firefox Security Update
This week was consumed with the Firefox security update. A security update of Firefox will result in the release of Firefox, Seamonkey, and Thunderbird. This is of course a great deal of work for all the involved parties. Those programs are rather complex and much can go wrong along the way. On the plus side though, we have gotten rather good at dealing with these updates in RHEL and Fedora. All the interesting bits can be found here:
 Advisories and Updates
In this section, we cover Security Advisories and Package Updates from fedora-package-announce.
Contributing Writer: ThomasChung
 Fedora 7 Security Advisories
- tk-8.4.13-6.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00261.html
- openssl-0.9.8b-15.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00263.html
 Fedora Core 6 Security Advisories
- openssh-4.3p2-25.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00214.html
- util-linux-2.13-0.49.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00216.html
- hplip-1.7.4a-3.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00217.html
- openssl-0.9.8b-15.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00218.html
 Events and Meetings
In this section, we cover event reports and meeting summaries from various projects.
Contributing Writer: ThomasChung
 Fedora Board Meeting Minutes 2007-10-16
 Fedora Ambassadors Meeting 2007-MM-DD
- No Report
 Fedora Documentation Steering Committee 2007-10-12
 Fedora Engineering Steering Committee Meeting 2007-10-18
 Fedora Extra Packages for Enterprise Linux Meeting 2007-10-21
 Fedora Infrastructure Meeting (Log) 2007-10-18
 Fedora Localization Meeting 2007-10-16
 Fedora Marketing Meeting 2007-MM-DD
- No Report
 Fedora Packaging Committee Meeting 2007-MM-DD
- No Report
 Fedora Release Engineering Meeting 2007-MM-DD
- No Report