DISCLAIMER: I am not recommending you to root your phone and if you are not sure what for or what are the consequences of doing it (including your warranty), then don’t do it. This post is only an explanation on how to do it. Also I am not responsible for any damage to your phone, including bricking it.

First, download Android SDK 1.5 from here, unpack it and go to the tools/ directory.

My first problem:

./adb shell
error: device not found

./adb devices                        
List of devices attached

Reading around I found out how to fix it, and then realized it was documented here

Create a file /etc/udev/rules.d/90-android.rules with the following content:

SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
SUBSYSTEM=="usb",ATTR{idVendor}=="0bb4",ATTR{idProduct}=="0c02",SYMLINK+="android_adb"
SUBSYSTEM=="usb",ATTR{idVendor}=="0bb4",ATTR{idProduct}=="0c01",SYMLINK+="android_fastboot"

And restart udev by doing killall -HUP udevd, then unplug and plug the phone.

Now, get Recovery-RA-HERO-v1.2.2.img and fastboot (unpack and chmod +x this one), and put them somewhere, or as this example assumes, in the same tools/ directory.

Now boot the recovery image:

./adb shell reboot bootloader
./fastboot boot Recovery-RA-HERO-v1.2.2.img

You can use the NDroid Backup option to backup your phone to the SDCard.

Get Superuser.zip (requires registration in the xda-developers phorum) and unpack it. You will get two files from there: “Superuser.apk” and “su”.

./adb shell mount /system
./adb push su /system/bin/
./adb shell chmod 4755 /system/bin/su
./adb push Superuser.apk /system/app/
./adb shell reboot

Now confirm that it worked:

./adb shell
su

(Click Always allow on the phone)

And that is!.

If you need to restore your NDroid backup, I haven’t tried, but you can do it from the recovery image or manually pointing it to the images:

fastboot flash boot /boot.img
fastboot flash system /system.img
fastboot flash userdata /data.img
fastboot reboot

Almost nine years passed since the first lines of Kopete code started to take form, in a remote country in the south part of the globe.

Still today, looking at an old Kopete screenshot has a special meaning for me. I had so much fun. I learned hundred of tricks and certainly it shaped me as a developer. Working with brilliant hackers across the world brought this multicultural curiosity. Both things combined resulted in myself living in a different country, married to a woman from yet another one, and having friend parties where almost everyone was from a different place, and working in a company involved in this great hobby.

However the world was different by then. At that point the discussion was whether you ICQed or you sent viruses via MSN. And the most difficult challenge was to get file transfer done right. Nothing of that matters anymore.

Kopete was initially very innovative, at least in its goals: to communicate with people, while leaving the IM network as a channel. We brought the concepts of “metacontacts” (bad naming), but basically you say people in your contact list, no matter if they were available on MSN, ICQ, or both.

Today I have a telephone with internet 24/7 in my pocket and I can IM on the bus. I don’t choose IM networks as a soccer team, but rely on them because I have friends on various of them. Just like I use twitter for “geeky stuff” while Facebook is a more “relaxed” environment.

Sadly, at some point Kopete lost leadership, when all the strong opinionated and grumpy developers that shaped its core heart got busy with other stuff, while people contributing to it were mostly interested in features like being able to have sub-sub-sub-sub-sub-groups, or notifications per-contact-per-network-perl-daytime or concepts like identities which made sense but that were not designed, transforming Kopete in a kind of a very sophisticated “IM App Construction Kit” but at the same time some of its configuration looks like an IDE, which wording that not every user would understand: identity, account, contact, metacontact, etc.

The focus was on supporting every single feature of every single IM system and to expose it in the user interface somehow. Which was at the same time not easy, as we implemented various protocols from scratch, and keeping up with features or even protocol changes as lot of manpower.

I tried to motivate myself to do development again, but every proposal on the mailing list just seems a completely different direction of what I would even had energy to discuss. Yes. I don’t get motivated even to discuss if adding one tab per IM network to the user interface makes sense or not.

Linux gained a promising technology when Telepathy started to mature. While Telepathy is yet another abstraction layer, it is one built in a way that has proven to be successful on the Linux Desktop, by providing dbus based services that are desktop independent. And it has reached the point where is even used in production devices (AFAIK Nokia), and has features like conferencing and multimedia in its design. Not to mention the protocols code is reused across applications.

