Association Subscribers Manager and Open source stuffs

To content | To menu | To search

Tag - Slackware::Slackget

Entries feed - Comments feed

Sunday 7 September 2008

slack-get feature highlights #3 : add FTP credentials to your medias.xml configuration file.

Hi,
Today, I will highlights a brand new mechanism in slack-get : how to add your FTP credentials to the medias.xml confniguration file.
First let's remind how was the ftp authentification mechanism before.
In the old ages, you had to fill a section in the config.xml file. The section look like that :
<network-parameters>
     <ftp>
          <login><![CDATA[anonymous]]></login>
          <password><![CDATA[slack-get@infinityperl.org]]></password>
     </ftp>
</network-parameters>

This section (in the <common> configuration bloc) is (still) used by the sg_daemon to authenticate himself on FTP server (this is the global credentials).
But you may have to provide particular credentials for one ftp server, so I added the possibility to use the standard URL syntax in the medias.xml file.
So starting from the svn revision 198, you can use the ftp://<login>:<password>@<some ftp server> syntax in your medias.xml file.
The specific credentials, of course, prevails on the globals ones.

On a developper side now, this trick is done by the Slackware::Slackget::Network::Connection->parse_url() method. This is a specific case of the ftp so far but I can easily make it available for any protocols if there is a need to do so.
I plan on testing, in this parse_url() method, the availability of a __parse_url() method drivers' specific. This could help to develop specific drivers with specific url format.
I will think about that.

That's all for today ! Enjoy the end of the week end !

Arnaud Dupuis

Saturday 6 September 2008

slack-get Perl api available (again)

Hi,
The Slackware::Slackget api is available on CPAN, but the latest documenation is now available in the SVN tree (viewable on Sourceforge's viewsvn service) and on my own server.
The two last ones will be more up-to-date than the CPAN one.

I hope that it will helps contributors !

Arnaud Dupuis.

Wednesday 3 September 2008

slack-get development diary #7

Hi,
Here is the 7th opus of the slack-get development diary. There is a lot to say because I made lots of changes since the last diary.

1) The C++ API's first parts :
Since the last post where I was talking about this I added to the existing Slackget::Package and Slackget::PackageList 3 new classes : Slackget::Config, Slackget::Utils and Slackget::QSimpleUpdate.
Slackget::Config is used to represent slack-get's XML configuration file and Slackget::Utils contains some static utilitary methods.
Slackget::QSimpleUpdate is a Qt 4 widget. Its goal is to present a list of packages to users in the most simple way. It behave very simply by showing a list of items wich contains an image, a package name and its version. More informations about a package are available via the Qt's traditionnal tooltip system.

I plan in renaming Slackget::Utils to simply Slackget but I am not yet sure. I am not sure because I want to re-organize the C++ api's tree.
There is currently a trunk/src/ directory which contains QSimpleUpdate sources, and a trunk/lib/Cpp/ which contains the other classes.
More specifically, it contains the SlackgetCore module. I plan on modify this tree the following way :
trunk/lib/Cpp/SlackgetCore/src/ -> contains all source files for the SlackgetCore modules (currently : Slackget::Package, Slackget::PackageList, Slackget::Config and Slackget::Utils)
trunk/lib/Cpp/SlackgetCore/include/ -> contains all headers file for the SlackgetCore modules
trunk/lib/Cpp/SlackgetGui/src/ -> contains all source files for the SlackgetGui modules (currently : Slackget::QSimpleUpdate)... This module actually do not exists at the time I am writting this article :)
trunk/lib/Cpp/SlackgetGui/include/ -> contains all headers file for the SlackgetCore modules
And of course I want to delete the trunk/src/ directory.
I am indeed a big fan of the Qt 4 modular architecture. Talking about Qt 4, all parts of the slack-get C++ api links against Qt 4. SlackgetCore links against QtCore (for all the super handy data types) and, of course, SlackgetGui will links against QtGui.

