The 11.2 repositories are only updated with a release, so they have just been updated with the RC2 version and the next version will be to the final version.

“zypper sl -d” shows on my system these repositories – and those are the ones you should have as well if you want to update to 11.2:

# | Alias                 | Name                  | Enabled | Refresh | Priority | Type   | URI
--+-----------------------+-----------------------+---------+---------+----------+--------+----------------------------------------------------------
1 | openSUSE-11.2-Update  | openSUSE-11.2-Update  | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/11.2/
2 | openSUSE_11.2_Debug   | openSUSE 11.2 Debug   | No      | Yes     |   99     | yast2  | http://download.opensuse.org/debug/distribution/11.2/repo/oss
3 | openSUSE_11.2_Non-Oss | openSUSE 11.2 Non-Oss | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/11.2/repo/non-oss
4 | openSUSE_11.2_Oss     | openSUSE 11.2 Oss     | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/11.2/repo/oss
5 | 11.2-test-updates     | 11.2-test-updates     | No      | Yes     |   99     | rpm-md | http://download.opensuse.org/update/11.2-test/

The last repository is optional for now, once 11.2 gets released it will be used for testing of updates.

To change your repositories, you can either edit the existing ones using (as root) “yast2 repositories” or remove (with “zypper removerepo”) the Factory repositories and add the 11.2 ones with “zypper addrepo”.

Finally, just run “zypper dup” to upgrade your distro – if you run it today, it will update you to openSUSE 11.2 RC2.

Note that there are no mirrors setup for this  repository today, so update might be slow.  Once openSUSE 11.2 gets released, all mirrors will have it.

What are devel projects?

Development of the openSUSE Distribution is done using a development project that we call “openSUSE Factory” or factory for short.  At one point during the development of a distribution, the new release is branched from factory and then development of factory is done for the next release.

Factory in the openSUSE Build Service has its own project called “openSUSE:Factory” which is a huge repository of packages.

Development of packages does not happen directly in openSUSE:Factory but in development projects (short form “devel projects”), so we have basically split factory development into devel projects and organized these many by topic areas, such as KDE, GNOME, Education, Java, and so on.

Devel projects are responsible for sets of packages and will be able to organize themselves rather than following a top-down model of management.

The idea is to allow teams to be self-organizing and for all contributors to have equal footing in terms of being able to contribute to openSUSE Factory.

The devel project allows people to develop in their own home projects on the package, submit the changes to the devel project, review it and then submit the package to openSUSE Factory where it gets reviewed by the owner of factory for some general packaging guidelines.

What are the advantages of devel projects?

• It allows development of related packages together.
• Breakage caused by one package can be seen already in the devel project.
• Since submission goes through the devel project, the maintainer of the devel project does an additional review of the package and knows about changes in his package before checkin to openSUSE:Factory.
• The split into several devel projects allows development to scale better since development work can happen independently in smaller teams.
• It’s easy to make the same package available for older distributions since the devel project contains related packages.
• The devel project information is also kind of a trust information, it points to projects which have been evaluated once as good enough for openSUSE distro contributions.

Some more information is available at the openSUSE Wiki.

Contribution

Let’s compare contribution with Open Source code developments:

In open source packages anybody can send in a patch – for openSUSE we prefer the patch in form of a package submission to the devel project.

Once you gain trust in an open source project, you get write access to a certain area of the project – with openSUSE you can get package ownership in the devel project or even made responsible for the whole devel project.

Communication

Devel projects are setup to enable collaboration on packages, therefore communication with others and means of communication are vital.

So, a good practice is to have for each devel project a mailing list, IRC channel etc where people can discuss the project and to point in the description of the project in the Build Service to this mailing list, IRC channel etc. If you need an openSUSE mailing list for your project, please talk to ml-admin@opensuse.org.

New Scheduler

The role of the scheduler is to get informed about package build changes, about package build changes, e.g. source changes or some build is finished and succeeded and then decide which packages need to be rebuilt because of those changes.

Michael Schröder integrated the SAT solver code into the build service scheduler.  The SAT solver code is used in our package management as well and helps with fast decision making and reduces memory footprint as well.

Parts of the scheduler itself are more than 100 times faster which results in some operations being more than 10 times faster now.  We have almost no queue of high or medium priority events anymore, so you should not see anymore a process for ages in the state finished.
However, this is pretty much new code, please report behavior changes or problems. Changed parts are:

• package dependency expansion calculation
• package ordering
• meta file generation
• replacement of :full.cache of package meta data (perl structured) with solv files

Binary Caches for Build Clients