There is a group of KDE hackers bringing this forward for KDE under a project called Real Time Communication and Collaboration, partially sponsored by Collabora.

I personally think this is the future of Kopete. IM not as an app, but as a desktop level service where the chat window and the contact list is just something using this service. It fulfills the vision we tried to achieve lot of times with Kopete: like when KMail contact status was implemented, or KAddresbook integration.

A future where people is people (and no metacontacts), and the focus is communicating, listening and seeing them, and not sorting and classifying them. I believe this project has the chance to achieve that.

As any big application, you can’t kill it by rewriting it from scratch. Kopete is awesome and will serve us for a while. The strategy this team is taking by building blocks one by one in the most simple way, sometimes reusing Kopete pieces where possible, is the right one. And I have the feeling they will coexist in parallel for some time.

This group of hackers is meeting right now in Collabora offices for a 1st sprint (Hello Will!). They deserve all the support from the community. Because they are writing the future of KDE instant messaging.

Pedro Huichalaf Roa publicó una columna donde explica más detalladamente la “Licencia Gubernamental de Software”, antes conocida con el (muy mal escogido) nombre de GPL-CL.

La columna nos dá el contexto que faltó cuando la información se comenzó a propagar por las redes sociales. Con su super-nombre (GPL-CL) estó sucedió más rápido de lo necesario, generando una polémica innecesaria.

Sin embargo, ahora que se ve que no era necesario polemizar, creo más que nunca que es un tema importante y que ojalá no se lleve a cabo como está.

Muchos de los puntos críticos de la licencia fueron muy bien explicados en la carta abierta que envió El Centro de Difusión de Software Libre (CDSL), el Portal Software Libre Chile, el Partido Pirata de Chile y Fundación GNUCHILE y en el análisis técnico publicado por eldiabloenlosdetalles.net, por lo que sólo voy a tocar los puntos que me tienen confundido.

También quisiera aclarar que no soy abogado. Sin embargo he publicado bastante código fuente bajo varias licencias (GPL, BSD, etc) siendo en algunos casos yo el dueño del copyright como la empresa donde trabajo en otros.

Citando el texto de Huichalaf:

Para entender este nuevo ecosistema, tenemos que partir de la base que la transferencia de tecnología se basa en aquella tecnología cuya propiedad le corresponde al Estado. Es decir, estamos hablando de aquellos software y desarrollos informáticos realizados “a medida” para organizaciones de la Administración Pública y cuya propiedad intelectual posea la entidad. Así, un ejemplo es un software desarrollado para gestión documental o calificación de personal.

En este parrafo, se deja claro que estamos hablando de desarrollos donde el Estado es el dueño del copyright.

Lo que ocurre actualmente en relación a este tipo de software a la medida, es que las entidades públicas para efectos de adquisición y desarrollo se comportan en forma autónoma sin que exista comunicación centralizada respecto a soluciones adquiridas.

¿En qué quedamos? ¿Son las agencias gubernamentales la misma organización: el Estado, o no?. El raciocinio se debe hacer sólo con una de ambas hipótesis.

Justamente en este sentido es que nace la idea de generar un repositorio centralizado de software desarrollado para la Administración Pública y cuyos derechos de autor le corresponden al Estado , lo que se concreta en softwarepublico.cl y al mismo tiempo, surge la Licencia Gubernamental de Software, que en términos simples, establece las condiciones de uso del software del Estado.

Aquí empieza la confusión. Si esta licencia es para uso interno del gobierno entre sus entidades, cada entidad puede hacer uso de los softwares sin mayor problema, a menos que el contrato por parte del desarrollador externo no deje al Estado como dueño del copyright, sino que como un mero usuario de una licencia, lo cual contradice el parrafo inicial de Huichalaf (Estado como dueño del copyright). El Estado no necesita entrar en un sistema de distribución de software. El problema de la distribución interna es algo organizacional y político, pero (repito no soy abogado) no algo legal.

Si el fin es compartir entre entidades, ¿Por qué la licencia es tan permisiva?, básicamente permitiendo la distribución de un modo muy similar a la GPL (sin restricciones más que conservar las condiciones, y una restricción agregada de registrarse en softwarepúblico.cl). Aquí surge la confusión, y pareciera que la licencia tiene un objetivo más abierto que el compartir entre entidades de una misma organización. Si esto no fuese así, y la idea es que sea permisiva, volvemos al ¿Por qué no usar la GPL?.

