Home Home > 2011 > 09
Sign up | Login

Archive for September, 2011

“Happy Pony” openSUSE?

September 22nd, 2011 by

At the openSUSE conference last week, Lydia Pintscher from the KDE Community Working Group led a BoF on “women in openSUSE”. This is what we (Stella, Bruno, Lydia, Pascal, Susanne, Greg) worked out:

There are very few women in openSUSE for a variety of reasons. In our perceiption, despite the good efforts of moderators on IRC, forums and mailing-lists, some attitudes there still persist, and we believe these are a key issue that keeps women away. To further address this as a small group, we decided to start at just one place, opensuse-project@. Here’s why and how:

There is quite some research on why there is so few “women in FLOSS” in general. One of the recurring topics there, and one that we also quickly came to in the BoF, was the ‘flaming’, or more generally, the negative possibilities of the direct, unfiltered yet anonymous communication on IRC, forums and mail.

We all value the speed and positive directness of those forms of communication — however it’s cutting off facial expression and physical reaction. So it’s very easy to miss the tone, without even noticing. To more sensitive souls, this is creating a barrier of entry that especially women do not want to cross, or if it hits you unprepared, will reject you, often with no return. Nota bene: this effect is not limited to women! It just happens to reject women more than men.

What’s going on there? On one side there is newcomers wanting to learn, and with a great potential to contribute, however with a “thin skin”, an expectation of being treated with respect and politeness, whatever that means. On the other side, there are knowledgeable people, often young, sometimes unpatient, maybe tired, frustrated themselves. Now the former ask naive questions while the latter “shoot out” a quick response without any visual feedback on what happens right after they hit the “send” button. Kazoom! And the frustration results into discussions that quickly are far beyond the original topic, frustrating, unproductive and the opposite of what we want: respect and getting things done.

openSUSE, like many other open source projects, has set the direction for mutual respect by working out Guiding Principles, and making members accept these. The openSUSE project Board is forming a body of volunteers who “enforce” these rules, something like the Community Working Group in the KDE project. The objective is to focus the speed and directness of the communication on productivity: turn the flaming energy of frustrations into creative energy that makes openSUSE a place to enjoy and to contribute to!

We, the BoF participants, want to simply support that effort, by working on just one list (opensuse-project@), and by providing additional material that complements the very high level goals set forth in the guiding principles.

Stay tuned :-)

openFATE News

September 21st, 2011 by

We just added 2 new goodies to our feature tracking tool openFATE:

Print views

You can now get a decent view of a feature that is adapted for printing. Either click on “Print preview” in your browsers menu, or on “Print” in the feature export box on the right side of your feature.

Adding inline images and screenshots

To add a screenshot or any other image included in your feature, just add a relation with type “url” that points to your image in the net. You can for example upload it to paste.opensuse.org or any other image hoster.

osc11 slides and screen cast workshop kvm/libvirtd

September 19th, 2011 by

Just a quick note, my slides and screen cast about my recent openSUSE conference workshop about KVM/libvirtd are online at http://goo.gl/fQfql
Check at material subject

Education at OSC

September 18th, 2011 by

Even if the last news from the Education project is just one month old, many people asked me during the openSUSE Conference why the Education project itself is currently so quiet.

Well, the “problem” is, that our Education team is currently more a team of technical specialists and many work is done behind the scenes without communication to “the outside”. So even if you did not hear from us for some weeks, we are still alive and coding!

Here are just a few examples, that are going on behind the scenes:

  • Translation of the new openSUSE Education Portal is work in progress. Many thanks to our contributors Guillaume for the Français, Freek de Kruijf for the Nederlands, Sabarth for the Português, Gankov for the Русский (Russian) Portal translation!
  • Kirill is currently reviewing all 425(!) packages in the Build Service Education project and submitting them to openSUSE Factory afterwards – so openSUSE 12.1 will come with a huge set of packages directly inside the official repository.
  • Cyberorg is working on the next release of the openSUSE Edu Li-f-e DVD with the LTSP integration.
  • Anubusg1 and many others (the project currently lists 44 maintainers) are doing the “normal” packaging stuff like upgrading and fixing packages for 12.1 (aka Factory)

The Desktop4Education project from Austria was again present at the Conference and gave a great overview of the current status of the project during their talk. Good to hear that the project is being frequently used as a reference case by the Austrian Federal Ministry for Education, Arts and Culture and as such promoted by them throughout Austria.

Talking with Andre Massing from the Simula Research Laboratory during his talk at the conference was quite interesting. Looks like the Science project might see some very interesting new packages in the next months. During the discussion, we agree that the Education and the Science project can share a lot of efforts in their project setups and organization. But they will stay separated (at least in the Build Service) as their audience is very different, even if they share some packages (which is currently done via links inside the Build Service).

