Hi all!

Yet more tasks:

1. At the moment, one of my scripts (which is somewhat for personal use) makes 
use of modified XML::RSS and XML::RSS::Aggregator Perl modules. There is a 
module on CPAN called http://search.cpan.org/dist/XML-Feed/, that can do 
everything this kludge-upon-a-kludge does and more. Problem is that it is not 
available in the Debian pool.

What can be done instead is use dh-perl-make to install it. It will be treated 
as an external distribution and won't be upgraded as part of the Debian 
upgrade.

It has quite a few dependencies:

<<<<<<<<<<
requires('Class::ErrorHandler');
requires('Feed::Find');
requires('URI::Fetch');
requires('XML::RSS' => 1.01);
requires('XML::Atom' => 0.08);
requires('LWP');
requires('HTML::Parser');
requires('URI');
requires('DateTime');
requires('DateTime::Format::Mail');
requires('DateTime::Format::W3CDTF');
requires('List::Util');
>>>>>>>>>>

Most of the serious ones are available in the Debian pool. (and the rest can 
be installed from dh-perl-make).

Can I do it?

2. Otherwise, it seems that the /root directory occupies 143 MB or so. The 
bulk of it is due to an apache 1.3.33 debian packages and a binary tree 
there. It's not mine, but maybe was used to test against the Apache resume of 
files > 2 GB problem. Can I delete these Apache files now?

Regards,

        Shlomi Fish


On Friday 05 August 2005 20:36, Shlomi Fish wrote:
> Hi!
>
> <<<
> First of all a note to Lior: are you subscribed to IGLU-Web? If not, please
> subscribe, because it's not a high volume list and we discuss everything
> related to eskimo there. Note that iglu-web blocks posts from
> non-subscribers, to prevent spam. (and because manual moderation proved to
> be too annoying a task, due to that).
>
>
> Here are the tasks that now have to be done:
>
> 1. Perl Modules
> ---------------
>
> Due to the fact the Perl modules in Woody were horribly out of date, I had
> to take the Perl .pm files out of their equivalent CPAN packages, and put
> them in "." with appropriate Perl directives to give precedence to modules
> found there.
>
> Now that we are using Sarge, then the CPAN modules found there, may already
> be adequate for our needs, and we wouldn't need the local ad-hoc
> installation from source. So I'm going to go over them and check that.
>
> 1.1 Investigate the Jobs Database RSS module.
>
> The Jobs data at the moment uses a Perl RSS-generation and parsing module
> (called XML::RSS, IIRC) to generate the RSS. The module that shipped with
> Woody was very old and did not support RSS 2.0 or possibly not even RSS
> 1.0. However, the instructions given to it were that for RSS 2.0. [1]
> (which worked fine on my local machine, which runs an up-to-date version of
> Mandriva).
>
> Some people reported problems with it with rss2email, in which it caused
> the HTML body of the item, to appear as quoted strings.
>
> Now Sarge should have a more up-to-date module from CPAN, which may work
> better. But we need to verify what happens there.
>
> 2. Including the URL of the job entry in the jobs list.
> -------------------------------------------------------
>
> Also regarding the jobs database: there should be a link from each entry to
> its /show-record URL (which displays only it and which can be used to
> quickly identify it or linke to it). It should not be too hard to program
> it in.
>
> 3. Moving the jobs/consultants database to BerliOS or OpenSVN.
> --------------------------------------------------------------
>
> At the moment, the code for the jobs list back-end is version controlled in
> my personal repository on stalker. (a Co-Op server where Nadav Har'El gave
> me an account). It's not bad being there, but it still occupies more and
> more space (as version control repositories go) and I have a limited quota
> there. I'd like to move it to BerliOS or to OpenSVN.
>
> BerliOS is supposed to be a hub for open-source development. At the moment,
> the jobs list is technically open-source, (MIT X11 license) but was not yet
> packaged into a CPAN module, documentation is scarce, and there may be
> other issues that may still label it as "software for internal use". I can
> put it in my web-cpan.berlios.de repositories without too many problems,
> but I may be slightly violating their social contract.
>
> OpenSVN.csie.org as far as I know doesn't care if what you put there is
> open-source or not, but connectivity to it is somewhat slower than BerliOS.
> I also set up a repository for Linux Israeli activities (linuxisrael) and
> we can put the code somewhere there.
>
> At the moment I'm leaning towards BerliOS.
>
> 4. Organizing /iglu
> -------------------
>
> Once upon a time, we had the /iglu volume for all the web-hosted files and
> everyone were happy. Then, came several virtual hosts which were directed
> to eskimo: Hackers-IL, Python-IL, Welcome-to-Linux, wiki.perl.org.il. I
> placed the first three straight under /iglu as /iglu/Hackers-IL/ etc.
>
> Then I decided putting them there together with the rest of the /iglu
> sub-directories was not such a good idea, and created a
> sub-directory /iglu/Hosts for them. However, only wiki.perl.org.il can be
> found there at the moment.
>
> I'd like to invest some spare cycles into moving the rest of the virtual
> hosts into the /Hosts. It shouldn't be too hard - just re-configuring
> apache, doing the move, and reloading apache.
>
> 5. Managing the MediaWikis with ease:
> --------------------------------------
>
> At the moment Eskimo hosts 3 MediaWikis: Python-IL's, Hackers-IL's and
> Perl-IL's. They all contain the entire unpacked distribution where it was
> unpacked, and all require separate upgrades or patch applications when
> these things are needed.
>
> I'd like to ask for any ideas from people here, regarding how one can
> easily centrally manage three such MediaWikis. Is there a script or
> somethings.
>
> At times like this I really hate the fact that PHP does not have modules.
> ;-)
>
> Let me know what you think of all of the above.
>
> Regards,
>
>       Shlomi Fish
>
> [1] - The XML::RSS abstraction of the various RSS versions is very
> minimalistic, if not non-existent.
>
>
> ---------------------------------------------------------------------
> Shlomi Fish      [EMAIL PROTECTED]
> Homepage:        http://www.shlomifish.org/
>
> Tcl is LISP on drugs. Using strings instead of S-expressions for closures
> is Evil with one of those gigantic E's you can find at the beginning of
> paragraphs.

-- 

---------------------------------------------------------------------
Shlomi Fish      [EMAIL PROTECTED]
Homepage:        http://www.shlomifish.org/

Tcl is LISP on drugs. Using strings instead of S-expressions for closures
is Evil with one of those gigantic E's you can find at the beginning of 
paragraphs.

Reply via email to