Home Home > 2013 > 09
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for September, 2013

Merchandising: where we are going

September 25th, 2013 by

Jos Poortvliet wrote shortly before the conference about merchandising. Today, he updates us on the status.

Recap

As a quick recap from the earlier blog, note that the goal of the merchandising program is to support openSUSE ambassadors in visiting events and representing openSUSE there. The old program suffered from some issues, including bad planning, bad materials and very expensive shipping. It was simply not very efficient and we didn’t know how much good it did (or not).

The plans

What we want to do can be best summarized as emphasizing quality over quantity and having a proper process. That means making a decent plan for supplying important events with a big box of quality materials and making sure we get a good return on the efforts we put in. And, as started with the Travel Support Program, we’d like the community to be in charge of it all, not SUSE.

Process

A simplified process picture would look somewhat like this:
Booth materials process

The ambassador/local coordinator/TSP teams make an event plan every six months or every year, looking at what events are coming. They classify them, determining what level of support each gets and who is going. This is of course coordinated with the individual ambassadors. The team then asks the openSUSE Team at SUSE to send the materials to the ambassadors, who in turn go and visit the event. At the end of every month we can let the wider community know about the events we visited!

Where we are

Right now, we’ve assembled a list of events, based on ambassador feedback and earlier event plans. I’ve also figured out what shipping options we have and what they would cost and made a plan for the contents of the box. I’d like to start with two different boxes, a big and a small one, and I have selected about 20 events which would get a box. 7 events will have visitors from the openSUSE team, so we’d be supporting 27 events with materials and people. Of course, the Travel Support Team can support other events – and we have the ability to locally produce materials as well. And after the first year, all this can be changed, with more and cheaper boxes (or fewer and bigger), different event selections and improved content.

Issues

We’re aware that this plan is not perfect: quite a few people who received materials in the last years won’t with this plan. But that’s what happens when you decide to focus on a smaller number of events… And we have and can think about solutions for that; for example, create a 1-kg event box with very reasonable shipping costs. Second, planning is hard and harsh, and we want to be flexible in that regard, and open for feedback.

Current status

So where are we now? Unfortunately, there has not been as much progress since the openSUSE conference as we hoped. A blocking issue is the availability of an artist handling the creation of materials we decided on. This will have to be done at SUSE with only a limiting role (for now) by the community artists. We are of course working on hiring somebody for this task but unfortunately one doesn’t just hire somebody.

However, what we do have is a good idea of shipping, a decent event plan and we not only determined mostly what we’d like to ship in each box (and how heavy they will be) but also have already started talking to suppliers. So as soon as we can get the artwork situation resolved, we should be able to get up and running in relatively short order – hopefully before the end of this year.

To give you a bit of an idea of what we have, see the image below.
openSUSE Booth styled

      1. There is about 2 kg of basic tools like duct tape, colored markers, a network and a vga cable, a dozen openSUSE pens and some trash bags (only in the big box)
      2. There is stuff for the table: a table cloth, flyer holder, table display (cube) and we’d like to have caps or bandana’s for the team
      3. Of course we have a cool and lightweight X-banner (if we can make it fit, they’re either big, heavy or both)
      4. We include some posters with information and for putting up a schedule
      5. And then there are some give-aways like stickers, flyers and perhaps cool posters with Unix Cheat Sheets or other info on them

A big thanks for Anditosan for making the images that make the example booth picture here look good. He’s already gathering potential artwork for the booths and if you have any input – direct it to the openSUSE artwork mailing list.

Next

So, the plan now is that once we have a designer, we create and print the materials, assemble the boxes, make appointments with the ambassadors for the events we’ve planned and start shipping.

Statistics

While merchandising seems to be on ice, development is still very active. Factory is now frozen with the Beta out, so we’re going to focus on bugfixing. The top contributors last week were:

Spot Name
1 Tomáš Chvátal
2 Dominique Leuenberger
3 Michal Vyskocil
4 Petr Gajdos
5 Dr. Werner Fink
6 Bjørn Lie
7 Raymond Wooninck
8 Stefan Dirsch
9 Hrvoje Senjan
10 Sascha Peilicke

How I ran openSUSE on a Nexus 7

September 22nd, 2013 by

The Nexus 7 (2012 version) is a 7 inch tablet by Google+Asus.
The nice thing about it is, that it has an unlockable bootloader. Also it has an armv7 CPU and we built openSUSE for this CPU for some years. I had one such device with a broken display, so doing some more risky things with it seemed to be appropriate.
I wanted to run my own software on it. Running openSUSE in a chroot (change-root) environment is usually a lot easier than replacing the whole system, so this is where I went.

