Posts Tagged ‘Fedora’
Report on Fedora Activity Day : May 2010, Pune, India
Day 1, Getting started
Fedora India team had originally planned a FUDCon sometime this year and after several discussions, we realized that our goals of enabling existing contributors to get together and get some things done face to face was better enabled via a Fedora Activity Day in Pune, India. We selected Pune as the venue for the event because the Red Hat Engineering services office is located here and we wanted to host the event in this place and the logistics was much easier this way. I volunteered to be the event owner and it was a interesting learning experience. For one, it is easy to understimate the amount of work required to get a event of even this relatively smaller scale up and running. More on that later.
It was a two day event on the weekend and the first day started off with Siddesh‘s workshop on autotools. Siddesh essentially redid the Fedora Classroom session he had conducted earlier. His blog with more details here. linkc is a project that I acted as a mentor for a couple of students doing an internship in Red Hat and I hope they step up to become active contributors to Fedora as well.
After Siddesh’s session, we had a quick pitch on what each of us hope to accomplish. Among the things I had planned, I made some solid progress in a few package reviews. The only thing that didn’t get any movement was fixing the desktop file issues listed here. We hope to perhaps do a followup online later and cover that.
I gave the list of security bugs from here to Rakesh Pandit and he worked on quite a few of them and has pushed updates. I was hoping to join him but didn’t find the time at the end. In Fedora, we have a security team from Red Hat montoring issues and filing bug reports but there isn’t a organized community resolving them and I hope we get that problem fixed soon as the current situation isn’t ideal at all. If the maintainers are busy or have orphaned their packages or bugs fall through the cracks somehow, we need to handle them. A SIG focussing on it would be very helpful.
Day 2, Fedora as upstream for OLPC
Sayamindu’s talk on OLPC as downstream for Fedora was the highlight of the second day. Saymandu has been working fulltime on OLPC for quite sometime now and his moving from there soon. Since he wanted to talk about some of the issues that he would like to see addressed, I took notes using gnote. Kushal Das was working with Sayamindu the couple of days and has a blog post on what they did, including a link to the video of the talk here. I will provide my summary:
He began by introducing himself and noting that OLPC is the largest downstream of Fedora with atleast a couple of million deployments all over the world. OLPC stays as close to Fedora as possible to avoid maintanence burden. OLPC moves slowly even though they need to work with the latest software and hence RHEL/CentOS is not a option and they did experimental but found out that it didn’t work for them. They only maintain a couple of packages with a few patches that hasn’t been merged into Fedora yet into a seperate repository and push everything else into Fedora and have commit access for the packages they care about. They do regular builds combining these two repositories whenever it is needed. When OLPC folks want to push builds and push updates via bodhi, there is a delay before it hits the repository. They currently workaround that by taking scratch builds and shoving them into their own repo and start doing builds and that sometimes means that they don’t followup on the updates they are trying to push. OLPC would like the bodhi delays to be short to avoid this problem. Modularized kicstarts is a desirable feature since they are currently using shell scripts and %include to deal with it. They would also like to decouple translation updates from software builds with some modularity via language packs similar to KDE, Firefox or Openoffice.org and unlike GNOME or even Sugar. Ubuntu uses a glibc hack which Saymindu looked into and found ugly and Ubuntu’s translation system is “broken” even though they won’t admit it he says. There is currently no good solution for this problem for OLPC. OLPC would also like to specify a specific version in kickstart for handling xboard-config updates. Post deployments updates like Fedora are not really feasible for OLPC. They tend to move slow and incrementally and hence they are very conservative about updates. If updates cause problems in a build, it is a major issue even if Fedora fixes it quickly subsequently. He indicated that this as not a problem as such but just something different about their process. He concluded by saying that Fedora is the best possible upstream for OLPC but some of the warts would be nice to see fixed. I followed up by a few questions and suggestions noting that the release engineering team would likely be glad to help from anyone in OLPC willing to sign the updates they care about and there has been steps taken to reduce the bodhi delays including auto-signing updates. For modularized kickstart files, I pointed out the spin-kickstarts repository as a example to emulate and suggested that they followup with Chris Lumens on any particular kickstart features they might need. I also pointed out Fedora’s auto-qa efforts to improve stability of updates and avoiding regressions.
I dabbled a bit with additional package reviews for the second day and helped Shrink get started with packaging Sup, a mail client written in Ruby which requires a few additional Ruby modules to be submitted as review requests as well. Shrink is a big fan of Sup and has some personal motivation in doing it. He has made some considerable progress already and has started getting responses to his review requests so I hope to see Sup in the Fedora repo soon.
We had a discussion at the end of the day about what we needed to do better for the next FAD. We had consensus that a more detailed agenda would be better and we should do followups online on a regular basis. Overall Fedora contributors in India thought it was more interesting and effective to collaborate face to face to get things done or even poke fun at each other! We also discussed for sometime on having a FUDCon next year. I will post updates on that when we have some concrete plans. There is a lot more to tell of course since we had a lot more participants and I haven’t covered everything that happened but I will let the enterprising individuals detail their experiences on their own:-) I hope everyone found the event as engaging as I did and look forward to more of these in the future.
GNUnify 2010 and Fedora
Notes for self:
* Keep the talks generic and have a good number of slides. Show demos if possible of tech features. Remember that much of the audience is students especially if you are a alloted a morning slot.
* Packaging workshop requires a simple clean example, slides with few points describing which channel to login, which packages to install etc. Random fonts are not necessarily easy to package or get started with
* Spin or remix demos require a offline repository with group information (comps) and createrepo with –update argument is very useful when package content in a repo hasn’t changed or changed much.
* Give away goodies to attract the audience. Going from there to getting contributors is a tough deal. Live with it.
* Everything must be simple and straight forward.
Transmission changes in Rawhide
I had pushed the latest development release, Transmission 1.80 Beta 4 in Rawhide a few days earlier but the next update is going to bring in some substantial changes in packaging. Transmission originally had a GTK interface and a while later, a command line version as well. Recent upstream releases includes a Qt interface which is tagged as Beta and never built in the Fedora package before of relative immaturity of it. A recent RFE filed by a user asked for the command line version to split up so that it can be installed on servers or other constrained environments where pulling in GTK and other dependencies are not wanted.
I took the opportunity to consult with upstream on the Qt interface. Charles Kerr who is a active upstream developer and frequent commenter in Red Hat Bugzilla claimed that the Qt interface was now good enough to be made available to more users for feedback. It took a lot more interactions and iterations than I originally thought but the next rawhide push should bring it split up packages for Transmission. The build is available here.
Transmission is now a meta package that pulls in -gtk and -cli to maintain status quo for users updating from previous releases. The -qt sub package is useful for KDE users. The -daemon sub package is for users wanting to run just the daemon with the minimal amount of dependencies and -common pulls in the web UI parts. icons and transmission-remote command for administration. Appropriate changes have been made in comps for package groups. Have fun.
KDE in Linux distributions
KDE in Linux distributions tend to be always a emotional topic to KDE fans for some reasons The recent openSUSE controversy is fresh in everyone’s minds but a long time before, there was a enormous revolt against UserLinux because it said that they will just ship with GNOME. UserLinux wanted to just streamline the distribution heavily and pick one default covering specific functionality. The choices were debated extensively and none of them came out to be as controverisal as the decision to pick a default desktop environment even though the decisions were explained in length. UserLinux is dead and burried. All that revolt served absolutely no real purpose at all.
Ubuntu was explained in a Linux conference by Jeff Waugh a while back when he was a Canonical employee and one of the very initial whiteboards on their brain storming process explained the goals and one of them that stood out to me was “To be a better Fedora than Fedora” and Ubuntu did learn a lot from the Fedora process on what to do and what not to do. The time based release process and not to screw up the initial launch for example. However perhaps they also did learn extensively from UserLinux. They positioned Ubuntu to do a lot of what UserLinux had originally planned to do. One item for each functionality, a wide support marketplace and so on. Because they understood the leaving out KDE from Ubuntu would be a contoversial move, they decided to go with completely separate branding for each of their variants – Kubuntu, Xubuntu etc. This move has its own advantages but it results in asymmetric branding. Ubuntu is both the project as well as the default distribution while others are alternatives. The problem doesn’t end there though. They vehemently deny it but Kubuntu really is just Ubuntu with KDE swapped for GNOME. In other words, Kubuntu is a KDE Spin of Ubuntu.
In a recent article about Kubuntu, it was criticized as going on a downward spiral. I don’t agree with many of the criticisms, especially the claims that additional sauce on top of vanilla KDE is really necessary including patches or different branding. People really need get rid of that notion that staying close to upstream is a bad idea. It dosn’t mean you need to go blindly with whatever upstream provides but if upstream does provide a good theme, it is ok to just stick to that. Fedora includes GNOME by default but has switched but custom Nodoka theme to just vanilla upstream Clearlooks theme and GNOME support in Fedora remains top notch as it has been in the past. Among the mainstream distributions, it makes Fedora still stand out nicely because everyone else is shipping a custom theme! The response from Jonathan Riddell, lead developer of Kubuntu on the wireless situation is extremely puzzling to me:
“Kubuntu is a KDE distribution, we use only KDE and are the only major distribution to do so. This means when KDE misses something we do too, we can only ship with what exists. Unforunately when Jaunty released there was no good KDE network manager. That hurts but there wasn’t any better KDE choice. ”
With all due respect, I have heard similar arguments before and that’s pure unadultered nonsense.. If you install ubuntu-desktop metapackage in Kubuntu, your OS gets converted from Kubuntu operating system to Ubuntu operating system? No, not really. It is just the same operating system and distribution with a different desktop environment. Pretending that Kubuntu is a separate operating system or distribution really is painting yourself into a corner and being religious about it means that you ship a really broken native client as opposed to just including nm-applet which works better than the KDE plasmoid at the moment. Sure, it lacks nice integration with KDE Wallet etc but why pretend there is no alternative at all? Fedora KDE Spin has included nm-applet for sometime and has far less complaints about breakage. Sure, KDE in Fedora is no perfect desktop environment either but a community should be willing to make compromises and use the best of what it is available instead of knowing shipping a broken default. Shipping GNOME or GTK software in KDE oriented Live CD is just fine when it is the better choice. I am not contributing to KDE in Fedora but I am really happy Fedora KDE team is willing to make pragmatic choices such as this.
Stop screwing around with updates
If you have been a Fedora 11 Thunderbird user, the last update was likely to cause you some confusion. Two primary things:
* Smart folders
* Global indexing
While these are useful features, pushing them as an update was a really bad idea. These features should have been disabled by default in an update. The first feature rearranged my folders. Suddenly my Inbox had moved from where I expected it to some place else completely. It can be disabled by the really tiny arrow marks on top. The second feature of course sucked up CPU trying to index gigabytes of my mail while I was waiting around trying to send a urgent email. Again, this feature too can be disabled in the UI.
Maintainers should really think about whether they want to push a beta release of any software into a stable release of Fedora. If the advantages are really prominent, take extra care before pushing any updates. Think about whether the update is really necessary. If so. one week time in Fedora updates-testing is just not enough to get enough feedback on this.
While I have started running Rawhide primarily and can cope with this problem, this is not an acceptable way to treat our end users. If you are a Fedora user, I appreciate you letting us know your feedback.
Preventing dependency breakage – Part II
My previous post has generated a bunch of discussions and I think it is worthwhile highlighting what I believe is the way to mitigate this and answer some of the concerns. I am using a FAQ form for this:
Who is responsible for the dependency problems?
The individual package maintainers are responsible for the packages they maintain and release engineering, QA team and others share the burden on finding a good solution to the overall problem. To be fair to package maintainers (I am one of them), maintaining three or four different branches (Fedora 13 – 10 at this point) for multiple architectures is not easy. A lot of maintainers do maintain more than one package and this means that we cannot expect the individual maintainers to do a perfect job. It is currently very easy to break the repository by a unintentional push as has happened over and over again including very recently.
What about a security update that breaks some dependencies. Isn’t fixing the security hole more important?
Not really. Yum’s current default behavior is to bail out if there are multiple updates and some of them have dependency issues. If you truely want users to benefit, fix the dependency issues before pushing the update. No exceptions.
Is anyone finding a solution?
Indeed. The AutoQA project from the Fedora QA team has been busy at work and one of the things would be to check for dependencies automatically. This should help us avoid pushing updates with dependency issues.
So just sit tight?
You can be patient or contribute to the AutoQA project but I think the short term way to mitigate this problem is by setting the skip-broken=1 option in /etc/yum.conf.
Interesting. What does that do?
It skips the packages that has dependency problems and updates the rest. You can either do yum update –skip-broken or set it permanently in /etc/yum.conf.
Sounds wonderful. Why are we not taking advantage of this already?
We are… to some extend. PackageKit already set this value in the yum backend it is using and users who use PackageKit (via one of its frontends) should not be seeing as many dependency breakages.
A lot of users however continue to use yum on the command line and these include non-power users on the desktop. Ideally, the graphical interfaces would solve all the desktop users needs and we don’t have to worry about command line users much but we are not there yet.
Why didn’t yum have this option set by default before? What are the downsides?
When skip-broken was first introduced it didn’t help skip many of the dependency problems. Over a period of time it has improved considerably. It is not perfect yet since there are a bunch of issues that you cannot easily detect beforehand. For example, file conflicts between packages across multiple repositories including third party ones. However setting it by default would help things considerably.
Another concern is that setting the skip-broken option by default would mask the dependency issues and users wouldn’t realize they are missing out potentially important updates. They wouldn’t report bugs and hence maintainers wouldn’t fix them soon. This was a valid point of view and one that I agreed with but yum in later revisions does list all the packages that are being skipped due to dependency issues if you use the skip-broken option.
What about system administrators who want to be informed of the dependency problems? How would they be aware of it?
If a sys admin is managing multiple systems, a test system can be used. There are tools to check the repository state and updates can be pushed directly using management tools like Spacewalk.
How will maintainers be aware?
In many cases, they get automated emails informing them of the problem already. However if you run across dependency issues in the Fedora repository, please take a moment to report them so that maintainers are aware.
You can do that via http://bugz.fedoraproject.org/ or add a comment to that update at http://admin.fedoraproject.org/updates
Why don’t you just document this option and be done with it?
That is already done but it doesn’t help much. Most users don’t read documentation. I have spend a lot of time on documentation, far more so than your average Fedora contributor and my experience is that users don’t read documentation much, if at all. The only reason I did contribute is because it is easier to document and point users to the link rather than repeat myself all the time.
If the software can be tweaked to provide a better out of the box experience, that is always going to be a far more superior solution than documenting workarounds.
Should yum set skip-broken by default now?
I believe so, yes. It is the decision of yum developers however and if they disagree that this should be the default, it would be good to understand why.
Meanwhile, I recommend users set this value and continue to report dependency issues. I will update this FAQ if there are more unanswered questions on this topic.
Preventing dependency breakage
Fedora has a increasingly large number of software packages.
# yum repolist
Loaded plugins: presto, refresh-packagekit, remove-with-leaves
repo id repo name status
livna rpm.livna.org for 11.91 – i386 enabled: 3
rawhide Fedora – Rawhide – Developmental packa enabled: 15,078
rpmfusion-free-rawhide RPM Fusion for Fedora Rawhide – Free enabled: 469
rpmfusion-nonfree-rawhide RPM Fusion for Fedora Rawhide – Nonfre enabled: 122
repolist: 15,672
That’s a impressive number of packages and growing at a very fast rate. Good news for everyone. However dependency breakage is not that uncommon.
http://mso-chronicles.blogspot.com/2009/09/broken-deps-libassso3.html
That’s not good news for anyone. It reduces trust in the Fedora Project and people blame the maintainers or even worse, they blame yum for it. It is not reasonable to expect maintainers to do a perfect job. We really need to ensure that absolutely no packages get pushed out without a basic dependency check. It does not matter whether it is a security update. It does not matter that it will take a few hours or even a day more. I don’t want to see another dependency breakage when using the official Fedora repositories. Never again.
mether's Fedora Blog 