2) The Perl API and sg_daemon :
Well... It changed a lot so I made a new release of Slackware::Slackget on CPAN ... And again it changed so much since then that I could make another release !
The medias variables system is one of the good examples. But the huge bugs in sg_daemon which was not managing media's host efficiently is the main cause of changes in the Perl API.
This bug (or bugs) was preventing the sg_daemon to switch from a media's host to the next one. I corrected this issue and it is now working as it should do.
The main changes in the Slackware::Slackget Perl module are :
  * I changed Slackware::Slackget::Network::Connection behavior by replacing the host's constructor parameter by a media one (see modules documentation). I also added a next_host() method to this module. The goal is to take care of operations needed by the Connection.pm module (like parsing the URL and loading drivers).
  * I fixed a little bug in Slackware::Slackget::Network::Connection::HTTP.pm (the file was moved to its final destination before all tests).
  * I fixed a bug in Slackware::Slackget::Base and Slackware::Slackget::MediaList. The bug was very simple : I forgot to tell XML::Simple's parser to force array on all <li> elements. This result in a bug when there was only one element in a list.
  * I also spent some time cleanning lots of code (removed unneccessary comments, comments unnecessary code, etc.).
  * All this things result in a massive documentation's update.
  * I finally made all needed changes in the sg_daemon (which is not part of the Perl API...) which is now handling well dead hosts and host changing.

The next focus points in the development are :
     1 - Improve the C++ api (and particularly develop all classes needed to connect to a sg_daemon)
     2 - Port the plugin system to the new daemon.
     3 - Develop a real working GUI.
     4 - Start coding the multi-daemon cooperative work.

Still a lot to do !

Enjoy !

Arnaud Dupuis

Tuesday 2 September 2008

New feature: slack-get medias' options

Hi,
I just added a new feature to the slack-get media system. It is something I wanted to add for a long time now but I never had the time.
But since I am still stuck at home because of this stupid pneumonia, I now have the time...
What I wanted is a variables system in the medias.xml syntax. The direct benefit is that it is much more easier to modify the medias file after an upgrade of your Slackware box.
Indeed, if it is nice to be able to maintain multiple sources of packages, it is sometime a pain in the ass to update this file after an upgrade... When all URL of mirrors must be changed...
The Slackware version number is, indeed, the first "official" variable.
This system is very easy to use : you just have to declare an attribute in the <medialist> tag and it will be automatically converted to a variable by the Slackware::Slackget::MediaList and Slackware::Slackget::Media classes. You can use the variable in any tag content by using the special syntax ${<variable name>}.
Here is a simple example :

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<medialist slackware-version="12.1">
<media id="slackware-official">
<files>
<filelist>FILELIST.TXT</filelist>
<checksums>CHECKSUMS.md5</checksums>
<packages>PACKAGES.TXT</packages>
</files>
<download-signature>1</download-signature>
<update-repository>
<faster>http://ftp.lip6.fr/pub/linux/distributions/slackware/slackware-${slackware-version}/</faster>
<fast>
<li>http://ftp.bit.nl/mirror/slackware/slackware-${slackware-version}/</li>
<li>http://ftp.belnet.be/packages/slackware/slackware-${slackware-version}/</li>
</fast>
</update-repository>
<description>The official Slackware web site</description>
<web-link>http://www.slackware.com/</web-link>
</media>
</medialist>

As you can see it is both convinient and easy to implement. I am quite sure it will be very usefull when we will upgrade from Slackware 12.1 to 13.0 ;-)

Arnaud Dupuis.

Friday 29 August 2008

Release: Slackware::Slackget v0.17

Hi,

A new version of the Slackware::Slackget module was released on CPAN.
This release features the followings changes :
 - lots of fix in order to make all classes of the module SGNC Compliant
 - Slackware::Slackget::GPG have had many methods implemented
 - change the to_string() behavior of the Slackware::Slackget::PackageList, Slackware::Slackget::Package and Slackware::Slackget::List to make them able to generate a Slackware's PACKAGES.TXT (supporting, of course, the slapt-get/swaret format for dependencies).

This module was in a need of a new release since the documentation have been updated a lot (and I personally use CPAN as my API doc reference ^^).

Arnaud Dupuis

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


Friday 7 March 2008

Release: Slackware::Slackget - Main Perl library for the slack-get package manager - v0.16

