After speaking to various people within open source communities, one thing that is lacking, or would rather be avoided, is responsibility for leading projects and/or movements. Institutions within society in which we are trying to sell the benefits of open source to are looking for legitimate communities which offer proven sustainable results no matter how large or small they might be.

So much momentum has been gathered over the years through the development of communities and their product of innovation that it has produced projects yielded by "leaderless" communities. These communities work within circular networks which are often driven by shear idealist interest rather than practical goals.

Adversely, Traditional institutions are measured though a result based approach that is highly focused on either top-down or semi-flat management structures where the goals are defined by management.

Here is a good comparison of both aspects


I believe there is a spot in societies for both beliefs and their followers, but the future might bring more of a hybrid concept where one concept builds off the other. It will be interesting to see, but overall we need to start thinking more dynamically no matter what school of thought we subscribe to, and unfortunately I do not think we have quite made it there yet.

One day................A day after tomorrow.

I've just learned out, that openSUSE zypp has wery useful configuration file /etc/zypp/zypp.conf, which contains crucial option solver.onlyRequires. If you set it to True, only really needed dependencies will be installed (of course you can install other packages manually).

This should be also possible to set during the installation. Just need to set the value from console before the libzypp is initialize - during first few screens of installation. But don't forget that it must be set after reboot/kexec as well so it is also valid for 2nd stage of installation and installed system.

We’ll do a launch party in our Nürnberg office on Thursday Nov 12, 7-10pm CET. We’ll try to attract people from the Nürnberg area and show them what’s new in openSUSE 11.2, hand out some media and show openSUSE 11.2 in action. Additional we’ll have a number of outstanding openSUSE folks from SUSE attending and looking forward having interesting discussion. With openSUSE 11.1 we opened up for the first time the “internal” release party to the public. This time we’d like to go one step further and having the launch party just for people interested in openSUSE. We appreciate and invite of course any buddies interested in openSUSE from the Nürnberg office.

What about doing a launch party in your area and share openSUSE 11.2 with others? Just add your party to the list of openSUSE launch parties.

Fellow Package Maintainers,

How are you dealing with this ?

I guess f-spot is not the only project maintaining multiple parallel branches, a STABLE one, from which the releases and bugfix releases are created, and a master, open for business, new stuffs, and experimentations.

When we need to correct something on the STABLE branch, we push a new commit over there, then merge the STABLE back to master so it gets the same fixes. That works fine.

But it gets harder with translation commits. Most of the (awesome) translators (well, all except of one) translates the master and commits right there. Then, when it's time to release, I either ignore those translations (and that's seriously annoying for translators who pushed soem work in the .po), or I blindly backport (cherry-pick) the translations back to the STABLE branch and hope that no strings was removed in master's code. Then I merge the STABLE back to master. Both solutions are seriously suboptimal. Really.

I know how this problem is "solved" in most of the GNOME projects by putting deadlines and code freezes, and string freezes, but I guess we're not the only project around with this kind of issue.

The ideal workflow would be to have the translators (hey guys) aware of the STABLE branch, make them translate that branch, have them merge it back to master, and then, optionally, translate the missing/changed strings and commit that to master. I said ideal, cause I'm NOT gonna ask any translator to understand and follow this, be able to maually merge if something goes wrong, etc...

Translators (did I say thanks for your job lately) are already doing an ant job, most of them with no tools but a text editor, and we can't really add any pain to the process.

So, what are you doing in that case. How could we improve the process ?

Comments are open.

ldapsearch is a very nice tool, but there is one small problem — if an attributes value contains any special characters (anything outside the range of printable ASCII characters), the value is base64 encoded.

so for
ldapsearch -x -h abook.rwth-aachen.de -LLL -b o=abook sn='brüns' cn
the results are:
dn: uid=Stefan.Bruens@rwth-aachen.de, ou=datenbank, o=abook
cn:: U3RlZmFuIEJyw7xucw==


the following snippet helps:
alias un64='awk '\''BEGIN{FS=":: ";c="base64 -d"}{if(/\w+:: /) {print $2 |& c; close(c,"to"); c |& getline $2; close(c); printf("%s:: \"%s\"\n", $1, $2); next} print $0 }'\'''

Results:
ldapsearch -x -h abook.rwth-aachen.de -LLL -b o=abook sn='brüns' cn | un64
dn: uid=Stefan.Bruens@rwth-aachen.de, ou=datenbank, o=abook
cn:: "Stefan Brüns"

Warning: Of course this works for attributes with printable characters only. LDAP can contain binary data, e.g. images of the user in JPEG format.

People who follow the openSUSE Build Service (OBS) developments might know it already, we work on an attribute system for OBS. But what it is good for at all ?

Our current driver is to enable every OBS user to do maintenance for packages in the maintained products (which are currently openSUSE 11.0, 11.1 and a few days 11.2). The maintenance concept itself is described in a very first draft here

However, the attribute system is way more powerful and can be used to store all kind of informations, attached to projects, source packages or even binary sub packages. The important thing here is that the attribute types have own permission rules. So it is for example possible to edit data in projects like openSUSE:11.1 or Fedora:9 which are usually read only.

