Hello,
There is one thing I hate a lot : answering stupid questions. It makes me loose
my time and I certainly do not like that !
The problem is that slack-get is asking stupid questions ! Take the
dependencies tracking for example :
Even if it find a package with the exact name you requested it propose to you
all the matching results.
And one other thing I really don't like in slack-get (and maybe in other
package manager) is that if it find the same package on more than one media it
asks you to choose one.
I do not like that because it is typically something which can be decided by
software itself. If I talk about slack-get, there is a simple way to prefer one
media to another : you have to fill a <official-media>
tag in the configuration file ! I mean, it is an obvious way to prefer this
official media and not bother user asking him if he prefer to install amarok
from Slackware's official servers or from linuxpackages.
But since, yuo can actually prefer this I added a new feature to the media
system : a ranking system.
You can now add a <rank> tag in the medias.xml file
(inside a <media></media> group), with an integer
inside. Since it is a rank, the smaller the number is the highest priority the
media get.
In a near futur (this week at most), I will implements the following new
decision algorithm in the dependencies tracking and package
installation/upgrade systems :
- if there is more than one result for a package check :
- check if there is packages with their name
exactly equal to the request select them
- if their is more than one package like that
(name == request) :
- check if the medias
use ranks
- if yes, then select the package with the highest rank (the smaller number
inside <rank></rank>)
- if not, check if the official-media have the requested
package
- if yes, select the package
- if not, ask user to choose a package
- else if there is only one, select this
package
- else (there is no package where name ==
request), ask user to choose between the original search results.
- else (there is only one response) select the package.
I think this algorithm, will help to not stupidly bother users by asking
unnecessary questions. And since I am fully aware that some users will not like
this automated thing, I will also add a configuration key and a command line
option to allow them to enable/disable this system.
That's all for today !
See ya' for the slack-get development diary #8.
Arnaud Dupuis
Tag - slack-get
Tuesday 9 September 2008
Another new feature in slack-get media system
By Arnaud Dupuis on Tuesday 9 September 2008, 10:35 - slack-get
Sunday 7 September 2008
slack-get feature highlights #3 : add FTP credentials to your medias.xml configuration file.
By Arnaud Dupuis on Sunday 7 September 2008, 11:32 - slack-get feature highlight
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
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
Friday 5 September 2008
Another huge bug discovered and fixed in slack-get !!
By Arnaud Dupuis on Friday 5 September 2008, 19:06 - slack-get
Hi,
Today I was going to improve (let's say "finish") the dependency tracking system, which is not good enough yet, and I ran into something very very bad...
Before doing anything with the package system, I all the time modify my medias.xml and add a local repository wich contains only one package and it's dependency tree.
Doing this I found a pretty importantly bad bug. This one is described on the slack-get bugtracking system on Sourceforge.
In one word the Slackware::Slackget::Connection's drivers system was completly bugged and had a very important namespace corruption wich was leading to a massive code malfunction.
So far, I strongly recommend to update your local SVN copy.
Fortunatly I fixed this in the latest SVN revision (198).
I hope that I will not found any other surprises like this one !
Arnaud Dupuis
Today I was going to improve (let's say "finish") the dependency tracking system, which is not good enough yet, and I ran into something very very bad...
Before doing anything with the package system, I all the time modify my medias.xml and add a local repository wich contains only one package and it's dependency tree.
Doing this I found a pretty importantly bad bug. This one is described on the slack-get bugtracking system on Sourceforge.
In one word the Slackware::Slackget::Connection's drivers system was completly bugged and had a very important namespace corruption wich was leading to a massive code malfunction.
So far, I strongly recommend to update your local SVN copy.
Fortunatly I fixed this in the latest SVN revision (198).
I hope that I will not found any other surprises like this one !
Arnaud Dupuis
Thursday 4 September 2008
Sourceforge SVN downtime : no slack-get commits for the next 24 hours
By Arnaud Dupuis on Thursday 4 September 2008, 02:00 - General
Hi,
Sourceforce is migrating Subversion's data on to new storage hardware and conduct performance
testing today from 04:00 UTC and for approximatively 24hours.
As a consequence all write operations will fail, so there will not be any updates of the slack-get svn tree during this time.
Read operations are unaffected by this process.
Good day,
Arnaud Dupuis
Sourceforce is migrating Subversion's data on to new storage hardware and conduct performance
testing today from 04:00 UTC and for approximatively 24hours.
As a consequence all write operations will fail, so there will not be any updates of the slack-get svn tree during this time.
Read operations are unaffected by this process.
Good day,
Arnaud Dupuis
Wednesday 3 September 2008
slack-get development diary #7
By Arnaud Dupuis on Wednesday 3 September 2008, 20:00 - slack-get development diary
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
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
By Arnaud Dupuis on Tuesday 2 September 2008, 23:07 - slack-get feature highlight
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.
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.
Saturday 30 August 2008
slack-get user interface: step 1, how I see the futur
By Arnaud Dupuis on Saturday 30 August 2008, 00:43 - slack-get
Hi,
I starts coding a little widget (Slackget::QSimpleUpdate). This one looks like that :
I am interested in any opinion/advice/suggestion concerning this. The code of this proof-of-concept is available on the SVN (in trunk/src/QSimpleUpdate/). I made it themable thanks to Qt4 support of CSS.
So far, I think it is a quite fine dock application. I wanted it to be simple to get working, and I also wanted that this widget is able to display enough informations.
That's all for today
Arnaud Dupuis
as I already said I am currently developping the C++ API of slack-get. I also wrote that I am concentrating on usefull part of the API, skipping the generative parts that are not absolutly required at the moment. So in parallel to this development, I made some tests for the graphical user interface. I came up with the conclusion that there is 2 different way to use slack-get :
- Keep a Slackware box up-to-date by installing security fixes and Slackware patches
- Keep a box up-to-date, upgrade and install packages (but not patches)
I starts coding a little widget (Slackget::QSimpleUpdate). This one looks like that :
I am interested in any opinion/advice/suggestion concerning this. The code of this proof-of-concept is available on the SVN (in trunk/src/QSimpleUpdate/). I made it themable thanks to Qt4 support of CSS.
So far, I think it is a quite fine dock application. I wanted it to be simple to get working, and I also wanted that this widget is able to display enough informations.
That's all for today
Arnaud Dupuis
Wednesday 27 August 2008
First parts of the C++ API
By Arnaud Dupuis on Wednesday 27 August 2008, 00:29 - C++
Hi,
I uploaded on the SVN repository the first part of the slack-get C++ API.
I am coding this one to be as close as possible to the Perl one. So the first two classes uploaded are, of course, Slackget::Package and Slackget::PackageList. As you can see I am using the Slackget:: namespace in order to identify slack-get's classes.
As usual, the documentation and all doxygen needed files are already on the SVN too.
I am focusing on usability and stable features for this C++ API. This means that, in a first time, I will not translate all features. All classes that will fall in those exceptions will be adequatly documented.
My goal with this API is to start coding the graphical user interface as quickly as possible.
Arnaud Dupuis
Wednesday 13 August 2008
slack-get development diary #6
By Arnaud Dupuis on Wednesday 13 August 2008, 11:35 - slack-get development diary
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 :
So from now on, you can start a daemon and do a
That's a very important point but it's nothing worth talking about without the dependencies tracking system.
Talking about that...
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.
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.
The goal of this command is to provide more informations about a package. Here is an usage example :
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
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 !
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
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
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
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
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)
"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
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
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 20 March 2008
Hardware failure and slack-get delay
By Arnaud Dupuis on Thursday 20 March 2008, 13:21
Hi,
Like the title of this post can let you imagine, my main computer's hardware is all broken.
After a hard disk drive, replacement (87 EUR or 137 USD), a CPU replacement (190 EUR or 300 USD) I now need to replace my mainboard (225 EUR or 353 USD)...
All those thing leads to 2 things :
Why ? Just because there is an important pending SVN commit (waiting a data recovering) on one of my broken disk...
Sorry for the delay but hu...
By the way I strongly advice French preoples against the IT shops in Paris' "rue montgallet" unless they are willing to save 200 € on 1500 in order to cancel their hardware's garantuee.
Arnaud Dupuis
Like the title of this post can let you imagine, my main computer's hardware is all broken.
After a hard disk drive, replacement (87 EUR or 137 USD), a CPU replacement (190 EUR or 300 USD) I now need to replace my mainboard (225 EUR or 353 USD)...
All those thing leads to 2 things :
- I've no more money (so please enjoy a click on a google add )
- I spend a lot of time trying to go to the shop, and try to fix this damn computer.
Why ? Just because there is an important pending SVN commit (waiting a data recovering) on one of my broken disk...
Sorry for the delay but hu...
By the way I strongly advice French preoples against the IT shops in Paris' "rue montgallet" unless they are willing to save 200 € on 1500 in order to cancel their hardware's garantuee.
Arnaud Dupuis
Monday 4 February 2008
Websites and (bothering) stuffs like that (bis repetita)
By Arnaud Dupuis on Monday 4 February 2008, 14:17 - slack-get
Hi,
Err, I think it was quite a bad idea to automatically import all article from this blog to http://slackget.infinityperl.org... Since the massive amount of new articles may have made slackget.infinityperl looks like exactly the same than the blog... and Google do not like that at all...
I'm so bad with referencing and stuff like that
If someone have advice on this point, feel free to contact me at (suppress all underscores) a_[dot]_d_u_p_u_i_s_[at]_i_n_f_i_n_i_t_y_p_e_r_l_[dot]_o_r_g
Bye.
Arnaud Dupuis
Err, I think it was quite a bad idea to automatically import all article from this blog to http://slackget.infinityperl.org... Since the massive amount of new articles may have made slackget.infinityperl looks like exactly the same than the blog... and Google do not like that at all...
I'm so bad with referencing and stuff like that
If someone have advice on this point, feel free to contact me at (suppress all underscores) a_[dot]_d_u_p_u_i_s_[at]_i_n_f_i_n_i_t_y_p_e_r_l_[dot]_o_r_g
Bye.
Arnaud Dupuis
Sunday 3 February 2008
Websites and (bothering) stuffs like that
By Arnaud Dupuis on Sunday 3 February 2008, 17:14 - slack-get
Hi,
As you could have figured I'm not really fond of website designing and stuffs like that...
But, in order to have some visibility on the Internet, this is my needed curse.
I intended to send http://slackget.infinityperl.org to oblivion but I realized that it was not really a good idea regarding google's stats.
So to fool the <insert your favorite search engine here>bot, I wrote a script (which is now running with cron), to automatically import all the post I do on this blog, and to do a static export in html from the blog to slackget.infinityperl.org.
I just wanted to keep you aware that you could read two times the same post
Just a little reminder about slack-get project websites :
Official web site : this blog
Old website : http://slackget.infinityperl.org
Web SVN interface : http://slack-get-10.svn.sourceforge.net/viewvc/slack-get-10/
Sourceforge page : https://sourceforge.net/projects/slack-get-10/
Freshmeat page : http://freshmeat.net/projects/ipslackget/
Arnaud Dupuis
As you could have figured I'm not really fond of website designing and stuffs like that...
But, in order to have some visibility on the Internet, this is my needed curse.
I intended to send http://slackget.infinityperl.org to oblivion but I realized that it was not really a good idea regarding google's stats.
So to fool the <insert your favorite search engine here>bot, I wrote a script (which is now running with cron), to automatically import all the post I do on this blog, and to do a static export in html from the blog to slackget.infinityperl.org.
I just wanted to keep you aware that you could read two times the same post
Just a little reminder about slack-get project websites :
Official web site : this blog
Old website : http://slackget.infinityperl.org
Web SVN interface : http://slack-get-10.svn.sourceforge.net/viewvc/slack-get-10/
Sourceforge page : https://sourceforge.net/projects/slack-get-10/
Freshmeat page : http://freshmeat.net/projects/ipslackget/
Arnaud Dupuis
Saturday 2 February 2008
SGNCC - Slack-Get Naming Convention Compliant : the new slack-get's naming convention document
By Arnaud Dupuis on Saturday 2 February 2008, 17:35 - slack-get
Document purpose :
The purpose of this document is to "standardize" slack-get development by imposing a naming convention for both (but not only) : slack-get clients, sg_daemon, all Perl modules and the C++ library.This include of course, all plug-in which can be released in the futur.
Vocabulary :
In the future, we will refers to the slack-get naming convention as :SGNC: for Slack-Get Naming Convention.
Additionally, we will refers to SGNC compliant code as SGNCC (SGNC Compliant).
Scope of the SGNC :
All the code released under the "slack-get development team" label must be SGNC compliant (SGNCC).More generally, all code released and packaged with slack-get must be (and will be) SGNCC.
The SGNC apply to all API visible method names. Every methods in a class or bundle must be SGNCC. By extension to this principle all methods in the sg_daemon, slack-get and the upcoming slack-get GUI have to be SGNCC.
All script released and packaged with slack-get should be SGNCC too. But in order to not slow down some developments it is acceptable to keep not SGNCC code in the branch/ SVN tree. If released with slack-get, this code will be optional at building and installation time. It will also be released in a different package.
Rules of SGNC :
We refer to functions and methods as the same generic term of "method".The SGNC consist in the following 3 simple programing rules :
- a method name consist of lower case, English words where space are replaced with underscores ;
- if the method name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper case.
- if a conflict was solved according to rule 2), and if the name conflicts with only one of the supported languages (Perl and C++), add a wrapper method around the renamed one, in order to comply with the rule 1).
The slack-get development team
Wednesday 30 January 2008
slack-get API review
By Arnaud Dupuis on Wednesday 30 January 2008, 08:39 - slack-get
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 :
Arnaud Dupuis
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 :
- a method name consist of English words where space are replaced with underscores ;
- 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.
- 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).
Arnaud Dupuis
Thursday 10 January 2008
Little question from a slack-get user
By Arnaud Dupuis on Thursday 10 January 2008, 09:52 - slack-get
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
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
By Arnaud Dupuis on Tuesday 1 January 2008, 09:56 - slack-get development diary
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
Wednesday 19 December 2007
"slack-get update" command on the way !
By Arnaud Dupuis on Wednesday 19 December 2007, 07:26 - slack-get
Hi,
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :
That's all for today. See you later for the development diary.
Arnaud Dupuis.
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :
That's all for today. See you later for the development diary.
Arnaud Dupuis.
Monday 10 December 2007
slack-get development diary #4
By Arnaud Dupuis on Monday 10 December 2007, 22:00 - slack-get development diary
Hi,
There is a lot to say for this development diary #4 !
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 !
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 :
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.
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.
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
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.
Monday 3 December 2007
slack-get perl module change its name !
By Arnaud Dupuis on Monday 3 December 2007, 07:32 - Perl modules
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
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
Tuesday 27 November 2007
New Network backend mechanism
By Arnaud Dupuis on Tuesday 27 November 2007, 21:32 - slack-get
Today I implemented the new slackget10::Network mechanism I wanted to. What is
it you ask ?
Clearly something which will help everything to be super-easy to improve. As you may know (or not) the slackget10::Network Perl Module has been completely redesigned and will be largely recoded.
The changes are quite important and the API is completely new. It's now a front end module (like slackget10::Network::Connection is) and it aim at providing a unified interface for all kind of "protocol" implementation.
The idea is to answer the question : "what are you doing with an incoming network packet ?". The answer is simple : you decode it, you interpret it, you build the answer and you encode the answer before sending it.
Clearly something which will help everything to be super-easy to improve. As you may know (or not) the slackget10::Network Perl Module has been completely redesigned and will be largely recoded.
The changes are quite important and the API is completely new. It's now a front end module (like slackget10::Network::Connection is) and it aim at providing a unified interface for all kind of "protocol" implementation.
The idea is to answer the question : "what are you doing with an incoming network packet ?". The answer is simple : you decode it, you interpret it, you build the answer and you encode the answer before sending it.
« previous entries - page 1 of 2
