Growth of Fedora Repository Has Almost Stalled

9 Comments

I went across statistics from Fedora Package Database and what caught my attention is that the increase of number of packages in the official Fedora repository has almost stalled:

fedora-number-of-packagesThe number of packages in Fedora 22 is 17021 and is not going much since Fedora 20. Does it mean there are no more projects worth packaging? I don’t think so. The number of open source projects goes up like never before, just look at GitHub.

I think this trend is related to the growth of Copr. The number of projects has been rising exponentially there. Mirek Suchý reported a couple of months ago that the number of projects in Copr was almost 3000 and almost 2000 were active. And the numbers have increased significantly since then.

It’s actually a success. It means we have achieved what we outlined in the Fedora.Next plans: we’ve built a ring of software around Fedora which has low barriers to entry for packagers and where software is easy to install for users. Although the number of packages in the official repositories is not growing like in the past the total amount of software available to Fedora users has grown like never before. That’s great.

What we’re still failing at a bit is how to build on this and bring the best of Copr to official Fedora repositories and convert the most promising Copr packagers into Fedora packagers. The official repositories still have their relevance. The quality of packages there is significantly higher than in Copr. We should encourage Copr packagers to work on their packages to meet Fedora standards and become Fedora packagers. We should show them the path. I can imagine that we offer an option in Copr to run the source packages against fedora-review to give the packager a hint what needs to be done to meet the official repository standards and if he/she is interested we can point him/her to documentation for the rest of the process.

The current situation is a great opportunity if we streamline the path to quality. Then Copr can serve as a broad source of “playground” software from which useful and proven projects can get deserved quality of integration and make it to the official repositories. But it’s also a threat because if we don’t provide a path and encourage Copr packagers they may just be satisfied with the easy way to make and maintain packages in Copr and no one will want to package software for the official repositories any more.

Chrome and missing key

Leave a comment

Are you using Chrome in Fedora? You might have noticed messages about a missing public key and you may have encountered problems with updating the application. That’s because Google fails to provide the public key for the Chrome RPM package. It’s become a serious problem in Fedora 22 where it aborts the update process completely and the package can’t be updated. The most convenient solution for users would be importing they key while installing the package, but some argue that an RPM should never automatically import keys.

Another solution is to simply add the following line to the repo file that the installation creates:

gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

And you’ll be asked to confirm the key import during the next updating. This solution is a one-liner. It was reported to Google 10 months ago and the problem has not been fixed yet. This a bright example of problems with using proprietary software. You’re completely dependent on the vendor and on their will to solve your problems. Fedora developers are sometimes accused of not caring about how proprietary software runs on Fedora. At least here in the desktop team, we do care because we care about the experience our users have using Fedora. But in most cases including this one, we just can’t do anything. I can only advise you to import the key manually to get rid of the problems:

sudo rpm --import https://dl-ssl.google.com/linux/linux_signing_key.pub

FUDCon APAC 2015 in Pune

1 Comment

I had the pleasure to attend my second FUDCon APAC, in Pune, India this time. I arrived the day before the conference at the airport in Bombay where I met Tuan. After four tiring hours, we arrived to Pune and met Kushal.

My contribution to the conference was a keynote on Fedora Workstation. I found out just a couple of days before the conference that my talk had been selected as a keynote. That is why I changed my presentation last minute, I removed slides with technical details, so that it’s understandable for general audience. I also didn’t speak about Fedora Workstation specifically, but about (Linux) desktop problems in general and how we’re trying to solve them in Fedora Workstation. I think the talk went pretty well and received a lot of questions in Q&A at the end of the keynote and later during hallway conversations. The most frequent complaint of users was lack of multimedia support, so I added it to my presentation, and explained that it’s not really a technical issue, and that we’re working hard to make it better, and that we might see a significant improvement in Fedora 23.

Me giving the keynote, photo is courtesy of Kushal Das.

Me giving the keynote, photo is courtesy of Kushal Das.

I also really enjoyed other keynotes, especially the one by Tenzin Chokden who has worked on adding Tibetan translations to Fedora.

I also achieved other things:

  • participated in the discussion about the location for the next FUDCon APAC.
  • shared with APAC ambassadors what is our system for swag production and distribution in EMEA.
  • attended a key-signing party and got my GPG key signed by Harris Pillay, Dennis Gilmore, Jared Smith and others.
  • met a lot of Fedora contributors from India and people from Pune office of Red Hat.
  • agreed with Ryan Lerch that we would create a repository of artworks for Fedora swag production (yay!)

I’m staying in India for a few more days. I and Dennis Gilmore went to the historical center of Pune on Monday and to highlands near Pune yesterday.

I’d like to thank Fedora Project for providing me with accommodation during the conference and taking care of me (it was my first conference where they arranged a pick-up at the airport for me!). My big thanks go to the whole organizing team and especially Kushal who has been a great host to us.

I’ve moved from Google back to Jabber

8 Comments

Yesterday I finally did what I had been planning for some time – moved from Google (Talk) back to Jabber. I started using Gtalk many years ago because at that time it was the most reliable XMPP service around and it had online history.

But Google has moved to closed Hangouts and recently announced that they would discontinue the XMPP compatibility. It hasn’t taken place yet, but the compatibility is getting worse and worse. I can’t add contacts from other Jabber servers, don’t receive their requests. If they send me a message, it’s not delivered to the mobile app etc. I have had enough.

