• Buscamos un/a desarrollador  web, con experiencia preferiblemente en Ruby-RoR, aunque conocimientos de otros lenguajes y frameworks son también válidos. Nos gustaría que haya trabajado en proyectos orientado a cliente. Debe estar familiarizado con procedimientos de desarrollo colaborativo y herramientas de Software Libre como bases de datos, sistemas de control de versiones, herramientas de bug tracking, etc.

• Dado que este equipo desarrolla su actividad en la comunidad openSUSE (aproximadamente el 20% del tiempo de trabajo estará dedicado a acciones de comunidad), es interesante que el candidato/a disponga de experiencia previa en alguna comunidad FLOSS.

• El candidato/a representará a SUSE u openSUSE en diferentes eventos, impartiendo charlas, sesiones técnicas y foros técnicos de discusión. Debe por tanto disponer de buenas dotes comunicativas. Experiencia previa en eventos internacionales de comunidades de desarrollo será un elemento positivo para la evaluación.

• El puesto de trabajo está localizado en Nuremberg, Alemania, aunque se desarrollará enteramente en inglés. En función de la valía del candidato y su país de origen, es posible retornar a su localización de origen tras 18-24 meses de trabajo en nuestra sede, teniendo que desplazarse a Alemania un par de veces al año.

• En general, SUSE contrata desarrolladores de cualquier parte del mundo. Habitualmente ayudamos a los candidatos seleccionados a tramitar su permiso de trabajo en Alemania (u otras sedes donde se localice la vacante) si fuera necesario. Pero dado que necesitamos cubrir la vacante lo antes posible, aquellos candidatos que ya dispongan de ese permiso, o sean ciudadanos de la UE, tendrán cierta preferencia (no es un requisito imprescinsible). La vacante también está abierta a empleados de SUSE en otras sedes de la empresa como Taiwan, Beijing, EE.UU. o Praga.

Por cierto.... en SUSE nos gusta cada vez más el español.....

• Participa en el proceso de selección para este puesto .
• Participa en otros procesos de selección.
• Información adicional sobre vacantes en SUSE. 

Aplicando a la vacante a través del enlace, me llegará tu CV igualmente, así que te ruego sigas el procedimiento apuntado arriba...me ahorrarás trabajo y asegurarás que tu propuesta no se pierde en mi ya de por sí saturada Bandeja de Entrada. ;-)

Por último, quiero comentarte que solemos recibir muchos currículum para cada vacante. Los Team Leaders los revisamos todos. Sin embargo, debido a la cantidad de vacantes, el equipo de Recursos Humanos no puede canalizar el envío  personalizado de respuestas a todos los candidatos. Sólo aquellos que llegan al estadío final reciben dicha comunicación.

No es probablemente la respuesta que merece tu esfuerzo como candidato hacia nosotros, pero nos resulta imposible gestionarlo de otra manera. Te pido disculpas por adelantado si aplicas pero no recibes respuesta más allá de la automática. Y he pasado por ese proceso y no es agradable. Simplemente, no puede ser de otra manera.

A few weeks ago I published in this blog the general requirements of the opening for my team at SUSE. I come here again with another description for another opening we have for the openSUSE Team at SUSE. The basic requirements are the following:

We are looking for a web developer, preferably with experience in Ruby - RoR (although other languages frameworks are also valid), that have worked on customer oriented projects. He/she must be familiar with popular Free Software data bases, control version systems, bug tracking tools, etc.

Since this team is very community oriented (20% of the working time will be related with engagement activities), is interesting that the candidate have a FLOSS community background.

The candidate will need to represent the team or openSUSE project in events, giving talks, participating in training sessions, meetings, etc. He/she must have good communications skills. Experience in international community oriented events is a plus.

The position is located in Nuremberg, Germany, although only English is required. Depending on the candidate’s experience and origin, it is possible to move back to his country to work remotely after 18-24 months, having to travel to Germany a few times a year.