First, I needed two tools. One is the “adb” – Android DeBug tool from the official sdk and the other is “fastboot” which was hard to find, so I mirror it here.
I got me the stable ROM from http://wiki.cyanogenmod.org/w/Grouper_Info and followed their installation instructions. adb shell only seemed to work while in bootloader (which you reach by holding Volume-Down+Power during boot)
The hardest part was to re-enable USB-debugging by going into Settings/About tablet and tapping Build-Number seven times.

Also before zapping everything that was there, I did in adb shell : cp -a /system/app /sdcard/
and back later.
So after following all the other installation steps, I had cyanogenmod booting. I attached a bluetooth keyboard so that I can better type. The ROM comes with a terminal app, which I opened. type su - to become root after a security popup.
Now, I downloaded my lastest Raspberry-Pi image from http://www.zq1.de/bernhard/linux/opensuse/. This is under /sdcard/Download where I unpacked it with xz -d
Then comes the tricky part. The image has a partition table, but here we just need the root filesystem. With fdisk -lu we can see that it starts at sector 309248. One could copy out that part with dd or use a loop device with offset like this:
#!/system/xbin/sh
mknod /dev/loop0 b 7 0
losetup -d /dev/loop0 # cleanup of previous try
losetup -o `expr 512 \* 309248` /dev/loop0 rasp*img
mkdir -p mnt
mount -t ext2 /dev/loop0 mnt

Now we have access to the openSUSE files under mnt.
In there I created me a chroot.sh:
#!/system/xbin/sh
for m in proc sys dev ; do mount -o bind /$m $m ; done
HOME=/root PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin /system/xbin/chroot . bin/bash
for m in proc sys dev ; do umount $m ; done

With that, the only remaining thing to do was to add a nameserver line to /etc/resolv.conf before I could use zypper to install software e.g. zypper install yast2-network yast2-ncurses.
Running yast lan on the Nexus 7 gives nice sight.

I guess one could also use the armv7 rootfs to have software built for armv7 instead of the compatible armv6. But for me it does not matter much.

Documenting the openSUSE Development and Release Process

September 18th, 2013 by

build
This week, the openSUSE Team Blog is written by Agustin Benito who talks about how we’ve been documenting our work around openSUSE.

Development a GNU/Linux based distribution like openSUSE can be divided in two major phases:

  • openSUSE Development process: creation and integration of the different packages. Milestones (alphas) and Beta.
  • openSUSE Release process: stabilization, QA and task related with the availability of the different images. Update process. From Beta to the Release.

There are also three major continuous actions throughout the process:

  • Management of the process.
  • Communication and marketing related tasks.
  • Development of new features

The development of new features usually happens upstream or within SUSE (in collaboration with community members) before it is added to the distribution. This phase takes place before or in parallel with the Development process (of packages and integration).

Focus: the openSUSE Team

The decision taken by SUSE during 12.2 to concentrate the SUSE employees working on openSUSE in a single department by creating the openSUSE Team had as consequence that new people has joined us to work in openSUSE. One of the early decisions within the openSUSE Team at SUSE was to put more focus on the distribution. The Release Team was created as a subset of the openSUSE Team, formed by Coolo and Tomas (Ismail Dönmez and Michal Hrušecký were also part of it in the past) to take care of the Development process. It was also decided that the whole Team would have as major goal to drive the Release process.
documentation icon

Documenting the process

Starting in July 2012, the openSUSE Team at SUSE has put effort in documenting the Development + Release process. Throughout the years, the process has evolved and some of those changes were not documented or the documentation was not up to date. We have taken the opportunity to analyze the the Dev+Release process, so we could learn from it and being able to design and execute changes to improve it.

The release process

As Team, we focused first on the Release process. We made an initial effort during the last few weeks of the 12.2 Release process, and we improved it during the first milestones of the 12.3 Release. For this 13.1 Release, only minor updates have been required.

Increasing the efficiency of the management side of things and structuring our work as a formal project has been another aspect of this. We set up a management tool that now is used together with the openSUSE sysadmin team. Ludwig Nussel is the controller of our efforts as team in the Release, planned through progress.opensuse.org. The combination of this planning and the improved release documentation has helped us to increase our efficiency despite new people joining our team.

The development process

During the past few weeks we have concentrated our efforts in analyzing and documenting the Development process. Our goal has been to analyze it, providing a high level view and just the minimum amount of details required to understand it by people with some knowledge of these kind of software integration processes.

We have recently published a draft of the Development process on the openSUSE Factory mailing list and are open for feedback.

Writing process

