Infinity Perl : slack-get, Perl, Qt, KDE and other Open source stuffs

To content | To menu | To search

Tag - Slackware

Entries feed - Comments feed

Wednesday 13 August 2008

slack-get development diary #6

Back from a long silence period, here it is : the 6th opus of the "slack-get development diary" !
There is a lot of new things that I need to talk about !
First the bad news : I saw on CPAN reports that the "fix" I made for Slackware::Slackget to properly test on Solaris OS is not working.
That is a bad thing but... I don't really see the purpose on trying to fix an issue on an OS which is not a Slackware based one and not even a GNU/Linux OS ! The Slackware::Slackget module will never be usefull on this OS, so since I have no Solaris to test I will just forget about it (unless somebody provides me with a patch for this system.

Now for all the good news :
  • slack-get suite (sg_daemon + slack-get) is now able to install, upgrade and remove packages
That's the first point, and I think it's a pretty important one. I fixed all the daemon and the (cli) client to make them able to perform packages operations without any problems.
So from now on, you can start a daemon and do a "slack-get install flightgear" for example :)
That's a very important point but it's nothing worth talking about without the dependencies tracking system.
Talking about that...
  • the dependencies tracking system is now fully functionnal
Woohooo ! This part was certainly one of the most painfull, but I finally manage to get it working the right way.
This part still need to be tested and there is no guarantees, so far, that it is working properly in all cases.
But so far my tests where very promisefull ! I add no problems and for the moment I have not yet discovered any bugs in this feature.
Again, that does not means that I will not uncover bugs later.
  • add support for automatic GPG key import
I added the possibility for the sg_daemon to download and import a GPG key. For the moment it only import Slackware Project's key and it is almost hardcoded but there is no reasons to extend this feature to all medias sooner or later.
This feature works well and is totally automatic : if sg_daemon do not find the Slackware Project's key in the user's GPG keyring, it download it and import it. Nice and easy.
  • add new feature to slack-get (cli client)
I added a new command to slack-get, it is called "info". You can use it the exact same way than the "search" command (this is the exact same code which is processing it).
The goal of this command is to provide more informations about a package. Here is an usage example :
$ ./slack-get info flightgear --media=slacky
Package: flightgear-1.0.0-i686-1as
Size (compressed): 3158 KB
Version: 1.0.0
Source: slacky
Description: The FlightGear flight simulator open-source project.The  goal  of  the  FlightGear project is to create a
sophisticated flight simulator framework for  use  in  research  or  academic environments,  for the development and pursuit
of other interesting flight simulation ideas, and as an end-user application
http://www.flightgear.org/ WWW.SLACKY.IT PackaGer Gohanz.


This little example, allow me to introduce the new command line option : --media. This one allow you to restrict the "search" or "info" commandes to the choosen media (in the previous example I wanted only results from the Slacky.it website).

Last about the slack-get cli client, I fixed lots of "non closing bugs". The non closing bugs are an annoying problem of slack-get cli client.
While the whole system became multitasks, it's becomming difficult to keep track of what the client asked by itself (particularly in a multi-administrators context), and after asking a sg_daemon to perform some tasks (and after the tasks are finished) the client does not end.
I corrected a lot of thoses problems.
A good example of this issue is with the "slack-get update" command. This one scheduled a tasks to upgrade all packages which have new ones in the patches/ subtree of the official-media (see config.xml). After the update, the client was not quitting. It is now corrected.
  • dynamic network backends negociation
Some of you may have noticed that sg_daemon should be able to dynamically negociate what network backends the client and it should use to understand each others. Until this morning it was not working, and it is now !
If sg_daemon supports XML and Base64 backends, and if the slack-get client supports XML and Gzip backends ; they will both agree on using the biggest common denominator (in this case they will use XML only).
I am very happy (and quite proud) of this mechanism. It allows tons of new development and many plugins to come !
  • lots of updates in the Slackware::Slackget Perl module
Last but not least I made tons of modifications in the Slackware::Slackget module. I added constants, generative methods to Slackware::Slackget::Media, add codes to Slackware::Slackget::GPG to support new import features, add method to Slackware::Slackget to check host's Slackware's version, and so on and so forth !

