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

Tags: ,

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

Tags: , ,

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.

Tags: , ,

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.

Tags: , , ,

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)

Tags: , , ,

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?

Tags: , ,

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!

Tags:

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.

Tags: ,

Every distribution has its own conventions to package scripting languages addons (perl modules, ruby gems, etc) as native packages. This allows packages to depend on those addons honoring the package dependencies, and at the same time, look like the addon was installed the scripting language tool (cpan, gem).

openSUSE keeps a repository of gems, thanks to Marcus Rueckert.

For ruby, David Lutterkort (augeas lead developer) created a nice tool to help converting gems into spec files.

I created a template for openSUSE-like rubygem-* packages, and David committed it upstream.

So, to create a package for a gem:

Fetch it:

gem fetch foo

Convert it:

gem2rpm -t opensuse.spec.template ./foo-1.1.gem > rubygem-foo.spec

Build and tweak it. Make sure everything is alright. Some gems work out of the box, some not, but still gem2rpm saves 90% of the effort. Consider submitting it to the project if you are willing to keep it up to date ;-)

Tags: ,

Two weeks ago I posted about making aria2c the default transfer mechanism for our software management stack.

With libzypp 6.1.0 in Factory, this is already the case. With the first community round of testing, we got quite a lot of bug reports and feedback. Some stuff did not work because the implementation was wrong, while others just showed us that aria2 worked differently as we thought.

The upcoming 6.2.1 addresses the following issues:

  • implemented speed indicators (bnc#475506). You should see transfer speed in applications that report it (like zypper).
  • implemented progress indicators correctly (bnc#473846). You should see progress reporting now in a consistent basis.

  • fixed broken pipe when looking for aria2c which caused a fallback to curl. (bnc#480930)

  • implement saving and reading mirror stats data in /var/cache/zypp/aria2.stats. This means libzypp now learns which mirrors are faster and more reliable for you and remembers it. Every usage adds more information to the “learning”.

  • handle failover correctly (bnc#481115). This means libzypp tries harder to get the file from alternate mirrors.

  • various improvements in error and report handling. General code review and minor fixes.

How to test?

Peter added an interesting “test feature”. If a request happens with a header X-Broken-Mirrors then the openSUSE redirector will send you broken mirrors. So edit your root’s aria2.conf:

cat ~/.aria2/aria2.conf
header=X-Broken-Mirrors: true

And observe zypper.log. Even if errors are reported, libzypp should try other mirrors and get the file successfully.

You can go more extreme, and use “X-Broken-Mirrors: only”, which will give you only bad servers. Even in this case you will see libzypp try hard to get the file before giving up. How hard to try is configurable, see last post for more information.

Big thanks to Peter Poeml and Tatsuhiro Tsujikawa for all the feedback and support, and of course

And with this, feature 302923 is done ;-) and the rest is tracked as bugs.

Tags: , ,

« Older entries