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.

The first Kokoa and Friends meeting took place the 20th of December at the Computing and Electrical Department of ESPOL.
This meeting supported by the openSUSE community, gathered people from different levels of the Kokoa community and the ESPOL university. From students that are just getting interested in using FLOSS (a.k.a. newbies), students who are “candidates” to join the Kokoa community, the current “active” members and the experienced “senior” members.
In this event different topics were discussed covering FLOSS usage in the academia and the industry. Stories of success and guidelines were shared with people interested in going forward in the world of FLOSS.

Special thanks to Cristina Guerrero, Nervo Verdezoto, Marisol Villacrés, and from Jarflex, Adonis Figueroa and Jessica Zuñiga the speakers of this meeting and specially to Arturo Tumbaco, who helped me with the logistics to make this event possible.

Here some pictures about the meeting.

On Dec. 13 our son Jonas was born. He and his mother are doing well. We are all happy that he is with us now.

Hi,
Now I work for SLMS ( Suse Lifecycle Management Server ) project. It cooperate with SuSE studio and use its API. I get idea that more people could benefit from easy access to studio API from ruby so I extract functionality and improve behavior, documentation and testing and now there is new rubygem studio_api.
Why you should use this gem?

• ActiveResource Behavior
• Actively maintained ( and will be due to SLMS support )
• Tightly developed with guys from studio team
• Well documented with yard
• Good test coverage

I think then a lot of glory words is better to show example. It is example based on example from documentation.
Example goal is simple. Create new appliance in studio, add own cool rpm and build appliance with it. It can be useful to test your new version of software in stable environment and have automatic appliance in which you can test it.

  require 'rubygems'
  require 'studio_api'

  # Fill up Studio credentials (user name, API key, API URL)
  # See https://susestudio.com/user/show_api_key if you are using SUSE Studio online
  connection = StudioApi::Connection.new('user', 'pwd', 'https://susestudio.com/api/v1/user')
  # Setup the connection for all ActiveResource based class
  StudioApi::Util.configure_studio_connection connection

  # Find template with KDE4 for SLE11SP1
  templates = StudioApi::TemplateSet.find(:all).find {|s| s.name == "default" }.template
  template = templates.find { |t| t.name == "SLED 11 SP1, KDE 4 desktop" }
  # clone template to new appliance
  appliance = StudioApi::Appliance.clone template.appliance_id, :name => "New cool appliance", :arch => "i686"
  puts "Created appliance #{appliance.inspect}"

  #add own rpm built agains SLED11_SP1
  File.open("/home/jreidinger/rpms/cool_rpm-1.0-1.60.noarch.rpm","r") do |f|
    StudioApi::Rpm.upload f, "SLED11_SP1"
  end
  # and choose it in appliance ( and of course add repository with own rpms)
  appliance.add_user_repository
  appliance.add_package "cool_rpm", :version => "1.0-1.60"
  #check if appliance is OK, like dependency problems with new rpm
  if appliance.status.state != "ok"
    raise "appliance is not OK - #{appliance.status.issues.inspect}"
  end
  
  build = StudioApi::RunningBuild.new(:appliance_id => appliance.id, :image_type => "xen")
  build.save
  build.reload
  while build.state != "finished"
    puts "building (#{build.state}) - #{build.percent}%"
    sleep 5
    build.reload
  end

  final_build = StudioApi::Build.find build.id
  puts "Appliance to download: #{final_build.download_url}"

So I hope that you like interface how I design it. Of course I welcome any suggestion how to improve it. You can use comments here, novell bugzilla or issues on github.
How to install it:

• In opensuse: 1-click for 11.3 and 1-click for factory
• alternative possible everywhere is to use
  gem install studio_api

At the end few useful links if you are interested:
repository on github
yard documentation
gem at rubygems.org

Thanks for attention and I welcome any comments

Use case: I want to create an appliance image for a build farm worker machine. I don't know its hardware configuration beforehand; in particular, it may have multiple network interfaces and I don't want to bother figuring out which is which. I will simply include network-autoconfig.rpm and plug the cable into any socket before booting.

network-autoconfig helps setting up machines with multiple network interfaces. At the first boot, all available Ethernet interfaces are cycled until one is successfully configured with DHCP.

I have submitted it to openSUSE:Factory now. Enjoy it in the upcoming openSUSE 11.4!

It is referenced as Feature#311012. You are welcome to improve it on Gitorious.