Home Home > Tag > Build
Sign up | Login

Posts Tagged ‘Build’

osc build with kvm on an encrypted volume group

March 15th, 2014 by

How-to build a initrd-virtio on a fully encrypted volume group

If like me you care about your data stored on your laptop, you certainly use a fully encrypted (excepted /boot) configuration based on lvm.

In my case I also like to create, build, fix packages locally with our tool osc. I’ve plenty of power, beefy ssd, so I dedicate a logical lvm for building cleanly package with qemu-kvm configuration, like obs does

Prepare the kvm building system

As root you create 2 lvm volume with lvcreate, one will be the build root, the other one will be the additional swap

In ~/.oscrc I enable the following parameters

build-type = kvm
build-device = /dev/mapper/vg0-lvobsbuild
build-swap = /dev/mapper/vg1-lvobsswap
build-memory = 4096
build-vmdisk-rootsize = 16000
build-vmdisk-swapsize = 4000
build-vmdisk-filesystem = ext4

You just have to adjust the Memory quantity and the device to what you create for your own environment.

(more…)

Kick off for GNOME:Ayatana Project…

December 29th, 2010 by

“Follow effective action with quiet reflection. From the quiet reflection will come even more effective action.” // Peter F. Drucker

This has been one of the guidelines in my life for quite some time… It started as a curiosity a long time ago with Notify OSD and evolved to full project in openSUSE. It is important to acknowledge at this point the motivation provided by the openSUSE GNOME Team from which I’ve been getting plenty of guidance and help, namely from Vincent Untz (vuntz) and Dominique Leuenberger (Dimstar). Thanks to them, we have now a GNOME:Ayatana Project on OBS (openSUSE Build Service), currently being populated with the support libraries for Ayatana’s Unity and Indicators.

Susan Linton has made a small article for Linux Journal about this project in the past. Though some people pointed to me that it was advertising and excelling Ubuntu… I would like to leave a statement… We’re not taking a hike on Ubuntu visibility, and it isn’t bad at all, on the contrary… In fact it will help Ubuntu, us and many others… specially if some Ubuntu patches are accepted faster by upstream. I hope other RPM distributions will follow the way we, openSUSE, proudly seem to pioneering! From my personal point of view… a distribution ‘distributes’… and despite this software isn’t attractive for some openSUSE users, I’m happy it is available (totally or partially) for all those who want to test it… Wait… you don’t even need to install Ubuntu or changing the platform you run!

Due to several reasons, being the most important of them versioning, this repository will start on the next release of openSUSE in March 16th (World day of Conscience, interesting point). This is also interesting as if YOU are willing to improve a package or submit a package you can now do it to this repository.

This goes with a very huge cookie for Dimstar and Vuntz for taking care of this repository and making sure that everything will comply with the openSUSE Guidelines. You are my personal heroes.

It has been quite an interesting experience to be with openSUSE GNOME team which is full of knowledge and helpful in many ways. I can’t also forget to mention that last week Luis Medinas has taken tutorship of a Portuguese contributor to openSUSE GNOME, João Matias and will provide him the necessary help to integrate him on the workflow of the GNOME Team. My personal thanks to Luis for stepping into this task, which from my personal point of view is very important.

Regarding to Ayatana it is worth to mention that Dimstar provided some valuable help in fixing the dbusmenu package and taking care of the necessary patch submission in GTK and gdk-pixbuf to allow dbusmenu to build with introspection support and generate properly the Vala files required for other packages. This handicap beaten… we’re on the good road for better functionality. This patches also allowed to correct some behavior in some indicators, one fine example of this the ‘Me Menu’ which now displays correctly a  ‘dot’ on the selected status as the screenshot bellow shows:

In the last days, despite it’s Christmas season and soon new year…. I’ve been also working on providing additional extensions to enable some functionality on some indicators. This was the case of indicator-sound, which provides an alternative sound gadget that offers extended functionality with multimedia players. A fine example of this is Novell’s Banshee player which has astonishing out of the box implementation with the sound indicator from Ayatana by a small extension that can be enabled. I’m still wondering why so many people toss heavy critics at this indicator calling it ‘mac styled’… while to be honest I doubt such people have even seen OSX sound applet, which is more or less a direct copy of the one present in GNOME, the vertical switch. Interesting view nevertheless.

Indicator-sound has also been fixed and no longer requires the nasty hack in the previous package. Since I’m not an Ubuntu user, neither I have extensive experience on their Desktop, I’m not sure if the functionality present so far in the indicators is the one offered by Ubuntu. I plan to run a Open Beta on the Ayatana software repository during the last Milestone of Factory to all Factory users to collect more data and improve the packages, at least the indicators, as in the present since I have ATI hardware I don’t have FireGL enabled on Factory, so I can’t really push much on Unity and test it for the time being.

Another subject of plugins was Xchat which is GNOME’s premier IRC client. Novell’s Evolution also got it’s plugin which is found to be partially working. I haven’t tracked yet if there are patch submissions to Evolution from Ubuntu to enable indicator functionality. That’s for sure one of the next steps, and since Evolution is a bit of ‘in-house’, would be nice to have them approved upstream if submitted already, as it would serve openSUSE as well.