In general, SUSE hires people from all over the world. We usually help those who are from outside the EU to get the work permit to work in Germany or Prague. But since we need to fill the position as soon as possible, it will be a plus, not a requirement, if you are a EU citizen or already have permission to work in a EU country. The position is also open for SUSE employees from US, Taiwan, China or other countries.

As a mentioned in a previous post, SUSE are growing and has a very good combination of a hacker and customer oriented atmosphere. The openSUSE Team at SUSE is formed by employees that work full time in this community project, which I think that it gives the position a plus for those who enjoy interacting with contributors and professionals in a learning and innovative ecosystem.

Finally, if you apply for one or our openings but you better fit in another one, or there are several good candidates for a single position, take in consideration that each selection process is not isolated. So escalating through a process for any opening, increases your chances to succeed in another opening for a different department.

• Apply to the opening
• Apply for other openings
• Further information about openings at SUSE

Applying to the opening through the above link ensures that your CV will be received by me, so please follow it so we make sure your CV do not get lost in my Inbox. ;-)

Finally, I want to say that the Team Leaders at SUSE check every CV we receive through HR. But due to the high amount of candidates we usually have, we cannot send a personal answer to every candidate (through the HR Department). Only those candidates that get to the final step of the process received them.


This is probably not the answer that you deserve as candidate from us but we simply cannot handle it in any other way. So if you just receive the standard automatic response, receive my apologies.

After some iterations of updating the system with zypper dup or yast and some years of service with the system you will find out that there is a lot of dust which is obsolete or has been forgotten. Recently I had the problem that I need to move my 32bit system to a 64bit system and thus the way to go was to migrate the running system into an image description, build a 64bit image from it and install that on the 64bit machine. But the most important part was to cleanup the running system and find out what it really contains. The report kiwi migrate created here was helpful and so I think it might be helpful for others too. Just call:

kiwi –migrate mySystem

It will end up with some data below /tmp/mySystem which of course can be removed at any time without any risk. Most interesting is the html report generated which you can view with any browser. So far kiwi collects the following information:

• kernel version and kernel specific kmp packages
• hardware dependent packages
• installed gem packages
• repository checkouts
• rpm packages installed multiple times
• rpm packages which could not be found according to the current repo setup including version and repo information
• tree of modified files, packaged but changed
• tree of custom files, those which doesn’t belong to any package or other part of the bullet list

basically the use case of kiwi migrate is to migrate the running system into an appliance description but I’m not there yet. There is still room for improvement but I think it still can help to cleanup the system and to see what is installed on the system and not managed by a package manager

I have tested this since openSUSE 11.4

Remember to have fun

I received some feedback yesterday about the talk I gave at the openSUSE Summit. Unfortunately there is no recording of the talk. I thought that it was being recorded, but it was not. That is why I am posting the full talk here as I wrote it before the presentation. Hopefully it makes sense and gives an idea of what direction we have for welcoming new contributors.

----------------------------------------------------------------


It seems like yesterday when I was finally able to hold a computer. I was fascinated by the shape of this instrument, the keyboard, the mouse and screen. In my mind there was simply too much genius into this machine that I could never be capable to invent something quite like this.
Back then, having an Internet connection was a dream. Playing with the regular default games like Solitaire were the most entertaining activities in my day sitting in front of the computer.

Although I always believed that computers were going to be part of my future my life took a different route later on. I became very interested in the arts and I became a sketcher, drawer, and painter. I also enjoy history and learning languages. In fact, I graduated with a history degree from college. I enjoy good design and clever organization.

However, my old Windows 95, wasn’t what I needed. I wanted to place the arts into the computer so I embarked in the search for an operating system that would give me the flexibility of working with my art and interests, as well as providing good design and powerful tools for the desktop.

