git is great for bisecting regressions (or finding a fix in a series of commits) - but compiling the kernel can take ages, especially if you have to do it on an Atom, and with the configuration of your favorite distribution...

Now finally I created a perl script for reducing the default config to the set of modules that are currently actually loaded. Reduces kernel compilation times on a quad core machine from 56 minutes to 6 for a standard SLED kernel Guess it's even more difference on this !@#$% Atom...

Usage:

# cd /var/tmp/linux-2.6	or wherever your git tree is located
# gunzip </proc/config.gz >.config	to get the current configuration
# make oldconfig	to add new options for current kernel
# ~/linux-adaptconfig.pl >.config.new	to remove all not required options
# mv .config.new .config
# make oldconfig	to be on the save side...
# make -j5	build, mother*beep*, build :-)

Yes, it's a hack. No, it's certainly not perfect. But it might be exactly what you had been waiting for. I waited long enough to actually write it myself...

In order to get easier access to Nokia things, and to boost security (as in, encrypt stuff, for a change), I've been reinstalling my trusted hp 6715b. Most nokians use ubuntu, so i went for 10.4LTS. I already severely disliked the way in which you have no installation options to chose from. You get the grandmother version every time, no "i have a clue, let me decide what i want to do, myself" button anywhere.

I was lucky, in 10.4 my now 3y old graphics card was still working out of the box. But, of course, i want to have my big virtual screen back. This, of course got dropped with randr 1.2 and the Virtual keyword was reused for something else. Matthias Hopf then re-added it in 1.3; mostly to appease me, and the handful of other weirdos out there. But, try finding this option in the xorg.conf manpage. Nothing! Try googling for it, and the first 50 hits either only explain the commandline version or the old style Virtual (which got broken). Apparently, you need to add 'Option "Panning" "${H}x${V}".

Easy, pico /etc/X11/xorg.. Damn. Nothing. head /var/log/Xorg.0.log says xorg.conf.d. Type man xorg.conf.d. Damn. Nothing: "No manual entry for xorg.conf.d" Suuuper. Apparently people are supposed to _know_ that this is part of the xorg.conf manpage.

So, create a new screen, device and monitor section in 01-screen in xorg.conf.d, and press ctrl-alt-backspace, like any experienced driver developer is used to. Damn. Nothing. Head into gnome preferences stuff, enable key combination. Try again. Drop into the console. Wait for the display manager to try again. And wait. And wait. Damn. Nothing again. Ok, the DM might have died, and i don't trust this new gnome stuff, so it might be better to reboot. So Ctrl-alt-del, which worked first time round. At least something one can depend on.

Next time i look back, ubuntu is showing its plymouth style loading, but the panel is gradually turning white. Something is not driving the panel and the driver died, for whatever reason. WTF? Try some key combinations to get a console. Damn, nothing! Pinging the box still worked, but of course, no sshd was installed. Attempting a reboot didn't bring anything either, it just runs into the exact same issue. Nothing is checking whether a previous boot got one to a working console or a working X.

So, insert the ubuntu installation cd, choose live system, mount the fs, chroot to it, apt-get install ssh, and less /var/log/Xorg.0.log to reveal:

> (==) Using config directory: "/etc/X11/xorg.conf.d"
> Parse error on line 3 of section Monitor in file /usr/lib/X11/xorg.conf.d/01-screen.conf
> The Option keyword requires 1 or 2 quoted strings to follow it.
> Parse error on line 3 of section Monitor in file /usr/lib/X11/xorg.conf.d/01-screen.conf
> "2560x1920" is not a valid keyword in this section.
> (EE) Problem parsing the config file
> (EE) Error parsing the config file
>
> Fatal server error:
> no screens found

I forgot to put apostrophes around "Panning", and i got greeted with a bleeding panel, with no option to easily get around it. What on earth are we thinking here?