LibreOffice 3.4 available for openSUSE

September 15th, 2011 by

I’m happy to announce LibreOffice 3.4 packages for openSUSE. They are available in the Build Service LibreOffice:Stable project.

LibreOffice 3.4 provides many interesting features and fixes. The openSUSE packages are based on the LibreOffice 3.4.2 release but they include all fixes from the last 3.4.3 bugfix release. Please, look for more details about the openSUSE LibreOffice build on the wiki page.

The openSUSE LO team hopes that you will be happy with this release. Though, any software contains bugs and we kindly ask you to report bugs. It will help us to fix them in the future releases.

Other information and plans:

It took me quite some time to prepare the 3.4 update because the split build was not longer supported and I had to completely rework the packages.

We are going to prepare official maintenance update for openSUSE-11.3 and 11.4. You might expect it within next few weeks.

I am going further improve the build framework to be able to early provide LO-3.5 packages in the LibreOffice:Unstable project. You might expect something about Christmas, see the LibreOffice 3.5 schedule.

Thoughts about using test driven development for my gsoc project

September 11th, 2011 by

Hi,

as you might know I participated in the GSoC this year. When the coding period
started my mentors and I decided to use the “test driven development” (TDD)
approach to develop the python obs library. In the following I’ll summarize
why I think using this approach was a good idea and how it helped me to write
the code.

  • It helps with designing a class interface
    With TDD you usually write the testcases _before_ the actual code. When
    doing so you already get a feeling if the design of the interface or method
    is practical because you use the interface multiple times in your testcases.
    Example:
    One of the first coding tasks was to write a class for managing (editing,
    saving etc.) project/package xml metadata. For instance a common use case
    is to add a new repository the project’s metadata so I wrote a testcase for
    it. The first version looked something like this:

    prj = RemoteProject('foobar')
    repo = prj.add_element('repository', name='openSUSE_11.4')
    repo.add_element('arch', 'x86_64')
    repo.add_element('path', project='openSUSE:11.4', repository='standard')

    I think this doesn’t really look pythonic (but of course this is just a
    matter of taste) so finally I ended up with the following:

    prj = RemoteProject('foobar')
    repo = prj.add_repository(name='openSUSE_11.4')
    repo.add_arch('x86_64')
    repo.add_path(project='openSUSE:11.4', repository='standard')

    (of course the add_* methods aren’t statically coded in the RemoteProject’s
    class – instead we use a “ElementFactory” which is returned by an overridden
    __getattr__ (for the details have a look at the code:) ))
    Without TDD I probably would have implemented the first version and
    afterwards I had realized that I didn’t like it…

  • It helps structuring the code
    Let’s consider some “bigger” method which needs quite some logic like
    the wc.package.Package class’ update method (the update method is used to
    update an osc package working copy). Before writing the testcases I started
    to think about how the update method can be structured and what parts can
    reside in its own (private) method (probably a natural thing which has
    nothing to do with TDD). I ended with the following rough layout:

    • calculate updateinfo: a method which calculates which files have to be
      updated (in particalur it returns an object which encapsulates newly added
      filenames, deleted filenames, modified filenames, unchanged filenames etc.)
    • perform merges: a method which merges the updated remote file with the
      local file
    • perform adds: simply adds the new files to the working copy
    • perform deletes: deletes local files which don’t exist anymore in the
      remote repo

    Then I started to write some testcases for the calculate_updateinfo method
    and implemented it. Next I wrote testcases for the various different update
    scenarios and implemented the methods and so on. It is probably much
    easier to write testcases for many small methods than for a few “big” methods.
    From time to time I realized that I forgot to test some “special cases”, so
    I added a new testcase, fixed the code and ran the testsuite again. The cool
    thing is if the testsuite succeeds (that is the fix doesn’t break any of
    the existing testcases + the newly added testcase succeeds) one gains
    confidence that the fix was “correct”.

  • It speeds up the actual coding
    My overall impression is that TDD “speeds” up the actual coding a bit. While writing
    the testcases I also thought how it could be implemented. So when all testcases
    were done I had rough blueprint of the method in my mind and “just” transformed
    it into code. For instance it didn’t take much time to write the initial
    version of calculate_updateinfo method.
    But of course this doesn’t work for all methods. Stuff like the Package class’
    update method took quite some time (and thinking!) even though I already wrote
    some testcases. The main reason was the fact that the update should be
    implemented as a single “transaction” (the goal was that the working copy
    isn’t corrupted if the update was interrupted). As you can see TDD is no
    black magic approach which makes everything easier – thinking is still
    required:)
  • It helps to avoid useless/unused code paths
    I just wrote the code to comply with the existing testcases – no other
    (optional) features were added. Sometimes I realized that some feature was
    missing. In this case I added another testcase and implemented the missing
    feature. So the rule was whenever a new feature was required a testcase had to
    exist (either a testcase which directly tests the modified method or a testcase
    which tests a method which implicitly calls the modified method).
  • It helps to overcome one’s weaker self
    From time to time I had to write some trivial class or method where I
    thought it isn’t worth the effort to write testcases for it. A perfectly
    prominent example was the wc.package.UnifiedDiff class (it’s only purpose is
    to do a “svn diff”-like file diff). At the beginning I wanted to start coding
    without writing testcases because I thought it’s enough to test its base class
    (that’s the place were the interesting things happen and the rest is just
    “presentation/visualization”).
    Luckily I abandoned this idea and wrote the testcases. It turned out that it
    was a good idea because this “trivial” visualization I had in mind was more
    complicated than I initially thought;)
    What I learned from this example is that it is most likely better to write
    testcases because the class/method might evolve and might get more complicated.