How was this document done?

      1.- The first action was to analyze existing documentation about the Development process. We took as sources several articles from openSUSE wiki and some previous analysis done by the former Boosters Team in this area.
      2.- We organized two sessions in which different people described the different steps of the process. These sessions were taped.
      3.- We transcribed the sessions and created a first document containing all the information about the process.
      4.- We processed that “story” in order to get the high level view of the process.
      5.- Using the ETVX methodology, we elaborated a first draft of the document.
      6.- We analyzed the result within the openSUSE Team and, after introducing some changes, we opened the discussion about it to other SUSE employees involved in the Development process.
      7.- Finally, in order to make the document easier to read (it is a complex process, so the documentation needs time to digest), we introduced improvements in the format and published in the openSUSE wiki, together with the .pdf version.

This process has allowed us to analyze and discuss the process as a team, learning not just about the hows but the whys. It has also worked as a test for documenting future changes in how openSUSE is developed. We also hope that the effort can be worth it to contributors that want to get a high level view of how openSUSE works, since some of the tasks are done in house. This document has to be seen also as an exercise of transparency.

Improvements

At openSUSE Team, we are strong believers of the principle “no data -> no analysis -> no improvements“. We think we are better prepare now to propose to the community improvements in factory to make it more usable for a wider range of contributors.
statistics with Geeko inside

Statistics Time

And like every week, we present you the top-ten of contributors to Factory!

Spot Hacker
1 Raymond Wooninck
2 Dominique Leuenberger
3 Dirk Mueller
4 Dr. Werner Fink, Bjørn Lie
5 Sascha Peilicke
6 luce johann, Michal Vyskocil
7 Michael Schröder
8 Stephan Kulow
9 Ismail Donmez
10 Cristian Rodríguez

Magic: It is now possible to use MS Silverlight based websites via pipelight

September 13th, 2013 by

It has long been a challenge to use MS Silverlight based websites on linux systems. Especially in The Netherlands this is a big hurdle as many (>80%) of the secondary school websites that pupils must use to communicate with their school (for homework, marks, etc) are equipped with Silverlight. Yes, really… 🙁

Fortunately at the end of August 2013 I discovered pipelight, a very smart idea to use MS Silverlight based website natively on Linux. The problem was however to find a working pipelight package for openSUSE. As there was none, I decided to build one myself using the incredible openSUSE Build Service. It was quite a quest to obtain a working package, but due to very good cooperation with the pipelight developers, I’m now able to present a working pipelight package to the openSUSE community. Oh, and while working on the package I reported a bug via the bug report system, that was solved and published via an rpm package within 1 hour after reporting it (that was during out of office hours). Indeed within 1 hour after reporting the problem it was; accepted, investigated, analysed, fixed, tested, handed over to me, packaged, tested and published! The amazing world of Open Source Software!

Pipelight works okay for the following sites (among many others): arte, LOVEFiLM, Netflix, Magister based NL schoolwebsites, WATCHEVER, etc. View the complete list on the pipelight website.

The installation instructions are on the pipelight website. Be aware though, that pipelight requires the wine package that is provided via the home:rbos:pipelight repository. With any other wine package, pipelight will (very likely) not work. If you rely on your currently installed wine package and installed MS applications and are unsure that the wine package provided via the home:rbos:pipelight repository will leave your currently in use MS applications untouched: don’t install pipelight (or only after making very good backups). You can always start by installing pipelight in a virtual machine.

Have fun with pipelight.

New Raspberry Pi Image

September 7th, 2013 by

update: new image with kernel-3.6 and minimal X11/icewm http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130911x.img.xz (103MB)

We got a new armv6 based image for the Raspberry Pi.
This one is only 82MB compressed, so pretty minimalistic.
http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130907.img.xz

The exciting new thing is that this was created using an alternative image building automatism which I wrote from scratch in three hours this morning.
The scripts can be found at
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
and are also embedded within the image under /home/abuild/rpmbuild/SOURCES/

This means that everyone can now easily build his own images the way he likes and even branch and do submit requests for changes that are useful for others.
The way to use this is simple.
If you have 6GB RAM, you can speed things up with export OSC_BUILD_ROOT=/dev/shm/arm before you do
osc co devel:ARM:Factory:Contrib:RaspberryPi altimagebuild
cd devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
bash -x main.sh

This pseudo-package does not easily build within OBS or osc alone because it needs root permissions for some of the steps (chroot, mknod, mount), which could only be workarounded with User-Mode-Linux or patching osc.
The build consists of three steps that can be seen in main.sh:

  1. First, osc build is used to pull in required packages and setup the armv6 rootfs.
  2. Second, mkrootfs.sh modifies a copy of the rootfs under .root to contain all required configs
  3. And finally, mkimage.sh takes the .root dir and creates a .img from it that can be booted

This can build an image from scatch in three minutes. And my Raspberry Pi booted successfully with it within 55 seconds.

There are some remaining open issues:

  • the repo key is initially untrusted
  • still uses old 3.1 kernel – solved
  • build scripts have no error handling