Hi,
The new version of the Slackware::Slackget Perl module have just been released on CPAN.
This 0.16 version add more unit tests to the test suite, should fix the incompatibility problems on Solaris, and fix some bugs in the API.
Particularly, in the Slackware::Slackget::File and in Slackware::Slackget::List classes.

Next changes in the API will be to add Java like iterators to the Slackware::Slackget::List class.

You can download this module on CPAN.


Arnaud Dupuis

Friday 15 February 2008

compatibility of the Slackware::Slackget Perl module version 0.15_99

Hi,
It looks like that the latest released version of the Slackware::Slackget Perl module is quite incompatible with the Solaris operating system.
I was expecting this kind of problem with this release because I added more tests to the test suite. And Slackware::Slackget, as its name said, is designed to run on Slackware GNU/Linux based distributions.
So before the 0.15 final release, in order to provide a very usefull test suite, I will add some more tests.
And unfortunately, I expect more issues... The more the test suite is accurate, the more it will point the problem with Slackware incompatible systems.

The problem with the Solaris systems is that the `file` command do not support the -b switch. I use the file command instead of a CPAN module to reduce the amount of dependencies of Slackware::Slackget but I will look at this and try to make the Slackware::Slackget::File class use a CPAN module if installed (like File::Type).

Arnaud Dupuis

Saturday 2 February 2008

Release: Slackware::Slackget v0.15_99 and SGNC documentation

Hi,

A new version of the Slackware::Slackget module was released few hours ago on CPAN.
This release features the followings changes :
    - modify Slackware::Slackget::File->filename() behavior to allow it to set the filename
    - fix is_heavy_word() method in Slackware::Slackget::Package, wich now return the correct result
    - update Slackware::Slackget::Date to make it fill the month-name from the month-number
    - update Slackware::Slackget::Date by overloading '<=>' and 'cmp'
    - changed all classes of the Slackware::Slackget module to be compliant with the slack-get naming convention (SGNCC : Slack-Get Naming Convention Compliant) (http://www.infinityperl.org/post/2008/01/30/slack-get-API-review)
    - add more tests to the test suite for the followings classes :
        * Slackware::Slackget::File (SGNCC & backward compatible)
        * Slackware::Slackget::Media (SGNCC & backward compatible)
        * Slackware::Slackget::Date (SGNCC& backward compatible)
        * Slackware::Slackget::Package (SGNCC & backward compatible)

It is tagged as a developers' release for the moment since all the test for all modified (SGNCC) modules, the documentation is not yet up-to-date considering all the changes made, and I still need some time to test if their is absolutely no side effects due to the changes I made in the API.

Arnaud Dupuis


Wednesday 30 January 2008

slack-get API review

Hi,

Back from holidays, I started to work again on slack-get by a huge code review and documentation updates of the API.
My current contract had an impact on this process since it consists in extending the NMIS tool. This tool is really great and useful like no other ones when it comes to network monitoring tasks.
But this tool also have an important flaw : its API is a real mess. It consist of a main script of 7000 code lines and few modules (around 10) totally undocumented !
My job is currently to run into this code, understand it (hopefully it's not too hard to guess) and find a way to add something like a plug-in system to it. Unfortunately, all NMIS modules exports all their functions in the calling script's namespace...
So I choose to have a different naming convention than the one in NMIS for plug-in's methods name... And their is no naming convention in NMIS...

And I sadly saw that it was exactly the same  with slack-get Perl API... So starting today I will change that and tag along with the following naming convention :
  1. a method name consist of English words where space are replaced with underscores ;
  2. if the name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper  case.
  3. if a conflict was solved according to rule 2), and if the name do not conflict with the other language, add a wrapper method around the renamed one, in order to comply with the rule 1).
Boring work but I deserve to do it...

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 ;-)

Monday 10 December 2007

slack-get development diary #4

Hi,
There is a lot to say for this development diary #4 !

Perl module: Slackware::Slackget vs slackget10 :

