Today we started an openSUSE Build Service Webclient online survey. We want to get more informations about the openSUSE Build Service Webclient users, the used hard and software and (potential) use cases.

If you use, used or want to use the OBS, please participate on the survey and help us to make a solid Webclient 2.

The survey is available via this link.

Thanks for your participation!

Our admins and developers – in Nuernberg, Provo and from home offices – worked hard today to get all openSUSE services up and running again.  Thanks a lot to all of them!

Nearly all services are be up and running again.  The only exceptions are the services features and ideas, these will be restarted latest by Monday.

Just a quick note: We have a power outage in the part of the city of Nürnberg where the Novell office and the main server room is.  This means that many of our servers are right down, especially the download redirector, the mailing lists, the openSUSE build service and users.opensuse.org.

I will post a message once the power has been restored and all machines are running again.  Current estimate (11am Nuernberg time) is that it will take another 4 hours (until 3pm Nuernberg time which is 13:00 UTC) at least to restore power.

Note: the power companies do not know yet exactly where the problem is.

This server and the wiki are located in another data center and are therefore available.

Updates:

13:15 CEST: New rumor: Current estimate for power restoring is six more hours, they need to dig up the street.

16:45 CEST: Bad news: It will take longer until power gets restored.  The local power company just stated “22:00 to 23:00″.  We will try to get then the first machines up but might not get everything running during the night.  Btw. currently it seems that it’s only our office complex that is without power, the rest of the area has power again.

17:15 CEST: I just chatted with our admins, and they currently hope to have everything up Saturday around 13:00 CEST (11:00 UTC) if – and only if – there are no major problems like hardware failures.

18:05 CEST: The admins will start early tomorrow morning – there’s no sense waiting for the power company this night.  The estimate stays at 13:00 CEST (11:00 UTC).  We’ve never experienced such a long outage before, this is exceptionally bad.

19:02 CEST: Beineri has uploaded some photos from the construction site (thanks!).

20:04 CEST: Marko has uploaded some photos as well (thanks!).  Some notes: I’ve heard (no official confirmation) that our office building has two power lines and currently both are getting repaired, they started with the first one and now dig out the second one as well.  Our building seems to be the last one in the area to get power back since it’s the only one with a 20kV line.

1:30 CEST: Power is back in the office – later than estimated.

9:20 CEST: Our admins have brought the basic net infrastructure up and will work on the rest now.

9:45 CEST: The first servers coming up, download.opensuse.org is available again.

10:20 CEST: lists.opensuse.org is up again, I’ve send an announcement out to the mailing lists.  I just don’t know when it will go through since some other systems are not running and I guess the mail queue is rather long.

10:33 CEST: After I approved my announcement, it went through directly and was sent out – this means, the infrastructure is indeed up and runing

13:00 CEST: Most systems should be up, the only problems right now are login on users.opensuse.org and the build service.

15:00 CEST: Info from our admins:

It has turned out that the electric feeder cable outside the building was blown which had to be digged out and then repaired, so the first estimation  of the energy provider was a little bit optimistic. Connection was re-established Friday night at about 1AM (localtime) and reconstruction started this morning at 7AM and most important services were back at about 9AM.

15:08 CEST: We’re still working on users.o.o and the build service, everything else should be ok.

18:50 CEST: users.opensuse.org and build.opensuse.org are back online.  We should now be good enough for the weekend.  Currently still down are ideas.o.o, features.o.o and tracker.opensuse.org (for our torrents).  We will have these restored on monday.

20:18 CEST: tracker.opensuse.org (for torrents) is running again.

The openSUSE Factory distribution is our permanent moving target, this is the place where all Alpha and Beta versions are mastered from. We are currently in the process of adjusting some things due to the move from SUSE internal AutoBuild to openSUSE Build Service:

We are getting rid of all the historical names. Factory from SUSE internal AutoBuild is currently in the directories “SL-OSS-factory”, “SL-OSS-factory-debug” and “SL-Factory-non-oss” inside of the distribution directory. These names are inconsistent and have lost their meaning to some degree.

The Factory distribution from Build Service is currently in repositories directory as rpm-md tree. This means you can install packages from it, but you can’t make a new installation from it.

So we will remove all these directories and publish Factory directly to the new factory directory. The organization below this directory will be the same as below the official distribution directories. So we will have

• iso directory: containing the latetest mini iso for network installation.
• repo directory: containing the installation source trees:
  • oss directory: The main tree from openSUSE:Factory project, everything for a new installation is inside.
  • non-oss directory: Additional non-free packages from openSUSE:Factory:NonFree project inside.
  • debug directory: All debuginfo and debugsource packages are in this directory. These are usually only needed for debugging or bugreporting.
  • src directory: All source rpms from openSUSE:Factory project are in this directory. Please note that it makes usually more sense to check out the latest sources directly from the Build Service.
  • src-non-oss directory: All source rpms from openSUSE:Factory:NonFree project.

Another important change is that we have moved the PowerPC packages to their own server.

This new setup should make it easier to mirror subsets of the Factory distribution, without breaking any repository metadata. This means mirrors can just sync the most important stuff like the main repository and ignore the rest. We hope to get factory on more mirrors around the world with this setup.

We plan to implement this until next week.

The openSUSE 11.1 beta 1 release marks a significant change for openSUSE. For the first time in 11 years, a SUSE release was not built in the SUSE internal AutoBuild service — openSUSE 11.1 beta 1 was built using the openSUSE Build Service!

(more…)

The openSUSE Project is proud to announce the 1.0 release of the openSUSE Build Service. The 1.0 release provides all the features necessary to support building openSUSE in the public build systems and allowing direct contributions to openSUSE from all contributors. Developers can now submit contributions to openSUSE directly at build.opensuse.org.

