Team Granular Blog

Granular on Twitter

Anurag Bhandari — Mon, 27 Jul 2009 09:47:50 +0000

In this era of microblogging, the need for a team/product to have a microblogging account is inevitable. That’s why we created Granular’s Twitter page where we’ll keep you updated with those “short” messages of what is going on in Team Granular. Catch the team members expressing themselves on Twitter and quick news related to Granular @GranularLinux.

Recent developments

Anurag Bhandari — Tue, 21 Jul 2009 10:48:44 +0000

It is worthwhile to check out the new front page of packages.granularproject.org. With the creation of repository for Granular 2, codename Wolverine, a need was felt to provide the option to browse all existing repositories through GPA. Developed using jQuery, the front page of GPA now acts as en entry point to browse the repositories wolverine and 2008, and will provide the option to browse any repository that is added in future.

The initial packages, as you’ll see, in the wolverine repo are those of KDE 4.3 RC2. Still many more to come!

Yatin is back

Anurag Bhandari — Wed, 15 Jul 2009 07:26:46 +0000

One of the founding members of the project, A.P. Yatindra (Yatin) is back with us into the team after about 2 years. It’s been a long time since he left, for some personal reasons, and much has changed in the project since then. But I am sure it won’t take too long for him to get familiar with the activities that go around in the team.

Welcome back, Yatin.

Granular & Unity

Anurag Bhandari — Sat, 11 Apr 2009 12:36:37 +0000

It’s a publicly known fact now that many of the former PCLinuxOS developers have started a new project, independent of PCLinuxOS, with the name Unity Project, with nothing against PCLinuxOS. The news was first publicly announced in the very popular Linux newsletter DistroWatch Weekly, 30th March 2009. Alongside many key former PCLOS developers, the Unity Project comprises of teams of distributions that were previously based on PCLOS, but later decided they would go the Unity way. And of course, there are some other talented technical & non-technical people who have decided to help the project grow.

Unity has begun with the initial aim of providing a robust base for many Linux distributions that were formerly based on PCLinuxOS. But the support for providing a common base for a distro would of course be extended in the future to other distro too. The Unity developers do not intend to make an end-user release of the distro, just a base for member distributions (branches) to use.

After many discussions and meetings among the Team Granular members, it was decided that Granular Project would also join Unity. Granular is intended to represent the KDE branch of Unity. Team Granular developers and packagers also are interested in contributing to the Unity Project in form of packages (RPM), resources, code, etc.

So, that would mean the end of 2 year long direct association of Granular with PCLinuxOS, and a new bond with Unity. Although this decision was a result of a few technical difficulties we were having with PCLinuxOS as the base, PCLOS has always been a great distribution, and all the devs who put all their hard work into it, our hats off to them! Wishing PCLinuxOS good luck, we move forward to a new future of Granular with the hope of giving it’s users (and potential users) the best of Linux world.

Making of Granular Package Archive

Anurag Bhandari — Sun, 29 Mar 2009 06:35:15 +0000

Introduction

As I mentioned in my previous post on Granular Package Archive, GPA is based on two technologies/programming languages – Java and PHP. Yes, you read it right, as weird as a combination of a statically and dynamically typed languages. The Java-based backend programs are responsible for collecting all the necessary information about each RPM package in the repository, and post all that information in a database. This database acts a common entity for the backend and the frontend alike. That is, the PHP-based frontend reads information from the database, and uses that information to interface with the end-user.

Basic illustration of the working of package archive

The Java backend

There are four Java classes involved:

ReadTextFile
Fetches the entire contents of a text file, and returns it as a String.
DirectoryScanner
Scans a directory and returns the list of files contained in it.
ExtractInfo
Extracts and returns many RPM properties for a RPM package.
PostToDB
Reads the full path to the repository on the server from the file “repository_location.txt” (using ReadTextFile), scans the repository directory for RPMs in it (using DirectoryScanner), extracts rpminfo for each RPM in the file list (using ExtractInfo), and dumps the extracted rpminfo about each RPM into the MySQL database.

The command I’ve used to get info about a RPM is:

rpm -qp –queryformat %{PROPERTY}

where PROPERTY can be NAME, SIZE, PACKAGER, URL, VERSION, etc. Note that if you have don’t have “rpm” command installed on your repository server and you don’t have enough permissions to install it in the standard path, you might then want to install “rpm” command in the home directory of your server account. In that case, you’ll need to add the –rcfile=/location/to/rpmrc/file modifier to the above command. In that case, also make sure you have properly setup the PATH and LD_LIBRARY_PATH variables properly for the “rpm” command to work.