First of all, the Perl part of the project (currently the biggest part). As you may all know now : the slack-get Perl module is now listed in the official Perl Module list on CPAN in the Operating System Interface category. And for this big promotion the module changed its name from slackget10 to Slackware::Slackget.
If some of you still wondered : slackget10 is officially abandoned, and today, completely outdated.
I added a lot of features to this module like the stackable backends. I also released on CPAN a debug module which add the support for a debug:// network protocol. This is a totally fake protocol which help development by outputing loads of informations on the standard output. The module name is Slackware::Slackget::Network::Connection::DEBUG. It's not a part of the Slackware::Slackget distribution, it's even not in the SVN trunk but in branch/perl-modules.
One of the big improvement of the Slackware::Slackget module is its test suite : the latest release on CPAN (0.14) haven't encounter even 1 fail !
I also tried a lot to make the module platform independent, and more generic. I have rewrite lots of code in order to take all the interdependent code out of the modules. It's now partially done and the next module which will feel my scalpel is Slackware::Slackget::PkgTools... I saw some horrible things inside of this one !

The slack-get suite programs : sg_daemon and slack-get :

Everything have changed ! Beginning with slack-get : this program wasn't available 2 weeks ago. It's a command line client for the sg_daemon it allow you to query the daemon. At the moment I write this development diary (svn revision 110) you can perform the following actions with slack-get : search a package (based on it's name, or anything in the description of this package), ask the daemon to rebuild the installed packages cache, ask the daemon to reload it's media list, ask the daemon to rebuild the update list. Well... now it only lack the possibility to install, upgrade and remove packages to be released... I'm already on the remove part (the easiest ^^).
Let's show you some search request performed on a cache which contains the official Slackware current repository, Linuxpackages repository and my own perl-modules repository (totally outdated) :

This is a big improvement since it actually do something... You may wonder how it is possible for me to implements 3 or 4 possible actions (features) for slack-get and have wait for so long before doing it. In fact it's now very easy and quick to add features to sg_daemon and slack-get because the base architecture is done coding (and well designed :D).
From now on, the remaining features I will include before releasing a first version (without any GUI but with the CLI client) are :
  • install package
  • upgrade package
  • remove package
  • run background for the daemon
Once it'll be done I will bundle it and release the 1.0.0-alpha2 version. Obviously, it will be a testing version.
In the real coding side, the last SVN revision of sg_daemon include tons of improvements like : automatic message formating, a first version of the backend stack negotiation system (between the daemon and the client), a real and simple network protocol, a powerfull and working base architecture and a bullet proof internal communication ! (with that if I don't attract some geek devs I don't know how to do it ;-) ).
The next big part of the work will be the implementation of collaborative part. But fortunately, a huge amount of this code was already wrote in slack-get-1.0.0-alpha1. To give you an example, all the code related to the master/slave mechanism is already written and slack-getd is able to work with many other daemons withtout to much pain in the configuration side (assuming you talk XML...).
But in addition to the existing code (that I will still need to port to the new event-based architecture), I want to add an "auto discover" feature to allow many sg_daemon(s) to work together without any configuration or human supervision. I want the daemons able to  elect a master, change their mode between master and slave, and many other distributed stuffs like that, based on some simple rules (what's the sysload, the average sysload, etc.) in total autonomy (if the sysadmin allow it !).
In addition to all of this development, I will publish a debug backend for Slackware::Slackget::Network to allow developers to track the state of a network message during the encoding and decoding process.

Some news from the GUI point :

I made a graphical interface to get the list of official Slackware mirrors (from the "Get Slack" page of the official website). It's still not finished (it cannot update the medias.xml file yet), but it's already working to get the list and writting it down to the hard disk. I think this dialog will be part of the final slack-get GUI.
And since it's the first screenshot I can show, here it is :

Well... nothing to climb to the roof but it's a beginning :)
All the testing GUI are available from the SVN branch : branch/gui_test.
The GUI is the next main development priority after getting the daemon working.

I think I'm done with this week (and a half...) diary, I'll keep you informed !

Cya

Arnaud Dupuis.

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

Monday 3 December 2007

slack-get perl module change its name !

Hi,
Like I announced on the developers' mailing list, the slackget10 was about to die. It's now done. The PAUSE (Perl Authors Upload SErver) admins sent me an email confirming the creation of the Slackware::Slackget registered namespace on PAUSE/CPAN.
I will modify all the library to fit the new namespace and release the changes as soon as possible.
One more thing : I created a new branch on the SVN for the GUI tests ;-)

Cya,

Arnaud Dupuis