August 4, 2009

osc-plugin-overview 0.3 released

Packager’s favorite dashboard got a new version. Most patches were contributed by Michael Andres.

  • follow links to a package with different package name.
  • adapt to changed API to retrieve submitrequests.
  • support ‘changes=1′ in ini-inifile to print changelogs per section (like -c)
  • osc no longer takes the md5 as revision.
  • cleanup changelog diff temp files
  • suppress changelog diff if source does not provide changes ( like obssr)
  • let changes diff consider only repos that actually provide changes.

Get it from [the build service], or visit the home page here. You can read the introductory post here.

Kopete Facebook plugin 0.1.3 released

Available for openSUSE Factory in my home project. I also submitted to the KDE:KDE4:Factory:Desktop project where you may find it built for older releases using a newer KDE.

Changes:

  • Some connection fixes
  • The idle status icon is now shown
  • Basic user info widget (bug #198286)
  • Show contact status message! (bug #198284)
  • build system improvements
  • qjson 0.6.x is now required

Known bugs:

  • The plugin crashes when exiting Kopete. Some weird stuff with “myself” contact which seems to be deleted twice

Note: This plugin is not associated with Facebook in any way.

June 30, 2009

Quickly testing Google Chrome binary on openSUSE

Get the deb package from the developer release site.

Unpack the deb:

ar x google-chrome-unstable_current_i386.deb 
lzma -d data.tar.lzma 
tar xpvf data.tar

Now you got a opt directory in the current directory with the full tree. Go to the Chrome directory.

cd opt/google/chrome

Symlink the libraries:

ln -s /usr/lib/libnss3.so ./libnss3.so.1d
ln -s /usr/lib/libnssutil3.so ./libnssutil3.so.1d
ln -s /usr/lib/libsmime3.so ./libsmime3.so.1d
ln -s /usr/lib/libssl3.so ./libssl3.so.1d
ln -s /usr/lib/libplds4.so ./libplds4.so.0d
ln -s /usr/lib/libplc4.so ./libplc4.so.0d
ln -s /usr/lib/libnspr4.so ./libnspr4.so.0d

Run it and enjoy!. Be sure to read about privacy features of this preview release.

LD_LIBRARY_PATH=$PWD ./google-chrome
June 2, 2009

Ark Linux to adopt ZYpp

Ark Linux is becoming the first third-party distro other than openSUSE to adopt ZYpp as its package manager.

May 25, 2009

Web-izing YaST

As you may know, are working on making YaST functionality accessible via the web. With this we mean not only browser. The current prototype has two parts: a generic web service (REST like API) and a web browser client.

Stefan Schubert announced last week a new snapshot for developers. You can find packages in the build service project. The packages are named yast2-webservice and yast2-webclient.

This is very early code. It is not fast, and the web client is not yet using all user interface possibilities that ajax gives, but there are we going :-) .

If you are an experienced user, and you get it running, you may be interested in getting it running from source code by reading our development web page. Both the webservice and the webclient are rails applications. Developing modules is also easy! Just show up in irc (freenode) #yast.

May 24, 2009

Facebook on Kopete, take II

Last week I blogged about Facebook support for Kopete, just after I was able to see my buddies for first time on the screen.

Since then I have made some improvements to message handling and other code cleanups. The code is now available in a git repository at github.

As KDE’s svn trunk is frozen, I will keep it there for now.

You can get packages for openSUSE Factory (version 0.1.2). I gave up trying to build it for openSUSE 11.1, as Kopete API has changed quite a bit. However the package may build on 11.1 plus the KDE 4.2+ repositories. You need libqjson from Flavio Castelli installed (or -devel package if you want to build it).

Roadmap for next 0.1.3:

  • Add caching to avoid downloading the pictures every 3 minutes.
  • More bugfixes

Roadmap for later:

  • Look into adding , searching, and other stuff.

Be aware. This is weeks-old-code. It has not been tested much and has lot of debug messages. Use it if you are a early adopter only.

May 20, 2009

Facebook support: First milestone reached

So, I have been working some weeks on this, and today I reached the first “usable” point. Screenshot:

facebook screenshot

As you may know, Facebook has a chat service. For me at least is slowly becoming the place where I have more people talking to me, and as you may also guess, the value of social systems is very tied to the number of users.

Sadly, Facebook guys where not smart enough as the Google guys and brought yet another damn protocol to this protocol overpopulated world. Then came the worst part. They announced something that was not there and promised Jabber support. One year later nothing has yet happened.

For a such popular service, one starts to think whether waiting another year is worth for a protocol that is so popular. As I wanted it myself now, at some point I decided I was willing to implement it even if a Jabber version was available later.

We already have the problem that users expect to see Google talk in the Kopete list, because developers don’t figure out that grandma does not know what Jabber/XMPP is. So a good improvement would be adding the concept of “services” where we could add a protocol by just saying “it is just jabber, but with this server settings, this logo and this name”. That path would allow for a easy move to other XMPP protocols later.

But for Facebook, no more wait. Yesterday I was able to use it for first time to chat, so I am blogging about it.

Next steps:

  • Add more error handling
  • Fix a bug in the contacts status when they go offline
  • Put it into kopete or playground svn
  • Make an openSUSE package ;-)
  • Cleanup. I started over the testbed plugin and it added some stuff that probably I don’t need
  • Proxy support. I coded the engine using QNetworkAccessManager so it is KDE independent. Only the Kopete plugin is KDE based, so I haven’t looked into proxy support and other stuff

Other stuff with less priority:

  • Adding contacts from the client
  • Configuration (there is no much to configure)