The PHP frontend

The frontend is actually what a user sees as a website. It provides an interface to view all the information, from database, available about the packages in the repository. And what better language could it have been to develop this interface than PHP? It’s a beautiful language to code in. To begin with, I used my existing project called MyBlog to take the design and comment/discussion system. Other than that, I wrote most of the code from scratch. The comment system provides for the option of discussion on each package by the visiting users. The developers and packagers can also use this feature to notify users about any changes made between package releases. For the comment form, I integrated the very popular open source WYSIWYG web editor FCKeditor. Overall, this PHP frontend is reasonably fast and serves its purpose well.

Package Archive for your repository

Yes, you can actually use this system for your repository too! I did the coding in a fashion to make it usable by others too. This system can be useful in case you are a part of a RPM-based Linux distro and want your users to give the option of knowing the packages contained in your repository.

The following information should help you deploy the thing for your purpose.

REQUIREMENTS:

PHP >=4 installed on your server
JRE >=5 installed on your server
JDK >=1.5 installed on your server if you want to compile the .java programs on the server itself
MySQL >= 4 installed on your server
MySQL Connector/J
Shell access (ssh) / crontab option on your server.

DOWNLOAD:

pa_backend.zip – Backend Java source programs and MySQL database structure
pa_frontend.zip – Frontend PHP website

USAGE:

Extract the contents of pa_backend.zip. Modify the file “PostToDB.java” to change the MySQL related variables and set them to reflect your MySQL database configuration – serverName, dbName, username, and password.
Edit the file “repository_location.txt” to put the complete server path to your own repository.
Compile the backend by issuing following commands:

$ cd pa_backend/
$ javac rpm/ReadTextFile.java
$ javac rpm/DirectoryScanner.java
$ javac rpm/ExtractInfo.java
$ javac rpm/PostToDB.java
Put the whole “pa_backend” folder into a non-readable location on your server. Prefer not to include any .java file while uploading, just .class files and the lone .txt file.
Based on the database information you put in PostToDB.java file, create the corresponding MySQL database.
Next, import the file “rpmdb.sql” (present along with other extracted stuff from the pa_backend.zip archive) into the just created database. This step is required to create the necessary database tables. Using a tool like phpMyAdmin will ease this task for you.
The backend setup is over now. Now, download the archive pa_frontend.zip and extract it.
Edit the file “mb_config.php” to modify the MySQL variables to reflect your database settings – $DB_NAME, $DB_USER, $DB_PASSWORD, and $DB_HOST.
All the other .php files are branded according to “Granular”. So, you might want to edit these .php files to take care of branding.
That’s all. Now upload all the files & folders in the extracted folder “pa_frontend” to the appropriate directory in your webserver location. Say, if you upload these into a directory “packages” in the root of your webserver path, you’ll then access the frontend website using the url http://www.yoursite.com/packages/.
Now, the final step is to instruct your backend to extract information about each package in your repository and post it to the database. You do this by either logging into your server using ssh or setting up a cron job for the same. Either way, you’ll need to execute the following commands:

$ cd /location/of/backend
(say, “cd ~/pa_backend/”)
$ java rpm/PostToDB section-name
(say, “java rpm/PostToDB main”)

where section-name is the name of a section within your repository. Repositories are generally divided into sections like RPMS.main, RPMS.kde, RPMS.non-free, etc. You’ll need to execute the second command above for each section in your repository.
The next time you execute these commands, perhaps to update the database with new packages, don’t forget to first truncate the table “packages” from your database. You can either do that by using phpMyAdmin, or manually by issuing commands:

$ mysql -h hostname -uusername -ppassword
mysql> use dbname;
mysql> truncate packages;
mysql> exit

TODO:

Make the package scanning & info posting process fast. It is too slow right now – only 3 packages processed per second.
Implement filter so that only .rpm files get scanned. This would be helpful in situations when a directory contains files other than RPMs as well.
Make the scanning such that only those RPMs are processed that were added/deleted after last scan was performed.
Make the frontend fully W3C standards compliant.
Make the backend read the MySQL server & database information from a text file rather than hard-coding this information in the Java program; like it is currently being done in case of repository location using the “repository_location.txt” text file.

Think you can help me improve this package archive system? If yes, please let me know by leaving a comment here.

Introducing Granular Package Archive