We have all the built packages on a central server and so far each client downloaded for each build all packages from the central server.  The server coped with it but still this produces a base load and also congests our network.  Michael has now implemented a binary cache on the worker.  In our setup we have on each client machine a couple of build worker (each in their own Xen instance) running and these worker share now a common cache of built packages.

I have no data on how much improvement it brings overall but it does show on a reduced load on the server – so that it can schedule faster – and also on far less trafic on the network.

Planned Build Improvements

Michael and Coolo consider improving the dispatcher in the near future.  The dispatcher basically decides which job runs next on which machine once.  This is at the moment a random selection of all available “scheduled” packages with some heuristics.  They plan on improving the heuristics to prioritize certain types of jobs.

If you’re interested in helping in any ways to improve the openSUSE Build Service, please join the opensuse-buildservice mailing list.

Thanks to Michael for implemting these – and for a review of this article.

Instead of the “old” but still working way of burning a media, booting from it and upgrading my system, I did the “new” way of openSUSE 11.2: Updating in place with “zypper dup”.

The basic steps are documented also on the openSUSE Wiki:

1. Adapt the repository list: I disabled all 11.1 repositories and enabled the openSUSE Factory OSS and NON-OSS reposositories using “yast repositories”
2. I run “zypper refresh” to get the local metadata and repo contents
3. I upgraded the package stack to the new version with “zypper in zypper”
4. I updated the rest of the system with “zypper dup”
5. After two hours updating – and while I could still use my system – the update was finished, I run “SuSEconfig”
6. and finally rebooted into the 11.2 system.

The upgrade gave me the following information about what it needed to do (note I used quite some openSUSE Build Service repositories that had some higher build numbers than factory has – this explains the downgrades):

1310 packages to upgrade, 173 to downgrade, 174 new, 1 to reinstall, 35 to remove, 179  to change vendor, 12 to change arch.
Overall download size: 1.42 GiB. After the operation, additional 167.5 MiB will be used.
Continue? [y/n/?] (y): y

Now I’m blogging this from my 11.2 Milestone 8 system!

Btw if you update via zypper dup, I suggest to read Michael’s post about download polices, it is possible now to download everything first – and then update the packages in one go instead of the download one package, install it, download next package way.

Update 2009-10-07: Let’s be more explicit about step 1:

1a) First disable all old repositories, either in YaST or with zypper using “zypper mr –all -d”.

1b) Then add the new repositories, in case of factory, you can do this via the following commands:

zypper ar -f http://download.opensuse.org/update/11.2/ "openSUSE 11.2 Updates"
zypper ar -f http://download.opensuse.org/factory/repo/oss/ "openSUSE Factory Oss"
zypper ar -f http://download.opensuse.org/factory/repo/non-oss/ "openSUSE Factory Non-Oss"
zypper ar -f http://download.opensuse.org/factory/repo/debug/ "openSUSE Factory Debug"

Myself: The unconference session on common desktop topics for GNOME and KDE discussed a better communication and coordination about future disruptive changes, suggested to remove noise from the mailing lists, e.g. test discussions from opensuse-factory, discussed how “osc collab” can be used by others (Vincent volunteered to enhance it so that more people can use it, just tell him), discussed some issues with the Build Service so that Adrian setup an extra session on it, talked that we miss a predictable behavior of applications on desktops and need volunteers especially with bug triage.

Pascal Bleser: Speaking with people individually was helpful.  There were two session on governance and those were productive.  It was   discussed to have escalation paths for cases of conflicts – with a last resort of having the board to facilitate and make decisions.

Bryen Yunashko learned that timezones are bad, he’s still catching up.  He took part in an accessibility session and thinks that we do not give a11y enough attention.  We need to test and make sure that the distribution is accessible.

Stephen Shaw explains that test frame works benefit from a11y and can automate testing that is currently done manually.  He found it great to work together during the conference with others, especially at the bug party and hope that we can keep up the fire.

Andrew Wafaa was glad to see GNOME and KDE guys interacting a lot – and therefore having an integrated community and not a split one.  He finds it great that the RPM summit will help to have less differences between spec files.  He thanks all the nice and pleasant guy that were here.

Stefan Werden came to the conference announcing that he will now produce the openSUSE box product.  He will also give back from his income to the community, as first step he hired Rupert Horstkötter to help.  He was glad to receive feedback on doing the box – and how to  support the openSUSE community and users.

Will Stephenson encourages doing the right things – not only stretch our own itches but do something that makes a difference to the rest of the world – both the Linux community and the not-yet Linux community.
Let’s have a wider view and work together!

Federico Mena-Quintero and Aaron Bockover spoke about bacon: They showed great and funny slides on bacon – healty bacon, chicken wrapped beacon, bacon lock (Federico explained the recipe).  Note: they worked during the conference on Bacon – a UI for Banshee that’s used in Moblin.