As a conclusion, I will just say that there is still some works to do but it's becomming to be a very usable tool. I'm using it every day now.
I hope all the work I made on slack-get will be of interets for you all !
As a bonus track I give you the new slack-get logo (that I made myself... so be kind ;-) )


Enjoy !

Arnaud Dupuis


Thursday 10 January 2008

Little question from a slack-get user

Hello,
I recently received an email from Mark, a slack-get user, who asked me a very simple question : why have I called slack-get this way ?
Well, this is a tricky question. Let me answer this :

At first I wanted to call it get-slack, this is the name of the menu you have to click on Slackware's website. But it was to close from the website and I didn't want to take this initiative (at least not alone, I could have ask for the permission of Pat or the crew). So helped by a huge sense of originaluty and creation, I decided to switch syllable and/or letters.
I came with some nice thing like : gsletack or gstckael but I was afraid somebody else already took the name (and a bit afraid about the poor americans unable to pronounce that ... not talking about Japanese... and not talking about me !).
So I finally came with slack-get, a bit inspired (i must admit it) by an obscur soft called apt-get, and largelly because of the signification of slack-get's acronyme :


So, Mark, I hope that I answered your question ;-) Else feel free to send me another email (I like receving email from slack-get users, particularly when they are kind with me and slack-get !).

See you later,

Arnaud Dupuis

Tuesday 1 January 2008

slack-get development diary #5

Hi !

First of everything : I wish you all an happy new year. May all your desires come to reality !

My own desire is to release a first version of the new slack-get daemon quickly as possible. I'm coding the real work for the upgrade and install actions (update, remove, search and the others are already working but the remove one was still not test on a real case).
Some things actually happened on slack-get development since the last diary.

Bugfixes

I fix a lots of (very old) bugs. For example, in the Slackware::Slackget::Base class (which is untouched since months), there was a bug and the FILELIST: tag from the packages text file was not removed correctly and was still present in the XML. This is now fixed.
I also improve a lot the way metadata are parsed by classes like Slackware::Slackget::Package by simplifying the parsing regular expressions.
Without turning this diary in a bugfixe list, I also modify some XML parsing behaviors in order to make the resulting data structure consistent over time. I modified the Slackware::Slackget::Package class quite a lot and it now parse itself the dependency fields in the packages metadata and translates them into XML. The impact of this is : a bigger XML file (packages.xml), and an increased loading time. But in the other end, all data are now completely parsed in the XML file and there is no extra work to do after parsing, and the dependency tracking is a lot easier (and actually quicker ^^).

Remaining bugs

There is still a bug in Slackware::Slackget::Network::Backend::Gzip. The backend which is in charge to compress and uncompress the network messages... Well it's not working at all, and worst i don't know why. But in the other hand, i have not tried a lot to fix this module. I focus on sg_daemon and slack-get for the moment (and the involved vital modules).
The Base64 and XML backends are still working fine.

Other stuff

You should also be aware that I'm trying to help as much as I can for the KDE 4.0 release, so until the 11th of January the slack-get's development will certainly be slowed down by my involvement in KDE 4.0 development.
And on the 11th of January i'm going to snowboarding in the Alps until the 20th of January ! So I will not be available at all during this time... Off course, because I'll be too busy trying to break some of my bones ;-)

Thursday 6 December 2007

Slackware::Slackget is born !

Hi,
As I announced many times, the slackget10 is now dead since the Slackware::Slackget namespace was created on CPAN.
I already released 2 versions of this module and will keep going !
With the last release, I finally managed to fix the test suite in in order to pass all tests on all testers architectures (even on Cygwin !).
I also improved a lot the network backend system by making it stackable and even if some problems are still here the global thing is on the rails.

What I'm not very happy with is the remaining problems with the S::Sg::Network module... On the paper it works just great, I can take the output of the decode() method to give it as input to the encode() one and all runs perfectly smoothly (see the network-backend.pl test script). But in real life... the sg_daemon and slack-get have some difficulties to talk to each other...

Anyway things are going pretty well and I have a lot to write in the "development diary" !!

Cya !

Arnaud Dupuis

Tuesday 6 November 2007

slack-get development diary #2

Hi,


First let me tell you some things about me : I've got a new job recently. I'm now working in a IT consulting company in their Open Source business unit. That's great !

I also marry my fiancée in June... So you can tell that I have less time to code ;-)

