One of the features available on the Upstream Tracker project is the ability to process custom URLs to track upstream package versions. This allows URLs to contain regular expressions which are processed using the re module in python. To demonstrate this feature, let me post a few sample inputs and outputs that were generated using this module.
Custom URL : http://coherence.beebits.net/download/Coherence-(.*)\.tar\.gz Coherence-0.6.6.2.tar.gz http://coherence.beebits.net/Coherence-0.6.6.2.tar.gz Custom URL : ftp://ftp.gimp.org/pub/gimp/help/gimp-help-(.*)\.tar\.gz gimp-help-2-0.11.tar.gz ftp://ftp.gimp.org/gimp-help-2-0.11.tar.gz Custom URL : http://code.google.com/p/giver/downloads/list/giver-(.*)\.tar\.gz giver-0.1.8.tar.gz http://code.google.com///giver.googlecode.com/files/giver-0.1.8.tar.gz Custom URL : http://sourceforge.net/api/file/index/project-name/libyui/rss/libyui-(.*)\.tar\.gz libyui-gtk-2.21.96.tar.gz http://sourceforge.net/projects/libyui/files/libyui-gtk-2.21.96.tar.gz Custom URL : https://launchpad.net/dee/+download/dee-(.*)\.tar\.gz dee-1.0.10.tar.gz https://launchpad.net/https://launchpad.net/dee/1.0/1.0.10/+download/dee-1.0.10.tar.gz Custom URL : https://launchpad.net/dee/+download/dee-0\.(.*)\.tar\.gz dee-0.5.22.tar.gz https://launchpad.net/https://launchpad.net/dee/0.5/0.5.22/+download/dee-0.5.22.tar.gz
From the above examples, we can see that the module supports projects hosted on sourceforge as well as projects where the download pages are accessible via HTTP and FTP. It is also possible to narrow down and search for only 0.x branch of a package using suitable regex as shown in the last example. The module tries to implement complete regex support and does this with the help of the python re module. However, to identify if a term has to be evaluated using re, we look for parenthesis. Thus, regular URLs with parenthesis would be treated as regex terms and would be processed accordingly. For example, consider the URL below :
Here, we list all the links present at https://launchpad.net/dee/+download/ and apply the regex dee-0\.(.*)\.tar\.gz on each of them. The links that conform to the format are processed to obtain the latest version and the location or the absolute URL of the tarball/source code. Here, dee-0\.(.*)\.tar\.gz is considered as the regex term as it contains parenthesis. Hence, currently, all regex terms should contain parenthesis ‘( )’ and should NOT contain ‘/’.
As work continues, there would be ways to escape the parenthesis which would enable users to work with URLs which contain parenthesis.
As a follow up to my previous post about customizing your GNOME Shell, here are a few themes I had recently come across. http://www.omgubuntu.co.uk/2011/10/five-pretty-awesome-gnome-shell-themes/ (opens in a new window). Other than smooth inset, which has been doing the rounds on the internet since GNOME 3 first arrived, the other themes look pretty new to me.
Have fun customizing!
GNOME3 and the GNOME Shell are no doubt, major improvements. They bring in usability and quite a bit of eye candy (in a different way compared to compiz) while at the same time, a few features went missing in 3.0 release – like Emblems, for instance. Nevertheless, GNOME3 is a great release and has been extremely stable so far (Yes, i have been using it since it’s release in April.).
One major complaint that I hear from people is that GNOME3 is not as easy to customize as 2.x. A lot of people seem to think that they are “stuck” with the blue-black theme that comes by default. Ofcourse this is not the case. In this post, I ll explain a few ways in which we can customize GNOME3 and the GNOME Shell.
But before proceeding any further, we have to make a clear distinction which was not necessary before. In GNOME3, with the advent of the shell, there are two sets of themes – one for the shell and the other for the windows (The GTK Theme). To get a smooth and complete makeover, one has to change both the themes. By default, we have the GNOME3 shell theme and the Adwaita Metacity theme for the windows.
1. GNOME Shell Themes
This must be one of the biggest issues I have with he way GNOME3 looks. I cant bear the big, black stripe on the top. It just does not look good. I am sure there are many of you out there who would agree with me on that. But luckily, there are quite a few good options out there that can replace it for us. Also, just to make it easier for us, let’s install the gnome-shell-theme-selector plugin so that we can swtich between themes faster. This plugin adds a Theme button on the top along with windows and application buttons in the Activities mode so that you can change you theme on the fly! So, let’s get started.
Open up a terminal, and type in the following commands to install GNOME Shell Extensions.
./autogen.sh –prefix=/usr –enable-extensions=user-theme
make && sudo make install
Now, let’s install the Themeselector extension. Fire up another terminal and follow me.
tar xvf themeselector-0.9.tar.gz
mv themeselector-0.9/extension.js ~/.email@example.com/
mv themeselector-0.9/metadata.json ~/.firstname.lastname@example.org/
mv themeselector-0.9/* ~/.themes/
Now, restart GNOME-Shell by pressing Alt+F2 and typing ‘r’ (Without quotes followed by enter). Now, in the activities window, you should have a themes tab with 6 themes to choose from!
To add any new themes you may come across later on, simply extract and add the folders to ~/.themes/ directory. Simple right?
2. GTK Themes
Now, to complete the new look for your desktop, grab a suitable GTK theme to match with your Shell theme from GNOME-Looks.org or from any other website. To install, simply extract the theme to /usr/share/themes.
Great, Not the last thing is to actually tweak the GNOME settings and make it use the GTK theme we just installed. Let’s see how to do that next.
The GNOME-Tweak-Tool is an aplication that is used to tweak a few values that changes the way your desktop looks and feels which, otherwise, is hard to change. The UI is clean and intuitive, which is a key aspect of a configuration tool.
To obtain the tweak tool, open another terminal and :
NOTE: Compiled binary is available in the git repository. Hence no need to recompile. Works as it is.
That should fire up a window as shown above. On the left, choose interface from the list and on the right, select the GTK theme you just installed using the drop down menu. And that’s it!
You can mess around and change a few other things like the font, font size and quite a few other settings. So be sure to check out all the options…
Here is how I have set up my GNOME3. I am not artistically inclined and I am sure a lot of you out there can do much better. So let me know what you guys end up with.
As most of you reading this post would know, separating libYUI was one of the topics for GSoC 2011 by openSUSE. Over the last three months, a lot of work has gone into the project. As the deadline approaches, we am happy to announce that libYUI is an independent framework!
Let me summarize the changes that have taken place over the last three months. For starters, libYUI is available over a range of platforms. Major platforms like Fedora, Ubuntu and Debian have ready made binaries available at OBS - http://download.opensuse.org/repositories/home:/nbprashanth/. Recently, Michal Hrušecký even ported the library to Gentoo! – michal.hrusecky.net/2011/08/libyui-in-gentoo/. The source has been completely detached from SUSE-centric technologies. So if binaries are not available for your distro, don’t fret. You can always download the source and install from – http://sourceforge.net/projects/libyui/files/.
Apart from porting the library to various platforms, another recent improvement was the upgrade of the GTK plugin from GTK2 to GTK3. In many aspects, this is a very important update.
As the major idea behind the porting effort is to make the library truly independent, it is necessary for libYUI to get a place for itself. For this, we have made a SourceForge page for libyui – sourceforge.net/projects/libyui/. This is an important step that allows us to concentrate on the development of libYUI as a separate framework not influenced much by any other project. We have a separate mailing list, forum and bug tracker set up as well.
Despite the SourceForge page, libYUI will not be using the SVN repository provided by SourceForge. Instead, the source would be moved from the openSUSE SVN to git (github) along with YaST.
There are a lot of projects that currently make us of this wonderful library. YaST is one major application that many geekos out there would be familiar with. Another upcoming application is the sought after SaX3 – An Advanced Graphical X configuration tool by Manu Gupta – http://sysbytes.wordpress.com/. Due to the port of libYUI, SaX3 can be compiled on various platforms! Now, is that not wonderful?
Apart from the above, several small developments have occurred, which one may be familiar with having read my previous, scattered posts. The documentation, for one, has been uploaded. It can be found at – doc.opensuse.org/projects/libyui/HEAD/. Also, we have a libYUI SourceForge page that will serve as the starting point for everything YUI-related – http://libyui.sourceforge.net/. Ofcourse, the page is pretty bland at the moment, but it does satisfy the basics. I ll work on that aspect a while later.
For those who want to contribute or take a look at the development version of libYUI, you can find the sources at – gitorious.org/libyui. Be warned that this URL is bound to change soon when YaST migrates to GitHub.
We are on the lookout for daring and bold testers who can give the new libYUI a spin on various platforms and report bugs, if any. Bugs can be reported on the SourceForge page. Feel free to give feedback as comments (as long as it is not about a bug). And if you are a developer who is curious or just not convinced about YUI’s capability, then give it a spin and see for yourself why it is better! Trust me, you wont regret it.
Last week has been quite dull after the mid term evaluations. The week started off with me trying to improve the documentation and a home page for it. While the latter went pretty smooth, the documentation is quite baffling. Most of the source code was quite well documented and small hacks with the Doxyfile seemed to produce the proper results. Nevertheless, there were cases (quite a few) where the results seemed out of place. While struggling with the docs, I also started working on the libyui-gtk-pkg package. This package provides the libzypp plugin for the libyui-gtk module. This has been separated from libyui-gtk package so as to make it platform independent. I am nearly there on getting this package to compile. A day or two should be sufficient, I guess.
By the end of last week, I switched over to writing examples for YUI in the hope that it would give me further insight into what a developer might expect from the docs. After a few not-so-great ideas, I settled on an IRC client written with YUI. The library to manage the IRC protocol is self-implemented and is complete. At this point in time, it handles only conversations and a single channel. This is very small compared to the span of the IRC protocol. But since the main aspect of the example is to showcase YUI as a UI library, I guess the features are sufficient.
Over the last month, libYUI has significantly expanded. It is an independent framework and is avalable outside the SUSE framework making it accessible to a wide audience. This has resulted in the project having distributed content on the web. For example, the source code is maintained at gitorious.org (currently svn.opensuse.org) and the documentation at docs.opensuse.org etc. YUI does not have it’s own mailing list and the issues are still being dealt with on the yast ML. Considering all this, we thought that it would be good to have a central place where from all the resources can be accessed. Thus, we bring to you, sourceforge.net/projects/libyui/.
This means that :
1. YUI has it’s own bug tracker. Any bugs/feature requests should be reported at the sourceforge page.
2. YUI will not maintain it’s source code at SF as we are already porting the code to gitorious.org.
3. Current release tarballs can be found at the SF downloads page.
4. Mailing List for YUI can be found at email@example.com. This can be used for all YUI (not YaST) related discussions.
5. Webpage for YUI along with examples and links to external resources will be up soon.
6. Forum for YUI related topics is available at SF.
So, stay tuned to sourceforge to keep track of YUI!
libYUI along with the ncurses, Qt and Gtk plugins are now available for non-SUSE platforms. The builds are hosted at OBS and the build targets are Fedora (14 & 15) , Ubuntu (10.10 & 11.04) and Debian 6. The download repository can be found at : http://download.opensuse.org/repositories/home:/nbprashanth/.
Bugs in packaging can be reported in the comments section below.
It’s time for some screenshots! (Finally). The programs are standard YUI examples found at the openSUSE svn : svn.opensuse.org/svn/yast/libyui.
System : Fedora 15; GNOME 3 Desktop
ComboBox1.cc – GTK
ComboBox1.cc – Ncurses
ComboBox1.cc – Qt
HelloWorld.cc – GTK(Left) & Qt (Right)
HelloWorld.cc – Ncurses
All plugins in action
Yes. Sorry. It is another report. But i ll try my best to keep this one short though.
Last week was all about the GTK plugin. This plugin was different from the other plugins and was dependent on libzypp. And libzypp was dependent on libsatsolver and that was dependent on…. well, you get the point. The libzypp dependecy had to be removed and that was my job.
Most of the time was spent in analysing how (and why) libzypp was used by the plugin. Once i figured that out and got the plugin to compile without libzypp, I was faced with more problems. Initial builds were fine on my Fedora box (F15). But when I built it on OBS, the F14 build failed. After reading the logs, i found out that gdk-pixbuf package by default installs itself in a different location in F14. This broke the build on F14.
The Deb builds were more problematic. They failed on my build system (ubuntu 11.04). CMake seemed to have difficulties in finding GTK includes and libs. After trying to tweak the code and check for alternatives using pkg-config, i finally stumbled on to a link where i found out that this was a known issue with CMake on Ubuntu 11.04.
Well, after this it seemed to be a waste to carry on with CMake when 50% of the builds failed. So i started off on a quest to convert the packages to autotools. Now, the GTK plugin completely uses autotools and works fine on Ubuntu 11.04 and F15. I am in the process of converting the other packages to use autotools as well for the sake of uniformity and maintainability. But that would ofc, depend on the approval of the respective package maintainers.
Another change this week is the removal of the git repo at gitorious.org/libyui/libyui. This space will be filled by the official libyui repository once the svn-git conversion is complete. The old repo can be found at gitorious.org/libyui/gsoc2011. I ll be maintaining all project related files there including the source packages that have been converted to autotools and examples. I am no expert at autotools. Infact, i had to do quite a bit of studying to replace cmake. So if anyone with a good autotools background finds any flaws with the packages, please leave a comment below.
The documentation would be the next task. At present, the documentation is generated by a makefile using doxygen. This is not linked to the documentation servers at openSUSE and hence, there are no weekly updates yet. This would be implemented once the YUI repo is shifted to git.
The GTK package will be added to OBS soon.
Less than 500 words.
Hi. The last week was full of changes for libYUI. To start off, the packages are no longer being built locally and the build process is now handled by OBS. This makes libYUI available on a wide range of operating systems and architectures. Currently, the build at OBS is being done for Fedora 14/15 as well as Ubuntu 10.10/11.04 for both x86 and x86_64 architectures. Interested people can find the OBS repository at http://download.opensuse.org/repositories/home:/nbprashanth/. This means that the binaries will no longer be availalbe at the gitorious repository(gitorious.org/libyui).
Secondly, the initial documentation for the library is hosted at http://doc.opensuse.org/projects/libyui/HEAD/. This documentation is subjected to frequent updates and will change regularly (weekly updates planned). Again, to avoid duplications, the gitorious repository will not contain the documentation anymore.
People who test the new packages are requested to submit bug reports (here or at OBS) in order to help improve libYUI.