The openSUSE Build Service allows developers to create and maintain packages for openSUSE and many other Linux distributions, including CentOS, Debian, Fedora, Mandriva, Red Hat, and Ubuntu. With the 1.0 release, the openSUSE Build Service expands its scope to building the entire openSUSE release, and provides everyone with the same access and transparent interface to work on the openSUSE distribution.

The openSUSE Build Service has offered a simple collaboration system since its inception for groups to work closely together on packages or solutions stacks. The 1.0 release improves on existing functionality to allow the Build Service to scale to larger projects like openSUSE’s Factory distribution, and to allow building openSUSE’s stable releases in the open.

What the changes mean for contributors:

• Anyone can find a package’s working copy as maintained by the official packager or packaging team. Contributors can submit changes against the working copy.
• The submission handling and notification system has been put in place, allowing any contributor to request a merge of their changes to a project.
• Quality assurance happens before contributions are merged. Test builds of a suggested change are accessible to anyone.
• Improved branch handling. It is easy to set up a branch of a package. The branch will build in the same way as the original package, but can be modified.
• Source handling is improved in 1.0. It’s now possible to easily maintain a branch, and modifications are stored without creating a full copy. This makes it easier to maintain features based on the latest copy of package. The Build Service builds the latest packages, including modifications, automatically.

The majority of this functionality is implemented on the server side. The rest can be implemented by the various Build Service clients, so that contributors can take advantage of the new features.

The Build Service team has also introduced a number of smaller improvements and bugfixes to make the system more scalable and usable.

The openSUSE Build Service is now considered “feature complete” for collaboration. The Build Service team is looking for additional feedback on improving the openSUSE Build Service as it will now be the standard tool for working on the distribution.

The openSUSE Project has released the first release candidate of the openSUSE Build Service 1.0. With the release candidate, all the features are now in place to support external collaboration with the community to build openSUSE in the open. Developers can now submit contributions to openSUSE directly at build.opensuse.org.

The openSUSE Build Service has offered a simple collaboration system since its inception for groups to work closely together on packages or solutions stacks. The 1.0 RC 1 release improves on existing functionality to allow the Build Service to scale to larger projects like openSUSE’s Factory distribution.

What the changes mean for contributors:

• Anyone can find a package’s working copy as maintained by the official packager or packaging team. Contributors can submit changes against the working copy.

• The submission handling and notification system has been put in place, allowing any contributor to request a merge of their changes to a project.

• Quality assurance happens before contributions are merged. Test builds of a suggested change are accessible to anyone.

• Improved branch handling. It is easy to set up a branch of a package. The branch will build in the same way as the original package, but can be modified.

• Source handling is improved in 1.0. It’s now possible to easily maintain a branch, and modifications are stored without creating a full copy. This makes it easier to maintain features based on the latest copy of package. The Build Service builds the latest packages, including modifications, automatically.

The majority of this functionality is implemented on the server side. The rest can be implemented by the various Build Service clients, so that contributors can take advantage of the new features.

The Build Service team has also introduced a number of smaller improvements and bugfixes to make the system more scalable and usable.

The openSUSE Build Service is now considered “feature complete” for collaboration, but the team is expecting a lot of user feedback since this now is our standard tool for working on the distribution. We will be releasing frequent updates to improve the Build Service based on this feedback. Contributors can discuss the build service on the mailing list and on Freenode in the #opensuse-buildservice channel.

Building packages for multiple distros can be a major pain — which is why we provide the openSUSE Build Service. One of the Build Service’s many features is the ability to create packages for many distros — including openSUSE, SUSE Linux Enterprise, Debian, Fedora, CentOS, and Ubuntu. One of the projects making the most of the Build Service is KDevelop. We talked with KDevelop developer Amilcar do Carmo Lucas about how the KDevelop project is using the build service.

(more…)

Hello avid gamers and game developers!

We decided to restructure and cleanup the games projects in the openSUSE Build Service. Before the change we had 8 projects for each game genre (action, adventure, arcade, board, puzzle, roleplay, strategy/realtime, strategy/turn-base) and one separate project for game libraries (so you can play games even on older distributions with obsoleted libraries).

This situation was causing more harm than good, so now we will only have one “games” repository with all game genres together. If you have already added old game repositories, please remove them and add the brand new one located at download.opensuse.org/repositories/games/ and then the directory of your distribution. The old URLs for the individual games repositories will no longer work.

If your favorite game is not yet packaged you can add it to the Games Wishlist at openSUSE wiki. Or even better, you can try to package it by yourself and when you are finished contact Pavol Rusnak and we will add the game to the repository. You can also ask on the opensuse-packaging@opensuse.org (subscribe) mailing list you have any troubles with the packaging.

Game On!

Michal Vyskocil has requested a new mailing list around Java topics. You can subscribe to it or browse the newly created archive. This nicely fits our other Java changes, which can be discussed on the mailing list:

• Debian and Ubuntu based Java buildings: It was not possible so far to build Java based packages for Debian or Ubuntu, because Java lives there in non-free or Multiverse repositories. We have imported these as Debian:Etch:NonFree or Ubuntu:*:Multiverse projects to offer java builds in future. We would like to thank Carsten Höger from Open-Xchange for his help and the needed java preinit package. A nice example for using Java on deb based distributions is the server:OX:snapshot project.
• openSUSE:Factory is using open source Java from openJDK6 now. We switched to openJDK6 as default Java to be able to deliver a complete open source Factory distribution including Java. This is currently not a final decision, just a test approach to evaluate the situation. This affects also everybody who builds a Java package for Factory using the generic “BuildRequires: java-devel”, openJDK6 will be used in this case as a Java environment. A drawback is the increased bootstrap time for Java in Factory atm, increasing the time for a complete Factory rebuild to several days. We are working hard to avoid this again in future.