Most of this applications, evolution, xchat, gwibber, empathy, pidgin are supported by indicator messages which collects information from several messaging services and places them on a single indicator in a cascade style experience for the user. I personally find it weird as I’m not used to this, but seems nice. Unfortunalty some applications seem rely on patches to be fully supported, like empathy. I hope upstream accepts the patches from Ubuntu (if submitted) and we can also benefit from such changes in our side.

Basically to sum up everything in a short review…

* Indicators are working fully or partially depending on patch level on some applications. If upstream starts accepting Ubuntu patches (some shouldn’t be much of a problem), it will work out for Ayatana software in openSUSE as well.
* Unity – Though it builds already with some compiz packaged from git sources (to include glib mainloop patching), I have no way of testing it, neither I have done integration on it. Unfortunately both my systems have ATI hardware and I have no way of testing it on Factory which seems to be too much bleeding edge for ATI to keep up. It’s stalled a bit, but in the worst scenario will be available a few weeks after the next official release of openSUSE.
* During this wait time… we might see a new release of compiz with the patches upstreamed by Canonical, which will for sure help us also a lot. No need for hurry in Unity at this time.

My personal experience with this project has given me lots of knowledge about OBS, hacking Makefiles and configure scripts… debug skills… and specially I ended up loving the way openSUSE is built and how it works. I would take also this opportunity to make a small statement… all the development so far has been deployed over GNOME 2.32. Much of the software packaged already supports GTK3 and should be easy to migrate it to GNOME3. At the moment, since the next openSUSE release is still based on GNOME 2.32, I’m not testing all this software on GNOME3. It might take a few days/weeks to have it available for GNOME3 after it’s release, though from a personal perspective, what I’ve seen on GNOME3 seems to be overkill! It’s damn nice and I have no doubt GNOME3 will succeed as the ultimate Free Desktop.

I would also like to mention that I’m not testing this indicators with KDE. In case someone wants to do this, please feel free to nag me on IRC (#opensuse-gnome @ Freenode) and leave feedback. I’m focused only on GNOME2 and GNOME3 deployment of this software packages, though I will help in whatever way I can if someone wants to work them out for KDE.

I’m using a patched version of Metacity (patches were submitted upstream) which improves the display of buttons by improving overlaying of images (I think). Look at the sharp corners of the theme in the pic bellow. As always, Faenza Icon theme with Canonical’s light theme Radiance (not hacked). This is another change I hope that goes upstreamed soon.

My sincere congratulations to everyone working on the awesome GNOME3, I’m sure it will be a success and make the delights of many! My faith points that GNOME3 will change Desktop user experience forever!

Have a lot of fun…!

Nelson Marques

Collaboratio

May 21st, 2008 by

Collaboration is not always an easy thing: Talking, meetings, making decisions and finding compromises. Sometimes I have the impression that some people in our business find this inter personal activities very exhausting and thus prefer to work on their own. Depending on how genius one is that works far. But for obvious reasons working alone has limits. If we talk about a whole Linux distribution for example one can not succeed: The working power, creativity and time of one is not enough.

That is one reason why we consider it as one of the keys for success that the Build Service enables people to work together in a useful and non annoying way. We think of tools in the Build Service which help. That is difficult because some formalism and guidance (in business often called ‘process’) is needed to keep things going in a transparent and reproduceable way. Control should stay there where it needs to be, for example at the maintainer of a project. On the other hand collaboration tools should not constrict people and their working together.

Here is a little story of Karl who wants to change something in the openSUSE Factory project. He needs to work with the Factory maintainers and this is how that is planned for the future:

Karl, a developer working for a small software company, loves openSUSE but not really the one package Kabax because there is a packaging problem Karl has analyzed.

Karl wants to change that to make sure that the next version of openSUSE contains a good version of Kabax.

For that, a branch of Kabax in Factory is needed where the fixes can be put in, built and tested. Karl uses osc to create a branch. The package is not really maintained in Factory itself, because the few Factory maintainers can not care about all packages there. Kabax has a Devel Project entry in its meta data that points to the project where it is actually maintained by the expert Karsten.

Because of the devel project, osc branches not really from the Factory package but from the development project where the development happens by Karsten. That might be different from the Factory package, but is clearly the development version that soon will be synced to Factory. When that happens is up to Karsten and the maintainers of Factory.

In the branch Karl starts to work on Kabax and creates a beautiful patch. Since his branch package also lives on the Build Service, it builds live for all relevant repos and along the changes of the devel project.

Once Karl is happy with his work he raises the attention of Karsten on his change by creating a submit request. A request in general informs others of something somebody else has done which requires action. In the case of the submit request it tells Karsten that there is a valuable change to his package that should make it’s way to Factory. Karsten now accepts the request and Karls contribution is in.

The nice thing about all this is also that the branch packages as well as the requests are open and visible to everybody who is interested in. That gives us the transparency we need. And of course that does not only work for Factory but for all projects if one wants to change something on a package where he/she does not have permissions yet.

How do you like this story?