This is Ubuntu LTS, with radeon, KMS, plymouth and xorg.conf.d. 5 nails in the free software desktops coffin.

A lot has happened since my last blogpost in June 2009.

Its 2011 and I have been working for more than a year on a new project called “Native OfficeOpenXML” (NOOXML). The story is quite simple: I was very disappointed with the quality of the support of the “docx” format in OpenOffice.org. Even more --- I'm very disappointed with the code quality and the design! of the OpenOffice.org Writer core and layout. There are people who believe this can be solved by “code refactoring” fixing “low-hanging-fruits”, “quick wins” and other magic silver-bullet-phrases. But one thing was for certain: There is no way to (re-)implement a core and a layout engine. Can't be done. Impossible. No way.

OpenOffice.org took the refactoring route. I took the rewrite route.

After one year here is where we are.

What has happened:
I started designing and implementing the NOOXML-core in Jan 2010. The magic is the datastructure which allows a compact representation of the documents and fast implementation of insert/deletion operations etc. I also wanted to be able to do real- time-collaboration, which influenced the design of the core a lot. In March 2010 I was able to load the ECMA Spec Part I (very big document) into the core. Not only on a desktop machine, but also on my “iPod” (not “iPad”!!).
Once I had the basic core design and implementation done I started working on the layout engine. The primary goal was to build a fast and reliable layout engine. In my implementation I focused on OfficeOpenXML fidelity. In August I had the basic layout features like text, headers, footers, tables, footnotes etc. done. I was able to render the ECMA Spec Part I (again: very big document; >5000 pages) to PDF. I then added section and multiple column support.
Yesterday I was able to render the ECMA Spec Part I document on the iPod (real device) AND in the Android emulator (since I don't have an Android device) and without a user interface:

(I know: I took a really long time. But there is sooooo much room for improvements. And hey: OOo can't even load it on a desktop-machine.)


And here is the UI-less port for Android 2.3:


Happy new year!

I’m going to FOSDEM, the Free and Open Source Software Developers’ European Meeting I’m going to that fine city of Brussels (yet again) for one of the best conferences going (IMHO). If you’re going grab me and say hi. If you’re thinking about going, stop! JUST GO!!! :-)

Phew. long time no news! It's been a busy start of winter ... on that topic a happy new year to everyone! Welcome if you're reading this for the first time on PlanetSUSE, have a look at my intro if you're curious who I am.

A few updates on what I've been working on this month at least.

libopensync-plugin-akonadi 0.22.1 released
Released an update to try and make it work better with the Google Akonadi resource (thanks ares)

Package updates on the OBS

• Packaged krazy2, the KDE code quality checker, straight from git in KDE:Unstable:Playground
• Updated get_iplayer, the BBC iPlayer download tool, in home:MasterPatricko. It now works!
• Packaged powertop2 beta, the power consumption monitor, in home:MasterPatricko; interesting improvements compared to powertop. Needs kernel 2.6.37 (i.e. Factory or Kernel:HEAD) to show off its full power, but still works in 11.3.
• Update liquidwar6, the particle simulation game, to 0.0.9beta in games
• Update maxima, the Computer Algebra system, in science to 5.23.0
  
• Update unshield, the .CAB file extractor from the SynCE project, in Archiving (and eventually Factory) to 0.6




• Fix build of denyhosts, the SSH brute-force protection tool, on x86_64




• Update redshift, the auto screen-brightness adjuster in Factory:Contrib to 0.6




• Created a package vncserver-autostart in home:MasterPatricko which adds an init script to start a tightvnc vncserver on bootup. Complete with sysconfig-style configuration. Completely insecure of course but perfect for a local network.

Started using my hard-earned openSUSE member benefits; tejas.guruswamy AT and masterpatricko AT opensuse.org are operational; got the blog syndicated on planet.opensuse.org

Plus, as always, I have a couple of new project ideas I'd like to get started on ... more on that soon. Comments welcome as always

From friendly blog  via Planet openSUSE   here is part of the old Linux joke.

 .... Disgruntled employees of all the other OS airlines decide to start their own airline. They build the planes, ticket counters, and pave the runways themselves. They charge a small fee to cover the cost of printing the ticket, but you can also download and print the ticket yourself. When you board the plane, you are given a seat, four bolts, a wrench and a copy of the Seat-HOWTO.html. Once settled, the fully adjustable seat is very comfortable, the plane leaves and arrives on time without a single problem, the in-flight meal is wonderful. You try to tell customers of the other airlines about the great trip, but all they can say is, "You had to do what with the seat?"

Heh, if that would be so simple like installing a seat, but it is very close, which every openSUSE user can confirm :)

