I think it is only fair to state publicly what should have been painfully obvious for some time already to anybody following: I have lost inspiration/motivation/interest in working in my spare time on GTK+ on Windows. It isn't likely that I will be producing any more Windows packages (32- and 64-bit) of GTK+ and dependencies to be offered on gtk.org (actually ftp.gnome.org).

Occasionally building such packages is all I have done for quite some time for the stack on Windows, anyway; it's a long time since I attempted any bug fixing for instance.

But the situation is not too bad: Check out the stuff in the openSUSE Build Service, see for instance http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/ . Note that even though I might be listed as a co-admin or something for that stuff, too, I haven't really done much for it. My colleague Fridrich Štrba is the main driving force there. Also note that other people have been fixing bugs and making GTK+ 3 build on Windows, for instance Hans Breuer deserves much thanks.

Another week, another release



This week release is version 0.2.0. It features GNOME 2.91.92, including :

• soon to be released Network Manager 0.9 and new UI integrated in GNOME Shell and GNOME Control Center (be careful, it has still rough edges)
• a11y support should be improved

If you have installed this image or if you use the home:fcrozat:gnome3 openSUSE and want to upgrade to 2.91.92, you can update using zypper up (if you still want to keep Network Manager 0.8) or zypper dup (if you want to switch to NM 0.9). Some packages might be uninstalled in the process.

Image is, as always, available at http://gnome3.org/tryit.html

Enjoy !

I’m happy to announce LibreOffice 3.3.2 bugfix release for openSUSE. The packages are available in the Build Service LibreOffice:Stable project. They fix various crashers, usability and translation problems, see the libreoffice-3.3.2.2 release news for more details. See also some notes about openSUSE LibreOffice build.

The openSUSE LO team hopes that you will be happy with this release. Though, any software contains bugs and we kindly ask you to report bugs. It will help us to fix them in the future releases.

Other information and plans:

The 3.3.2 packages includes KDE3 support again. Thanks Lubos Lunak who fixed all known issues and Ilya Chernykh who helped with packaging.

The 3.3.2 release is in a very good shape, so we decided to slow down the bug fixes release cycle. You might expect the 3.3.3 bug fix release two months from now.

LO-3.4 feature freeze is pretty close and we will start producing test packages in the LibreOffice:Unstable project. Please, be patient because there are many interesting changes in the build framework. They are good for the future but I expect some problems with packaging. I hope that I will manage to provide something by the end of April.

I’m blatantly abusing GSoC for a project that I would like to see in openSUSE but that I’ve never had time to work on. But really it’s a worthwhile thing to have: a set of Plasma widgets that users and developers can add to their workspace to make it easy to see what’s going on in OBS in the projects that matter to them. If you want to work on a fun project with cutting edge technologies such as Qt, QML, Plasma then head on over to the GSoC 2011 Ideas Page.

I really look for the perfect gsoc student: someone who has a brilliant idea, noone else thought of how to improve linux in general or openSUSE in specific and just needs my guidance.

But for those that need some ideas, my best bet is really to rewrite clicfs to make it even better. Right now clicfs is a FUSE filesystem hosting a loop image. So a page read goes from ext4->loop->fuse->clicfs->CD->clicfs->fuse->loop->ext4.
If it lived in the kernel, it could offer a block device you mount your ext4 on, leaving aside loop and fuse:


modprobe clicfs packfile=/read-only/openSUSE-kde.i586 cowfile=/read-write/.COWfile cowlog=/dev/ttyS0
mount /dev/clicfs/0 /mnt
chroot /mnt /bin/init


Great idea, no? For someone who wants to become famous, it would be the perfect target!

OSC is a powerful tool for packaging experts, exposing all the latest and greats features of the Build Service. It’s written on python and easy in studying and using. However there are situations when its functionality is not enough; sometimes we need something special. In this case to us will help plug-in mechanism, which in osc is realised very simply.
Plugin can use all of the features, which already implemented osc, as well as provide an output in a convenient format for you. For example, if I want to check changes in kdelibs4 between openSUSE:11.3 and openSUSE:11.4, I can do something like this:

> osc rdiff openSUSE:11.3 kdelibs4 openSUSE:Factory kdelibs4

After that I will receive a detailed output about all changes. Yes, that’s great… but not always it’s convenient. For example, in this case output will contain more than 2000 strings, and I need time to find, say, a *.changes file if I want quickly to understand that has been changed. In case if I want to transfer output to processing to another program (as often happens in practice), I have to shape this data. Unfortunately osc is not as intelligent and can’t show changes from one file (from *.changes, for example) only…

Hello world