Cuando se trata de ser dueño del copyright, el Estado es uno. Cuando se trata de distribuirlo internamente, ya no es una sola entidad. ¿Cómo es la cosa?

Luego la segunda parte que no calza en el puzzle. ¿Para qué se publica en softwarepublico.cl y no se mantiene en una intranet del gobierno?. Si el objetivo es solo compartirlo entre entidades, esto es ilógico. Si el objetivo es compartirlo con la ciudadanía (lo cual no estaría mal, siendo que ella paga por él) esto tendría sentido.

Si este repositorio es accedido solo por entidades del estado, entonces no habría problema. El problema es cuando se comparte entre países, lo cual es una gran oportunidad, o cuando contratistas del Gobierno reciben este software como modo de externalizar un servicio. Ahí pasamos a la distribución, y por ende se activan las incompatibilidades con la GPL, y por ende no se podrá (por citar un ejemplo) usar la librería del lado “cliente” de MySQL.

Esto contradice ahora la estrategia de Alfredo Barriga de querer externalizar algunos servicios en la “nube”.

Por ejemplo, si un sistema de soporte IT desarrollado a medida bajo esta licencia, se externalizara a un contratista, se estaría incurriendo en distribución.

Hasta aquí tampoco entiendo por qué no utilizar una licencia absolutamente libre, ya que en efectos prácticos esta licencia permitiría a cualquiera que tenga acceso al software a seguir distribuyendolo como fuentes.

Resumiendo:

• Una licencia nueva es una pésima idea que trae consigo más problemas que soluciones, y estos problemas permanecerán ocultos hasta que una gran oportunidad se vea bloqueada por ellos.
• No se entiende por qué una licencia tan permisiva siendo el objetivo una distribución en un entorno cerrado, y por ende por qué no utilizar la GPL de una vez.
• La idea confunde licencia y distribución. Se podría utilizar la GPLv3 y simplemente no distribuir fuera del gobierno lo que no sea para distribuir, o dejarlo como propietario para uso exclusivo del gobierno (y controlar a los contratistas con el contrato, no con la licencia). Lo que se va a distribuir, se puede poner en http://www.gobforge.gob.cl/, el cual no se que rol tiene en todo este tema de la nueva licencia o que criterio se utiliza para poner software en un lado o en el otro (más confusión aún).
• Creo que el plan confunde el ordenar la casa, los contratos, las condiciones, etc., con una licencia nueva: Persiguiendo un objetivo que con sus mismos defectos destruye.

Me gustaría saber ¿Por qué no se podría usar la GPLv3 más un proceso y política clara y explícita respecto a distribución, contratos para contratistas, desarrollo externo, licencias a utilizar en cada caso, etc.

Yendo más allá, creo que la licencia no es el paso más importante. Siento más urgente y me hubiese gustado ver directivas. En especial cuando hablamos de desarrollo a medida por terceros:

• Que obliguen el uso de software libre en los softwares hechos a medida excepto en casos estrictamente justificados (costo, razones técnicas).
• Que regulen y expliquen el como los datos de los ciudadanos se van a almacenar en servicios externos. Aquí en Alemania está prohibido sacarlos del país por ejemplo.
• El uso de estándares: acceder a la información del gobierno, datos, etc en forma transparente: Las APIs de Obama, o la discriminación que uno sufre cuando te obligan a enviar datos en formato .doc.

Release fast, release early. That is what I am trying this time so don’t get too excited. I only added one feature. Yes one.

You can list the pending submit requests related to you. Nothing else. And not with a very pretty layout

but it will get better.

However, I have an infrastructure in place that will allow me to consume the API very easily, and I will push new versions every time I add something.

What I want to add next?

• Improve the user interface so that it looks pretty
• Ability to act on a request and see the diff (colored!)
• Explore projects and packages
• A service that polls for build failures and show notifications. Same for requests.

I don’t plan to implement the whole user interface in a phone, but mostly the parts where a phone makes a good tool for the build service. Do you have an idea? Screen mockup? Share it with me!

To try it, just search “opensuse” in the market. The code is available here.

openSUSE is a gem for ruby development

In this post I would like to show what openSUSE has to offer to ruby enthusiasts.

The latest openSUSE version ships with ruby 1.8.7, rubygems 1.3.1 and rails 2.3.2. The latest two being not so recent, here is where the openSUSE project shines. Say hello to devel:languages:ruby and devel:languages:ruby:extensions build service projects.