I found a page on alternative operating systems and tried some free alternatives of the time; QNX, BeOS, a few others that failed and eventually I ended up in Linux. I started  buying Linux magazines. They featured burned CDs with a Linux copy of whatever system was issued then. Dial-up connections took longer to get the ISO than the magazine shipped to my town, so I chose the magazines over the Internet. I tried installing Best Linux, Mandrake, Slackware, Suse, PC Linux OS, Ubuntu, Vector Linux, PC-BSD, and a few others. In spite of the hardware compatibility problems of back then, eventually Linux became more robust and it was able to work with all of my hardware was the one I would choose to use.

In this search Suse fit right in. I was able to work with all of its tools and the good ol’ KDE 3. I loved the KDE interface and the font system. I am sorry if there are any Gnome lovers in the audience and if this offends you. I loved the power configurations that you could do on KDE as well as some window style themes like Domino window style and others. I was able to use GIMP, Krita, Kaffeine and a few others.

Working with Linux filled my spirit with great enthusiasm. I realized that Linux was present in many places already and that the industry would eventually embrace Linux by porting applications to it. This time was when I started asking for support on IRC. I saw the good amount of people who loved Linux and how willing many of them were to help new users like me. IRC showed me that there are people in this world still who will donate their genius to the world. People who will use their free and busy time to code for an open source project. I decided to give back to the community. But the question was not about willingness, but about ability? Did I have what was needed to enter an open source community?

This is what brings me here today. Stories like mine are countless and yet it seems so refreshing to share them. Coming from the non-technical world, working with the community was a challenge. How can you, who only “uses” a computer, contribute in any meaningful way to the project that “codes” for computers?

As I mentioned, I used IRC to connect to some of the members. First asking some questions and then giving suggestions. But many things that “I” wanted were not so easy to do, therefore my suggestions went nowhere. A typical response from the community was, if you want to change it, do it yourself. While that sounds like a very good response that empowers individual users to work with open source code, there was little I could do to help or change what I wanted to contribute with. I tried long and hard for a while to convince some people to put into code some of my ideas but with little success.
I decided to reduce the scope of my requests. Little by little I realized that, instead of asking for changes, I needed to contribute. I could not make others contribute for me.

I decided then to create a blog. Just a simple tool to show others about my ideas on GUI design. The blog still brings some people to it. I am not the next Facebook but I do feel like my ideas posted there get some traction. I published ideas on how KDE could look on openSUSE. I focused my comments particularly on working with KDE 4 and openSUSE. I have always wanted a radical GUI change for openSUSE, and I still do.
I do not think that my comments got too far. The biggest thing achieved by my blog was when Aaron Seigo from the KDE project read one of the entries on my blog and decided to show a quick programing example using a desktop switcher idea that I wrote about. I didn’t even ask him to do it and it happened. My blog had reached further that I could ever do it on IRC.
I realized that I needed to speak the language of those who change the current in the Linux world, and that was by doing it yourself. But I needed to focus my contribution. I could not ask anyone to code for me but I could sway opinions about artwork. Overtime I have participated in creating some simple artwork for the distribution. Recently, we had a Novell conference in the town where I live. I was invited to it and met some of the people I mingled with on IRC.

My involvement with the openSUSE community could represent the involvement that many other non-technical contributors go through as they approach working with open source communities. I happen to be a historian and my training has made me take a more critical look at the events that lead up to my participation and the participation of non-technical contributors to the projects we love. When I mean non-technical, I mostly mean that I cannot program code.

Being part of an open source project is in its very nature a “public” event. Just like I had to become “public” with my blog, open source communities are not only open source but also public source. Meaning that the very nature of your contributions to an open source project are made publicly available. It is a meeting where the whole world is invited. Open source projects are perused thoroughly. Interestingly enough, in many instances when the solitary confinement of a home basement gives birth to wonderful open source projects that attract much attention to programmers who might not expect to be in the forefront of their project.