That was for the explanation why I haven't code a lot this week :)

But the slack-get development is still moving quite nicely, even if I had loads of problems this week. I focused on turning all the network handling code in sg_daemon POE compliant. So I looked at a POE Component (PoCo) wich implements the HTTP protocol.. Great the is one who manage parallel downloads !! I tried it and it is just what I need. So I began to search the same things but for other protocols sg_daemon support... and here are the problems.

I found nothing for the FILE protocol and the PoCo for FTP is still young and do not provide the same API than PoCo::Client::HTTP. So I ended to reverse the changes I already made to slackget10::Network::Connection::HTTP and decided to change the API to emulate the POE way of doing things. So the slackget10::Network::Connection object must, now, be constructed with an argument InlineState => {}which contains 3 events : progress, download_finished, and download_error. You have to associates a handler to each of this events.

Talking about this class, the internal architecture have changed and it is now way easier to add drivers for slackget10::Network::Connection. You just have to create a class wich implements some methods. It will be the feature highlights of the week.

I have not much to say considering that all my family stuff for my weddings and all the problems I met with the "POE-ification" of the network code slowed me down a lot.

Let's hope for next week :-)

Enjoy !

Arnaud Dupuis

Tuesday 30 October 2007

slack-get feature highlights #1 : managing the install medias

Hi !

Today I'm introducing a new kind of post : the slack-get functionality highlights. What is that ? Well once a week (or more often maybe) I will introduce and explain a specific functionality of slack-get.
It can be in sg_daemon, or slack-get tools (CLI or GUI). It can also be some nice features of one of the slack-get libraries (slackget10 Perl module or the upcoming C++ one).

Enough introduction ! Today's highlight is about the media management system. Before everything, please note that all the examples in this diary will work on all slack-get version >= 1.0.0_pre-alpha1