Lubos Lunak reminds us that we have many great things that others don’t have like the openSUSE Build Service.  Do we – and others know about this?  We should communicate better how great openSUSE is, e.g. that we have binary packages for many distributions at the day of a new release?

Federico Mena-Quintero spoke about hacking together a house using whiteboard: Having windows on two sides of a room, having the bedroom on the east side (to wake up by sunlight in the morning), having  courtyards on the south, having a privacy gradient, balconies need to be 2m wide for table and chairs.  He ended with speaking about  positive space and how The Gimp and Inkscape work.
Federico was the only one that needed two slots of five minutes for his lightning talk – but it was a really fun lightning talk.

Michael Löffler – who moderated the session – said  that we had 300 registrations and more than 200 people attending.  He found the many small meetings and hacking sessions very productive.  The atmosphere was great and productive!

He asked for feedback about the conference:

• Michael Meeks suggests to have it again close to where many developers are (like this time).
• Missing wireless: With internet connection with only 2 MBit, we did not plug in the wireless and setup only wired network in a small area.  Idea to have internet not in the presentation rooms for the future.
• Unconference was great since it allowed to create sessions as needed.
• Future conferences once every year – or once for each openSUSE release.
• Add company or project to badges to see other people’s background.
• Have two days at the end to have some sprints on the distribution.
• Installparty for casual users so that developers have direct contact to users.

Klaas volunteered to setup a small survey on the conference.

More photos are part of my osc09 flickr set.

• gallery.opensuse.org
• flickr osc09 group
• Roger Whittaker’s photos
• Coly Li’s photos

The flickr photos are also shown on the osc09 twitterwall.

Please tell me about further galleries and I’ll update this blog post.

Update 2009-09-23:  Add Coly Li’s photos

Notes below:

What’s the current state? – Michael Löffler explains:

• openSUSE Board has no decision power -> can advise, facilitate discussions
• 99.9 % of decisions are made by maintainer, discussions on mail lists, IRC etc.
• Example: Coolo as openSUSE Distro project manager makes many decisions

Group discussion starts – I have not written down who said was.

We’re doing good here.

No real written way of how decisions are done.

Reason for meeting:

• Is process enough?
• What needs changes?
• How to change?

Governance means also talking of roles.  Some of the roles have been setup long in the past by Novell.

Compared to other projects: Those do the work, make decisions.

There are some roles that community cannot take part in, e.g. security team.

There might be different kind of governance inside the project.

The distribution is at the heart of the project.  There are still some areas that controlled.

Making a decision does not mean that Novell engineers have to implement it.

Do we want to create a new kind of structure?  Example: Team of product managers.

Btw. product managers listen to customers/users, see what they get on contribution and optimize process. Similar to a maintainer of an Open Source project that does not program. Linus could be called a product manager.

We want to work together – forking the distribution when we do not agree is not the solution.

Structures have to be effective.

If people can see that they influence the project and consider part of the project, it is success.

It’s not always clear to people how decisions are made – and escalated.
We have to describe how this processes work – clearly and how it works.

There are some decisions of the kind: Good idea, we’ll accept the contribution and need volunteers to do it.

Btw. what is the technical point of the distribution?  What sets it apart from others?  Why should I contribute to openSUSE and not to X?

Novell’s goal with openSUSE:
Ralf Flaxa: To have the technical best melting point of everything where we solve common problems and bring Linux forward with the freedom to have variation.  If openSUSE solves technical problems that bring Linux forward, it’s helpful.
As well private dream: Dream of showing the world that we can make money with Open Source. For openSUSE I love that we embrace others.

Goals for the distribution? We might write some of these up, e.g. we support choice and therefore several desktop environments.
Do we want to focus on getting new contributors – or on getting new users?

Some goals are implicit.  We also need to discuss high-level concepts and question publically – instead of deciding ourselves.

Are we using the wrong tools for making discussions? Open discussions on mailing lists do not seem to work.  There is lots of repeatition of arguments, meta discussions about the discussions etc.

Idea of consolidation: Say “We’re soliciting ideas, please send in your thoughts to email@opensuse.org.  We’re collecting input and present a proposal.”

Coolo makes some decisions – but also facilitates decision making between experts and listens to experts.

Issue is mainly not making decisions but conflict resolution.
Should we empower the openSUSE Board for this?

Let’s look at what other Open Source projects do.

Concepts of Core Teams?

Different ways of questions: Present your own opinion and ask for comments – or present choices?

Often the same people diverge every discussion.  Sometimes somebody just has to say “Shut up!”.