As some might know, I am switching ("intermediate") employers, and i am going to do home-office from now on. Home-office probably has tons of advantages, but one disadvantage is that you need to own your own office hardware, like a printer and a scanner. Such beasts were sitting around in Belgium, but in the 3.5 years that i have been in Nuernberg, i have either depended on the office i was respectively working for, or i ran to the copyshop around the corner. The latter is extremely unpractical and becomes rather expensive.

So, today, a Canon Canoscan LiDE 110 arrived from amazon (plus a basic samsung laser), and i have just succeeded in getting it to work with openSuSE 11.1, albeit in a very unscientific way. Here is how.

Sane is divided in front and backends. openSuSE 11.1 requires just an updated backend.

For the LiDE 110, only very recent sane (git from halfway december 2010) supports the LiDE 110 and 210, so grab the git repo.

Then, grab a recent openSuSE sane-backends package, for instance from here. Get yourself the src.rpm, and install it.

A crude way of getting something our specfile can work with is to tar -jc up the sane-backends git repo, and to move that to /usr/src/packages/SOURCES

Then edit the specfile, make sure to bump the "Version" and/or "Release" directives. Then have the "Source0" directive is pointing to the correct tarball, and make sure that the line with "%setup" is pointing to the right %{name}-... directory.

If you are as lucky as i was today, the existing patches, which are mostly about integration, will apply rather cleanly, and rpmbuild will succeed.

Install the created files (you probably won't need -devel), and you should now be able configure your scanner using yast. If yast complains about hal, then run rchal restart.

Now scanimage -L should be happy, and then you're all set.

Happy scanning!

Well, it’s just a small announce… I was in Yemen for some time, around 16 days, for work. I wasn’t able to answer emails and work for openSUSE, and I’m really sorry for that. But I just went back Yesterday and tomorrow I’ll start to work again.

My first goal is to package XBMC that recently released a new version.. so… STAY TUNED!

Have a lot of fun, Andrea

Following up on my previous blogpost I would like to give a small update on what happened so far about a longer supported (open)SUSE release.

We had a longer discussion on the mailing list if an openSLES (a’la CentOS) or “openSUSE LTS” would be the better or easier solution. There are pros and cons for both while the required infrastructure differs a lot. I’m not diving into details here though. While I would find a SLES clone appealing I’m not in the position to drive such an effort. I also do not think that having both makes sense and therefore I decided to go on with the other approach for now trying to extend the lifetime of an existing openSUSE release.

People in the community came up with the project name Evergreen and I think that matches what we try to build pretty well. I proposed to give the whole effort a trial with openSUSE 11.1 which went unsupported with the new year. At the moment we still have organizational and technical issues and most likely won’t be able to utilize all the update features (deltarpms, zypp patches) but still we will try to deliver updates from a certain update repository. Because of the holiday season we couldn’t figure out the details yet but hopefully will get it sorted out in time. Stay tuned for further detailed information here and on the mailing lists.

Please note that this effort is in experimental state still and didn’t attract that many contributors yet unfortunately. So at the moment it’s still unclear if we will be able to deliver as we would like to.

If you are interested in this project feel free to join our (current) project list.