The first is a project containing a more recent 1.8.7 ruby (p249 vs p72 in 11.2). However, as a build service project, it is built on top of multiple targets so you can add this repository not only to 11.2 but also to SLE and older openSUSE releases.

In this project you will also find a ruby19 package which is nothing else than ruby 1.9.1 p376 installable in parallel with 1.8.7.

The devel:languages:ruby:extensions contains ruby libraries and gems. For example you can find rails 2.3.5 there. Libraries are usually packaged as ruby-something and gems are packaged as rubygem-something. Gem packages have some nice attributes:

• They are visible by the software management stack (rpm ZYpp, and all the ZYpp integrated tools: PackageKit, YaST, etc)
• They are visible to the gem tool. The rpm is installed where the gem tools expects to find it
• They are the best choice if you want distribute a fully packaged application, or an appliance using SUSE Studio
• You can easily create them from a standard gem using the gem2rpm-opensuse script included in the rubygem-gem2rpm package

To add the gem repository to your 11.2 system, just do (as root):

zypper ar 
http://download.opensuse.org/repositories/devel:/languages:/ruby:/extensions/openSUSE_11.2 rubygems

Living on the edge

While the ruby environment provided by openSUSE is great, you may want to go one step further. What comes to my head:

• If you have both ruby and ruby19, you would need to have a different package for each ruby interpreter
• Sometimes you want to try a really experimental virtual machine, however openSUSE offers no package for it (eeer, and experimental VMs make packaging difficult, especially if the developers are MacOS users whose build script download prebuilt binaries of LLVM over the internet eeeek!)
• If you run or develop applications in the same machine, you may want to isolate the gem environment for each applications
• You may want quickly to test a program with different interpreters.
• You may not have root access! And sadly quacking like an administrator won’t give you superpowers.

Enter rvm, the ruby version manager

rvm is a nice tool that can quickly compile ruby interpreters from source and switch between them, all without root access (you can also set the current interpreter to the “system” one). Gems you install for one interpreter are isolated from the other interpreters, and you can create “gem sets”.

While rvm can be installed really easily:

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

for the HEAD version in github or

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-latest )

You can also install it the “openSUSE way”, if you added the devel:languages:ruby:extensions repository:

zypper install rubygem-rvm

Once you have it installed, you will need to run rvm-install (as user) and edit your shell profile so that the environment is set correctly.

Then you can start using it. To see all the interpreters available in your system:

rvm list

To see all the ones known to rvm:

rvm list --all

Build 1.9 from source:

rvm install ruby-1.9.2-head

Build JRuby:

rvm install jruby

Use jruby:

rvm use jruby

Then you can “double check”:

ruby -v

jruby 1.4.0 (ruby 1.8.7 patchlevel 174) (2009-11-02 69fbfa3) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20) [amd64-java]

Combine rvm with the powerful bundler

Of all the new ruby tools, the ones I find most useful is the bundler, which was created as a rails independent solution to make ruby applications specify the gems they need in their environment.

You can create a Gemfile in the top level directory of your application:

Something like.

source 'http://gemcutter.org'
gem "rails", "3.0.0.beta3"
gem "runt", :git => "http://github.com/tevio/runt.git"

As you can see, you can specify gems from git repositories, or use specific branches or versions. This is really nice for deployment, as you can get the working environment really easy.

bundle install

Would install the missing gems. It would reuse system gems, etc. If you are using rvm, it would install them in the interpreter specific gems.

The bundler has more advanced features, like the ability to take all the gems and “bundle” them directly “in” the application, but I leave that as an exercise to the reader.

Conclusions

So that finishes this post. I hope you could see how openSUSE looks like for a ruby developer.

I would like to first thanks Marcus Rückert (a.k.a darix) as he was the main brain behind the rubygem packages. Also big thanks to the YaST, Klaus, SUSE Studio and Build Service teams, whose development resulted in many package updates and contributions.

You can find the packages in my home project.

Changes

• Gemified. It is now available as a ruby gem. The rpm package is now therefore rubygem-enhancerepo
• Changed command line option parsing: for multiple items in an option, don’t use commas anymore: –generate-update pkg1,pkg2 becomes –generate-update pkg1 pkg2
• Support for product metadata generation from release packages. Enhancerepo will scan *-release rpm packages and insert product.xml information in the metadata.
• Bugfixes for delta and updates generation
• Improved output

