Aurora goes Firefox Developer Edition

Mozilla announced a few days ago a new flavour of the Firefox browser called Firefox Developer Edition. This new Firefox edition is in fact replacing the previous Aurora version. Just to add some background how it was structured until a few days ago:

  • Nightly – nightly builds of mozilla-central which is basically Mozilla’s HEAD
  • Aurora – regular builds published for openSUSE under mozilla:alpha
  • Beta – weekly builds for openSUSE under mozilla:beta
  • Release – full stable public releases as shipped as end user product for openSUSE under mozilla and in Factory/Tumbleweed

There is a 6 weeks cycle where the codebase goes from Nightly to Aurora to Beta to Release while it stabilizes.

Now as Aurora is replaced to be Firefox Developer Edition I am also changing the way how to deliver those to openSUSE users:

  • Nightly – there are no RPMs provided. People who want to run it can/should grab an upstream tarball
  • Firefox Developer Edition – now available as package firefox-dev-edition from the mozilla repository
  • Beta – no changes, available (as long time permits) from mozilla:beta
  • Release – no changes, available in mozilla and submitted to openSUSE Factory / Tumbleweed

A few more notes on the Firefox Developer Edition RPMs for openSUSE:

  • it’s brand new so please send me feedback about packaging issues
  • it can be installed in parallel to Release or Beta and is started as firefox-dev and is using a different profile unless you change that default; therefore it can even run in parallel with regular Firefox
  • it carries most of the openSUSE specific patches (including KDE integration)
  • it currently has NO branding packages and therefore does not use exactly the same preferences as the openSUSE provided Firefox so it behaves like Firefox when installed with MozillaFirefox-branding-upstream

openSUSE 11.4 has reached end of Evergreen support

I have posted the following to the openSUSE lists a few moments ago:

as you probably know our initial commitment to support 11.4 within
Evergreen was until July 2014.

While I was hoping that we can keep 11.4 alive for some time longer this
is currently not possible from what I would call the "core team" which
is Stefan and myself. We are too busy nowadays to be able to scan and
patch every issue we get aware of.

Thanks to you all who contributed to the success of Evergreen/11.4!

The important message is:

   openSUSE 11.4 Evergreen is not actively maintained anymore!

So if you can, we recommend to switch to openSUSE 13.1 as soon as
possible which is still planned to be an Evergreen release.

Some more details below:
The repository already got and will most likely get more updates from
package maintainers who care about 11.4 and/or their packages though.
You noticed that with recent releases of patches for the bash and NSS
issues already, BUT this is _no_ guarantee that every security issue
will be fixed.
We will accept contributions from anyone though and I will try to take
care about "my" packages.

Some numbers from 11.4 Evergreen (as far as I was able to get them easily):

Evergreen lifetime: 21 months
11.4 overall lifetime (incl. Evergreen): 41 months / 3 years 5 months

Evergreen lifetime numbers (w/o official maintenance period):
Released update source packages: 804
Unique touched source packages:  177
rough number of patches (based on incident counter): 320

Let me also quote Marcus' numbers from official maintenance lifetime:

Total updates: 723
	Security:    416
	Recommended: 306
	Optional:      1

openSUSE Conference 2012

Finally got around to find time to write a bit about my attendance of the openSUSE Conference 2012 in Prague.

Overall I found it a quite successful event even when I could think of a few improvements for next time.  I’ve attended quite some talks during the days and also helped recording some of them. But to me the most important thing was to meet and talk to people. Since openSUSE 11.4 is going to go Evergreen very soon there were quite some discussions including two related BOFs and a maintenance hands-on with Marcus from the SUSE Maintenance team as we are planning to use OBS’ maintenance features for the upcoming 11.4.

What I missed was a bit more space to meet and hack a bit. Both venues were a bit short on seats outside of the talks or BOF rooms. But congratulations for a pretty stable wifi network during the conference. I missed it at the hotel though 😉

Apart from that I’ve met some new (to me) people and missed some other community members including some from the board which is a bit unfortunate for the main community event but still there were many good conversations.

Special thanks to Petr from SUSE showing us the city and helping me to find my hotel when I arrived (and everything else) and also the openSUSE travel support program which was sponsoring my travel to the conference.

I’m looking forward to next year’s conference and hope I can attend there as well again.


ESR and Thunderbird under KDE

A quick update about recent changes in Mozilla applications for openSUSE.