A simple example is the OBS:Screenshot attribute, as you might guess you can attach references to screenshots to it. Every maintainer or bugowner has write access to it, this means if you are the bugowner of a package, you store this kind of informations not only in your projects, but also in the openSUSE:11.X project packages.

There is also the openSUSE:Playground attribute type created, just for you, when you like to play with this. Btw, the current available attribute types can be requested via “osc meta prj OBS”. And when you use the osc 0.123svn from svn trunk or openSUSE:Tools:Unstable Project, you can even check single attributes in different ways or create them.

For example:


osc meta attribute openSUSE:11.2 # Shows the attributes of the openSUSE:11.2 project
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --create # just creates the attribute in my home project
osc meta attribute home:adrianSuSE zphoto # returns empty, since the package hasn't the attribute.
osc meta attribute home:adrianSuSE zphoto --attribute-project # returns with attribute, since it falls back to the project


# stores two values (World Domination and fast) inside of the attribute:
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --set "World Domination,fast"
osc meta attribute home:adrianSuSE # shows all attributes in my home


osc search --attribute openSUSE:Playground # finds all packages in all projects with the openSUSE:Playground attribute
osc search --package zphoto --attribute openSUSE:Playground # finds all zphoto packages in all project with the openSUSE:Playground attribute


Okay, Okay, all that sounds not horrible sexy when you read it first. But imaging the possibilities. Each team or use case can get their own attributes. They decide what to store in which package, independend if they can modify the sources of project or not. So a team can easily mark packages for any kind of purpose (to fix bugreport 1234, to complete their product Z, to show the state of the packages on web page X, …).

The “osc mbranch” command from the maintenance concept shows also the power of this. You do not need to know where all instances of your package, just tell the server that you need to work on it and the server collects them all.

Please note that the API for the attribute system still might change until OBS 1.7 gets released, we may even need to remove the attributes (even though this is not planned). However, the version running at opensuse.org should be ready to play with this system. And I _really_ would like to hear any kind of feedback, ideas or requests. Can you please comment here, what you can imaging, what else you can use this system for ?

Thanks a lot !

PS: New attribute types can be defined only by the administrator atm, but I am really happy to create any kind of attributes for you, even though you just want to play with it!

2 quick announcements:

libunique now has a managed binding, Unique#. As the mapping is already feature complete and API stable, the code is tagged 1.0.0. It's simple, it's as easy and obvious to use as the native libunique, it doesn't have funky dependency (except, well, for libunique 1.0.0), it installs itself in the GAC...

The code is hosted on gitorious http://gitorious.org/unique-sharp/unique-sharp and patches are welcome. There's no tarball so far, but if you need one, ask and you might receive.

F-Spot got yet another bugfix release (0.6.1.4) I worked on during the weekend, fixing an X issue on some screens. Unfortunately, the Karmic release of Ubuntu (congrats guys) unleashed a new horde of avid testers, and they were able to find an issue in the --view mode (the same issue, for the same widget, was reported for the facebook exporter too). I'll look at it this weekend, in the meantime the workaround is to run f-spot --view with GDK_NATIVE_WINDOWS=true.

[Update 2009/10/31: bug fixed]

Yesterday i noticed that openal-soft on 11.2 is broken, it just locks up with current pulseaudio. It’s not surprising noone noticed as there are no packages in Factory that use it anymore. Even Chromium BSU which roughly has a 0% chance that it will ever need maintenance, security or otherwise was dropped from Factory and moved to the build service games dumpsi^Wrepo. Please, put your packages back to Factory. Chances that people find and use the software are much bigger if the distro has it rather than some random build service repo. Yes, there are some rules you have to follow then but that’s also a sign of quality for our users. Yes, it won’t be the latest and greatest version always but that doesn’t matter for most packages. So please put your packages back to Factory [unless they are full of security bugs ;-)], a distro without packages is not useful.

 Because of my thesis i've been away from development. But i'm still involved with openSUSE-GNOME since it's my natural environment for work.

GNOME on openSUSE 11.2 is very stable it's was build around 2.28.0 with upstream fixes, there's so many cool features for 11.2 that it feels like a new openSUSE and it's really fast compared to 11.1. Now i found zypper much more user friendly, fast (i feel that it's faster than apt) and support live upgrades just like other distros. Of course openSUSE 11.2 become faster on boot mostly because of the new kernel and ext4 (i'm not sure if some tweaks from goblin team went to the initscripts).

I encourage people to try openSUSE 11.2 (specially GNOME developers) because OBS which makes building packages easier and faster, the team is really tied to upstream (no obscure patches and downstream work without going upstream), the GNOME community is really cool and friendly and because the whole distro is stable and fast.

I tried the fprint_demo utility. Get fprint_demo for 11.2 / Factory / 11.1 But the finger print reader in Lenovo T60p doesn’t export the image. So if you have a different finger print reader on your machine, it seems you can get the images from it!