Thanks

This release was possible thanks to contributions and testing from Michael Calmer and Jordi Massaguer Pla

Next release

A 0.4.2 release will follow shortly, because 0.4.1 was queued from some time already. At least 2 features are planned for 0.4.2/0.4.3

• Merge splitting of any metadata patch from Jordi Massaguer Pla
• Merge pattern conversion patch from Michael Calmer

About Enhancerepo

Enhancerepo is a tool to edit and index rpm-md (a.k.a yum) software repositories. It is developed in gitorious.

Main features:

• Reindex metadata
• Generate delta rpms from different package versions, and the corresponding metadata
• Generate updates (patches) metadata from different package versions
• Insert keywords and other properties
• Create product descriptions from -release packages

In May 2008, Facebook announced that they were planning to add XMPP (a.k.a Jabber), the standard messaging protocol behind Google Talk and other chat programs, to their Facebook Chat solution.

In May 2009, seeing that nothing happened, I announced that I was working on Facebook support for Kopete and released a prototype on github. The plugin was not perfect, and it was talking to Facebook using non-standard ways (including html scrapping!), but allowed people to see their contacts and chat.

Yesterday, Facebook finally announced XMPP support. This means various things:

• You can connecto to Facebook chat using any XMPP compatible program: Kopete (using the standard Jabber plugin)
• My Kopete plugin is not longer needed and will be deprecated

To setup it with Kopete just add a Jabber account like this:

Kopete preferences for Facebook chat

This is a great move from Facebook. As Lars already mentioned, the Web 2.0 sites have brought lot of innovation and fresh wind to the Web. However, they have ignored interoperability a lot, and he is right, you need “connectors” to get your data.

The Web 2.0 has changed the way users store their data. Now it is everywhere. Without good interoperability we are only adding complexity to users.

If your website implements contacts, don’t forget to add a url with a http accessible vCard list. If your site implement events, provide an url with iCal entries. Google has done a good job with Google Calendar and Google Mail. Worth to mention the urls with calendar/contact entries can be “secret urls” which contain a long random string, but require no authentication, which makes it easy to add to your desktop mashup utilities, organizers, plasmods, etc.

Facebook still could do more. They invented a whole new email system. But they forgot to offer IMAP/SMTP interoperability with it. I am not sure either (feel free to correct me) whether I can generate a secret url with iCal entries of Facebook events as well.

Anyways, big thanks to whoever is responsible of getting this done. You did a big favor to the Internet itself.

As for Kopete. As protocols start to use XMPP, the need of hiding XMPP for the end user arises. The account wizard should display the services known by name, and do the XMPP setup with the known preferences. May be something I can work on now that I don’t need to maintain the protocol anymore. And I almost forget: we need a way to migrate current users of the plugin.

With the availability of up to date software for openSUSE, thanks to the amazing build service, our users have started managing the software in ways we did not imagined some years ago.

Update? Upgrade?

This has created some confusion between operations like update and upgrade, package vendors and the package selector functionality. This new situation plus the confusion leads to bug 548551

When you install a package, it has a vendor. Official packages have the “openSUSE” vendor. While packman packages vendor is something like “Packman Project”, and packages from the build service, have a vendor based on the project name, like “OBS KDE Project”.

Updating your system means looking for the latest package of the same vendor that can be installed without doing destructive operations to your system, like uninstalling another package due to a conflict. This is the reason for behaviors like:

• “zypper up” does not pick latest KDE packages even if the repository is added
• An official update (same vendor) for SoftwareFoo is available, but because your custom libSomething packages conflict with it, the update is not applied.
• However, if you manually switch to the packman package, “zypper up” will upgrade from now on using new versions of the package in the packman repository, and therefore ignoring the openSUSE one.

This behavior is expected as we don’t consider a package with the same name to be the same package across vendors. A packman package may include mp3 support and the one in the openSUSE repo may not. If packman updates this package every monday, and openSUSE does every Friday, “zypper up” would end with your application having mp3 support depending on the day you are upgrading.

Bleeding edge repositories

If you are using a distribution like openSUSE Factory, packages are removed, split, renamed and aggressively replaced by new versions. This makes moving from a openSUSE Factory installation on a given day, to the state of the repository some time later a process that may require more aggressive operations, like downgrading packages or removing others, in order to reach the goal of moving to the second point.