Idea 2 for discussion: Create wiki page with a proposal and ask others people to refine the wiki page.  Inform mailing list about proposal and ask for improvements and say you ignore comments on mailing lists.

Leadership in discussions is missing!  We need to lead to the discussions more.  Several proposals on how to create new concepts.

What happens if consensus can not be reached?  Should we empower the board for this?  What to do if the board does not come to a decision?  Should the board refuse to make decisions? Are there other questions that the board should decide on?  Should the board delegate decisions?

People should feel responsible for their area and make decisions – and respect others.

How to continue the discussion and move forward?

• Take it to the board and ask the board for a proposal to present on a mailing list?
• Let the members vote on the enaction of the final proposal and ratify it.  Otherwise we might have the board proposing a change and empowering themselves.
• Discussion on a mailing list where only openSUSE members can participate and trolls get removed?

Idea: Invite interested folks to board discussion.  Interested were Michael Meeks, Zonker, Rupert Horstkötter, Jan Weber, Roger Whittaker, Vincent Untz, Cornelius Schumacher, Kalman Kemenczy.

Followup tomorrow, Henne to reserve room and lead discussion.

AI: AJ to blog this (done with this post).

The articles are:

• openSUSE Build System: Building Binary Packages for Many Linux Distributions at Once
• openSUSE Build System: Building RPM Packages
• openSUSE Build System: Building DEB Packages

Ben Martin gives a short overview of the Build Service and then explains step by step how to build a binary package. If you’re interested in building binary packages, I advise to read his articles.

The solution that was proposed – and which should be used in general – is to build against the snapshot repository of openSUSE:Factory.

openSUSE:Factory (as Factory is called in the openSUSE Build Service (OBS))  has the following repositories in OBS:

• standard: This one is constantly changing.  Packages get checked into this repository and then the whole dependencies get rebuilt.
• snapshot: Is a shadow copy of standard that is currently created manually before major changes are checked into Factory. We’re still evaluating on how to create snapshot in the best way.
• staging: This is used for testing of packages before submitting to standard.  It’s used for testing those packages like gcc, rpm and automake that are known to cause problems, so that all these can be fixed before openSUSE:Factory gets built.
• images: This is an internal project for building the ftp distribution and the ISO images, it depends on the packages in the standard repository.

So, if your project builds against snapshot, you will have faster turn-around times since the packages don’t need to wait for a complete rebuild of the distribution.  If you do that you risk a breaking build when submitting to openSUSE:Factory proper (because up until then you built against a slightly older version), but at least you can get work done.

The advice really is to build against snapshot due to the faster turn-around times and also since it distributes the load better for OBS.

Important: Please build either against snapshot or standard but not against both to save build power of our build farm.

How to build against snapshot?

If you branch of your project from a project that builds already against snapshot, your packages will build against it as well. In general, with branching you get all the distributions to build against that the original ones had, so it’s good practice to review what you’re building against.

If you want to replace standard by snapshot for your project do something like Vincent did:

$ osc meta prj -e home:vuntz:branches:GNOME:Factory
and change the line:
<path repository="standard" project="openSUSE:Factory"/>
to this:
<path repository="snapshot" project="openSUSE:Factory"/>
You can also add the repository manually in the web interface of OBS: Go to “add repositories”, click on “Advanced” and then select “openSUSE:Factory/snapshot” in the selection list.

Package Branching

First I checked the (in my case already existing home:a_jaeger:branches:openSUSE:Factory) project out and did: mv /build/home\:a_jaeger\:branches\:openSUSE\:Factory/ /build/branches Now I can use the following script and call it with a package name to branch a package and check it out:

#! /bin/bash
cd /build/branches/
osc branch openSUSE:Factory $1 home:a_jaeger:branches:openSUSE:Factory
osc co -c $1
cd $1
quilt setup $1.spec

Quilt is also setup automatically for easy generation of patches. Btw. quilt has a nice man page and some information in the openSUSE Wiki. A submit request will then be done to the devel project. So, that means I only have one project to look at for all of my factory packages. I also have this project setup that it only builds for openSUSE:Factory, some other devel projects might build for several distributions. That way I can also cleanup by project easier after I changed packages – I don’t want to have packages lying around for ever after I fixed them. This reduces space and build power of the openSUSE Build Service.

What packages depend on package X?

One commenter on my last blog  post asked how to calculate dependencies of a package in openSUSE:Factory.

Here’s another script that might come handy until osc has support for “osc whatdependson”:

#!/bin/bash
curl -s http://download.opensuse.org/source/factory/repo/oss/suse/setup/descr/packages.gz \
| zcat | grep -E "^=Pkg|^$1" | grep -B1 $1| grep =Pkg | sort -u

Call it like “depends mozilla-xulrunner190″.