How do slack-get manage its media and how the daemon choose to download a package from a server or another ? This is indeed a good question because there is very few documentation about this feature.... my bad :(
So.. slack-get use a configuration file called medias.xml where all medias are listed. This file is a XML one (as suggested by its extension...), and look like that :
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<medialist>
    <media id="media1">
       // lets forget this part for now
    </media>
    <media id="media2">
       // ...
    </media>
</medialist>



Quite easy to understand isn't it ? there is a media list which contains a list of media... fair enough :)
Now what about the <media></media> entity ? It's basically THE basic entity for all media you want to use as an install source.
As I write this, you can have 3 types of media :
  • http ones. For all repositories you access via the http protocol ;
  • ftp ones. For... yes : all the repositories you can access via the ftp protocol ;
  • file ones. That's the general one. You can use it for installing Slackware packages from your Slackware DVD, from a NFS drive or any other repository which can be seen as "local filesystem" by your system.
The structure of the XML entity <media></media> look like that :
<media id="a_media_id">
    <files>
        <filelist>FILELIST.TXT</filelist>
        <checksums>CHECKSUMS.md5</checksums>
        <packages>PACKAGES.TXT.gz</packages>
    </files>
    <update-repository>
        <faster><!-- an URL --></faster>
       <fast>
          <li><!-- an URL --></li>
          <li><!-- another URL --></li>
       </fast>
       <slow>
          <li><!-- an URL --></li>
          <li><!-- another URL --></li>
       </slow>
    </update-repository>
    <description>The description of this media.</description>
    <web-link>http://www.mysite.org</web-site>
</media>


The <files></files> entity gives the name of the files which actually contains the wanted informations. there is 3 informations wanted :
  1. the list of the repository files ( usually in the FILELIST.TXT file ) ;
  2. the list of the files checksums ( usually in the CHECKSUMS.md5 file ) ;
  3. the detailled list of packages ( usually in the PACKAGES.txt file ).
the slackget10 Perl module compile all those informations in a single file ( called installed.xml, we will discuss about it in another "slack-get functionality highlights" issue ).
You can say here if you prefer to download the compressed version if exists and if the repository is not really standard (file name in lower case for example) you also have more flexibility here.
I got emails from a bunch of peoples who even used the old slack-get daemon (slack-getd) to install red hat packages ! Which means one thing : you can do more than I coded with slack-get :D
Actually, it's not hard to modify the initial way-of-doing-things of slack-get, you just have to replace some of the Perl modules.

Let's see a simple example : adding the Slackware 12.0 DVD to the media list.
First open the medias.xml file with your favorite editor, then add the following :
    <media id="SlackDvd12.0">
        <files>
            <filelist>FILELIST.TXT</filelist>
            <checksums>CHECKSUMS.md5</checksums>
            <packages>PACKAGES.TXT</packages>
        </files>
        <update-repository>
            <faster>file:///mnt/cdrom/</faster>
        </update-repository>
        <description>The official 12.0 cd-rom directory.</description>
    </media>

The first thing you can note is that we didn't used all the possible XML entity in this example. Indeed all fields are not mandatories. The only mandatories "fields" (attribute or tag) are :
  • id : the media id attribute ;
  • the <update-repository></update-repository> tag ;
  • the <faster></faster> tag.
So we added a new media, its id is "SlackDvd12.0", it use the standard files (so we can simplify this entry and remove the <files></files> section), and the only repository we have is in the /mnt/cdrom/ and have a small description.
We can simplify this media section (without loosing any informations), like that :
    <media id="SlackDvd12.0">
        <update-repository>
            <faster>file:///mnt/cdrom/</faster>
        </update-repository>
        <description>The official 12.0 cd-rom directory.</description>
    </media>


This example, is simple and quickly added, let's have a look at a more complete example, by adding the LinuxPackages repository to our medias list :
    <media id="linuxpackages">
        <files>
            <filelist>FILELIST.TXT</filelist>
            <checksums>CHECKSUMS.md5.gz</checksums>
            <packages>PACKAGES.TXT.gz</packages>
        </files>
        <update-repository>
            <faster>http://opensys.linuxpackages.net/Slackware-11.0/</faster>
            <fast>
                <li>http://www.nymphomatic.org/mirror/linuxpackages/Slackware-12.0/</li>
                <li>http://linuxpackages.inode.at/Slackware-12.0/</li>
                <li>http://ftp.scarlet.be/pub/linuxpackages/Slackware-12.0/</li>
                <li>http://www2.linuxpackages.net/packages/Slackware-12.0/</li>
                <li>http://mirror.etf.bg.ac.yu/linuxpackages/Slackware-12.0/</li>
                <li>http://linuxpackages.slackwaresupport.com/Slackware-12.0/</li>
            </fast>
            <slow>
                <li>ftp://linuxpackages.inode.at/Slackware-12.0/</li>
                <li>ftp://ftp.scarlet.be/pub/linuxpackages/Slackware-12.0/</li>
                <li>http://linuxpackages.cgucccc.org/Slackware-12.0/</li>
                <li>ftp://ftp3.linuxpackages.net/pub/Slackware-12.0/</li>
                <li>ftp://mirror.etf.bg.ac.yu/linuxpackages/Slackware-12.0/</li>
                <li>ftp://ftp.slackware.hu/linuxpackages/Slackware-12.0/</li>
                <li>ftp://opensys.linuxpackages.net/pub/Slackware-12.0/</li>
                <li>ftp://ftp.nymphomatic.org/linuxpackages/Slackware-12.0/</li>
            </slow>
        </update-repository>
        <description>Slackware resources to help install and configure the Linux slackware distribution, Email list, Discussion Board, Howtos, Contributed packages, and much more</description>
        <web-link>http://www.linuxpackages.net</web-link>
    </media>


Here we specify compressed files in the <files></files> section. This is possible because the slackget10::File class can load both of compressed and uncompressed files.
Then we have a list of repositories. The <faster></faster> one is like your preferred mirror, it will always be used unless it is not reachable. If it's not, servers in the <fast></fast> section are tried, then come the ones in the <slow></slow> section.
As you can see we have mixed type of mirrors : some are HTTP ones while other are FTP ones. That is not a problem, you can mix sources of all kinds. The only limitation is that slack-get must have a driver for the specified protocol (for the moment you can use only, http://, ftp:// and file://).
You can also see that we have set a web site for this media. This information is use in many way, for example in the search page of the slack-get site, or in the GUI to provide a link to the repository maintener site.

In real world, slack-get can test all the repositories and classify them by their answer time. Like in many other fields, I tried to make the slack-get's parts as clever as possible and do the right thing with the right informations. I hope it works ;-)

Now for the unreleased things and the unbelievably new informations : I will add the support of variables in repository URLs... this will allow you to write things like that in your medias.xml :
<update-repository param="$SLACKWARE_VERSION=12.0">
    <faster>http://opensys.linuxpackages.net/Slackware-$SLACKWARE_VERSION/</faster>
</update-repository>


Nice isn't it ? I'm still not sure about the final shape of this feature but I think it'll be like I just showed you.

To conclude, you are now more informed on the media management system of slack-get and you can easily manually add new repositories to your medias.xml file.
In the next version of the GUI you will be able to edit this file with a nice window.
I hope this article helped you to better understand some of the slack-get's black magic :-)
Please, feel free to react, comment and propose improvements.

Arnaud Dupuis

Saturday 27 October 2007

slack-get development diary #1

Hi !

I've got a lot to say today !
First of all I was surprised by the number of failed test in my last release of the slackget10 Perl module. After some work on this, and with the great help of David Cantrell, we managed to find to work out the problem.
It is in the test suite of XML::Simple (used by slackget10::Base and other slackget10::* classes) : if XML::Parser failed to install the XML::Simple's test suite do not chain fail, and the installation is not done well, but it's done.
So if you try to use XML::Simple with the directive :
$XML::Simple::PREFERRED_PARSER='XML::Parser';
slackget10::Base just crash. David submitted a patch which is very simple but also very efficient :
eval 'use XML::Parser';
if($@) {
    warn("XML::Parser is not installed. XML processing operations will be very slow.\n");
} else {
    $XML::Simple::PREFERRED_PARSER='XML::Parser' ;
}


It fixed the problem, and I have integrated it directly to the trunk of slack-get SVN repository.

The second point is the slack-get communication protocol draft. Things are going well, I think I finished to determine at least 70% of the communication needs.
If you are willing to give me an advice on this draft do not hesitate ! Go checkout the SVN version and have a look in the trunk/devel/ directory.

About sg_daemon now : I've got the internal scheduler working ! yeehaa !
I've finish the porting of the "installed packages list building" functionality  and it's now working with the internal scheduler of sg_daemon.
The great thing is : that was the hardest part :)
Porting the other functionalities will be easy... or not... indeed some internal functions of sg_daemon are not adapted to the POE architecture and will take some time to port.

Last but not least, I've come with a new icon for slack-get, feel free to give your opinion :

Wednesday 24 October 2007

new release of the slack-get Perl Module - slackget10-0.10

Hi all !


After doubt and interrogation, even after I though to dismiss the slack-et project it couldn't be helped... I enjoy developing this tool !
So be it. Here is the latest release of the slack-get Perl Module. Tons of thing are new since there was a not-released version...
This release main features are :
  • loads of bugfixes (starting with the test suite)
  • removed unused modules
  • removed deprecated modules
Well a lot of things !

I'm now working on the slack-get communication protocol. This protocol is full XML based and have to be well designed to support all situation of usage.
It also have to be bulletproof and highly error resistant.

By the way the slack-get devel mailing list have open, please find more information on this at Sourceforge , you can also find more informations about slack-get SVN on Sourceforge.

You can find all documentation and source of the new version of slackget10 on CPAN

That's all for the moment.

Good day

Arnaud Dupuis

Saturday 15 September 2007

Qt 4.3.1 second package

After the first package we released, here is the second version.


Changes are only in the configuration :
./configure -prefix /usr/lib/qt4 -glib -opengl -confirm-license

So now the base directory is /usr/lib/qt. There is no other changes in this package.
I'm looking forward for the next Qt 4 release !

Download link: qt-4.3.1-i386-2.tgz

Arnaud Dupuis

Saturday 8 September 2007

Qt 4.3.1 first package

Here is the first public release of the Qt4 package. This package is the last version of Qt4 (4.3.1).

I already use it successfully. The package was built from qt-x11-opensource-src-4.3.1 with the following configure : ./configure -prefix /usr -glib -opengl

If you don't want to replace your Qt 3 installation please use :

installpkg -root /usr/local/ qt-4.3.1-i386-1.tgz

Feel free to send me (or drop here) your comment or suggestion.

Enjoy !

download link: qt-4.3.1-i386-1.tgz

Arnaud Dupuis