With the release of Firefox and Thunderbird 11 (and Seamonkey 2.8) the older versions (10) got obsolete as always. But Mozilla created ESR (Extended Support Release) for Firefox and Thunderbird based on versions 10 and will maintain them for a longer time. Please read the FAQ about the details. For openSUSE we will not switch to these versions for different reasons but I’ll provide these from the buildservice repository mozilla. You should be able to install the current versions (10.0.3) of Firefox and Thunderbird by choosing firefox-esr or thunderbird-esr (there is also xulrunner-esr) in your package manager if you added that repository before. Please note that this is opt-in only and it’s not possible to install latest normal version and ESR versions in parallel. They are using the same profile directory and therefore I didn’t give them a separate installation directory neither. It’s also a bit risky to jump between ESR and normal versions because of the profile. So as normal version gets higher every six weeks the riskier to jump back and forth. Basically those ESR versions should probably be used only if really necessary but I still wanted to provide that possibility. If you install the ESR versions and found issues please let me know. Because of the renaming and parallel usage of the branding packages I might have missed some packaging foo to make updates in every case smooth.

A similar topic is about Firefox 3.6 and Thunderbird 3.1. The latest round of updates (3.6.28 / 3.1.20) was most likely the last one and people should start switching to more recent versions. That also means that 11.4 will get Thunderbird 12 as replacement for 3.1.20 with the next round. Other versions are already on the latest packages. (Evergreen will likely switch to the ESR versions btw.)

And about the last announcement (from my “quick update”) people might notice that Thunderbird 11 now got at least some of the KDE integration from Firefox as people kept pinging me about it. (And Firefox’ KDE integration is also back for the official updates!)


Mozilla based web authoring applications

I’m not a web designer really but I happen to be kind of responsible for packaging two web authoring applications in openSUSE which are SeaMonkey’s Composer and KompoZer. While the SeaMonkey integrated editor is somewhat limited (AFAIK) KompoZer (which was forked from Nvu at some point) has more advanced features. But KompoZer development seems to be pretty slow and it misses quite some of the new web stuff which is around nowadays. In addition the current version is BETA for quite some time now and seems to have a major issue in openSUSE 11.4 and 12.1.

Because of that I finally had a look at BlueGriffon (written by the same developer as the Netscape/Mozilla/SeaMonkey Composer and Nvu) as it seems to be in active development and supports quite some of the new HTML5 and CSS3 stuff and created an initial openSUSE package available in the mozilla OBS repository for testing now. There is also an openSUSE feature request to make it available.  If you are a web developer or already know BlueGriffon please give the package a try and send your feedback.

My plan for the openSUSE distribution would be to keep SeaMonkey’s Composer (basically anyway because it’s a part of SeaMonkey which is to stay), add BlueGriffon and drop KompoZer. If you see a reason why that might be a bad idea based on your experience as a web authoring application user please let me know.

Looking forward to your feedback!


Evergreen project status update

I guess it’s time for another Evergreen status update.

I cannot tell much about 11.2 (but as far as I can see Stefan does an awesome job in maintaining it) but will share my thoughts about the 11.1 flavour of Evergreen.

When I started that project it was clearly an experiment as I haven’t had an idea how much work it would be and if people would use it or even help with it. Looking back at what we’ve created it finally is more than I expected. Compared to what I announced in the beginning it was almost possible to maintain every part of the distribution and not only server packages. There are things which turned out be quite hard (e.g. kernel) but overall most issues were covered for 11.1. I think what I was able to prove is that it’s possible to somehow maintain a distribution  with very few manpower.

Now as 11.1 is nearing its 3rd birthday on December, 18th and given the fact that it’s getting harder having stuff updated while still being more or less compatible and stable I found that I cannot keep the pace with my limited spare time and without neglecting my other volunteer projects (remember Mozilla’s rapid release cycle?). For that reason I’m announcing that I’ll step back from being the Evergreen/11.1 project leader by end of this year. As of now noone else has stepped up so I need to announce that 11.1 will most likely be unmaintained as of end of this year. This does not affect 11.2 and I’ll also try to keep my packages updated for maintained Evergreen projects in the future. I’ll also stay involved and help out with organizational and administrative stuff where needed.

It’s still possible to step up taking over the 11.1 maintenance but in the end I think 3 years is already a good timeframe for a community distribution.

I hope that I find a bit of time in december to post a (statistical) summary about Evergreen/11.1 to let you know about some details.

Thanks for your support during the last year!


on Macaw, Aurora, and Miramar

With Firefox 4 released a few weeks ago it’s time for me to look into what comes next.

The first to follow are maintenance updates for Firefox 4 which are now codenamed Macaw. 4.0.1 is in upstream beta testing for a few days now. At some point in future we will have a SeaMonkey 2.1 release which will  be (most likely) based on the same Gecko version as Firefox 4 and you can get 2.1b3 snapshots for that from mozilla:beta. From the same repository you can also install a new Thunderbird 3.3a4 (codename Miramar). Please note that this early package has no Enigmail support yet.

Now to some interesting changes which are coming up with Firefox development and releases. Mozilla switched to a “rapid release cycle” after the release of FF4. This means that we will see new Firefox major releases around every 6 weeks. Firefox 5 is currently planned for end of June 2011. Firefox now is developed through different stages before the final release where Aurora is branched already for FF5 and will enter the beta stage in a few weeks. A current Firefox Aurora build is available in mozilla:alpha.