Take, for example, Linus Torvalds. By sending a simple invitation to write code for his newly developed kernel, Linus became a star ever since. However, Linus remains away from the spotlight, as much as he can, by avoiding large audiences and venues that place too much attention on him. Although Linus remains a fiery commentator, he has never liked the attention that his kernel brought upon him. This could be true of many other programmers who may be confronted with the publicity that their open source work generates.

The project created attracts people of all places and languages. Even people who who may not understand the complexities of the creation of such project. People who only see the end result, the non-technical user. However, the expectations vary from audience to audience as the open source project is made available. In the case of non-technical users, they may demand that the functions of the software be perfect. Many new users assume that the developer is completely in charge of the open source project when in most cases there may be many contributors to the project who do not have specific functions. This situation makes support harder to achieve on the end user’s point of view. Many of them will feel left out when trying to understand why a certain program does not run on their Linux computer.

Non-technical users who want to contribute will also assume many things when coming in contact with a technical open source community.

Recognition
Collaboration
Availability

Technical users on the other hand expect
Recognition
Collaboration
Availability

I categorized these priorities as the same on purpose. However, the interpretation of these terms is rather different depending of what end of the spectrum you are.

On the non-technical collaborator side, recognition means that non-technical user contributions do have weight and are understood by the rest of the community members. We may incur into thinking that our contributions are truly ground-shaking, earth-shaping, world-saviors. Non technical users will think that their simple ideas put them ahead of the thinking done by technical users. We have a better answer.

However, for technical users who can program, recognition starts when others understand the trouble, time and effort that they took into creating a piece of software for the world to use. Recognition that their work has class and it is relevant for others. Overstepping these ideas on both worlds could lead both type of community members to disagree in their views about a specific project. While technical users are contempt, for example, with the powerful features of Yast in openSUSE, some like me might be unhappy with the GUI design of it. We are speaking about the same project yet, I could miss the recognition solely based in my assumptions about Yast not being good-looking and missing the fact that it is a powerful graphical tool.

Similarly, technical users may focus on the programming strengths of their software and miss the graphical elegance that you could integrate into the program upon suggestions from a non-technical community member.

In these interactions both type of members may also misunderstand the collaboration that each of them can integrate into a particular project. While there is always assumptions about newcomers and over-stayers in an open source project, there is also a good amount of misunderstanding about one’s capabilities. If you are a newcomer to the open source world, being non-technical may brand you as someone who “does not understand everything” meaning that overall there are many things for you to learn before entering a project. On the opposite end there is also assumptions made by non-technical users about the technical users’ collaboration. Non-technical users assume that technical users operate much like a customer service department. They are part of a project only to help and fix problems. While some of this hints at the reality, it is only a partial picture of reality.

Non-technical users miss the opportunity of collaborating with the tech savvy because they only intend to drive the development of an app and rarely intend to do it themselves. Both parties then withdraw and little advancement and integration is made.

Availability is another convergence point for open source project members. They have, as experienced, expectations about the availability of each party. While technical users always seems to be ready to take on order on IRC, nontechnical users should join a project only if they are able to put in the time to work on it, or for it. Neglecting people’s availability is a major cause of project coding delay. Not understanding the work and part that each person takes in a project could result in a release that is half-way done. Often times new users in a project may assume that people are online 24/7 thinking that emailing will not take long, IRC chats and comments will be instantaneous, and that adding a line of code will be done telepathically. In reality, most of us do not work for the project. The project is a side note, unless you are apart of a corporation such as Canonical, or Novell, and people have been assigned to work for open source projects. This does not mean in any way that people who have been hired for a specific community project have a little less desire or time to work on it. The point is that the majority of us contribute with free time or do something on a whim. It happens to me personally, I get inspired to create artwork at random and suddenly this could be interpreted as me signing a life of devotion toward a project, when in reality I would only like to have my work be used and forget about it later.