Because I’m running Google services on my own domain, the move was pretty simple. I just changed DNS records and moved my contact list. I sometimes really regret that Jabber has not been widely adopted. I really love the idea of just moving your account to a different provider if you’re not satisfied with the current one. Almost zero vendor lockin. If I disappeared from your contact list, you may need to add me again. My account is jiri [] eischmann [] cz. It’s hosted by my friend who runs aerohosting.cz and offers Jabber as an additional service as well as e.g. OwnCloud.

Although I use Jabber, I really like Telegram and I now consider it as my primary instant messaging. It’s the only service from the new wave of IM networks which has a fully open protocol and it’s pretty secure. And I do think it’s also in other aspects better than other IMs such as Messenger, Hangouts, or Whatsapp.

I have also been planning to move my email from Gmail. It won’t be so simple there because I’ve got two more accounts there. I will have to move tens of thousands of emails, and I also will have to disable the accounts somehow internally because otherwise Gmail would keep delivering emails to my old account, I suppose.

Time to revisit how we’re doing updates?

4 Comments

Fedora 22 is out and it’s again the most quality release we’ve ever released. Our quality assurance is improving and on the developer side, we’re also trying to do our best heavily using ABRT retrace server to prioritize bugs that affect many users. Unfortunately while the quality of releases itself is improving, the quality of updates that follow the release is not.

There are still too many regressions. I’ve installed Fedora on computers of my relatives and they’re happy with it, but sadly I can’t let them do updates themselves because there is still a high risk that they might end up with a broken system. I update their systems myself and always check whether everything is working when I pay them a visit. If we want to attract a larger user base, average users can’t be afraid to update their systems.

IMHO our current updates setup doesn’t ensure the required quality. It’s pretty much a “one-size-fits-all” approach. The kernel, the most critical part of the system, needs the same number of + karmas as some small unimportant, self-contained utility. Updates of critical components get to users too quickly without much of testing. I’ve got updates-testing repo enabled, but whenever I find a (critical) regression it’s very often too late because the update already got +3 karma and made it to the stable updates. Yeah, I already have the “Missed the train” badge :)

While Bodhi is too fast for standard updates, it’s too slow for critical security fixes. Especially in older supported releases (F20 now). There are not many testers willing to test updates there. The active community are usually early adopters who jump on new releases early and a several-month-old release is history to them. Then security updates just get stuck in Bodhi waiting for stable karmas.

What to do with it? I truly believe we need batch updates. One pack of updates, say, once a month. We would collect updates in updates-testing for 3-4 weeks, then freeze it for a week, so that even the latest updates have some time to be properly tested (I can imagine the pack of updates gets some more structured testing like our releases do for example). This way, individual updates would get much more time to be tested and the monthly update could be tested as a whole. I believe it would improve the quality of updates and users would not be under the fire of updates (it’s actually one of frequent complaints that there are too many updates in Fedora).

I don’t see a lot of downsides there. Who’d like to get updates as soon as possible could still enable updates-testing. This actually could build an even bigger community of update testers which would again help improve the quality of updates.

Any security updates? It’s clear that they can’t wait for a month to reach the users. They will need their own process. But I think it’s clearer and clearer that they will need their own process in the current setup as well. Maybe pulling in the security team which would evaluate proposed security updates and if they approve them as critical they will get into some fast track?

I’m going to FUDCon APAC 2015!

Leave a comment

Last year, I was really impressed by the level of organization and atmosphere at FUDCon APAC that took place in Beijing, China which is why I decided to submit a talk for FUDCon APAC 2015, which is going to take place in Pune, India. And guess what! My talk was accepted!

I named the talk “Present and Future of Fedora Workstation”. I’m now part of the Red Hat desktop team and we have a lot of interesting stuff that has made it to F22 and even more interesting stuff that is planned for F23. So I’ll talk about all the goodness that is changing Fedora Workstation into the best desktop system for active and creative users (developers, writers, designers,…).

I’m arriving to Mumbai at 8:35am on June 25th. I’ve seen that some people have arrivals around that time, too. It’d be great to organize transportation to Pune together. After FUDCon, I’m taking a week of holidays and would like to check interesting places around, hope to see e.g. Goa before the proper rain season starts. India will be my 50th visited country and I’m looking forward to it.

See you in Pune!

Automatic Problem Reporting in F22

4 Comments

I regularly go through most frequent problems reported to ABRT retrace server because it helps me prioritize bugs in Fedora that are assigned to my team. I think ABRT service is great for developers to prioritize their bugs + it helps collect much more data about the crash than an average user normally provides.

However,I’ve noticed a significant drop in number of reports in Fedora 22. It’s just two weeks before the final release when many early adopters are already running F22, but the difference in number of reports from F21 and F22 is huge: 64373:904.

12 days before F21 was released, we collected 16081 reports from this version. That’s almost 18x more. I don’t think we’re experiencing such a huge drop in adoption, so I investigated more…

…and learned that GNOME Control Center got a new privacy setting in F22: Problem reporting. And if you upgrade from Fedora 21 automatic crash reporting is disabled even though you had it enabled before the upgrade. To make it even more confusing if you go ABRT settings automatic reporting is enabled there. That’s because the setting in GNOME Control Center serves as a master setting that overrides settings in ABRT. So if you have upgraded to F22 and want to provide developers with very valuable data, please go to Control Center->Privacy->Problem Reporting and enable automatic reporting. Manual reporting is still possible from the ABRT app.

The ABRT team is working on a fix for this.

If you do a fresh installation, you should be able to allow automatic reporting in the Initial Experience after installation.

Older Entries

Follow

Get every new post delivered to your Inbox.

Join 32 other followers