272
I Use This!
Activity Not Available

News

Analyzed almost 3 years ago. based on code collected over 3 years ago.
Posted about 11 years ago
Due to technical issue, the release of HTML version will be delayed by several days. Sorry for the inconvenience. Download the PDF
Posted about 11 years ago
Back to La Cantine for joint talks, great to see Kris porting LibreOffice to compile with LLVM already (so we can get emulated Windows compile warnings, far faster than we can on windows). Out for lunch at an English pub nearby (odd). ... [More] Wrapped up the conference, with sad 'byes to many hackerly types. And out for dinner with the team; wandered at great length trying to find another cluster of hackers in a Scottish pub. [Less]
Posted about 11 years ago
Up early; off to IRILL slightly late for Kohei's talk, but enjoyed that - good to see some progress on the calc internals. Tried to sync. the rooms on two floors' schedule, and adapt to last minute program changes. Out for lunch with ... [More] the Lanedo guys; back for more great hackerly talks, and a pottage of misc. Lightning talks, some of them arranged only minutes before we started: lots of useful grist there and great speakers. Surprisingly pleased by the 'star field' effect from an elderly projector. Gave my web-office talk with slides, and demo video to make up for the lack of a live demo. On to a curious party venue in the evening, did a bit of hacking with Kohei, finally managed to draw my dependency thoughts onto a piece of paper with Eike, caught up with Gabriel, code review with Lior, and fun with Doug & Simon. Incredible that hot on the back of blaming TDF for their inability to monitor the security list (that their committers are on, and are publicly committed[sic] to monitoring); it is now insinuated by juxtaposition that TDF is spreading unwarrented information. It seems that this is related to Team OpenOffice's unexpected announcement that OO.o "can't be allowed to die" and needs to "continue to be professionally developed", which looks like a distraction to me, and is exactly nothing to do with TDF. Interestingly the openoffice.org website (as controlled by ASF) contained (until recently) encouragement to donate to "Our prime treasury - Team OpenOffice.org e.V.". Opening up a dialog with the very guys AOOo are recommending downloaders to send money to might be a good internal housekeeping policy. Certainly it is not TDF's problem whatsoever. Stayed up inordinately late happily chatting with Fridrich & Tibbylickle. [Less]
Posted about 11 years ago
The openSUSE Project offers a wide portfolio of Free Software with it’s premier Linux distribution, openSUSE (currently openSUSE 11.4). While  this packages will cover the vast majority of users potential needs, sometimes a more advanced user might ... [More] require additional features enabled, or just shave down a package to his own needs. This example will cover the installation and modification of ‘mutter‘ with a patch to allow the usage of Ubuntu Light Themes, Ambiance and Radiance with GNOME 3.2. This was tested on a openSUSE 12.1 BETA with GNOME:Factory repository. 1. Installing OBS CLI client, osc First timers will require to install the openSUSE Build Service CLI client, osc. There’s lots of ways to do this,the easiest one is just: $ sudo zypper in osc Follow the on-screen instructions. Additionally, the first time you run ‘osc’ you will be prompted for a Username and Password, this are the ones you use for the openSUSE/Novell infra-structure (ex: forums, connect, etc). Your home project will be: home:$USER (ex: for user ketheriel, home project is: home:ketheriel)   2. Using ‘osc’ to branch a package from a repository The first step will be to branch an existing package (mutter from GNOME:Factory). It’s on this branch that we will apply the changes and test the build. Branching a package is as easy as: $ osc branch GNOME:Factory/mutter NOTE: First time users should always run a ‘osc –help’ to have an idea of the commands available and the syntax. On the above example (osc branch GNOME:Factory/mutter) the syntax is clear enough: osc branch PROJECT/PACKAGE. There are more arguments that can be used, but that’s pretty much enough. By default the package is branched to: home:$USER:branches:GNOME:Factory/mutter (where $USER is your username). You can now “checkout” the branched package with: $ osc co home:$USER:branches:GNOME:Factory/mutter This will create a directory called home:$USER:branches:GNOME:Factory. Inside this directory you have a ‘mutter‘ directory which has the files used to build the mutter window manager for GNOME3. The plan is quite simple: Change directory to  home:$USER:branches:GNOME:Factory/mutter; Make the necessary changes (in our case add a patch taken from Ubuntu); Test the build locally; Check-in the changes; 3. Adding a Patch: spec file and changelog To enable Ambiance and Radiance on GNOME 3 we need to patch mutter with the following patch (taken from Ubuntu).  Change directory to home:$USER:branches:GNOME:Factory/mutter (if you haven’t done it before) and get the patch in with: $ wget -c  http://nmarques.fedorapeople.org/patches/ubuntu/mutter-3.2.0-ignore-shadow-and-padding.patch Add the patch to your mutter package with: $ osc add  mutter-3.2.0-ignore-shadow-and-padding.patch Before we run a local build test, we need to add the patch to the spec file and patch the package on the %prep section of the spec file. Open the spec file with your favorite text editor and add do the following changes: <span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">Summary: Window and compositing manager based on Clutter </span><span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">Source: http://download.gnome.org/sources/mutter/3.2/%{name}-%{version}.tar.bz2 </span><span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;"># PATCH-FIX-OPENSUSE mutter-3.2.0-ignore-shadow-and-padding.patch -- Ignore light-themes shadow and padding attributes. Allows to use light themes on GNOME3. </span><span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">Patch: mutter-3.2.0-ignore-shadow-and-padding.patch </span><span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">Url: http://www.gnome.org We add a comment (# PATCH-FIX-OPENSUSE (…)) which explains what the patch does, and a Patch entry giving the same of the patch file. We still need to patch the application on the %prep section, this is done with: %prep setup -q %patch -p1 The patch macro should patch the application previous to the build. We can now test the build of our patched mutter package with: $ osc build --local-package Everything went right and the package builds? Awesome… It’s time to update the changelog with our changes, this is done with: $ osc vc And provide an entry like: <span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">------------------------------------------------------------------- </span><span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">Thu Oct 13 23:41:07 UTC 2011 - YOUR_EMAIL@ADDRESS <span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;"> - Add mutter-3.2.0-ignore-shadow-and-padding.patch: use Ambiance and Radiance </span><span class="Apple-style-span" style="font-family: Consolas, Monaco, monospace; font-size: 12px; line-height: 18px; white-space: pre;">themes. Taken from Ubuntu.</span></span> -------------------------------------------------------------------   All the changes comited to the package should be a part of the ChangeLog, this will help future maintainers to understand the patching and the package. The final step is just to “check in” the package… $ osc commit This will send your changes to your branch on OBS (home:$USER:branches:GNOME:Factory/mutter). You only now need to install the new mutter package and enjoy! WARNING: This was tested on openSUSE Factory GNOME:Factory. For any other platform, you should branch the package from the respective project.       [Less]
Posted about 11 years ago
Last time I described how to contribute quite to any package in openSUSE Build Service. But I left out the most important part. I haven’t shown how to change anything. This time I want to show you, how to create patches, if you need them, easily. ... [More] Let’s start start with package we checked out from obs. Creating patch for anything is different only in first few steps. First we got to the directory where do we have the package checked out. We run quilt setup This command will parse the .spec file, unpack tarball and prepare all quilt stuff. Now is time for patching, so let’s enter the newly created directory and try following command quilt push You know that in .spec there might be some patches. quilt push will take first patch that is not applied yet and apply it. If you want to go back, you can use quilt pop. You can also use quilt patch -a to apply all patches if possible. If it is not possible, it will tell you loudly and you have to handle situation manually. This often happens when you are updating package to the newer version. How to deal with it? Trick is to start with quilt patch -f which will apply everything it can and tell you about stuff that can’t be applied (and creates bunch of .rej files. Now you have to fix these, but you are already working on patch, so just skip following paragraph and continue with howto If all patches applied without problems/you don’t have any yet, you have to start one. You can also start here, if you don’t have a spec file and you just want to create a patch for some sources that were lying on your hard drive. You can start new patch by calling quilt new package-version-patch-name.patch From now you are working on patch. As patch consists from changes to the files, you have to do that changes now, right? One easy way is to call quilt edit path/file This will open up you favorite editor (the one that is set in your EDITOR variable) and open up specified file and let you edit it. You can also do a little bit different trick. You can use quilt add path/file This just saves the current state of the file. You can then edit it how ever you want or replace it with another file or do some changes to it however you want. Once you are done with editing, it’s time to actually create a patch. You can review all changes by using quilt diff and if you are happy with them, call quilt refresh -p0 This will create patch with patch level 0 (this is the best choice for .spec files, git creates patch level 1 by default). It will also tell you where your patch is. So you can just take it and use it. Last little note, as I already pointed out, you can of course use quilt not only with .spec files. You can enter any directory anywhere and start creating patch using quilt new patchname.patch, quilt edit path/file and quilt refresh -p0. It will work too. quilt setup and quilt push are just great help to apply all patches that you have already prepared and continue from there. Hope this may help some of you with patching software and playing with packaging. Next time, I’ll continue with how do I package MySQL on openSUSE in more details and how do I handle all different variants. [Less]
Posted about 11 years ago
Last week, openQA 1.0 was released. We did an interview with Bernhard Wiedeman, the main developer of openQA. First of all, what´s your job regarding the openQA project? My role in the project was to wish for, envision, design, organize and ... [More] implement most of openQA and OS-autoinst (the test-engine powering the openQA service). I made it do what was needed most and added things others wanted as well. Actually, my job at SUSE (doing cloud stuff) is completely unrelated to openQA, which is still my hobby project. What is your personal goal for openQA? I want it to significantly improve the overall quality of free software in general and openSUSE in particular. This is a big goal, but I know that it can do it, because it has already found dozens of bugs in KDE, GNOME and other software shortly after their introduction and I believe that has already made a difference. Unfortunately, quality itself and the effects of high quality are hard to measure. Are there still any issues you want to point out? The results sometimes show problems that are not bugs in the tested software, but problems in the test-code, but I usually fix such tests quickly. There are still things missing. e.g. accumulating results (Jenkins does this nicely) and notifying interested parties – this way I would not have to write as many IRC messages or bug reports – but I am hesitant to re-invent the wheel there. Also many things that could easily be tested are still not included. Interested developers can have a look at the OS-autoinst todo list http://www.os-autoinst.org/todo.txt . I hope to address some of those items during Hackweek VII. Which were the biggest issues you and the team had have in the past? There were never big breakages or such. Also, openQA is not like OBS (yet) where you have a hard time when it is down for some hours. What has changed in your life since you´re working for SUSE? I have moved from Berlin to Nuremberg which means that I can not be with my family as often as I would like. For some reason this also caused a tenfold increase in my Pizza&Döner consumption which worries me a bit. I miss cooking potato soup, omelette and a lot of other tasty things. On the positive side I work with people who have written the tools (like screen and zypper), I have used for years on a daily basis. And for some reason, bugging people for bugfixes works better when you are at their desk ;-) openQA test details What has changed in the openQA project since the last year? Short answer: nearly everything. Long answer: One year ago, there was just my private Debian server running regular Factory tests and publishing result videos and logs as files in a huge directory which made it even hard for me to use. But last October, the SUSE-sponsored openQA server went online. It could run tests a lot faster and I made a nice web-interface for the results, so that it became much easier to find out what broke and when. I added more different variants of tests to cover distribution-upgrade and latest development versions. Dominik (who is now working for SUSE QA) added support for reference images, audio testing and live viewing of running tests. Tell us a bit about the openQA team. The openQA developers right now, are Dominik and me. It does not need much maintenance, so work is only needed to add more tests or features. Then there are people proposing useful additions and there are more people looking at the test-results and even though there is nothing to organize this (I guess, we could use the opensuse-testing mailinglist or IRC channel), it makes them sort of an informal distributed openQA-result-review-team. To finish it off, let’s go a bit more philosophical and ask: “Why?” More specific, what do you want to achieve in life? This is something, I asked myself when I was 21 and after a many months of chatting with people (who I never saw) and feeling and thinking, found an answer that made me laugh tears. Everyone has to find his or her own answer (such that it be their very own) so I will only tell that openQA is just one part of my neverending endeavor/effort/quest/journey. Thanks for the interview! [Less]
Posted about 11 years ago
Hi, just another quick update about openSUSE @ ARM project. Yesterday I posted that I’m happy geeko because I have openSUSE chroot on my ASUS Transformer. Several people were excited and wanted to try it too, even though I posted that it is highly ... [More] work in progress. Ok, so to satisfy these curious readers, I’ll share my chroot. What is there and hopefully working is zypper and osc, so you can install new packages as we will fix them and you can help with fixing broken ones. But I would recommend not to use any of this on your internal memory. At least on external SD card you are not afraid to destroy or ideally on some network filesystem. How it works? You need some machine you have root on and at least a little bit decent busybox. Then just unpack content of this archive to your SD card, make adjustments to the linuxchroot script if needed and run it from terminal. You should end up chrooted into openSUSE. If not, I warned you that this is not even in alpha state, so check what script is doing, why is it failing and fix it Comments are welcome, support requests not so much And I take no responsibility for anything and everything is up to you So this is definitely not for end users. Download link [Less]
Posted about 11 years ago
openSUSE ARM Update - 141011 The big update is that a couple of kind companies have stepped up and sponsored some hardware for the effort to get openSUSE on ARM. Huge thank you to: They have kindly sponsored and shipped several EfikaMX ... [More] devices. Thanks to Peter Czanik for organising this on our behalf.   Ti in association with the PandaBoard community have kindly sponsored and are shipping several PandaBoards.   Thank you, this is a huge help.   Now that we have some devices on our way it doesn't mean we can sit back and relax, we still need more devices. Yes, I'm going to say it again - Please help the Geeko and donate as much or as little as you can (preferably not zero ;-) ).     So what else is new? Well openSUSE has managed to run on a couple of modern ARM devices. Joop Boonen managed to get openSUSE running on his PandaBoard. He even made a couple of videos:   First boot of openSUSE ARM port on Pandaboard   First Boot of a openSuSE ARM port on Pandaboard via monitor/keyboard and serial operation     Michal Hrušecký managed to get openSUSE running on his ASUS Transformer Tablet (albeit in a chroot), he has also provided information on how to do this yourself if you're feeling brave :)   We still don't have anything that we can release yet, as we are still working to fix packages. We are fighting forward and we will succeed!! [Less]
Posted about 11 years ago
Fifteen years ago Matthias Ettrich started the KDE community. On 14th October 1996 he wrote his famous email to the de.comp.os.linux.misc group on Usenet. He called for other programmers to join him to create a free desktop environment for Linux ... [More] targeted at end users. Many, many people joined. Thousands of developers wrote millions lines of code. We did 90 stable releases of our core set of applications alone, not counting all additional stuff and the thousands of 3rd party applications.So now, fifteen years later, we are done. We have a wonderful free desktop environment for Linux which is used by millions of users every day. Well, are we done? Not quite. While we have reached the original goal of creating an appealing desktop which makes Linux accessible to everyone for everyday tasks, our scope has broadened. There are whole new classes of devices in need of free and friendly user interfaces, it's not only the desktop anymore. The cloud presents new opportunities for connecting computers more than ever, and presents new challenges for freedom of software and data.We are on it. The last two weeks saw frentic activity in the KDE community. Last week we released version 4.7.2 of our flagship product, the classical desktop. On Sunday we released Plasma Active One, our speedboat going into the waters of tablets and the device spectrum. On Tuesday we released ownCloud 2, our helicopter going into the cloud on its mission to retain your freedom and control about your data.The KDE desktop is part of our live. We and millions of others use it every day. It's great for getting work done. We are on par with other desktops, but we are still pushing the limits and innovating, for all the users out there. This won't change anytime soon.Plasma Active is one of the results of our innovation activities. It brings KDE to tablets, and it comes with a strong vision to create an elegant, desirable user experience for a spectrum of devices. It builds on the foundation of the KDE software, but it opens new doors, explores new areas. I'm really looking forward to what we can achieve there.ownCloud goes beyond what we have done before. It runs in the cloud. But it's built on the values and the community of KDE. We deeply care about software freedom. Enabling users to retain control about their data and their privacy is a big part of that. ownCloud does that where other cloud solutions fall short. It brings fresh blood and energy, and opens up a space, which we weren't able to address before. Here as well I'm looking forward to what we can do.Fifteen years of KDE is a long time. I joined the community in 1999, and I can say that KDE changed my life. I probably wouldn't have the job I have today without KDE, I wouldn't live where I live today, and I would miss a lot of great experiences and friends I wouldn't have met. In the interview I gave for the "people behind KDE" series, there was a question, what my favorite feature of KDE was. My answer was: "the community". Many other KDE people answered the same.That's the core. KDE is an awesome community. I'm proud to be part of it, and I'm looking forward to be part of it for the next fifteen years of KDE. [Less]
Posted about 11 years ago
I promised that I’ll write a post about how you can contribute. There are several ways how to contribute to MySQL, but most of it means modifying packages. And as everything in openSUSE is built using openSUSE Build service, first post will be ... [More] actually pretty general obs and osc howto. In the next posts, I’ll go deeper into specific details of MySQL packaging. Find the package If you want to play with any package in openSUSE Build Service, you need to have a Novell login and preferably the osc command line client for obs. You can do most of the stuff from web as well, but this way is more comfortable So let’s say that we want to play with MariaDB. First we have to find package we want to update. This can be easily done on the web. Just take a look at packages at server:database repository. mariadb is the version currently included in the Factory. If you want to update bleeding edge version, these are named usually something like mariadb-53 for 5.3 branch or mysql-commmunity-server-56 for MySQL Community Server 5.6 branch. So basically if package name doesn’t contain version, it’s package for factory, if it does, it is just for people wanting something that is not in Factory yet (or already). Get source As you can’t commit to server:database directly, you will need to branch this package somewhere you can commit to and check it out. In examples I will use NICK as a placeholder for the nickname that you got during your registration. Let’s go through example during which we want to play with MariaDB in 5.3 branch. First step is to create our own branch of the code we can commit to: osc branch server:database mariadb-53 home:NICK Now we have a copy of mariadb-53package in our repository in obs. But we want to do some changes locally on the hard drive. So let’s check it out: osc co home:NICK/mariadb-53 Now we have it in directory home:NICK/mariadb-53 and we can start playing with it and do some changes. How to do some changes will be described in the following blog posts. Building and testing After some changes are done, we want to test them, don’t we? Let’s call osc build --ccache to test whether it builds. --ccache enables ccache support which takes more space but speeds up built and consequent rebuilds. So it is a good idea to use it especially in MySQL case If compilation will work well, it will give you several packages to try. And if everything goes well, it’s time to finally contribute all the work back! Contribute Few final commands: osc ar osc vc osc commit Which marks all new files for addition, deleted files for deletion (osc ar), document the changes (osc vc) and commit them (osc commit). Next step it to wait and see whether it build on server as well (osc results) and if it does and it still works, it’s time to send it to me using osc sr command. After that I will get it, take a look at it and either accept it and if it is factory version then also forward it to the Factory (you’ll have your name forever in the changelogs) or I will decline it and tell you what’s wrong. If there is something wrong, you would need to fix it to get you changes accepted. So goto 'Building and testing' Temporal conclusion As you have seen, it is quite easy to use osc to contribute to the packages. Well, I left out the most complicated part – actually changing the package, but that will be topic of the next post and you’ll see that even that part isn’t hard [Less]