This could also account for a high turnover of contributors to open source projects. Likely new users, technical and non-technical join a project with the fire of their desire to contribute with an idea. Suddenly they are confronted with the three misconceptions outlines before and realize that open source project completely depend on the voluntary contributions of its members. I highlight “voluntary” because this word shows elasticity in time frames, consistency and desire to strive with a particular project. Then, newcomers slow down, their fire goes out and eventually they could become a passive or completely inactive contributor.

Some may think that the project or the community will be magnetic enough on its own that people will join the community by its sheer weight, however this may not be the case all the time. Non-technical users get to feel the weight of the disparaging differences between how little they know about the community and what a tough relationship this could be when trying to make contributions to a community that is far more experienced in coding and other venues.

Eventually, a miscommunication between the technical community and the non-technical contributor could lead into the break between potentially great contributions and a project that could actually use the contributions. After all, the life of a community comes from its members, there is nothing done in a community project until a member contribution is made. Meaning eventually that not having any use of the new non-technical contributors makes the project slow down, and miss opportunities for change and advancement.

Willingness of new users to learn the ways of the community is also fundamental for the healthy relationship between the two. New users are to be much like a sponge when coming into contact with the community. There might be many instances when there were new members unwilling to learn the ways of the community. Unwilling to understand and follow established procedures as well as traditions. In this case it does not matter how brilliant a new community member might be, there is an element of personal appreciation in the community, the additions will not be taken into consideration. The technical community member will disregard your contributions as important.

Obviously, these are very general statements from personal observation throughout my time with the openSUSE community. Can or is this situation any different? of course. Is the community to do anything to keep or invite new members? Yes, definitely. There might be some programs, such as the ambassador program in openSUSE that empowers community members to participate in the community by adding what they can. But introducing people to the local community might not be as challenging as introducing a new community member to a global community. Then there is less to manage, less faces to see, and eventually, less work to be done.
The goal of this analysis is not to point fingers at community members for not understanding the non-technical population of their teams, but rather to understand the tremendous potential that their work can accomplish. Making ourselves cognizant of the tremendous reach that we can achieve with our communities by embracing non-technical users could be the biggest accomplishment of an open source community.

Some could wonder, how is it possible that a community that advocates the creation of code is capable of being so welcoming that even the least technical person can be part of it? This realization by the rest of the users and open source enthusiasts can eventually gather a swarm of strong collaborators to a project. Injecting the needed speed and expertise into a particular project.

Our aim however is the reach of harmony. While we all may be different species, we live in the same jungle harmoniously. What does it take for non-technical users to join the pack of technical users? A simple reminder of what we can do and the water we are trying to swim on. What does it take for technical users to understand non-technical users? It is to understand that we all need water to survive. Whether we like it or not, we will come to the river for sustenance. Some of us will likely stay next to the river for the rest of our lives.

Thank you

Recently Fedora’s Lukas Tinkl pushed to kdelibs (for the 4.10 release) a patch that enabled Solid to talk to udisks2, which is a replacement for udisks. Fedora already moved to udisks2 (and killed HAL) and future GNOME releases will only use udisks2, so the need for a working backend was a necessity, and at the same time they acted like good open source citizens, and pushed the code both to 4.10 and the KDE Frameworks branch of kdelibs.

Unfortunately, there was a snag: the code was there, but not getting compiled. But no one noticed, as Fedora was patching the CMakeLists.txt during their build process (it wasn’t a mistake: they were removing things they didn’t need from upstream KDE, such as Solid’s HAL backend). At the same time, Alin on the openSUSE Factory mailing list noticed that with udisks2 he didn’t get devices offered by the Device Notifier widget.

So that’s where myself and Raymond, an openSUSE member and contributor, went to investigate the issue. Indeed, there wasn’t any reference to the UDisks2 backend in the build system for Solid. That’s where Raymond took off, and started to adapt it. At some point, we were stuck, so I pinged the helpful Rex Dieter from Fedora and he directed me and Raymond to #fedora-kde. There a quick discussion with Lukas Tinkl himself and Kevin Kofler helped ironing the final thigns out. In the end, Raymond produced and pushed to KDE’s repository a patch to enable the building of the backend.