As we explained above, the update operation won’t do this. The right way to do it is to perform a distribution upgrade. People using “zypper dup” are doing exactly this. This operation will move your system to the versions of the available packages. This may actually mean downgrading and removing installed packages. The recommended way to do this, is to perform it against a specific repository. This helps narrowing the “goal” further than telling the solver to do a “wide” distribution upgrade. This is what “zypper dup –from repo” should do.

If you intend to use “zypper dup” without an specific repository. You need to define repository priorities if you don’t want to encounter some surprises. For example you could set packman to a higher priority than openSUSE Factory so every Factory update does not remove your mp3 support.

What was missing?

Part of the confusion, and the difficulties to follow repositories with latest versions of big components (like KDE) on top of a stable release (like 11.1) comes from two sides:

• “zypper dup –from” was broken, and therefore performing a “wide” distribution upgrade ( bug #549490), which is fixed now (1.2.7).
• YaST package selector had no support for performing upgrade operations. This is available starting yast2-qt-pkg 2.18.18.

Upgrade operations are requests to the solver. When selecting packages by selecting the latest one manually (what “upgrade all in this list” did) you are not necessarily selecting the one the solver will select. Therefore such operations are best represented as “requests”, which can be combined with manual user selection/removal of other packages.

When browsing the packages in the repository view, you will see a notification that allows to insert a request to the solver to switch all installed packages to the versions of this repository.

Once you file the request, you will see the list of repository upgrade requests. You can cancel any of these.

And finally, you can do this in multiple repositories (equivalent to passing –from multiple times to zypper).

I hope this post made more clear how this operations work. The changes described above should be available in Factory soon. And may be we need to think what to do with legacy functionality like “upgrade all in this list”.

You can use the new functionality to stay current with your favorite desktop environment community repositories, or why not, to stay current with Factory.

I have released kopete-facebook 0.1.4 which fixes idle status of contacts and message sending.

I still have some important bugs, which I hope I can fix before the openSUSE 11.2 release.

From those known bugs, one is the inability to reconnect (go offline and offline), which is due to the “myself” contact using the email as userid, which is in turn due to a Kopete limitation of needing to know an id, but facebook sends it after login. I have tried so many hacks (like switching the myself contact at runtime), but all have other side effects.

Another one is a crash at exit, which I still can’t understand. Help appreciated.

Note: this plugin is not affiliated with Facebook in any way.

Should appear here soon (or build it yourself).

Long time ago, I wrote about our interoperability efforts built around rpm-metadata format and first-class PackageKit support.

On the rpm-metadata side however, even if we depend a lot on these tools, the situation was far from ideal:

• We need usually extensions to the rpm-metadata to support the features that make the openSUSE software management more powerful compared to other tools
• We are in continuous talk with the yum team to make those extensions common so they can be standardized instead of staying in suseinfo/susedata.xml
• Some of those extensions got implemented, in createrepo 0.9.x
• We are stuck with createrepo 0.4.x plus a high stack of patches
• createrepo 0.9.x requires a recent yum
• yum on openSUSE is unmaintained, and not included in the distribution
• openSUSE Build Service and other infrastructure depend on a proven createrepo (which means they depend on the custom patches)

This situation won’t sustain in the long term, so the following action plan was agreed between various stakeholders:

• we will update yum and createrepo to the upstream latest versions, and maintain them in [the system:packagemanager] project
• all patches except a couple were discarded, so don’t expect those versions to work flawlessly for now, we will reevaluate them one by one, upstream them or discard them
• openSUSE infrastructure will freeze their production version from our project once the newer versions work, instead of maintaining a fork
• as we don’t want to include yum in the default package selection, but createrepo depends on it, yum was split in yum and yum-common (libraries).
• yum is still available in the system:packagemanager, and will be kept up-to-date. We are interested in competition, as it makes the [ZYpp][10] team work harder
  
• I will improve enhancerepo (for custom tag extensions generation) and include it in this project in a near future
• Most patches in the current packages were one liner fixes where the developer did not spent 5 minutes to upstream it. This attitude created a uncomfortable patch mess. We will change this by upstreaming fixes or just rejecting having those patches in the package.

If you use createrepo or yum in your infrastructure, we invite you to contribute to this project! yum-3.2.25 was released a couple of days ago, and it is already available there.

[10]: http://en.opensuse.org/Libzypp