This changed release process also means that there won’t be long maintained branches anymore which has an impact on how we deal with updates during a distribution lifetime. Nothing has been discussed on that topic yet though. Another fallout is that our Firefox packages will be standalone packages again after several years of being based on XULRunner. What will happen to XULRunner in the distribution is yet another thing we need to figure out.


Evergreen status after some months

I’ve just noticed that I haven’t written about Evergreen here since the beginning. I actually did post at least one status update on our list but I think it would be good to give some information to a wider audience (hoping that this blog is read by more people).

In general we are in good shape. Up to now we have released around 55 source updates. You can find the list here. So looking back that means that we were able to update almost everything including desktop applications which was not clear in the beginning how that would work out. Also the Packman team decided to support Evergreen by keeping the Essentials repository available. Unfortunately it is not quite usable at the moment since it contains RPM packages signed with keys not supported by the RPM version in 11.1 which means zypper refuses to install those.

Another milestone is that it seems we will also support 11.2 when it runs out of Novell’s maintenance on May 12th, 2011. Another community member agreed to  lead the effort. More details on that to come soon.

But not everything is working perfectly fine though. Besides some rare cases where community members submitted packages to Evergreen/11.1 all the backporting/packaging work up to now was done by myself. At some points in time I was quite on the limit of my time for the project and there is no redundancy if something bad happens to me. We really need more people contributing to Evergreen. That said it would be really nice if maintainers (especially community maintainers) would  prepare updates for 11.1 as well. Obviously there is no obligation in doing so but I somehow think that in some cases they are just missing the fact that Evergreen exists at all.

So if anyone out there has interest in helping maintaining 11.1 and/or 11.2 please contact us through our mailinglist or contact me directly.


openSUSE project “Evergreen”

Following up on my previous blogpost I would like to give a small update on what happened so far about a longer supported (open)SUSE release.

We had a longer discussion on the mailing list if an openSLES (a’la CentOS) or “openSUSE LTS” would be the better or easier solution. There are pros and cons for both while the required infrastructure differs a lot. I’m not diving into details here though. While I would find a SLES clone appealing I’m not in the position to drive such an effort. I also do not think that having both makes sense and therefore I decided to go on with the other approach for now trying to extend the lifetime of an existing openSUSE release.

People in the community came up with the project name Evergreen and I think that matches what we try to build pretty well. I proposed to give the whole effort a trial with openSUSE 11.1 which went unsupported with the new year. At the moment we still have organizational and technical issues and most likely won’t be able to utilize all the update features (deltarpms, zypp patches) but still we will try to deliver updates from a certain update repository. Because of the holiday season we couldn’t figure out the details yet but hopefully will get it sorted out in time. Stay tuned for further detailed information here and on the mailing lists.

Please note that this effort is in experimental state still and didn’t attract that many contributors yet unfortunately. So at the moment it’s still unclear if we will be able to deliver as we would like to.

If you are interested in this project feel free to join our (current) project list.


community powered long term support for openSUSE?

Just recently I found again that openSUSE is not really positioned for some usecases. In my personal case that is especially the usage as a web/mail/dns/etc server on hosted environments. IMHO it just doesn’t make sense to roll out a distribution which is supported for only 18 months to a hosted system with limited access to it. I still have been doing that with previous openSUSE releases but it’s so annoying that I really regret it. Also the possibility to zypper dup doesn’t really fix that issue for different reasons. Anyway this post is not about whining about that fact or to explain why I don’t like to update these type of systems remotely every <= 18 months.

A possible solution?

Sometime last year there was a discussion about options for something like an “openSLE” or “openSUSE LTS” distribution. There is an external page where some outcome was documented here. The dicussions stopped mainly because of health issues of the main initiator. There was done some planning and voting on the different options but no real results ever happened (as far as I know). So I’m trying to resurrect that topic a bit once again:

The amount of work related to such a project is the critical part and therefore my proposal is to try to start off with a “lightweight” approach.

This would be something like an openSUSE LTS version. That means that the community would take over (security) maintenance after Novell as main contributor drops it out of official maintenance after around 18 months. This will likely only work for a subset of packages which were delivered with the original distribution but the focus might be on server services anyway. Using the openSUSE release which also is the base for SLE could help us a bit as the work is done anyway (some of the Novell employees who are also openSUSE community members would hopefully help us here?). There are quite some details to work out still but it could be doable.

While I think we wouldn’t need a lot of people we at least need some and the more the better.  We will bring that topic up again on opensuse-project@o.o as well. The main intention of this post is to get feedback if there is enough interest and contributors to do further planning. I’m very interested in hearing from you via comments, mailing lists or personal mail.