Let’s me show how we can create a very simple osc-plugin. In the derectory /var/lib/osc-plugins/ we create a new file tell_me_something.py with such content:

@cmdln.alias('say')
def do_say_something(self, subcmd, opts, *args):
    if sys.argv[2] == "something":
        print "openSUSE rulezzz"
    else:
        print sys.argv[2]

At start, osc will check this directory and will register all found there plugins. In that case, if in the plugin’s content there are errors, osc will report about it immediately. If now we run

> osc help

we will see in the list our function say_something and the key to start it – say. Let’s test:

> osc say "hello"
hello
> osc say GNU/Linux
GNU/Linux
> osc say something
openSUSE rulezzz
>

As you can see, it’s very easy – just python and nothing else. Let’s go back to the output of the function rdiff(), which we mentioned at the beginning.

show me changes

In output of rdiff() nothing wrong, but I would like to immediately get information about what exactly has been done and, for example, which bugzilla-reports (related to this package) have been closed, etc. All what I need, are in rdiff’s output. It means that all what I have to do is just to shape this output.

In 40 minutes of hacking I got such output:

> osc changes kdelibs4 openSUSE:11.3 openSUSE:11.4
PACKAGE: kdelibs4
BUGZILLA_NOVELL: 668185, 670426, 644236, 596021
BUGZILLA_OTHER: 246652, 170806, 149991, 221989, 252280, 253387, 253294, 193364, 253414
CHANGES:

- work around random error on first startup, bnc#668185,
  kubuntu has a similiar patch applied