What’s the lesson learned from this? That despite distro wars, differences, and even heated debates, collaboration is still a key aspect of FOSS. And in the end the talks between upstream (myself, although I’m not a professional coder by any means), openSUSE (Alin, Raymond) and Fedora (Lukas, Rex, and Kevin) ended up with an improvement that benefited KDE and by association everyone using it.

In short: FOSS rocks also for this.

_Note for Planet openSUSE readers: _This is my first post for planet openSUSE, so hello to everyone. Perhaps a proper introduction will come later…

Today is the second day that the openSUSE Summit goes on in Orlando, Florida. Attendance is great. There are lots of people here, more than we initially expected, attending and making great assertions to each of the sessions going on. If some of you are in the area and would like to attend, please go into this website and look up the appropriate information.

Yesterday I was able to see some of our team's contributors, Sebatian (tian2992), Eugene, (it-s), and Richard (Ilmehtar). We decided to get together today, at some point, and work on some guidelines for our team. We will be making a few proposals to the team, because of this, later. The idea is to streamline our work. We understand that there are many ways in which the artwork team can fulfill its functions, but in the end, it really needs to comply with release dates more strongly. Right now, we are planning to create steps for our artwork to be done before release, we are also planning to work with people to come up with new design ideas for the distributions and, in the future, change our UI a little more.

The main idea is that we can do a good brainstorming here and then make proposals, mockups, and so on. Eventually, we will present these ideas at the openSUSE Conference and to the rest of the team later at the mailing list. We don't want to post something that is just ideas and half-way done. So stay tuned.

Today is a great day for a couple of our contributors. Richard Brown (Ilmehtar) will be presenting today and also me, Andy (anditosan). My presentation will feature a live stream. If you want to see and listen, please go here.

https://new.livestream.com/accounts/1483845/events/1544568

Broadcast will start at 2 PM Eastern Time, USA.

I hope you enjoy!

Na falta do que fazer, resolvi entender como funciona o Django admin. Como os desenvolvedores daqui reclamam do aplicativo que foi construído pela equipe p/ gerenciar os produtos e os bugs (na minha cabeça isso é uma tentativa de justificar os erros que a gente encontra no que eles desenvolvem), resolvi tentar fazer uma versão em Django. Como isso não é pra ser usado, então não tenho pressa.  E

Da es anscheinend noch keine Anleitung auf deutsch gibt wie man sein Arch Linux auf systemd umstellt, werde ich mich nun daran versuchen. Folgend werden wir ein Arch Linux vom alten init-System auf systemd umstellen.

Pakete installieren

Zu allererst ein volles Update des Systems mit dem Befehl:

pacman -Syu

Nun installieren wir systemd mit dem Befehl:

pacman -S systemd

Konfigurationsdateien erstellen

Jetzt legen wir folgende Dateien an mit dem jeweiligen Inhalt:

/etc/hostname

#hostname vom Rechner

 

/etc/vconsole.conf

KEYMAP="de-latin1.map.gz"
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

 

/etc/locale.conf

LANG=de_DE.utf8
LC_COLLATE=C

 

/etc/timezone

Europe/Berlin

Kernelmodule eintragen

Wenn zusätzliche Kernelmodule geladen werden müssen die in der /etc/rc.conf stehen, so müssen diese noch extra eingerichtet werden, da die rc.conf bei systemd in diesem Falle ignoriert wird.

Legen Sie für jedes Kernelmodul das geladen werden soll im Ordner

/etc/modules-load.d/

eine Datei an. Hier am Beispiel vom vboxdrv

touch /etc/modules-load.d/vboxdrv.conf

und schreiben Sie in die Datei den Namen des Kernelmoduls

vboxdrv

Dies wiederholen Sie mit allen zu ladenen Kernelmodulen.