Anurag Bhandari — Fri, 27 Mar 2009 15:14:01 +0000

With our growing RPM package repository, we felt a need to create a web interface for the end-user to give him a glimpse of what actually lies inside the repository. Such an interface would let the users know about latest package additions/updates in the repository, provide information about each & every package that is in it, give the option to search for packages based on several parameters, and facilitate discussion on individual packages by other users too. Keeping all these things in mind, I started creating such an interface about a month ago using my already existing project MyBlog. So basically, this new interface is a website that contains information about each RPM in Granular’s repository, and more. We call it the Granular Package Archive.

Think of such as a system as the well-known Debian Package Archive or the Ubuntu Package Search. Granular Package Archive (GPA) was built from scratch, with the exception of MyBlog-like interface and discussion system. GPA is where two technologies combine to provide a very user-friendly interface to Granular’s repositories. I used the Java programming language to build the backend, and PHP to provide the actual website interface to the end-user.

Now before I get into the dirty details of behind-the-scenes working of GPA, let me quickly jot out all the features it has to offer:

Information available for all the RPMs present in our repositories.

Category-wise listing of RPMs on the front page. The categories are decided on the basis of groups to which packages belong to.

Well detailed individual RPM pages.

“Random Package” and “Latest Packages” on sidebar.

Quite functional “package search”. Search is made on parameters – package name, packager, summary and description. Performing an empty search till list all the RPMs present in the repository.

Anyone can leave comments on individual package pages. This makes up for detailed discussion on packages.

So, these were some quick features about the system. For details about the working of GPA, check out our follow-up post. Also, do not forget to check out how GPA feels like:
http://packages.granularproject.org/

Granular 1.0 in Digit magazine

Anurag Bhandari — Mon, 16 Mar 2009 14:55:21 +0000

The March 2009 issue of the popular Indian computer magazine – Digit – featured the most recent release of Granular, 1.0 (Esto Vox), on one of the two dual-layer DVDs that are usually bundled with the magazine. To give it a more Granular-like feel, Granular’s text logo was printed on the top of the DVD, and the background of that DVD was made to match the color of “G” in Granular’s text logo. Although it would have been better to see the red logo of Granular too printed on the DVD alongside the text logo, we have no complaints whatsoever.

A big thanks to the Digit team for including Granular 1.0 with their magazine. Team Granular will continue to improve & maintain the quality of Granular as a Linux distro so people always get only the best.

Video on introduction to Granular 1.0

Anurag Bhandari — Tue, 10 Mar 2009 13:30:33 +0000

Some one with the alias “SneekyLinux” at miroguide.com published a brilliant video introduction to the latest Granular release – version 1.0 (Esto Vox). The video was posted on 28 Jan 09, a few days after the release of Vox, as a review.

To quote the author of the video:

A look at granular 1.0,based on pclinux os,is a real good shot of happy in the os world as it does what it says.. “works out of the box” sweet……but is it sweet enough ?

Although the video was intended to be a review of Vox release of Granular, any Linux user not familiar with Granular can use it as a nice introduction to the Granular 1.0 release.

Link: https://www.miroguide.com/items/1368850

Granular 1.0 is coming

Anurag Bhandari — Sun, 28 Dec 2008 10:16:09 +0000

December was a month of serious Granular development as all the Team Granular members worked hard in their respective areas to come out with the final release of much delayed Granular 1.0 as soon as possible. And so, finally we were able to complete all the tasks in our previously large next release to-do list, which has been updated now and contains no pending tasks for the next release.

We’ll shorty begin the testing phase of Granular 1.0, and very soon after that you’ll be able to download your own copy of the much awaited Granular 1.0.

Expect Granular 1.0 in the first week of Janurary 2008. We are trying our best to coincide the release with Granular’s 2nd birthday, which falls on 1st January.

RPMs… RPMs…

Anurag Bhandari — Sun, 07 Dec 2008 21:47:10 +0000

These days, we are packaging RPMs like hell. A lots of them are being built to make them ready for the final Granular 1.0 release. And I am pretty well impressed with the speed with which Chris is doing this stuff. All the major pending updates are being taken care of right now as they are our top priority. We have many of them built up right now and the updates will be released as soon as possible. So, the present list you’ll see at the above link is some RPMs short of what we had before starting the development.
After we have handled everything in that list, we’ll move on to the next important to-do RPM list.

We are having fun building RPMs. Stay tuned for a nice Granular 1.0 final release which is coming soon.