- call update-mime-database in pre/post install scripts
- don't show synthetic volume label when none is really available,
  allow kio_sysinfo to fall back to device path (bnc#670426)
- update to KDE Platform 4.6.0
  * Plasma applets can be written in QML
  * Plasma data engines can be written in Javascript
  * Plasma data engines can use generic cache for offline mode
  * udev, udisks, upower replace HAL in Solid
  * For more details, see http://kde.org/announcements/4.6
- add patch from 4.6 branch to fix plasma crash on exit
- Add dependencies on udisks and upower for 11.3 and up for Solid
- update to 4.5.95
  * KDE 4.6 RC2
  * no upstream changelog available.
- update to 4.5.90
  * KDE 4.6 RC1
  * no upstream changelog available.
- For 11.2 and 11.3 only : Will build now with polkit-qt-1
  v 0.99.1, which is an official requirement of KDE 4.6
- update to 4.5.85
  * KDE 4.6 Beta2
  * Final Beta before RC, various fixes from Beta1
  * no upstream changelog available.
- For 11.2 and 11.3 only : Added patch to revert changes that
  requires a higher version of polkit-qt-1
- update to 4.5.80
  * KDE 4.6 Beta1
  * no upstream changelog available.
-  Closing the shell via CTRL+D crashes [bko#246652]
- fix build with gcc 4.6
- tighten qt4 dependencies
- update to 4.5.3
  * see http://kde.org/announcements/changelogs/changelog4_5_2to4_5_3.php for details
- update branch diff for various bugs in 4.5:
  * Crash on configure toolbars (bko#170806)
  * KCookieJar can't read cookies from another port (bko#149991)
  * Fix oversized number input widgets (bko#221989)
  * CSS conformance issue (bko#252280)
  * Fix helper protocols such as mailto: and telnet:
  * Plasma crash on comic applet switch (bko#253387)
  * HTTPS urls in KMail do not open properly in browser (bko#253294)
  * Mailto: links in FireFox started by kmailservice fail (bnc#644236)
  * Crash in directory listings when toggling
    show hidden files flag (bko#193364)
- Upstream patch added for kmail issue (bko#253414)
- update to 4.5.2
  * see http://kde.org/announcements/changelogs/changelog4_5_1to4_5_2.php for details
- build apidocs separately to reduce build time
- BuildRequire utempter-devel
- update to 4.5.1
  * see http://kde.org/announcements/changelogs/changelog4_5_0to4_5_1.php for details
- new package: kdelibs4-apidocs (bnc#596021)
- update to 4.5.0
  * KDE 4.5.0 final (version bump over RC3)
- update to 4.4.95
  * KDE 4.5 RC3 (not announced)
  * critical fixes for 4.5.0 release
- Add libsoprano-devel Require to libkde4-devel
- update to 4.4.93svn1149349
- update to 4.4.5
  * bugfixes over 4.4.4
  * see http://kde.org/announcements/changelogs/changelog4_4_4to4_4_5.php for details

and between 11.4 and factory:

> osc changes kdelibs4 openSUSE:11.4 openSUSE:Factory
PACKAGE: kdelibs4
CHANGES:

- update to 4.6.1
  * Bugfixes over KDE 4.6.0
  *  see http://kde.org/announcements/changelogs/changelog4_6_0to4_6_1.php for details
- remove upstreamed patches

aha… and what’s about vim between 11.2 and 11.3?

> osc changes vim openSUSE:11.2 openSUSE:11.3
PACKAGE: vim
BUGZILLA_NOVELL: 598903
CHANGES:

- Add screen control sequences to inputrc (bnc#598903)
- Use the icon from the tarball instead of our custom icon. It
  looks much better.
- Drop gvim.png from the source package.
- build data subpackage as noarch
- updated patches to apply with fuzz=0

Now we can see exactly what was has been done and which bugzilla-reports was fixed/closed. Yes, we have bnc# and bko# reports: reports from bugzilla.novell.com and bugs.kde.org (it cut be also bugs.kernel.org). Second group will be always different (KDE/Gnome/Mozilla/Kernel…).

Source code of plugin is here, and I hope this post will be useful for you if you’ve never written a plugin before.

I like to suggest a general policy for openSUSE:Factory project to document from where a tar ball (or any other file from upstream) is comming from. Why that ? It makes it much easier to review version updates and it guarantees that no one can inject some mal code via a modifed tar ball.

So far I added the source services “download_url” and “tar_scm” to our OBS instance, which downloads the files and stores them as files via a commit. Some people use them already, some others don’t like them because they store the files with _service: prefix.

In last hackweek, I added another way to handle this, which I would like to request as setup and policy for openSUSE:Factory project. You can add a project wide source service, for example the new “download_files” service. That would mean that no needs to add a _service file to the sources anymore. It is enough to add an URL to the spec file Source: tags. The service will automatically download it from there.

But that does mean we still have have _service:download_files:osc-0.1.tar.bz2 file names ? Not when we also add the new “trylocal” parameter and use latest osc versions. This parameter will let act osc to execute the services, but name the files without prefix and commit them together with the other files.

Where is the advantage then ? The server is still validating that this is an identical file. It downloads it again and compares it. In case it is the same file, nothing will happen.

What will happen, when the file differes ? We basically have two options, either we can let the service mark the source as broken or we would store the file with _service: prefix again.

The later mode has the advantage that you can still do version upgrades via slow connections and let the server download the files.

Please find some more details about new possibilities with the source services here.

An example setup for this can be tested via

osc bco home:adrianSuSE:FactoryTest bc

and do for example a version downgrade to 1.05 version to see how it works. Please note that you need the osc from openSUSE:Tools:Unstable project for this.

We can also apply the still suse-internal spec formater and validator scripts via this way later one.

Another advantage of this setup would be the new “update_source” service, which could run in some openSUSE:Factory:AutoUpdate project and tries automatic version upgrades when upstream releases a new version. They could be reviewed and just picked (directly or with additional manual fixes).

As always, another week, another release, aka 0.1.1

This week release is a polish release :

• very few package changes
• many services are disabled when booting live CD, improving its loading speed
• password is no longer asked at all in live CD for root or standard (tux) user
• when installing the image on a system (add liveinstall parameter on bootloader), some services are enabled back (apparmor, preload, firewall), thanks to Chris comments

Another service announcement :
my GNOME3 openSUSE 11.3 repository will soon be removed ; packages will be only available for openSUSE 11.4 (same OBS project). Therefore, I strongly suggest to upgrading your system to openSUSE 11.4.

You know the url to fetch the latest release :  http://gnome3.org/tryit.html

Enjoy !

Hi,
today I must solve issue with not well structured code. Problem is that one method return last correct version, but in one specific case it needs to return newest version (even incorrect). There is many calls between top level method which know what needs to call and target method which is called from generic code. Now I need to fix it and code is not well tested and quite sensitive to changes ( this fix is fix of another fix :). So what is the safest way to change it?
I decide that the best solution which doesn’t change almost nothing ( but is suitable just for maintenance update, for trunk I create better solution ) is temporary overwrite of target method to change its behavior. Now how to do it?
There is simple example:

class T
  def test
    puts "test"
  end

  def lest
    puts "lest"
  end

  def m
    test
  end
end


T.new.m
T.send(:define_method,:m_a) { lest }
T.send(:alias_method, :m_old, :m)
T.send(:alias_method, :m, :m_a)
T.new.m
T.send(:alias_method, :m, :m_old)
T.send(:undef_method, :m_a)
T.send(:undef_method, :m_old)
T.new.m

as you can see after modification class is exact same as before ( except if there is method a, but it is possible to handle it via introspection and dynamic choose of method). I don’t need to change whole stack of calls to add parameter or introduce new singleton class which can have flag.
I hope it help someone with his fix of not so well written piece of software.