systemd einrichten

Nun kommen wir zur eigentlichen systemd Konfiguration. Zuerst müssen wir das target, also das Ziel festlegen, was in unserem Fall das Ursprüngliche init 5 oder bei systemd das graphical.target ist.

Mit dem Befehl

systemctl enable graphical.target

geben wir dies an systemd weiter.

Nun müssen wir noch alle Deamons die beim Start geladen werden sollen, angeben. Schauen Sie dazu in die /etc/rc.conf hinein und übertragen Sie alle zu startenden Deamons in systemd.

Steht in der rc.conf zum Beispiel

DAEMONS=(syslog-ng acpid dbus iptables networkmanager ntpd alsa cupsd crond kdm)

sehen die Befehle an systemd so aus:

systemctl enable syslog-ng.service
systemctl enable acpid.service
systemctl enable apcid.socket
systemctl enable iptables.service
systemctl enable NetworkManager.service
systemctl enable ntpd.service
systemctl enable cupsd.service
systemctl enable cronie.service
systemctl enable kdm.service

Ohne NetworkManager benutzen Sie einfach

systemctl enable dhcpcd@eth0.service

Tipp: Manche Deamons haben andere Namen im systemd. So heisst zum Beispiel cupsd bei systemd cups.service. Um den richtigen Namen zu finden kann mit

systemctl --all | grep cups

gesucht werden.

Altes init-System löschen

Nun müssen Sie noch das alte init-System löschen

pacman -R initscripts
pacman -S systemd-sysvcompat

Das war es auch schon. Nach einem Neustart sollte systemd den Rechner nun ohne Probleme hochfahren. Sollte ein Deamon nicht starten können Sie die Fehlermeldung mit

systemctl status [deamon].service

abrufen.

Mehr Informationen zum Thema systemd in Arch Linux gibt es in dem sehr ausführlichen Artikel unter https://wiki.archlinux.org/index.php/Systemd

Wichtig: Wer auf der sicheren Seite sein möchte kann initscripts auch erstmal behalten und mit dem Kernelparameter

init=/bin/systemd

ausprobieren ob systemd wie erwartet funktioniert. Ist dies der Fall kann dann das alte init-System wie im letzen Kapitel beschrieben gelöscht werden.

Yesterday, September 11th, 2012, 1.5 million people meet in Barcelona under the slogan "Catalonia, new European state.

Spanish government is trying to minimize it. Please do not ignore us.

See:
http://rt.com/news/catalonian-national-day-protest-independence-925/
http://www.bbc.co.uk/news/world-europe-19564640
http://edition.cnn.com/2012/09/11/world/europe/spain-catalonia-protests/index.html
http://www.guardian.co.uk/world/2012/sep/11/catalan-independence-rally-barcelona?newsfeed=true
http://www.digitaljournal.com/article/332659

IopenSUSE 12.2 got released some days ago and it seems that the plymouth integration is received very well. Even the openSUSE theme got good comments and is seen as sophisticated. This to my big surprise.   But i am very happy about it as that it proofs that we all did a good job. Unfortunately it seems that plymouth in combinztion with NVIDIA chipset can sometimes cause some unpleasant surprises. But lets hope we cn sort this out with the next release.

As that the pressure ix off again, i started to work on updates of KDE:Unstable:SC again. Yesterday kdegames was moved from svn to git and split out in seperate repositories. So a lot of new packages have to be created. Hopefully i can finish this soon, so that i can create a new snapshot this coming weekend.

Also Chromium saw a big chance recently. A couple of builds ago we noticed that chromium started to behave rathar crashy. Investigations showed that the our attempt to build with as much system libraries as possible failed. The chromium developers seemed to hsve r3ached the point where the system libraries are no longer compatible with the ones shipped with the chromium source. So as of two build, Chromium is now switched to utilize its full sourcecode. This resolved the issues and also the wotk required in keeping the opensuse patches up to date.