Finally here’s a small statistic about osc2’s current code coverage (generated
with python-nose’s nosetest):

Name                Stmts   Miss  Cover
---------------------------------------
osc                     1      0   100%
osc.build              79      4    95%
osc.core               19      2    89%
osc.httprequest       180     19    89%
osc.oscargs           145      1    99%
osc.remote            278     11    96%
osc.source             68      2    97%
osc.util                1      0   100%
osc.util.io            85      8    91%
osc.util.xml           23      0   100%
osc.wc                  1      0   100%
osc.wc.base           173     20    88%
osc.wc.convert         71      6    92%
osc.wc.package        792     39    95%
osc.wc.project        397     20    95%
osc.wc.util           387     28    93%

(line numbers and non osc2 modules are removed)

As a conclusion I would say that using the TDD approach was a good idea and
helped a lot. So you might want to give it a try too – it probably won’t harm:)

Last but not least I want to thank my mentors Sascha Peilicke and
Marcus ‘darix’ Rueckert for their time and tremendous help (meetings,
suggestions, interesting links etc.) during the GSoC. Thanks!

AR.Drone with openCV in the openSUSE 11.4

September 10th, 2011 by

After publishing an article in the openSUSE Wiki (in portuguese sorry) about AR.Drone, I am developing an application to control it using the library opencv computer vision to Processing and using your camera in the operating system openSUSE 11.4. The source code soon in The Open Build Service (OBS), For now, watch the video below of the image HERE.

fsck.ocfs2: I/O error on channel while performing pass 1

September 5th, 2011 by

When running fsck.ocfs2 if you get an error like below, turn off feature metaecc and run it again.

fsck -f -y /dev/drbd0
fsck from util-linux-ng 2.17.2
fsck.ocfs2 1.4.3
Checking OCFS2 filesystem in /dev/drbd0:
Label: vmimages
UUID: B5A45669962C4E40AE9FB2BF16184981
Number of blocks: 157281328
Block size: 4096
Number of clusters: 19660166
Cluster size: 32768
Number of slots: 4

/dev/drbd0 was run with -f, check forced.
Pass 0a: Checking cluster allocation chains
Pass 0b: Checking inode allocation chains
Pass 0c: Checking extent block allocation chains
Pass 1: Checking inodes and blocks.
extent.c: I/O error on channel reading extent block at 112162 in owner 516113 for verification
pass1: I/O error on channel while iterating over the blocks for inode 516113
fsck.ocfs2: I/O error on channel while performing pass 1

#disable metaecc (man tunefs.ocfs2 for more)
tunefs.ocfs2 --fs-features=nometaecc /dev/drbd0

#run fsck again
fsck -f -y /dev/drbd0

to re-enable it after completing fsck, run:
tunefs.ocfs2 --fs-features=metaecc /dev/drbd0

ATI/AMD flgrx : status of the helping pledge

September 1st, 2011 by

Dear users of fglrx drivers (pre-packaged or .run installer)
On 19th August I’ve opened a pledge see this article, and I’m give you today a refresh status :
Click here to lend your support to: Funding ATI-AMD fglrx packager Sebastian Siebert and make a donation at www.pledgie.com !

I personally already thanks of the actual donors. You rocks !
We are almost done at today, but almost is not done :-)

So if you can spread the word a bit more, that’s would be really cool. My objective is been able to give the money back to Sebastian Siebert during our openSUSE conference. And so create a kind of ceremonial.

Can I count on you ?