April 29, 2009

Making package management even faster?

Joshua Bahnsen wrote on the yum mailing list (summarizing):

Is there support for compression types other than gzip for the yum metadata? For example, bzip2 or LZMA? I am keeping track of 16 RHEL channels, using createrepo with the standard gzip I am totaling 1.4 GB of metadata. Compressing those same XML documents with LZMA yields a total of 140 MB. That’s 10x savings overall, I think that’s worth a look.

James Antill asked some questions, and also pointed some issues:

These we can probably try and help with, but we’ve been asking and waiting for 12+ months for RHN and CentOS to move to generating .sqlite files server side. So I wouldn’t bet that we can help in the general case, quickly. Plus any client side support for lzma probably wouldn’t get into 5.x until at least 5.5 (more likely 5.6 or 5.7). So realistically you are targeting Fedora and 6.x for a change like this.

For Fedora the main issue is that they use sqlite version of the metadata generated on the server side, therefore they are more interested in how those files compress.

openSUSE still downloads the raw metadata. Mostly because our sat-solver is really fast converting it to the solv cache. We have thought about shipping solv files in the metadata some day, but we still haven’t look at that in detail.

However I wanted to see how it could make a difference for openSUSE by using lzma when compressing the metadata. I took the 11.0 update repository, as it has quite a lot of stuff in it, which makes it big to download when it changes.

For that, only a minimal patch to /usr/bin/repo2solv.sh is needed. You can get that patch here.

Here are my metadata size results:

I also looked to how fast the parsing of the metadata goes. For that I parsed each file 3 times and averaged each time component. I dropped disk caches before.

As you can see, the repo is 4x smaller and parses 2x faster, which is still very nice(the 10x gains seems to be for files like other.xml which we don’t download).

You can get the data from here.

A change like this is still challenging:

  • We need upstream support to keep repos compatible
  • It can only be done in Factory, and people need to update the software management stack before the format is changed.

What do you think?

April 7, 2009

Introducing osc-plugin-overview

You maintain some packages in your repository, which you package from some upstream source. You want to quickly compare versions across your development project, Factory, and upstream. You want to configure what is the package list and to display packages only if they are outdated.

You want to configure a view writing myview.ini to ~/.osc-overview which says something like:

[someview]
repos=obs://devel:languages:ruby:extensions
         ,gem://gems.rubyforge.org
packages=$1
filter.older=$1

And you want to type “osc overview myview” and get back something like:

table

You can configure as many package data sources as you want for a view. No limit for 2 columns. You can specify from which repo the package list comes from using the $x macros. Same with the older version filter.

Then osc-plugin-overview may be what you are looking for, or even better, it may be soon, when we add more features. See more complete description, where to download it and planned features in its wiki webpage.

This is the first release so it includes support for getting information from build service projects, submit requests against projects, upstream gem servers and that is. I expect to add stuff like customizable output (machine readable, patchnfo, changes, diff) and other sources like local directories and upstream ftp servers. Help welcomed!

March 19, 2009

Easy packaging of ruby gems for openSUSE, part II

I was in the need of learning about osc plugins, because I want to rewrite some scripts that I use to track maintenance updates to the software management stack. Learning osc plugins meant learning python at the same time.

I was inspired by the osc gnome todo functionality, which shows something like this:

vuntz@lyon ~/work/opensuse/tmp/>osc gnome todo
Downloading data in a cache. It might take a few seconds...
Package  | openSUSE:Factory | GNOME:Factory    | Upstream
---------+------------------+------------------+-------------
anjuta   | 2.23.91          | 2.23.91          | 2.24.0.1 (r)
at-spi   | 1.23.92          | 1.23.92          | 1.24.0
gdm      | 2.23.92          | 2.23.92 (s)      | 2.24.0 (s)
gedit    | 2.23.93          | 2.23.93          | 2.24.0

So, in my last post, I wrote how to easily package gems for openSUSE, saving at least 99% of the work. However, how do you know that you need to package a new gem? Well, here is osc ruby todo, in its first 0.0.0.0.1 release:

duncan@tarro:/osc-plugins> osc ruby todo
126 gems in build service projects
Retrieving upstream gem information...
+ libxml-ruby upstream: 1.1.2 bs: 0.9.5
+ radiant upstream: 0.7.1 bs: 0.6.9
+ launchy upstream: 0.3.3 bs: 0.3.2
+ hpricot upstream: 0.7 bs: 0.6.161
+ net-ssh upstream: 2.0.11 bs: 2.0.8

So, it connects to gems.rubyforge.org and tell you which gems are outdated. Do you want to keep openSUSE a nice ruby platform? help me. The following features are waiting:

  • track ruby package versions
  • track other gem repositories, like the rails one or github
  • also compare it with version in factory
  • nice tables
  • caching
  • Use gem2rpm and the openSUSE template to automatically create the specs for outdated gems

You can download it from git.opensuse.org, just symlink the .py file to ~/.osc-plugins. It requires rpm-python and Python 2.6 or newer.

My ultimate goal is to get a similar one for zypp/yast that allows to compare our Head repositories with Factory and maintenance repos, show diffs and make submit requests.

So how does it works? How to create your own osc plugin? Look at the source code of the osc-* projects at git.opensuse.org, You will realize it is as easy as:

  • Open a .py file
  • Create a do_something method, adding the documentation and checking input and arguments
  • Use the meta_ API and urllib to get data from the build service
  • Use makeurl to build the right authenticated urls to do the requests.
« Older Entries
Newer Entries »