Compared to the old image, this one has some advantages:

  • It is easier to resize because the root partition is the last one
  • Compressed image is much smaller
  • Reproducible image build, so easy to customize
  • It is armv6 with floating point support, so could be faster
  • We have over 5200 successfully built packages from openSUSE:Factory:ARM
    so for example you can install a minimalistic graphical environment with zypper install xauth twm xorg-x11-server xinit and start it with startx

So if you wanted to play with openSUSE on RPi, you can do so right now and have a lot of fun.

OBS Webui Gets New Search Functionality

September 5th, 2013 by

obs-logo
Our team blog this week is written by Stephan ‘coolo’ Kulow and he talks about work in the team done on the Open Build Service.

Search

For years one of the biggest complaint about the webUI was that it is impossible to find packages. The search ability has been part of the interface from the beginning, but with over 200.000 packages being build today it is crucial to get the right package.

Where is my kernel?

Especially for developers new to openSUSE and the build service it is common to have to search for the package to fix for a specific bug. So you find yourself looking for kernel in the webUI and you are prompted with tons of results that are displayed in a rather random order and the notion that your search resulted in more than 200 hits and is basically invalid. Huh? home:foobar:latest-experiments:kernel is surely not the openSUSE kernel to fix, but then what is?

Now if you ask google about “kernel site:build.opensuse.org” you get closer to the problem at hand: “About 16,800 results” – that is a lot to pick the first 20 results to display from. The OBS webUI tried to find a good pick with an algorithm that might have been clever when build.opensuse.org had 100 projects. Today, it can only be called old and useless.
obs in the dark

Ancor for world fame

So I tricked Ancor to look into the problem by claiming he would get all the praises in the OBS world for implementing a sane search.

The problem is far from trivial, but there are good tools to get a better result than what we had now and Ancor has a lot of experience with these (and Rails in general). So it seemed like he could attain a great balance between effort and outcome.

But as always the devil lay in the details, so this post is also about getting feedback about the actual result.

What we did

Ancor integrated Thinking Sphinx into the OBS, so the name, title and description can be combined with other attributes into one big index that allows page ranking.

Additionally there is no limit of 200 results anymore, the webUI will display all results now, but only 20 at a time as you might have seen in larger sites offering search results display…

We collected attributes which are most likely relevant for people searching for packages. For example, we gather the linkcount of a package into the database (so far only the backend knows what is a link and what is a plain package). The idea is to move links down in the source results.

Coming back to the kernel example, the kernel-source package is the real package, while kernel-default, kernel-desktop, kernel-xen, …. exist too but are all links to kernel-source. So it is fair to present kernel-source first.

Problem is: there are still 228 kernel-source packages in the build service (yes, people like branching the kernel – a lot), so the number of links pointing to the package is another attribute. Packages that other packages branch go up in the list while the resulting branches move down. What also plays a role in the calculation: is a package the devel package of another? (which is the final punch to have Kernel:HEAD/kernel-source as first result displayed, as opposed to the old searching algorithm displaying a discontinued “linux-kernel-nutshell” as shown in the screen shots).
search for kernel on OBS

To sort the vast majority of results that are all _links, not linked to and not devel packages, we take the activity index. This is a number the OBS tracks for every package, but is nowhere displayed. It goes from 0 to 100 and goes down with time and goes up with regular commits. So if you look for kde, you will actually see KDE:Unstable:Playground as first project to match. This is because of two things:

  • kde is indeed a very bad search term
  • the unstable playground sees a lot of commits, so your chance of getting something fresh there is the highest

Your feedback wanted

Of course nobody is perfect, and while the code of Ancor is close to, the weights given to the attributes were my choice, so all problems in the sorting you see are my fault. Please take some time and redo some searches you might have done in the past and report if the results are sane to your experienced eye. Within the HTML of the search results is a hidden span with the raw attributes used in the calculation, so if you find something strange, look for weight, linked_count, activity_index, is_devel and co. Possibly the package that looks bogus to you in the top results is just very active.

Depending on the feedback we get, we might need to change the weights or add yet more attributes in the search and ranking. Do your own experiments on build.opensuse.org today!

statistics with Geeko inside

Statistics

And as always, we finish with the top-ten contributors to openSUSE Factory of last week!

Spot Name
1 Michal Vyskocil
2 Dominique Leuenberger
3 Ladislav Slezak
4 Marcus Meissner
5 Hrvoje Senjan
6 Lars Müller, Ismail Donmez, Cristian Rodríguez, Bjørn Lie
7 Stefan Dirsch, Matthias Mailänder, Jan Engelhardt, Dmitry Roshchin
8 Tomasz Konojacki
9 Ludwig Nussel, Dirk Mueller
10 Raymond Wooninck, Lukas Ocilka