2007-04-07  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Nice to have: an overview over the neuralgic patches up to 5.10 that
	broke XS modules with both links to patches, versions of the modules
	before and after the fix, error messages, etc. This would help people
	who have a broken XS module to find the quickest fix.

	* Bug: we scan the cache for sizes, then sort by date, then delete. We
	should first sort by date, then scan for sizes, then start to remove
	without scanning as soon as we know we are above the limit.

	* Maybe add a depends keyword to distroprefs because the number of
	missing dependency declarations in modules does not decrease despite all
	the bug reports we have sent out.

	* As soon as we support bz2 we must have an implicit dependency on
	packages Compress::Bzip2 whenever we want to untar such a thing.

	* For the Todo from David Golden: On installation of a distribution,
	check %INC for modules in that distribution. If found, warn the user and
	suggest that they call "reload cpan" at the prompt.

	Very good idea.

	* HTML::CalendarMonth is failing but the error output is really large. I
	just tried to report() it and must check later if the mail actually
	arrived. --- It seems this report never arrives.

	* Todo(???): introduce --notest and --force, etc. I'm not fond of it but
	Slaven has observed that two users expected it would work that way.

	* off topic: replace "falling" with "decreasing" where appropriate

	* off topic: Richard's talk about debugger brings me the idea to patch
	it to support saving of terminal history. I started implementing it and
	then lost track of my changes. Now in k75:/home/src/perl/perl5db/

	Patch sent in but Richard would like to get the default behaviour being
	to write the histfile.

	* bring the FirstTime dialogs into POD and back

	* somebody reports that RT does recursion. But what is the driving
	module for RT? RSPIER/Bundle-RT-0.030601.tar.gz ? No, this will only
	tell CPAN to install "most of RT's dependent modules". Not RT itself.
	--> this needs a bugreport.

	* wishlist Mark Overmeer: less output

	* http://www.youtube.com/watch?v=daJ1Hs_y738 screencast hint from
	Juergen Christoffel

	* http://rt.cpan.org//Ticket/Display.html?id=25223

	contact brian

	* offtopic: Perl::Repository::APC needs a doc patch that it doesn't work
	on case insensitive file systems.

	* Todo: write one of the CircDepe distros new to include version
	number(s) in prerequisites, especially undef.

	* Bug report/feature request from David Cantrell via David Golden:
	report shall only report on what-I-say, but not on the prerequisites.

	I have answered and I am not yet sure I want to go down that route.

	This muddies the waters. If we only report on things on the commandline,
	we can probably not get 'report Bundle::Spd' or 'Bundle::CPANxxl' to
	work properly? Well, maybe we can. We just have to try. And when? Before
	the release?

	I'd also need input from David because I could easily break his
	intentions.

	* Musing: when we some day optimize for the best CPAN mirror we shall
	learn from bittorrent and consider that the index file problem is
	separated from the rest of CPAN. And that we can fetch older files from
	everywhere but younger files only from hosts being fresh enough.

	* Next biggies: mod_perl, Subversion

	* Feature request by self: The bad performance of YAML.pm seems to be a
	showstopper. YAML.pm needs to be banned or disabling of YAML operations
	should be possible, don't know exactly how.

	* IAMCAL/XML-Parser-Lite-Tree-0.03.tar.gz fails when called early,
	succeeds when called late?

	Yes, this is the case. Because X:P:L:T depend on XML::Parser::Lite.
	PAUSE has indexed BYRNE/SOAP/SOAP-Lite-0.60a.tar.gz for that, but I have
	disabled the installation of this distro, so we fail quickly with a
	missing dependency.

	But during megainstall somebody installs X:P:L 0.65_3 and solves the
	problem for X:P:L:T. So who is it? With locate I find this:

	% ls -l /home/ftp/pub/PAUSE/authors/id/H/HE/HEX/XML-Parser-Lite-0.66.tar.gz
-rw-rw-r-- 1 root root 4388 Jan 31 13:53 /home/ftp/pub/PAUSE/authors/id/H/HE/HEX/XML-Parser-Lite-0.66.tar.gz

	But when going through the logfile, I find that SOAP-Lite-0.69 has
	installed it. Is my logfile the only one who knows who installed what?
	What a sad story. It's getting even worse when we realize that nobody
	discovers who overwrote which previous version!
	
	I must ask HEX if this is all as intended. DONE.

	We should also institutionalize a place where FAILED reports of the
	PAUSE indexer are directed to. We receive 3 every day and nobody cares
	about them, not even the authors.

	I also need to understand how I can speed up Gnus on large, rarely
	visited mailboxes. It is extremely slow on my pause mailbox and I cannot
	simply catchup on that as I do with the lookslikespam mailbox.

	And how do I deal with the X:P:L:T dependency in exactly this situation?
	It's not a goto. We need to patch up the dependency: instead of X:P:L it
	would have to be BYRNE/SOAP-Lite-0.69.tar.gz for now. But this would
	have to be removed as soon as HEX gets the index entry. Well, I think we
	have to pass on this one. Pity.

	And we have a similar issue with Flickr::API which also depends on
	XML::Parser::Lite (but which still fails tests, even if we resolve the
	X:P:L dependency).

	I think it's best described as a pseudo dependency. It depends on a
	thing that is contained in another but this other thing hides this (with
	the underscore in the version number).

	As was the case before we had distroprefs, externally known dependencies
	are best handled by bundle files. My "bundle file" here is the
	MEGA_INSTALL macro in my Makefile.PL. I simply add SOAP::Lite _before_
	Plagger.

	* Feature request by self: "o conf init ~"

	Should only try to talk about uninitialized or undefined config
	variables. (?)

	Tried it and it was much more work than expected, giving up. For a
	future reference, see the lines around C< $matcher eq "~" > in
	FirstTime.pm

	* TTL stuff

	* retry to run under Devel::Cover and actually read the results.

	* Feature: make the FTPstats max counter settable.

	* make _get_urllist a public method for Randy.

	* Write manpage for CPAN::HandleConfig, esp load().

	* I realize that CPAN::FTP::localize is undocumented and is what Randy
	wants.

	* Integrate hosts into $META like authors, distributions, and modules?
	If we're cautious, this might turn into an automatic optimization.

	If Coro does index downloads for us, we do not have to fear slow
	connections and can gather better data.

	* Guessing of -p0/-p1 for patch maybe wrong if the patch tries to create
	a new file against, say, /dev/null.

	* Would be nice: integrate the config variable name into the init
	dialogs such that one has a chance to learn their names over time.

	* Would be nice: 'o conf /check/' to list all variables matching a regex.

	* Todo: offer the choice between (readline) Gnu and Perl and Coro. See
	my trials in the bin/ directory (SVN only). Possibly this is done via
	envariables? Then we only should document it.

	* Mail::Send problem persists that Test::Reporter's mails do not arrive
	when sent with Mail::Send but do when sent with Net::SMTP (IIRC). In any
	case I must disable installation of Mail::Send somehow or debug.
	Test::Reporter has got a wish item via RT already some weeks ago.

	http://rt.cpan.org/Ticket/Display.html?id=13836

	http://code.google.com/p/test-reporter/

	* if we make the TTLs setable, maybe we should make the TTL for
	CHECKSUMS file too. In any case we have the problem of imacat also when
	the TTL of the local copy of the CHECKSUMS file has not yet been
	reached!

	* Coro. See also notes below, search for anyevent	

	* The first thing that I encounter when I start testing instead of
	installing things is that test doesn't stop when the installed version
	is higher than or equal to the CPAN version. Ilya invented for that
	test_uptodate??

	* replace 03 index file with YAML.

	* Looks like a bug to me what I find in Bundle-SZABGAB-0.01.yml:
	CONTAINSMODS is empty because Gabor has a distro in the bundle.

	* Todo: clean up "XXX" in the code

	* M2 (Wishlist) separate the TTLs for 01,02,03. If somebody asks 'a
	FOO', we should only check for the authors database, etc.

	* E1 Todo: use 00whois.xml instead of mailrc, and follow the UTF-8 HOWTO to
	get rid of the term_is_latin variable. Test output with locales.

	* H4 branch 1.87-dbmdeep-hackery revive? It was very broken but I do not
	remember details. Hint: DBM::Deep promises significant memory savings
	and in that branch we tried to see how it can be made to work for us.

	* M3 RT 17353: Flag outdated CPAN sites and move them to the end of the
	list when they have reached 291 hours. (Note: $CPAN/authors/02STAMP)

	* E1: revisit rev 158:159, the introduction of "recent" and "perldoc".
	#21791 has its bugreport. I don't like that most of the subroutines are
	thrown into CPAN::Distribution either. OTOH, we have commands that have
	no central role within CPAN. One can always refuse to use them. Hrm.
	HTML::Display!

	* E5: (again and again) verify that the CPAN.pm-using modules continue
	to work:

	DMUEY/AltaVista-BabelFish
	MSCHILLI/CPAN-Unwind
	ULPFR/CPAN-WAIT
	RJRAY/Devel-Modlist
	SMUELLER/PAR-Dist-FromCPAN
	DAGOLDEN/Perl-Dist
	CRAKRJACK/Test-CPANpm

	DONE (added most of them to MEGA_INSTALL)

	* E5 watch RT for open tickets. This todo can never be closed.

	* E1 Todo: continue to close the Pod::Coverage gap. Currently only
	CPAN.pm is covered

	* E3 Todo: write a test for dot-cpan/Metadata usage. Hmmm. Important for
	the future of locking, the future of DBM::Deep, protocol changes. Not
	sure what to test.

	* M3 Todo: investigate what BUGHUNTING in Tarzip means "today": it's
	about a very old bug in Archive::Tar that is most probably fixed. Turn
	bughunting on with the command C< !print$CPAN::Tarzip::BUGHUNTING=1 >.
	It is slow but everything should just plain work. When we're confident
	that everything works, we could offer a tar_policy option that has
	options "ext" and "mod", for external programs vs. modules, default to
	"ext"?

	* M3 Reopened Bug: it seems that a user who is in /bin and has "." in
	the beginning of the path gets ./sh as his shell from FirstTime. If we
	encounter . in the path we should rather ignore it. But first we must
	verify the behaviour. Reported by Slaven Rezic on behalf of Tino
	Schulze. This has nothing to do with -I. but only with the shell and
	$ENV{PATH} and as we do not know which shell it was it seems we cannot
	test for the problem.

	* H1 These days developer TELS posted to perl5-porters that his newest
	release is available at

	    http://bloodgate.com/perl/packages/devel/Math-BigInt-1.78.tar.gz

	Suddenly it dawned on me that I want to support

	    install http://bloodgate.com/perl/packages/devel/Math-BigInt-1.78.tar.gz

	What am I missing?

	The other commands dealing with files would have to learn a bit.

	d http://      # fails as before with "No objects of...."

	               # alt: does a HEAD and tells user that the URL can e reached

	ls http://     # lists nothing

	               # alt: says that ls doesn't support URLs

	get http://    # this is probably all we need to implement. Maybe a new
	               # class needed that does as_string and as_glimpse as well?

	And maybe a pragma that turns this feature on? So that 'get http://...'
	never works but 'force get http://...' does? Alt: config variable to
	turn feature on, then a separate module that implements it.

	Brian likes the idea

From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: Welcome new user LOCAL
To: modules@perl.org
Date: Mon, 18 Sep 2006 14:52:48 -0500
Organization: Perl Authors Upload Server
Reply-To: modules@perl.org

In article <877j0361hl.fsf@k75.linux.bogus>, (Andreas J. Koenig)
<andreas.koenig.gmwojprw@franz.ak.mind.de> wrote:

> My spontaneous idea was to support the command
> 
>     cpan> get http://bloodgate.com/perl/packages/devel/Math-BigInt-1.78.tar.gz

oh, very interesting, especially if I already have the file:

   cpan> get file:///....

This makes CPAN::Mini::Inject a bit less useful because I no longer
need the middle man.

	* Make the "new -> ." symlink in scripts/ as outlined in a mail to kurt
	and jarkko

	* M2 feature request by Juergen Christoffel: have time stamps on the
	history and a history command to see them

	* hr ================ no todos below this line ================ /hr

	* hr ================ no todos below this line ================ /hr

	* hr ================ no todos below this line ================ /hr

2007-04-06  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* looping in installation: Dist-DCC
	(DMAKI/DateTime-Calendar-Chinese-0.05.tar.gz) install() calls test which
	calls make. This encounters 4 prereq (DES, DEC, DUAM, DUAC). The first
	two of those have already failed tests but we continue anyway. The other
	two are re-queued, the "later" flag on D is set. So we leave
	make/test/install early due to the later flag. As soon as we hav left
	the first position of the queue, the later flag is cleared. DUAM quickly
	decides that it is already installed. DUAC ditto. Dist-DCC is now again
	the first on the queue. It calls install/test/make again. Look, the
	later flag is cleared already, so nothing prevents us from looping
	through.

	So the bug seems to be that we rely on the module installation of DUAM
	and DUAC to recognisably either fail or succeed. But DUAM and DUAC seem
	to be not installed and installed at the same time. The Moon.pm and
	Common.pm files are found, their versions are considered "undef". But
	the distro they are in, Dist-DUA-0.08 considers itself already
	installed. What has happened to it? Indeed I can see that Dist-DUA-0.08
	has been installed. Why do we not recognize their installed version?

    $VERSION = $DateTime::Util::Astro::VERSION;

	So this is the root cause. The PAUSE indexer somehow determined 0.04
	being the version. One bug must have happened over there. But we should
	not run into a loop just because of this.

	Until recently we broke out of this loop because we set and consulted
	is_tested. But this left us in the is_tested state leading to the
	"Prepending" bug.

	As we now (correctly) reserved the is_tested/is_installed stuff
	exclusively for the task of prepending to PERL5LIB, we now need
	something similar for finer control over prereq menagement than "later"
	and undelay provide.

	I do not want to use "later" for this because it already does something
	OK and needs a short lifespan. (For the record: leave test and install
	early when we discover that we have to deal with prereqs first).

	But now the first thing I need is a recipe how to reproduce the loop
	bug: new bleadperl + Bundle::CPANxxl. install
	DMAKI/DateTime-Calendar-Chinese-0.05.tar.gz triggers many installs and
	soon fails nicely with

  DMAKI/DateTime-Calendar-Chinese-0.05.tar.gz
  ./Build test -- NOT OK
Running Build install
  make test had returned bad status, won't install without force
Failed during this command:
 DMAKI/DateTime-Util-Astro-0.08.tar.gz        : make_test NO
 DMAKI/DateTime-Util-Astro-0.09.tar.gz        : make_test NO
 DMAKI/DateTime-Event-Lunar-0.05.tar.gz       : make_test NO
 DMAKI/DateTime-Event-SolarTerm-0.04.tar.gz   : make_test NO
 DMAKI/DateTime-Event-Chinese-0.04.tar.gz     : make_test NO
 DMAKI/DateTime-Calendar-Chinese-0.05.tar.gz  : make_test NO

	So mayby with the advent of DMAKI/DateTime-Util-Astro-0.09.tar.gz the
	loop is gone? Looking into the distro I find the 

	$VERSION = $DateTime::Util::Astro::VERSION;

	dictum in all files, so the saga continues. Maybe I can reproduce the
	bug if I disable 0.09? No. If instead I "goto(0.08)" and turn
	build_dir_reuse off? No. If I manually set the $VERSION of DUAC and DUAM
	to undef? No.

	My current blead@30849 can reproduce the bug. Backup. On that perl
	installation it is enough to

	  install DMAKI/DateTime-Calendar-Chinese-0.05.tar.gz

	to enter the loop. The solution is the sponsored_modules attribute which
	is already used to prevent re-testing within one command. So now we
	prevent re-installing too.

2007-04-04  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* with yesterday's fix DMAKI/DateTime-Util-Astro-0.08.tar.gz runs into
	an endless installation loop:-(

2007-04-03  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Prepending /home/k/.cpan/build/Text-Autoformat-1.13-tM9mak/blib/arch /home/k/.cpan/build/Text-Autoformat-1.13-tM9mak/blib/lib /home/k/.cpan/build/DateTime-Util-Astro-0.08-YLAScV/blib/arch /home/k/.cpan/build/DateTime-Util-Astro-0.08-YLAScV/blib/lib to PERL5LIB for 'make'

	Now I got it. If for whatever reason we have another "test" after an
	"install", we enter is_tested again but do not leave it because install
	is "already done".

	What's the fix? Either do not enter again or always leave even when
	"already done". The former is not easy or even impossible because we
	never know that a distribution is already installed. We only know it for
	modules. So the second solution is the better.

	* CPANPLUS 0.78?

Recursive dependency detected:
    CPANPLUS (have: N/A; want: 0.78)
 => KANE/CPANPLUS-0.78.tar.gz
 => CPANPLUS::Shell::Default (have: N/A; requires: 0.0)
 => KANE/CPANPLUS-0.78.tar.gz.
Cannot resolve.

	Need to relax the dependency check for self?

	http://rt.cpan.org/Ticket/Display.html?id=26077

	* YAML::Tiny 1.04?

	Now that YAML::Syck is broken, YAML::Tiny tests also fail. It seems
	because they compare Syck with Tiny.

	* Try newer apache for mod_perl (Current is 1.3.37!)

	* Try out outline mode for Changes file

	* The "Prepending" bug: Prepending /home/k/.cpan/build/XML-LibXML-1.62-yZpjGO/blib/arch /home/k/.cpan/build/XML-LibXML-1.62-yZpjGO/blib/lib /home/k/.cpan/build/Apache-Session-1.82-idoFjK/blib/arch /home/k/.cpan/build/Apache-Session-1.82-idoFjK/blib/lib /home/k/.cpan/build/mod_perl-1.30-YPYnZK/blib/arch /home/k/.cpan/build/mod_perl-1.30-YPYnZK/blib/lib to PERL5LIB for 'test'

	This gathering is always around more or less of the same modules. And
	today (megainstall.20070403T0058.out) I did not run a parallel shell
	session, so the problem builds up from some other forces. It started
	with mod_perl, then Apache-Session joined the club and then XML::LibXML.

	YAY, mod_perl is a real problem: installation fails because the apache
	part wants to install its deputies into /usr/local where I have no
	permissions. Need to revisit the parameters I can influence.

	So next problem child is Apache-Session. I find no line in the output
	(yet?) that would explain the problem but a suspect it's simply due to
	the mod_perl dependency. Nope. Only declared prereqs are

    requires: 
      File::Temp: 0
      Test::Deep: 0.082
      Test::Exception: 0.15
      Test::More: 0.47

	???

2007-04-02  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug or what?

% make run
/home/src/perl/repoperls/installed-perls/perl/p3VGl7t/perl-5.8.0@30827/bin/perl -Ilib -MCPAN -eshell
CPAN: Term::ANSIColor loaded ok (v1.11_01)
Terminal does not support AddHistory.

cpan shell -- CPAN exploration and modules installation (v1.90)
ReadLine support available (try 'install Bundle::CPAN')

cpan[1]> m HTTP::Body
CPAN: Storable loaded ok (v2.16)
Going to read /home/k/.cpan/Metadata
  Database was generated on Mon, 02 Apr 2007 05:09:49 GMT
CPAN: YAML::Syck loaded ok (v0.84)
Going to read /home/k/.cpan/build/
......................................................Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Use of uninitialized value in concatenation (.) or string at lib/CPAN.pm line 657.
Catching error: 'Alert: While trying to  YAML file
  
with '' the following error was encountered:
  
' at lib/CPAN.pm line 274
        CPAN::shell() called at -e line 1

	Same for 30824. But when I repeat the 'm' command after that, it works.

	There must be a yaml file that breaks something. Needs further investigation.

	The broken YAML file is ~/.cpan/build/DBD-SQLite-1.13-Hqur1h.yml which
	fails at line 30/31:

 29   prefs:
 30     comment: '\nBecause the Makefile.PL depends on having DBI installed we w    ant to\nlet them build DBI and then rerun perl Makefile.PL and then make"\n\    nIt\'s a crazy example that I do not really like. I prefer resolving\nsuch a     thing with a build_requires or similar mechanism and see it\nas a Todo item     that such hacks are not needed in the future.\n'
 31     install: {}
 32 

	YAML::LoadFile isn't accepting this as valid YAML either. So who wrote
	it? It was written by YAML::Syck 0.84.

	https://rt.cpan.org/Ticket/Display.html?id=26057

2007-04-01  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* The HTTP::Body failing test is interesting. It's a loop over 11 cases
	with 5 tests on each. We get one "ok" and the next line in the code is
	an is_deeply() which consumes memory until exhausted.

	Replacing YAML with YAML::Syck resolves the problem. But running the
	program in the debugger with YAML also resolves it.

	https://rt.cpan.org/Ticket/Display.html?id=25927

	Also posted to P5P.

	* Much worse, I just discover that the last run of megainstall hangs and
	it is not obvious where.

	It has to do with Jifty and lsof says it has
	/home/k/.cpan/build/Jifty-0.70117-rnNlvG/t/Mapper as the CWD.

	The last lines in the output file are

		 Calling 'column' within a schema class is deprecated:

				package Jifty::Model::Session::Schema;
				column session_id => ...;        # NOT VALID

		 Please write this instead:

				package Jifty::Model::Session;
				use Jifty::DBI::Schema;
				use Jifty::Record schema {
						column session_id => ...;    # VALID
				};

		 Sorry for the inconvenience.

		*********************************************************
		 at /home/k/.cpan/build/Jifty-0.70117-rnNlvG/blib/lib/Jifty/Model/Session.pm line 20

		#   Failed test 'use Jifty::Test::WWW::Mechanize;'
		#   at t/Mapper/t/01-raw-api.t line 16.
		#     Tried to use 'Jifty::Test::WWW::Mechanize'.
		#     Error:  Base class package "Test::WWW::Mechanize" is empty.
		#     (Perhaps you need to 'use' the module which defines that package first.)
		#  at /home/k/.cpan/build/Jifty-0.70117-rnNlvG/blib/lib/Jifty/Test/WWW/Mechanize.pm line 5
		# BEGIN failed--compilation aborted at t/Mapper/t/01-raw-api.t line 16.
		# Compilation failed in require at (eval 1124) line 2.
		# BEGIN failed--compilation aborted at (eval 1124) line 2.
		Can't locate object method "new" via package "Jifty::Test::WWW::Mechanize" at t/Mapper/t/01-raw-api.t line 21.
		# Looks like you planned 32 tests but only ran 2.
		# Looks like you failed 1 test of 2 run.


	I kill the hanging test and hope to remember this problem next time
	around.

	And the major Todo here is to give an alert when such things happen.

	* Apache resurrected!

	But I see a bug or two:

cpan[5]> m mod_perl
Module id = mod_perl
    CPAN_USERID  GOZER (Philippe M. Chiasson <gozer@cpan.org>)
    CPAN_VERSION 1.30
    CPAN_FILE    G/GO/GOZER/mod_perl-1.30.tar.gz
    MANPAGE      mod_perl - Embed a Perl interpreter in the Apache HTTP server
    INST_FILE    /home/src/perl/repoperls/installed-perls/perl/pK4VYj9/perl-5.8.0@30806/lib/site_perl/5.9.5/i686-linux-64int/mod_perl.pm
    INST_VERSION 1.30


cpan[6]> m mod_perl
Module id = mod_perl
    CPAN_USERID  GOZER (Philippe M. Chiasson <gozer@cpan.org>)
    CPAN_VERSION 1.30
    CPAN_FILE    G/GO/GOZER/mod_perl-1.30.tar.gz
    MANPAGE      mod_perl - Embed a Perl interpreter in the Apache HTTP server
    INST_FILE    /home/src/perl/repoperls/installed-perls/perl/pK4VYj9/perl-5.8.0@30806/lib/site_perl/5.9.5/i686-linux-64int/mod_perl.pm
    INST_VERSION 1.30


cpan[7]> d GOZER/mod_perl-1.30.tar.gz
No objects of type Distribution found for argument GOZER/mod_perl-1.30.tar.gz


	Note that the last upload date does not appear.

	And when I scroll back I see a potentially third one:

Running make for D/DM/DMUEY/AltaVista-BabelFish-v42.0.2.tar.gz
Prepending /home/k/.cpan/build/mod_perl-1.30-gG7ERZ/blib/arch /home/k/.cpan/build/mod_perl-1.30-gG7ERZ/blib/lib to PERL5LIB for 'get'

	And later:

DEL(528.9>100.0MB): /home/k/.cpan/build/mod_perl-1.30-wAaavP 
DEL(257.3>100.0MB): /home/k/.cpan/build/mod_perl-1.30-gG7ERZ 

	These are now removed so are no good witnesses. Leaving the shell and
	re-entering?

cpan[2]> m mod_perl
Module id = mod_perl
    CPAN_USERID  GOZER (Philippe M. Chiasson <gozer@cpan.org>)
    CPAN_VERSION 1.30
    CPAN_FILE    G/GO/GOZER/mod_perl-1.30.tar.gz
    UPLOAD_DATE  2007-03-30
    MANPAGE      mod_perl - Embed a Perl interpreter in the Apache HTTP server
    INST_FILE    /home/src/perl/repoperls/installed-perls/perl/pK4VYj9/perl-5.8.0@30806/lib/site_perl/5.9.5/i686-linux-64int/mod_perl.pm
    INST_VERSION 1.30


cpan[3]> d GOZER/mod_perl-1.30.tar.gz      
Distribution id = G/GO/GOZER/mod_perl-1.30.tar.gz
    CPAN_USERID  GOZER (Philippe M. Chiasson <gozer@cpan.org>)
    CONTAINSMODS Apache Apache::Connection Apache::Constants Apache::Constants::Exports Apache::Debug Apache::ExtUtils Apache::FakeRequest Apache::File Apache::Include Apache::Leak Apache::Log Apache::ModuleConfig Apache::Opcode Apache::Options Apache::PerlRun Apache::PerlRunXS Apache::PerlSections Apache::RedirectLogFix Apache::Registry Apache::RegistryBB Apache::RegistryLoader Apache::RegistryNG Apache::Resource Apache::SIG Apache::Server Apache::SizeLimit Apache::StatINC Apache::Status Apache::Symbol Apache::Symdump Apache::Table Apache::URI Apache::Util Apache::fork Apache::httpd_conf Apache::src Apache::testold mod_perl
    UPLOAD_DATE  2007-03-30

	Interesting. This must be the same bug as described below for
	DMAKI/DateTime-Util-Astro-0.08.tar.gz et.al. Something gets installed
	properly, its state gets reanimated twice, and some data get lost during
	this step. Not sufficient to write a recipe how to reproduce.

2007-03-31  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Tcl-0.91

	When was Tcl updated last time?      2006-11-13

	When was Tcl added to megainstall?   SVK rev. 2016 on 2007-03-04

	When did Tcl start failing?          20070330T2346 (@30791)

	What is the failure saying?          t/call.........Tcl_InitNotifier: unable to ...
	                                     start notifier thread...dubious...and many ...
	                                     such messages

	Binary search says?                  First try against 30402 says that 30402 also fails

	Do we have a counter example?        20070305T0316 (@30463)

	What the latest counterexample?      megainstall.20070329T1818.out.term (@30777)

	cmp autobundle 30777/30791?          Snapshot_2007_03_31_0[01].pm too many differences.
	                                     I blame the extra tests I did for 30777

	cmp autobundle 30776/30806?          Snapshot_2007_04_01_0[01].pm also many differences.

	Are there google results on the
	error message "Tcl_InitNotifier:
	unable to start notifier thread"?    Plenty.

	I suppose my box upgrade on 0328 triggered some tcl breakage and I can
	ignore the issue from bleadperl's viewing angle.

	* Spreadsheet-ParseExcel-0.29

	http://rt.cpan.org/Ticket/Display.html?id=24693

	* Getopt ArgvFile 1.10

	No update since 2005. It seems to me the test now fails due to CPAN.pm's
	renaming of the root directories.

	http://rt.cpan.org/Ticket/Display.html?id=26001

	* AltaVista::BabelFish 42.0.1

	tests OK but CPAN.pm complains about an unfulfilled dependency,
	IO::Redirect. CPAN.pm does no know about IO::Redirect. Ticket in RT
	written.

	http://rt.cpan.org/Ticket/Display.html?id=26000

	* Net::Twitter 1.04

	testers has a pass, no fails. No bugreports in RT. It fails because
	JSON::Any fails. And JSON::Any fails because of a POD bug uncovered by
	Test::Pod or some such. Uh, oh!

	http://rt.cpan.org/Ticket/Display.html?id=25991

	* Devel::ebug 0.47

	Nothing blead related in RT. Tests ok with 30804. On retry installs
	successfully also with 30791. The error in the logfile is a YAML thing.

	NEEDS FURTHER WATCHING

	* Template::Timer 0.04, don't know where it comes from.

	It's been uploaded in 2005 and does profiling on TT. Catalyst-View-TT
	may have brought that in but who brought us that? Need to look into RT
	which is down at the moment. There is one bugreport about strange
	behaviour with 5.9.2 but no followup. Here it fails with 20002 too and
	with 16904.

	Cannot imagine what the problem is. Maybe som TT internal thing and
	older versions of Template did something differently.

	http://rt.cpan.org/Ticket/Display.html?id=26002

	* HTTP::Body 0.9 broken too.

	Ahh, this is the already reported YAML bug.

	* CPAN-SQLite from CVS broken too:

	20070326T0114 perl        30754
	20070326T0933 perl        30756
	20070326T1512 perl        30759
	20070326T2046 perl        30763 B
	20070327T0157 perl        30769 B
	20070327T0954 perl        30771 B
	20070327T1451 perl        30773 B
	20070327T2003 perl        30774 B
	20070328T1247 perl        30775 B
	20070329T0833 maint-5.8   30765
	20070329T1122 perl        30776 B
	20070330T0409 perl        30777 B
	20070330T2244 perl        30777 B
	20070330T2346 perl        30791 B

	A single 'make clean' helped and is now in the LOCAL distroprefs file.

	* Why is this in last night's megainstall (megainstall.20070330T2346.out):

  CPAN.pm: Going to build P/PE/PEVANS/Time-HiRes-Value-0.03.tar.gz

Checking whether your kit is complete...
Looks good

Checking prerequisites...
Looks good

Creating new 'Build' script for 'Time-HiRes-Value' version '0.03'
Copying lib/Time/HiRes/Value.pm -> blib/lib/Time/HiRes/Value.pm
Manifying blib/lib/Time/HiRes/Value.pm -> blib/libdoc/Time::HiRes::Value.3
  PEVANS/Time-HiRes-Value-0.03.tar.gz
  ./Build -- OK
  Prepending /home/k/.cpan/build/DateTime-Util-Astro-0.08-yKjgxA/blib/arch /home/k/.cpan/build/DateTime-Util-Astro-0.08-yKjgxA/blib/lib /home/k/.cpan/build/mod_perl-1.30-eynhXg/blib/arch /home/k/.cpan/build/mod_perl-1.30-eynhXg/blib/lib /home/k/.cpan/build/Bit-Vector-6.4-SYePdn/blib/arch /home/k/.cpan/build/Bit-Vector-6.4-SYePdn/blib/lib /home/k/.cpan/build/Text-Autoformat-1.13-w2ad5G/blib/arch /home/k/.cpan/build/Text-Autoformat-1.13-w2ad5G/blib/lib to PERL5LIB for 'test'

	It seems to indicate that some modules were built and tested
	successfully and await installation. But why did they not get installed?

	I can see elsewhere in the logfile:

  DMAKI/DateTime-Util-Astro-0.08.tar.gz
  make install UNINST=1 -- OK

  STBEY/Bit-Vector-6.4.tar.gz
  make install UNINST=1 -- OK

  DCONWAY/Text-Autoformat-1.13.tar.gz
  make install UNINST=1 -- OK

	So apparently three times the unsetting of the is_tested flag did not
	work. Do we have a new bug in perl or is it our own bug?

	Going back to February 22, I see the same thing for
	DateTime-Util-Astro-0.08-BsMTev XML-LibXML-1.62-Zi4hvt
	Apache-Session-1.82-3jaGeJ Bit-Vector-6.4-nHiJ0u

	This was less noisy in January, started in February, so I suppose our
	own bug:(

2007-03-30  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Perlbal fails all over since we have it in megainstall at
	20070323T0231.

	Why are there some logfiles without a broken Perlbal?

	B for broken:

	B 20070323T0231 perl        30700
	  20070323T0727 maint-5.8   30701 gpg failure? terminated?
	B 20070323T1315 perl        30714
	B 20070323T1935 perl        30726
	B 20070323T2327 maint-5.8   30723
	B 20070324T0326 perl        30740
	B 20070324T1335 maint-5.8   30743
	B 20070324T1813 perl        30745
	B 20070325T0041 perl        30750
	B 20070326T0114 perl        30754
	B 20070326T0933 perl        30756
	B 20070326T1512 perl        30759
	B 20070326T2046 perl        30763
	B 20070327T0157 perl        30769
	B 20070327T0954 perl        30771
	B 20070327T1451 perl        30773
	B 20070327T2003 perl        30774
	B 20070328T1247 perl        30775
	B 20070329T0833 maint-5.8   30765
	B 20070329T1122 perl        30776
	  20070329T1818 perl        30777 gpg failure? terminated?
	B 20070330T0409 perl        30777
	  20070330T2219 perl        30777 terminated somehow
	B 20070330T2244 perl        30777
	B 20070330T2346 perl        30791
	  20070331T0514 perl        30804 still running

	The two gpg failures/terminated questions are suspicious. I rename them
	to .out.term so they do not lead to confusion.

	* Perlbal failing with maintperl, bleadperl (very different failure
	modes). 2 reports sent (as k), check which arrived!

	And 5.8.8 failed the first time but succeeded the second time. Binary
	search impossible because sometimes it hangs. Too fragile: hanging test
	45 for example. Maybe the prerequisites not tight enough?

2007-03-29  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

2007-03-27  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug: Uuuuuh, pressing ^C and then trying an illegal command, ugliness:

	LWP failed with code[500] message[read timeout]
Trying to get away with old file:
6114541  500 -rw-rw-r--  1 1000     1000       504953 Nov  8 08:02 /home/k/.cpan/sources/modules/02packages.details.txt.gz
Going to read /home/k/.cpan/sources/modules/02packages.details.txt.gz
  Database was generated on Tue, 07 Nov 2006 12:25:12 GMT
.
Caught SIGINT, trying to continue
	
cpan> hosts
Refusing to autoload 'hosts' while signal pending at lib/CPAN.pm line 590.

	Seems to be FIXED

	* Verilog-Perl a.k.a. Verilog::Language broke some day but not on perl
	but on some other module most probably. I spent a long time
	investigating and still no good plan how to identify the problem.
	There's quite a bit to read further down on 2007-02-17.

	2007-03-28 akoenig: 2007-01-27/28 the tests started failing.

	grep -1 WSNYDER/Verilog-Perl logs/megainstall.20070*.out|grep 'make test'

logs/megainstall.20070127T1700.out-  /usr/bin/make test -- OK
logs/megainstall.20070127T2309.out-  /usr/bin/make test -- OK
logs/megainstall.20070128T0351.out-  /usr/bin/make test -- NOT OK

	all tests before that were OK, all tests after failed.

logs/megainstall.20070127T2309.out:ESC[1;44m  WSNYDER/Verilog-Perl-2.371.tar.gz
logs/megainstall.20070127T2309.out-ESC[0mESC[1;44m  /usr/bin/make test -- OK
--
logs/megainstall.20070128T0351.out:ESC[1;44m  WSNYDER/Verilog-Perl-2.371.tar.gz
logs/megainstall.20070128T0351.out-ESC[0mESC[1;31m  /usr/bin/make test -- NOT OK

	Now this: back in February I proved it is not perl. Now I proved, it is
	something based on date, not perl version. So something else was updated
	that evening, either a distro or a distroprefs file.

% diff -u =(grep 'CPAN.pm: Going to' logs/megainstall.20070127T2309.out | sort) =(grep 'CPAN.pm: Going to' logs/megainstall.20070128T0351.out | sort)
--- /tmp/zshkEon7w      2007-03-28 08:09:44.000000000 +0200
+++ /tmp/zsheCNzmI      2007-03-28 08:09:44.000000000 +0200
@@ -321,6 +321,7 @@
   CPAN.pm: Going to build J/JR/JROBINSON/DBIx-Class-0.07005.tar.gz
   CPAN.pm: Going to build J/JR/JROGERS/Net-Telnet-3.03.tar.gz
   CPAN.pm: Going to build J/JU/JURL/DBD-ODBC-1.13.tar.gz
+  CPAN.pm: Going to build J/JV/JV/Getopt-Long-2.36.tar.gz
   CPAN.pm: Going to build J/JW/JWIED/Net-Daemon-0.39.tar.gz
   CPAN.pm: Going to build J/JW/JWIED/PlRPC-0.2018.tar.gz
   CPAN.pm: Going to build K/KA/KANE/CPANPLUS-0.076.tar.gz

	It is GetOpt-Long-2.36!

	Now I wrote a bug report and RT answers with an internal server error.
	Bug report lost? Fortunately no:

	https://rt.cpan.org/Ticket/Display.html?id=25900

	* David Golden sent me this link to perlmonks
	http://perlmonks.org/?node_id=603402 and we have since fixed the
	documentation in perlrun or so. Need to come back to monks and report
	this success. DONE.
	
2007-03-26  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Todo: shuffle the Todo list so that it is useable again

	* Jifty seems to hang in the test 

	/home/src/perl/repoperls/installed-perls/perl/pWbnf63/perl-5.8.0@30754/bin/perl -w t/Mapper/t/02-api.t

	I must kill the associated process because it is standing still since
	2:48 and now it is 5:25. Will have to be seen again before we can take
	some action.

2007-03-25  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug: the notest pragma seems to be sticky. I encounter today that I
	cannot test Module::Build with the error message:

Skipping test because of notest pragma

	I do not know who sets it. Even after 'fforce get' it is set.

	After removing all Module-Build*.yml files in the build directory the
	problem goes away. Apparently we restore the pragma from a previous
	session... UHHH. Bug!

	Fixed in SVK rev. 2112 or so.

	* Todo: XUL::Node is some POE stuff and asks two questions

	* rxvt-unicode current version is @ 8.2, debian's is @ 7.9

	* Todo: post a working patch against Danga-Socket based on Dan Kogai's
	posting
	http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-12/msg00187.html

	DONE

2007-03-24  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* screencast still in idea stage: Slaven suggests to write an abstract
	widget as described in Tk::mega. This shall then use a text widget and
	only implement a few things like add_character, delay, add_line. Each
	shall then be passed through to the text widget. If our needs cannot be
	fulfilled by the text widget, we can still switch later to a canvas
	implementation.

	Further methods needed to make TAB behaviour visible. Both on capture
	and on output tricky. Does screen capture the TAB with its built-in? No.

	It's a drag. It turns me off. It seems the only software that does it
	right might be xterm itself? Ask Marc if rxvt can do it? DONE

2007-03-23  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* rt.cpan.org #25627 is awaiting further thoughts.

2007-03-21  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* I just discovered Term::ReadLine::Zoid by Jaap Karssenberg (PARDUS).
	It seems to work if the prompt is a string, it fails if it is an
	overloaded string. E.g.:

	PERL_RL=Zoid /home/src/perl/repoperls/installed-perls/*/p*/perl-5*@30598/bin/perl -Ilib -MCPAN -e 'shell("zoid> ")'
CPAN: File::HomeDir loaded ok (v0.64)
CPAN: Term::ANSIColor loaded ok (v1.11)

cpan shell -- CPAN exploration and modules installation (v1.8879)
ReadLine support enabled

zoid> q
Lockfile removed.

	But it starts in vi mode so immediately turns me off.
	PERL_RL=Zoid::Emacs works better.

	See also Zoidberg, the Perl shell. It seems to need a binary search. Or
	two! First it failed a test in blead which passes with ~29000. But with
	~29000 it's misbehaving during installation because it wants to write to
	/etc/. Maybe a Module::Build problem. With ~23000 it is installable.
	Strange. After a few hours we reach the area 2809[45] and the diffs
	indicate that we must be chasing a red herring. Usually we detect this
	by removing the older of the two involved perls and restarting the
	binary search and then comparing the profile of installed modules and
	their versions near the old and the new borderline. As we have no idea
	which modules to watch we will have to use autobundle.

	28094 succeeds, 95 fails. The patch 28095 is empty (!; see 28097 for
	some kind of explanation). The modules in the old (failing) 28095 are
	documented in Snapshot_2007_03_21_00.pm The first succeeding perl above
	28094 is which? 28100 and its snapshot is Snapshot_2007_03_21_01.pm

	And the first that then fails again is 28101 and I have now to change
	one module after the other to find out which has a bug. The snapshot of
	the 101 is Snapshot_2007_03_21_02.pm.

	Upgrading ExtUtils::MakeMaker from 6.30_02 to 6.32: no success.

	100 ok: Zoidberg-0.96-GO1tIS 	ExtUtils::Install	1.39
	101 fail: Zoidberg-0.96-wZKukQ 	ExtUtils::Install	1.41

	Stepwise upgrading of ExtUtils::Install:

   54015 2006-04-09 YVES/ExtUtils-Install-1.38.tar.gz
   65192 2006-04-14 YVES/ExtUtils-Install-1.39.tar.gz
   66620 2006-04-15 YVES/ExtUtils-Install-1.39_01.tar.gz
   56020 2006-04-30 YVES/ExtUtils-Install-1.40.tar.gz
   56582 2006-07-02 YVES/ExtUtils-Install-1.41.tar.gz
   57600 2007-02-02 YVES/ExtUtils-Install-1.41_01.tar.gz
   57628 2007-02-03 YVES/ExtUtils-Install-1.41_02.tar.gz
   58146 2007-02-11 YVES/ExtUtils-Install-1.41_03.tar.gz

	
	1.39    ok
	1.39_01 not ok
	1.40    not ok
	1.41    not ok
	1.41_01 fails its tests
	1.41_02 not ok
	1.41_03 not ok

	[(Sidetrack: Up/downgrading to 1.39_01 does not work. When I go to the
	~/.cpan/build/ExtUtils-Install-1.39_01 and call './Build install' then I
	see just this:

Reading skip patterns from 'INSTALL.SKIP'.
Writing /home/src/perl/repoperls/installed-perls/perl/pbN6H8H/perl-5.8.0@28100/lib/site_perl/5.9.4/i686-linux-64int/auto/ExtUtils/Install/.packlist

	I have to remove the INSTALL.SKIP file to install it. After that the
	installation finishes and I get 1.39_01.)]

  Downgrading to 1.39 makes it "work" again. When it comes by zoidrc it says:

Skipping /etc/zoidrc (unchanged)

	Apparently I have this zoidrc since Feb 12 or somebody set the timestamp
	to that. The file belongs to me, so I would be able to overwrite it. The
	failure to install it is a bug in ExtUtils::Install since 1.39_01.

	http://rt.cpan.org/Ticket/Display.html?id=25627

	What's noteworthy is that there seems to be no viable workaround short
	of patching Zoidberg. I cannot find a way to skip the installation step
	of etc/zoidrc. Not with "appdir", not with "distroprefs/*/commandline"
	where I tried to remove some files in the right moment, not with
	"||true" on the commandline because etc/zoidrc comes before the modules.
	Only thing is to disable all ExtUtils::Install after 1.39 and allow 1.39
	and downgrade everywhere. But here my love to Zoidberg is not strong
	enough and I decide to wait for a new release of ExtUtils::Install.

2007-03-20  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug in perldoc when rendering S< > which is being used in
	Tk/pod/mega.pod. It seems the rest of the line is being lost or so.
	tkpod displays it correctly.

	* Todo: screencast into the distro.

	http://kubasik.net/blog/2006/12/04/finally-howto-screencast-on-linux/

	http://ubuntu.wordpress.com/2006/06/08/how-to-create-a-screencast-in-ubuntu/

	I think I do not like these tools. They may be good for a YouTube video
	but for inclusion in the distro I want a text file that can be replayed,
	not a video. Tk, wx or curses. But maybe with sound. And of course,
	things that need just-in-time-explanation like "Watch now what happens
	when I hit TAB" or "see the result in slow motion now". It's probably
	much harder to produce such a beast than one would think on first sight.

2007-03-19  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Todo: fix wxWidgets to not download 20 MB every time I try to build
	it. [...] Oh well, I removed wxWidgets from MEGA instead.

	* Todo: investigate a bug in Cache.pm. Cache-2.04 failed today but it
	does not fail when I want to report the bug. The error message in the
	logfile was:

t/file...........
#   Failed test 'Cache::Tester::test_expiry: entry with 1 sec timeout added'
#   at /home/k/.cpan/build/Cache-2.04-L1wXv8/blib/lib/Cache/Tester.pm line 449.
# Looks like you failed 1 test of 84.
dubious
	Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 37
	Failed 1/84 tests, 98.81% okay

2007-03-18  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Alien::wxWidgets uses C< use Fatal qw(mkdir); > and uncovers that
	bleadperl forgot Fatal.pm when the _ prototype was introduced.

	http://groups.google.com/group/perl.perl5.porters/browse_thread/thread/2cae4476fda4c645/94fa909e7ae230a8#94fa909e7ae230a8

2007-03-17  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Retrying now with 5.6.2 from my k account. Worked.

	* Just sent a report for 5.8.3 from my k account and it arrived immediately.

	* report about 5.00504? I forgot that CPAN::Reporter does not run there.
	Lots of prereqs broken on 5.005

	* Report from OSX:

Sending test report with 'pass' to cpan-testers@perl.org
postdrop: warning: unable to look up public/pickup: No such file or directory

	* Report for 5.6.2, where did it get lost? Mail::Send is NOT installed
	(which is good). Net::SMTP is 2.29. 2.30 does not compile because it is
	calling utf8::encode. Will have to retry later.

	* Why is he not sending?

cpan[5]> report ANDK/CPAN-1.88_79.tar.gz
[...]
Test report not sent

	I think I had 'send_report' set to 'no'. Retrying after setting it to
	ask/no. Yes, this time it sent a report for 5.9.5 and it arrived.

2007-03-15  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* clean 31sessions.t output and run 30shell without Expect and clean
	that stderr thing too.

	This doesn't seem to be possible to do reliably. As soon as I let STDOUT
	and STDERR be joint with 2>&1 some tests fail. I think I'd prefer to
	have the Test:: stuff refrain from using STDERR alltogether and as long
	as they don't (or can't?) I'll let some STDERR escape.

	And this?

make[1]: Entering directory `/home/k/.cpan/build/CPAN-Test-Dummy-Perl5-Make-Failearly-1.02-8r8dgG'
make[1]: *** No rule to make target `clean'.  Stop.

	Ah, if {writemakefile} failed, do not try 'make clean'! DONE

2007-03-14  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Class::MOP needs a binary search because test t/003methods.t fails in
	blead but not in 22000. But a naive binary search discovers breakage in
	t/081_meta_package_extension.t on patch 26370. But we certainly can
	ignore that because this test works again nowadays. So I need a
	distropref to limit tests.

	Learn something new about Module::Build:

	    ./Build test --test_files t/mytest.t

	So now binary search again without the 081 test:

----Program----
eval {require Class::MOP};
print $@ ? "N/A" : "OK";
print "\n";

----Output of .../pL9BuO7/perl-5.8.0@26486/bin/perl----
OK

----EOF ($?='0')----
----Output of .../pHxMchK/perl-5.8.0@26487/bin/perl----
N/A

----EOF ($?='0')----

	Change 26487 by nicholas@nicholas-saigo on 2005/12/26 12:31:01

	Rework constant.pm to take advantage of the space savings of proxy
	constant subroutines whenever it can.

% ./Build test --verbose --test_files t/003_methods.t                                                                                                [CPANSHELL]
t/003_methods....1..64
ok 1 - use Class::MOP;
ok 2 - use Class::MOP::Class;
ok 3 - ... our method is not yet blessed
not ok 4 - ... we added the method successfully

#   Failed test '... we added the method successfully'
#   at t/003_methods.t line 65.
# died: Not a GLOB reference at /home/k/.cpan/build/Class-MOP-0.37-SpVpcK/blib/lib/Class/MOP/Package.pm line 197.
Not a GLOB reference at /home/k/.cpan/build/Class-MOP-0.37-SpVpcK/blib/lib/Class/MOP/Package.pm line 197.
# Looks like you planned 64 tests but only ran 4.
# Looks like you failed 1 test of 4 run.
# Looks like your test died just after 4.
dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 4-64
        Failed 61/64 tests, 4.69% okay
Failed Test     Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
t/003_methods.t  255 65280    64  121  4-64

	REPORT sent to P5P.
	
2007-03-13  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Do you want to build wxWidgets? [yes] y
Which archive type? [tar.gz] tar.gz
Do you want to include OpenGL support [no] n
Creating new 'Build' script for 'Alien-wxWidgets' version '0.28'
MBARBON/Alien-wxWidgets-0.28.tar.gz requires perl '5.6'; you have only 5.009005; giving up

	Looks like a bug in Alien::wxWidgets but somehow I feel guilty. Reported
	via RT.

2007-03-12  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Jost sent me the test output with TEST_VERBOSE and it was sooo
	frustrating:

PERL_DL_NONLAZY=1 /usr/local/perl-5.8.8/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(1, 'blib/lib', 'blib/arch')" t/30shell.t
t/30shell....1..230
ok 1 - histsize is 100 before testing
ok 2 - Another dummy test
ok 3 - RUN_EXPECT[1]
ok 4 - empty test %h=()
# PRESSING RETURN
# EXPECT: (?s:ReadLine support (enabled|suppressed|available).*?cpan[^>]*>)
# Looks like you planned 230 tests but only ran 4.
# EOF on i[1]prog[]
# expected[(?s:ReadLine support (enabled|suppressed|available).*?cpan[^>]*>)]
# got[]
# 
dubious
	Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 5-230
	Failed 226/230 tests, 1.74% okay
Failed Test Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
t/30shell.t  255 65280   230  452  5-230
Failed 1/1 test scripts. 226/230 subtests failed.

	I see no way short of incrementall improve diagnostics there and hope
	that the next release shows us more. DONE.


2007-03-11  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug: when I ^C a job, then it seems that some "force" is kept around
	for the next command. We must clear all modules, distros and bundles
	from 'force' bits when we let a Signal interrupt us. I'm not actually
	sure this is what happened but I have the impression that it is possible.

	Or maybe we have a different bug. This is the command:

	fforce test DMAKI/DateTime-Calendar-Japanese-0.05.tar.gz

	requires DMAKI/DateTime-Calendar-Japanese-0.05.tar.gz

	This in turn

	  DateTime::Util::Astro::Moon [requires]
    DateTime::Util::Calc [requires]
    DateTime::Util::Astro::Common [requires]
    DateTime::Event::SolarTerm [requires]

	DMAKI/DateTime-Util-Astro-0.08.tar.gz is the first one and it complains
	about Calc missing.

	DMAKI/DateTime-Util-Calc-0.13.tar.gz then complains about nothing, runs
	tests that fail for some reason. So we come back to Astro. This fails
	tests apparently because Calc is missing.

	So then we come to Calc again because it was on the list above. We fail
	the tests again, but I frankly do not understand why they are run at
	all. Normally we do not run a test twice within a single command.

	Then comes Astro again because of DateTime::Util::Astro::Common and
	fails again tests.

	Then we reach the last one on the list, SolarTerm. This again depends on
	Calc, so we build Calc again, fail, test SolarTerm, fail and ***finish***.

	So now my impression is that the setting of $xo->{make} might cause bad
	things to happen because we are not paying attention to the status of
	make/test/install before that, no? No, it's the fforce that make things
	so ugly. Because all parties inherit the fforce, they need to retest so
	often. So probably no bug at all, just ugly.

	CLOSED.
	
	* Bug: 

Recursive dependency detected:
    DMAKI/DateTime-Calendar-Japanese-0.05.tar.gz
 => DateTime::Calendar::Chinese (have: ; requires: 0.02)
 => DMAKI/DateTime-Calendar-Chinese-0.05.tar.gz
 => DateTime::Util::Astro::Moon (have: ; requires: >= 0.04)
 => DMAKI/DateTime-Util-Astro-0.08.tar.gz
 => Math::BigInt (have: 1.77; unknown status)
 => TELS/math/Math-BigInt-1.80.tar.gz
 => bignum (have: 0.17; requires: 0.19)
 => TELS/math/bignum-0.19.tar.gz
 => Math::BigInt (have: 1.77; requires: 1.79).
Cannot resolve.

	All involved parties get the stigma of circular dependency. That seems
	wrong. Only Math::BigInt and bignum should get it.

	OK, I fixed this but now D:Event:SolarTerm, D:U:Calc, D:U:Astro,
	D:Event:Lunar somehow fall into a spiral of unresolvable dependecies and
	are never redeemed from it. No? Maybe I was just impatient.

	FIXED.

	* HTML::CalendarMonth is failing but the error output is really large. I
	just tried to report() it and must check later if the mail actually
	arrived. --- It seems this report never arrives.

	* There was a mail from David Cantrell about a failure on OpenBSD which
	I could not imagine any reason for.

	ANSWERED.

2007-03-10  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Continue discussing the perlmonks bug with P5P. Only Schwern has
	answered and we need a resolution. Either document as it is at the
	moment or change it and then document it. I tend to the former because
	it is consistent. DONE
	
2007-03-08  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* David Golden sends me a link to perlmonks
	http://perlmonks.org/?node_id=603402

	It's about 1.8802. This guy does a

	setenv PERL5LIB /home/me/build/perl-addons/inst/usr/local/lib/perl5:/home/me/build/perl-addons/inst/usr/local/lib/perl5/site_perl

	and sets for the './Build install' command?
    Your choice:  [] --destdir /home/me/build/perl-addons/inst

	and for 'make install' command?
    Your choice:  [] DESTDIR=/home/me/build/perl-addons/inst

	When he installs Params::Validate, it indeed gets installed into that
	directory but when he asks 

	! use Params::Validate; print "$Params::Validate::VERSION\n"

	he gets an error

	When he quits the shell and enters it again and repeats the command, it
	is OK.


	Reproducing:

>16:18:39 k@k75:~/sources/CPAN/SVK/trunk% rm -rf ~/.cpan_pm_603402/destdir
>16:18:46 k@k75:~/sources/CPAN/SVK/trunk% PERL5LIB=/home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/bin/perl -I ~/.cpan_pm_603402 -MCPAN::MyConfig -Ilib -MCPAN -eshell
CPAN: Term::ANSIColor loaded ok (v1.11)

cpan shell -- CPAN exploration and modules installation (v1.8879)
ReadLine support enabled

cpan[1]> install Acme::Meta
CPAN: Storable loaded ok (v2.15)
Going to read /home/k/.cpan/Metadata
  Database was generated on Thu, 08 Mar 2007 14:08:52 GMT
Running install for module 'Acme::Meta'
CPAN: YAML::Syck loaded ok (v0.82)
Running make for N/NW/NWCLARK/Acme-Meta-0.02.tar.gz
CPAN: LWP::UserAgent loaded ok (v2.033)
CPAN: URI::URL loaded ok (v5.03)
CPAN: Digest::SHA loaded ok (v5.44)
CPAN: Module::Signature loaded ok (v0.55)
Signature for /home/ftp/pub/CPAN/authors/id/N/NW/NWCLARK/CHECKSUMS ok
CPAN: Compress::Zlib loaded ok (v2.004)
Checksum for /home/ftp/pub/CPAN/authors/id/N/NW/NWCLARK/Acme-Meta-0.02.tar.gz ok
Scanning cache /home/k/.cpan_pm_603402/build for sizes
............................................................................DONE
Acme-Meta-0.02
Acme-Meta-0.02/Meta.pm
Acme-Meta-0.02/MANIFEST
Acme-Meta-0.02/t
Acme-Meta-0.02/Changes
Acme-Meta-0.02/README
Acme-Meta-0.02/Makefile.PL
Acme-Meta-0.02/META.yml
Acme-Meta-0.02/t/1.t
CPAN: File::Temp loaded ok (v0.18)
Package came without SIGNATURE


  CPAN.pm: Going to build N/NW/NWCLARK/Acme-Meta-0.02.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Acme::Meta
cp Meta.pm blib/lib/Acme/Meta.pm
Manifying blib/man3/Acme::Meta.3
  NWCLARK/Acme-Meta-0.02.tar.gz
  /usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/1....ok                                                                    
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.07 cusr +  0.00 csys =  0.07 CPU)
  NWCLARK/Acme-Meta-0.02.tar.gz
  /usr/bin/make test -- OK
Running make install
Installing /home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/Acme/Meta.pm
Installing /home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/man/man3/Acme::Meta.3
Writing /home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/i686-linux-64int/auto/Acme/Meta/.packlist
Appending installation info to /home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8/i686-linux-64int/perllocal.pod
  NWCLARK/Acme-Meta-0.02.tar.gz
  make install DESTDIR=/home/k/.cpan_pm_603402/destdir -- OK

cpan[2]> m Acme::Meta      
Module id = Acme::Meta
    CPAN_USERID  NWCLARK (Nicholas Clark <nwc10+please+use+perlbug+for+perl+queries@colon.colondot.net>)
    CPAN_VERSION 0.02
    CPAN_FILE    N/NW/NWCLARK/Acme-Meta-0.02.tar.gz
    UPLOAD_DATE  2006-10-01
    MANPAGE      Acme::Meta - Enhances the Meta package
    INST_FILE    (not installed)


cpan[3]> ! use Acme::Meta  
Can't locate Acme/Meta.pm in @INC (@INC contains: /home/k/.cpan_pm_603402 /home/k/sources/CPAN/SVK/trunk/lib /home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8/i686-linux-64int /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8 /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/i686-linux-64int /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8 /home/k/sources/CPAN/SVK/trunk) at (eval 48) line 2.
BEGIN failed--compilation aborted at (eval 48) line 2.

cpan[3]> q
Lockfile removed.
>16:20:19 k@k75:~/sources/CPAN/SVK/trunk% PERL5LIB=/home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl /home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/bin/perl -I ~/.cpan_pm_603402 -MCPAN::MyConfig -Ilib -MCPAN -eshell
CPAN: Term::ANSIColor loaded ok (v1.11)

cpan shell -- CPAN exploration and modules installation (v1.8879)
ReadLine support enabled

cpan[1]> ! use Acme::Meta
cpan[1]> m Acme::Meta    
CPAN: Storable loaded ok (v2.15)
Going to read /home/k/.cpan/Metadata
  Database was generated on Thu, 08 Mar 2007 14:08:52 GMT
CPAN: LWP::UserAgent loaded ok (v2.033)
CPAN: YAML::Syck loaded ok (v0.82)
CPAN: URI::URL loaded ok (v5.03)
Module id = Acme::Meta
    CPAN_USERID  NWCLARK (Nicholas Clark <nwc10+please+use+perlbug+for+perl+queries@colon.colondot.net>)
    CPAN_VERSION 0.02
    CPAN_FILE    N/NW/NWCLARK/Acme-Meta-0.02.tar.gz
    UPLOAD_DATE  2006-10-01
    MANPAGE      Acme::Meta - Enhances the Meta package
    INST_FILE    /home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/Acme/Meta.pm
    INST_VERSION 0.02



	So the bug is real and reproducable with blead. It seems to be about
	@INC expansion. Before I installed Acme::Meta I had this @INC:

cpan[1]> dump @INC
CPAN: Storable loaded ok (v2.15)
Going to read /home/k/.cpan/Metadata
  Database was generated on Thu, 08 Mar 2007 14:08:52 GMT
CPAN: Data::Dumper loaded ok (v2.121_11)
$VAR1 = '/home/k/.cpan_pm_603402';
$VAR2 = '/home/k/sources/CPAN/SVK/trunk/lib';
$VAR3 = '/home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl';
$VAR4 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8/i686-linux-64int';
$VAR5 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8';
$VAR6 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/i686-linux-64int';
$VAR7 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8';
$VAR8 = '/home/k/sources/CPAN/SVK/trunk';

	After I installed Acme::Meta I had this @INC:

cpan[1]> dump @INC         
CPAN: Storable loaded ok (v2.15)
Going to read /home/k/.cpan/Metadata
  Database was generated on Thu, 08 Mar 2007 14:08:52 GMT
CPAN: Data::Dumper loaded ok (v2.121_11)
$VAR1 = '/home/k/.cpan_pm_603402';
$VAR2 = '/home/k/sources/CPAN/SVK/trunk/lib';
$VAR3 = '/home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/i686-linux-64int';
$VAR4 = '/home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8';
$VAR5 = '/home/k/.cpan_pm_603402/destdir/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl';
$VAR6 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8/i686-linux-64int';
$VAR7 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/5.8.8';
$VAR8 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8/i686-linux-64int';
$VAR9 = '/home/src/perl/repoperls/installed-perls/maint-5.8/pZ22fQT/perl-5.8.0@30509/lib/site_perl/5.8.8';
$VAR10 = '/home/k/sources/CPAN/SVK/trunk';


	So apparently I knew too little about @INC population.

	It seems perl 5.8.8 scans the PERL5LIB directories at startup if they
	exist and only populates @INC for directories that either are explicitly
	mentioned or that really exist. The directories .../5.8.8 and
	.../5.8.8/i686-linux-64int are not added as long as they are not
	created.

	And apparently I had always relied that perl solves it for me.

	POSTED analysis to P5P with the subject "Composing @INC from PERL5LIB".
	

	* David Cantrell reports that YAML must be > 0.39 if we want to use it.

	FIXED

2007-03-06  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Oh Joy of having authors who carefully track the dependencies between
	their packages. bignum currently depends on Math::BigInt 1.79. But
	current version is 1.80. But Math-BigIng-1.80 depends on bignum 0.19. So
	if I have 1.77 I must first install 1.79, then I can install bignum and
	only then I can install BigInt 1.80.

	I'm sure some people will call it a bug that CPAN.pm is not able to
	install the old version 1.79 as a dependency of 1.80.

2007-03-04  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* blead@30460:

ext/Time/HiRes/t/HiRes......................................FAILED at test 35
[...]
../ext/Time/HiRes/t/HiRes.t: overall time allowed for tests (90s) exceeded!
ok

	* Strange failures with bleadperl @30458:

 ADAMK/Test-ClassAPI-1.03.tar.gz              : make_test NO
 ADAMK/File-Flat-1.00.tar.gz                  : make_test NO
 ADAMK/Test-Inline-2.201.tar.gz               : make_test NO
 RUZ/DBIx-SearchBuilder-1.47.tar.gz           : make_test NO
 JESSE/Class-ReturnValue-0.53.tar.gz          : make_test NO one dependency not OK (Test::Inline)
 ADAMK/Algorithm-Dependency-1.102.tar.gz      : make_test NO one dependency not OK (Test::ClassAPI)

	when I tried all these, they worked fine.

	It seems that ADAMK/Test-ClassAPI-1.03 is depending on Params::Util but
	not declaring it? Yes, that's it. Already reported as
	http://rt.cpan.org/Ticket/Display.html?id=25009

	* 29026 broke Text::Template

t/09-error.........Illegal value `WLUNCH' for TYPE parameter at t/09-error.t line 41
t/09-error.........FAILED test 3
        Failed 1/5 tests, 80.00% okay

	It's a \Q\` matter and shall be treated as a bug in user code, I suppose.

	https://rt.cpan.org/Ticket/Display.html?id=23620 and a new distroprefs
	file. I only looked into RT too late:(

2007-03-03  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* just sent a report about Exporter::Simple. Debugging shows that it was
	sent with Net::SMTP. Same for XML::Compile. Neither arrived at testers.
	Maybe I had a different smtp host then? I do not remember to ever have
	changed it.

	smtp_server=localhost

	We should try	mx.develooper.com ?

	Tried that with Attribute::Util. Debugging says that it was sending to
	develooper.

	Or maybe I shouldn't have changed my email address?

	Changing back to andreas.koenig.gmwojprw@franz.ak.mind.de and reporting
	about UNIVERSAL::exports.

	YES, this was it. So I need to turn the clock back: I have not reported
	anything for quite a while:(

	* whats missing for this release?

	cpan -r bug report      # mail to brian is on the way

	Jost's sun-solaris test # no idea what to do

	can we have RT          # Bundle::RT is in

	and Tcl in megainstall  # DONE

	* my internet access is broken at the moment. When it is back I need to
	answer two posts by Eric Wilhelm.

	* possible bug: when a distroprefs file has "match" but no valid keyword
	under match/, then it seems that it matches always instead of being
	rejected as invalid. We must make the one of the match subthingies
	mandatory. Need to study
	http://www.kuwata-lab.com/kwalify/users-guide.01.html for that when my
	internet is back.

	FIXED in svk rev. 2002 or so.

2007-03-02  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* New FAILS from testers: Jost on Sun sees only 4 OKs in 30shell on
	solaris and a dubious. Slaven saw one test in 31sessions failing.

	The Slaven thing can be averted by taking out a piece of the "Expected"
	regexp. DONE

	For the failure on sun I need a different strategy. Something that gives
	more feedback.

t/30shell..........dubious
	Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 5-230
	Failed 226/230 tests, 1.74% okay

2007-03-01  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* XML::Simple failed a test today. When I came and tested it again, it
	succeeded. Fortunately the tests spit out helpful diagnostics. Looks
	like XML::SAX must be installed? No, this seems not the problem. So
	maybe a intermittant failure.

t/3_Storable......
no element found at line 1, column 0, byte 0 at /home/src/perl/repoperls/installed-perls/perl/pvDPEkV/perl-5.8.0@30435/lib/site_perl/5.9.5/i686-linux-64int/XML/Parser.pm line 187
# Looks like you planned 23 tests but only ran 13.
# Looks like your test died just after 13.
dubious
	Test returned status 255 (wstat 65280, 0xff00)

2007-02-28  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Tcl needs some attention to compile? NO

2007-02-26  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* supposedly a bug: Slaven found both cpanconfig and cpan_config FIXED

	* todo: document match/perlconfig DONE

2007-02-24  Andreas Koenig  <k@andreas-koenigs-computer.local>

	* jochen stenzel asked me for a comparison of CPAN::Site and dot
	distributions or better said, a summary about the options we have today
	to support modules besides CPAN itself.

	My current favorite is to have all distros that are not on CPAN in a
	repository, check the repository out on the local disk, ideally always
	in the same path/location. Then write a Bundle file that contains all
	"root" directories of these non-distros and install the Bundle. (Note to
	self: need to write detailed instructions how to do all that). The
	advantage of this is that nobody needs to make releases, all code is
	checked out at any point in time and is current. If one needs to make
	sure that the software is in a stable state, this can be achieved with
	the options provided by the revision control software. The disadvantage
	of this method is that CPAN.pm knows nothing about the state of the
	distros, it just installs them and does not keep a record that it did so
	and cannot determine if there is a newer version. If you install the
	Bundle again immediately after you have installed, it just starts from
	the beginning again (rinse, repeat).

	I must try if 'cpan .' also works for a Bundle. I do not think it does.

	Then I must study how CPAN::Site works nowadays. The problem with that
	always was that it required manual work on the side of the maintainer of
	the additional repository.

	Of course, the ideal solution would be if CPAN.pm could just "subscribe"
	to any number of parallel Universes and then mix them with some
	algorithm (first wins; manual conflict resolution; etc.). Still, this
	would require skills on the side of the archive maintainers or muchly
	improved tools for them.

	pip by Adam Kennedy tries to solve the problem (I think) by injecting
	distros/tarballs into the author "LOCAL" directory. Simple quick
	solution but no integration into an index at all, so the same
	disadvantage as the dot distros (rinse,repeat) but with the additional
	(of course very minor) disadvantage that somebody must make releases,
	tar them together and then CPAN.pm has to unroll them again.

2007-02-20  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* scripts installation broken. Tried it with pingomatic and keepcool. FIXED

	* when was notest introduced? In 1.80, December 2005. New features by
	Slaven this year are: 'cpan .', scripts, 'perl -I. -MCPAN' now works.

	* consider different sorting of directory listings. suggested by Slaven.
	REJECT

2007-02-19  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Chris has tested _76: twice OK, once NOT on 31sessions/28th test.

	* Chris has tested _75 and I can see that his shell says the unexpected

	'Unknown shell command \'yes\'. Type ? for help.
'
	But the "yes" gets eaten earlier too

	Would you like me to configure as much as possible automatically? [yes] yes

	How can it happen that the yes is both consumed and still left over on
	the input?

	Now I have it! He must have set PERL_MM_USE_DEFAULT!!!!!!!!!

2007-02-18  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* I'm quite helpless with the 5 reports from chris.

	Apparently the output is from the command N-1 while the shell believes
	to test the command N.

	So the reason could be that the shell asks one more question to chris
	than to me.

	I have tried

	cpanplus with bleadperl on k75
	cpanplus with 5.8.8 on k75
	cpan with 5.8.6 on k78
	cpan with 5.8.8 on dev05
	cpan with 5.8.8 on playground
	cpan 1.7601 with 5.8.7 on k66

	Ahh, the last one has lots of errors. But not the one that chris has.

	* last night Convert::PEM with 30342 went into an endless loop and
	filled the disk. Convert-PEM-0.07-Dlxs3I/ is left over, I had to remove
	the logfile but let's try if report can reconstruct. Of course not,
	because the yml file could not be written. Report starts in a new
	directory and succeeds within seconds. Visiting the left over directory
	from the nightly run also brings no evidence: tests run OK within
	seconds. Oh well.

2007-02-17  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* testers has 5 nearly identical FAILS results on 1.88_74, all made with
	CPANPLUS 0.076, all from chris. The failure goes like this:

#   Failed test 'command[test CPAN::Test::Dummy::Perl5::Make]'
#   at t/31sessions.t line 170.
#                   '    patch              [ ]
# Please use 'o conf commit' to make the config permanent!
# 
# '
#     doesn't match '/t/00_load.+ok/'


	and I cannot imagine how this can happen.

	So I find myself using CPANPLUS for the very first time since ages.

	I type 'f Verilog::Languange' and CPANPLUS does not seem to answer ever.
	Oh well, after about two minutes it says

    1 Verilog-Perl                                       2.361    WSNYDER   
    2 Verilog-Perl                                       2.371    WSNYDER   

	Cool feature.

	I do the same for CPAN and they answer

    1 CPAN                                               1.87     ANDK
    2 CPAN                                               1.8869   ANDK
    3 CPAN                                               1.8866   ANDK
    4 CPAN                                               1.8872   ANDK
    5 CPAN                                               1.8867   ANDK
    6 CPAN                                               1.8864   ANDK
    7 CPAN                                               1.8871   ANDK
    8 CPAN                                               1.88     ANDK
    9 CPAN                                               1.8865   ANDK
   10 CPAN                                               1.8873   ANDK
   11 CPAN                                               1.8874   ANDK
   12 CPAN                                               1.8868   ANDK
   13 CPAN                                               1.8801   ANDK
   14 CPAN                                               1.8802   ANDK

	What a strange sorting! And where are the underscores? And when I say 'i
	11' they say

Installing CPAN
*** Install log written to:
  /home/k/.cpanplus/install-logs/CPAN-1171719784.log

Module 'CPAN' installed successfully
No errors installing all modules

	This action took less than a second and I must open that logfile to find
	out that CPAN is already up to date (without version information). And
	above that I do have 1.8873 installed, not 1.8874 so why they do not
	install 1.8874 is not clear.

	But I can test 1.8874 ok and now I have again no idea why the 5 FAILS on
	testers.
	
	* Macbook compiles bleadperl@30032 with a horrible amount of test failures

Failed Test                               Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
../ext/Encode/t/Aliases.t                    2   512    ??   ??  ??
../ext/Encode/t/CJKT.t                     255 65280    60  120  1-60
../ext/Encode/t/Encode.t                     2   512    ??   ??  ??
../ext/Encode/t/Encoder.t                  255 65280   516 1032  1-516
../ext/Encode/t/Unicode.t                  255 65280    37   74  1-37
../ext/Encode/t/at-cn.t                    255 65280    29   58  1-29
../ext/Encode/t/at-tw.t                    255 65280    17   34  1-17
../ext/Encode/t/enc_data.t                   2   512    ??   ??  ??
../ext/Encode/t/enc_eucjp.t                  2   512    ??   ??  ??
../ext/Encode/t/enc_module.t                 2   512    ??   ??  ??
../ext/Encode/t/enc_utf8.t                   2   512    ??   ??  ??
../ext/Encode/t/encoding.t                   2   512    ??   ??  ??
../ext/Encode/t/fallback.t                 255 65280    44   88  1-44
../ext/Encode/t/from_to.t                  255 65280     3    6  1-3
../ext/Encode/t/grow.t                       2   512    ??   ??  ??
../ext/Encode/t/gsm0338.t                  255 65280    21   42  1-21
../ext/Encode/t/guess.t                      2   512    ??   ??  ??
../ext/Encode/t/jperl.t                    255 65280    15   30  1-15
../ext/Encode/t/mime-header.t              255 65280    11   21  1-11
../ext/Encode/t/mime_header_iso2022jp.t    255 65280    14   28  1-14
../ext/Encode/t/perlio.t                   255 65280    38   76  1-38
../ext/Encode/t/utf8strict.t                 2   512    ??   ??  ??
../ext/Hash/Util/FieldHash/t/01_load.t     255 65280     8   12  1-2 4-8
../ext/Hash/Util/FieldHash/t/02_function.  255 65280    ??   ??  ??
../ext/Hash/Util/FieldHash/t/03_class.t    255 65280     7   14  1-7
../ext/Hash/Util/FieldHash/t/04_thread.t   255 65280    ??   ??  ??
../ext/Hash/Util/FieldHash/t/05_perlhook.  255 65280    ??   ??  ??
../ext/Hash/Util/FieldHash/t/10_hash.t     255 65280    ??   ??  ??
../ext/Hash/Util/FieldHash/t/11_hashassig  255 65280    ??   ??  ??
../ext/Hash/Util/FieldHash/t/12_hashwarn.  255 65280    ??   ??  ??
../ext/Hash/Util/t/Util.t                  255 65280   227  430  1-227
../ext/PerlIO/encoding/t/nolooping.t       255 65280     1    2  1
../ext/Storable/t/downgrade.t              255 65280   169  325  7-169
../ext/Storable/t/restrict.t                 2   512    ??   ??  ??
../ext/Sys/Syslog/t/syslog.t                 4  1024   159    4  129-132
../lib/Pod/Simple/t/corpustest.t                        43   15  3 5 7 9 11 17
                                                                 19 21 23 25 28
                                                                 36 38 40 42
../lib/base/t/fields-base.t                255 65280    29   20  20-29
../lib/base/t/fields.t                     255 65280    16   22  6-16
../lib/encoding/warnings/t/4-lexical.t                   3    1  2
comp/utf.t                                   2   512    15   30  1-15
io/layers.t                                             37   13  6 9-11 13 21
                                                                 23-24 33-37
run/fresh_perl.t                                        94    1  94
uni/chomp.t                                  2   512    ??   ??  ??
uni/chr.t                                  255 65280     6   12  1-6
uni/greek.t                                  2   512    ??   ??  ??
uni/latin2.t                                 2   512    ??   ??  ??
uni/tr_7jis.t                              255 65280     6   12  1-6
uni/tr_eucjp.t                             255 65280     6   12  1-6
uni/tr_sjis.t                              255 65280     6   12  1-6
uni/tr_utf8.t                              255 65280     8   16  1-8
79 tests and 530 subtests skipped.
Failed 50/1366 test scripts. 1312/172604 subtests failed.
Files=1366, Tests=172604, 647 wallclock secs (357.74 cusr + 65.52 csys = 423.26 
CPU)
Failed 50/1366 test programs. 1312/172604 subtests failed.


	* Todo: mark hosts command and dot directories as alpha code in the
	documentation.

	* Bug: Watch the upload date between the two runs of 'm'

cpan[4]> m Verilog::Language
Module id = Verilog::Language
    DESCRIPTION  Language support, number parsing, etc
    CPAN_USERID  WSNYDER (Wilson Snyder <wsnyder@wsnyder.org>)
    CPAN_VERSION 2.371
    CPAN_FILE    W/WS/WSNYDER/Verilog-Perl-2.371.tar.gz
    DSLIP_STATUS Rdpfp (released,developer,perl,functions,Standard-Perl)
    INST_FILE    (not installed)

cpan[5]> m Verilog::Language
Module id = Verilog::Language
    DESCRIPTION  Language support, number parsing, etc
    CPAN_USERID  WSNYDER (Wilson Snyder <wsnyder@wsnyder.org>)
    CPAN_VERSION 2.371
    CPAN_FILE    W/WS/WSNYDER/Verilog-Perl-2.371.tar.gz
    UPLOAD_DATE  2007-01-23
    DSLIP_STATUS Rdpfp (released,developer,perl,functions,Standard-Perl)
    INST_FILE    (not installed)

	1.8802 does not seem to have this bug. Ah, but I cannot reproduce it now
	with 1.88_74 either, so it's not always there. Turning off
	cache_metadata does not bring it back.

	I must keep an eye on this but it is no showstopper.

	* Verilog-Perl a.k.a. Verilog::Language broke on patch 30044. The
	failure mode is that the modules themselves compile fine but the output
	of the compiled program 'vppp' differs from the expected one.

	    UPLOAD_DATE  2007-01-23

	Suspiciously young and the patch 30044 appeared on 27th.

   91807 2006-10-02 WSNYDER/Verilog-Perl-2.361.tar.gz
   93591 2007-01-23 WSNYDER/Verilog-Perl-2.371.tar.gz

	I repeat the binary search with nailed down version demand on
	Verilog::Language 2.371 to make sure that the first run was not trapped
	into a difference between the two versions. ... No, it's not a version
	trap.

	So I made my own 30333 where the sense of the ifdef is turned around to
	say the opposite. It seems to me this is the way it was intended. But no
	success. Even backing out 30044 does not help.

	Now I removed the whole installed 30333, reinstalled it with the backed
	out 30044 patch. (recompiled but not recompiled from scratch). As my
	first module I try Verilog and it fails.

	Now I recompile from scratch. 'make clobber' and start with ./Configure.
	30044 is backed out. No, Verilog remains broken.

	This is impossible. Let me see 30043 again. Yes, it passes all tests.

	And when I now patch perl.h with 30044 straight forward and compile perl
	again and install it and then fforce test Verilog::Language? Then it too
	passes all tests!

	Does ./installperl not overwrite perl.h??? It does overwrite it.

	CCACHE to blame? No CCACHE_DISABLE makes no difference.

	Something within Verilog must be broken too. It's a preprocessor. It may
	parse header files and draw conclusions.

	Let me repeat:

	30043: ok
	30044: not ok
	30333: not ok

	Apply diff 43:44 to 30043: still ok
	apply diff 44:43 to 30333: still not ok

	So *something* between perl and Verilog does not notice the perl.h
	change and remains in the state it had on the very first compile. Maybe
	this something even survives make clobber.

	"regen" or some such?

	apply diff 44:43 to 30333 and regen: still not ok

	Remove the old 30044 and build one with buildaperl from scratch, no
	extra patching:

	30044: ok

	!!!!! something must have gone wrong when building 30044 the first time,
	so the binary search went wrong too and I was hunting the wrong diff for
	many hours.

	Maybe there is still a race condition in binsearchaperl?

	Remember: if a binary search brings a result that raises doubts, remove
	both perls from installed-perls and their build directory as well and
	rerun the binary search.

	This is even true if there is NO race condition within binsearchaperl.
	It's always possible that some third party installed something that
	disturbs the binary search, like say Carp.pm

	So I start the next binsearch since 30044 now is OK and it diagnoses
	3006{4,7} as the threshold and I decide immediately to remove 30067 to
	run the next binsearch. And it jumped only forward and decided now it
	would be between 3007[26]. It's very clear now that it is not bleadperl
	but some other module that is used by vppp.

	LATER. I must delay further analysis because this can take a long time.


2007-02-16  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Talk: convert a megainstall file to HTML with <pre> and <span
	class="XXX"> and many anchors so that we can jump directly into it. Then
	make HTML slides that jump into that file and into the distroprefs files
	which may need converting too for best lettersize.

	Interestingly, when I do this, rendering of the resulting HTML file is
	too much work for my firefox on linux/Dell/500 MHz. The MacBook is
	several orders of magnitude faster but still a bit painful.

	* in the talk, compare dot distros with pip and Inject.

	* read CPAN::Inject and CPAN::Mini::Inject manpages

	straightforward and modest. No index support, so only distribution
	support.

	* read pip manpage:

	Wow: http://svn.phase-n.com/svn/cpan/trunk/pip invitation to write
	directly to it. But nobody gives me the clue howto follow this
	invitation. It *is* subversion. Ah, two levels higher we have the
	paragraph

	    To access the repositories above via Subversion, browse to the
	    location in the repository you want via your web browser and then
	    use that URL with your favorite Subversion client tool. You may
	    asked to enter your username and password for access to any
	    restricted repositories.

	Indeed, I can do

	    % svn co http://svn.phase-n.com/svn/cpan/trunk/pip/ ./

	and when I want to check in, it asks me for username and password. But
	it speaks only http, so no way to use that seriously. No contact address
	on that page either except for a link to the Michael.Sinz homepage.

	Typos: "is available is", "guarentee"

	Missing example of a p5i file in the manpage.

	Ahh, now I understand how it works. Authentication does not go via pause
	(I watched the logfile while logging in with wrong password) but every
	author must get a password from adam directly. So that's OK. It's just
	misleading to say

	    Write access to the repository is made available automatically to
	    any published CPAN author, and to most other volunteers on request.
	
2007-02-15  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* I'm guilty to not have mentioned Devel::Size when we were talking
	about releasing 5.10. It's gone broke when? 29544: Eliminate PVBM

	We need something like this which is from a patch by Nicholas for
	Clone.xs:

+#if PERL_VERSION <= 8
       case SVt_PVBM:   /* 8 */
+#endif

	FIXED in http://rt.cpan.org/Ticket/Display.html?id=24982 and distroprefs.

	* I just discovered that CPAN::Reporter does not work with 5.8.0 because
	IO::CaptureOutput does not either.

2007-02-13  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* My tests usually are run with perls that are pretty well equipped with
	modules. I should always test with a minimum perl installation. We need
	to provide one. Let's nominate a funny number. 30123.

	31sessions test succeeds with this.

	BUT if I remove Archive::Tar and Compress::Zlib, then it fails. Wonderful.

	FIXED around SVK rev. 1913

	* Today with 30254 I observed HTML::Mason test failure, but only once:

t/10-cache....................
#   Failed test 'cache_self_expire_in'
#   at /home/k/.cpan/build/HTML-Mason-1.35-ecRYhh/blib/lib/HTML/Mason/Tests.pm line 593.
# Looks like you failed 1 test of 20.
dubious
	Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 6
	Failed 1/20 tests, 95.00% okay

	When I started a binary search this same perl succeeded with all tests.
	Go figure.

	* From Adam K:

 > Ahhh, yes...'reload index' was the key for me.  Unfortunately, I had a
> very stale mirror (ibiblio.org) as my first site.  I then repopulated
> my cpan site list based on info from http://www.cs.uu.nl/people/henkp/
> mirmon/cpan.html and thought my index would get updated automatically.

Andreas

This is the issue I was talking about before, with regards to mirror
changes.

We should probably always flush non-archival files when the mirror changes.

	FIXED in SVK rev. 1903

	* Bug: Template-Plugin-Number-Format-1.01 declares prerequisite
	Number::Format with version undef (real undef, not the String undef) and
	it does not get installed before the tests happen. I need a random perl
	that has neither T:P:N:F nor Template nor N:F.

for p in `binsearchaperl --show-cache --bounds 30000-99999 --apcdir /home/src/perl/repoperls/APC --prefix /home/src/perl/repoperls/installed-perls` ; do
  $p -e 'for my $p (qw(Template::Plugin::Number::Format Number::Format Template)){
    eval qq{require $p};
    print $@ ? "-" : "+";
  }
  print $^X, "\n"'
done

	Gives 30192.

	FIXED in SVK rev. 1902

2007-02-12  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

2007-02-10  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Unicode/Map.pm, Spreadsheet/WriteExcel.pm, Jcode.pm are all undeclared
	prereqs of Spreadsheet ParseExcel and prevent binary search. RT is down.
	RT is up again and I added this observation to
	http://rt.cpan.org/Ticket/Display.html?id=24693

	* Bug in APC: the tempdirs that end up in the chache are mode 0700
	instead of 0755. Fixed in APC revision 230

	* Bug in patchaperlup:

Not in MANIFEST: wince/README.perlce.withCR
Not in MANIFEST: wince/registry.bat.withCR
ALERT: Going to remove apparent testfile(s): lib/Text/Balanced/t/00.load.t lib/Text/Balanced/t/pod-coverage.t
Maybe this MANIFEST is broken?
Proceed? (y|n) [y] 

	Fixed in APC revision 229

2007-02-09  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Look after TT 2.17 [...] Not needed, Andy has released 2.18 today YAY!

2007-02-08  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* CPAN::Inject fails with 5.8.9-tobe. I tend to believe this happens
	because 5.8.9 has 1.7602 and C:I needs 1.87. Now what is intimidating is
	that when I run under 1.88_73, then CPAN.pm refuses to install CPAN
	saying that it is up to date. While the installed CPAN.pm is outdated,
	the used CPAN.pm is really uptodate. Aha! force install at its best.

	* Feature request by self: The bad performance of YAML.pm seems to be a
	showstopper. YAML.pm needs to be banned or disabling of YAML operations
	should be possible, don't know exactly how.

	* ----Program----
eval q{use DBIx::Class 0.07005};
print $@ ? "N/A" : "OK";
print "\n";

----Output of .../pBEyrHy/perl-5.8.0@29025/bin/perl----
OK

----EOF ($?='0')----
----Output of .../pgLprwz/perl-5.8.0@29026/bin/perl----
N/A

----EOF ($?='0')----

	t/76joins.......................NOK 6/53
#   Failed test 'join 6 (HASH reference for ON statement dies) ok'
#   at t/76joins.t line 110.
#                   'HASH reference arguments are not supported in JOINS - try using "..." instead' at t/76joins.t line 109
# '
#     doesn't match '(?-xism:^HASH\ reference\ arguments\ are\ not\ supported\ in\ JOINS\ \-\ try\ using\ \\\"\.\.\.\"\ instead)'
t/76joins.......................ok 29/53# Looks like you failed 1 test of 53.  
t/76joins.......................dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 6
        Failed 1/53 tests, 98.11% okay


	https://rt.cpan.org/Ticket/Display.html?id=24349

	Binary search points to 29026.


2007-02-07  Andreas J Koenig  <akoenig@iconmobile.com>

	* Feature request by self (again?): when dieing due to recursion
	detection, please list the demanded version number behind each module
	name. Adjust the test in 30shell.t. DONE

2007-02-07  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug in patchaperlup: the 5.8.0/ directory is breaking concurrency.
	When a process untars a perl before the other one has moved to the
	File::Temp directory, it seems to overwrite something. Binary searches
	and the normal megainstall loop must not run at the same time!

	Fixed in APC revision 231

2007-02-06  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug: I have a tar ball of an already installed bleadperl@28095 with a
	certain mix of outdated modules. When I run upgrade with that perl on
	dev05, then it runs into:

  JPEACOCK/version-0.69.tar.gz
  ./Build test -- NOT OK
Warning (usually harmless): 'YAML' not installed, will not store persistent state
Running Build install
  make test had returned bad status, won't install without force

Recursive dependency detected:
    Archive::Tar
 => K/KA/KANE/Archive-Tar-1.30.tar.gz
 => File::Spec
 => K/KW/KWILLIAMS/PathTools-3.24.tar.gz
 => Module::Build
 => K/KW/KWILLIAMS/Module-Build-0.2806.tar.gz
 => File::Spec.
Cannot continue.
Failed during this command:
 RKOBES/ExtUtils-Command-1.13.tar.gz          : make_test NO Test::Harness too old
 RKOBES/ExtUtils-Manifest-1.51.tar.gz         : make_test NO Test::Harness too old
 KWILLIAMS/ExtUtils-ParseXS-2.18.tar.gz       : make_test NO Test::Harness too old
 KWILLIAMS/PathTools-3.24.tar.gz              : make_test NO Test::Harness too old
 KWILLIAMS/Module-Build-0.2806.tar.gz         : make_test NO Test::Harness too old
 JPEACOCK/version-0.69.tar.gz                 : make_test NO

	As so often, we are missing the required version numbers in the
	dependency graph, so I must ask CPAN.pm manually.

    Archive::Tar
 => K/KA/KANE/Archive-Tar-1.30.tar.gz
 => File::Spec                                        # 0.82 but 3.18 is installed
 => K/KW/KWILLIAMS/PathTools-3.24.tar.gz
 => Module::Build
 => K/KW/KWILLIAMS/Module-Build-0.2806.tar.gz
 => File::Spec.

	Aha. This demonstrates that the recursive dependency detector calculates
	wrong. It does not seem to take into account the minimum required
	version number. Maybe this is all due to the Test::Harness anomaly?

	Can I shorten the path? Trying on k75. If I only ask for 'install
	Archive::Tar', what happens? It gets installed. Same for File::Spec.
	Same for Module::Build. Grrr. And when I say 'upgrade', then it does
	indeed upgrade? Because Expect is not installed we must answer the
	libnet question after a while (which surprises me because it is in
	DD_PREFS) and shortly after that we are facing the same output as
	described above.

	Can this situation then be reproduced after leaving CPAN.pm? Or do we
	have to start from the beginning? 'install version' just fails due to
	'qv.al' and such. The upgrade command now does not reproduce the above
	situation.

	Seems to be FIXED in SVK rev. 1865 or so. There was (1) a variable
	confusion: s/depth/color/ around line 8802 and (2) the need to pull the
	desired version number out again within color_cmp_tmps and to compare
	with what we have available at the moment. (3) we needed a way to
	withdraw quickly when we only set all commandcolors to 0. Not sure if we
	couldn't withdraw much quicker though: isn't recursion detection after
	the command has finished completely bogus? No, it is necessary because
	if we run into recursion it is no fun and we must break it.

	BTW, it's incredible how long it takes to upgrade 28095: more than 30
	minutes.

2007-02-05  Andreas J Koenig  <akoenig@iconmobile.com>

	* Important things I forgot in the talk paper (minus means already written):

	-degraded mode
	-add distribution name to every OK/NOT OK; also inspired by Ilya.
	-mention 'cpan .', compare with pip and Inject stuff
	-mention yaml_module and YAML::Syck earlier
	-build_requires_install_policy
	-scripts installation
	Devel::Cover statistics??? -- not really interesting
	eexpect example -- no, no good example found
	- force/fforce
	- auto_commit
	-	maybe mention Kwalify in the distroprefs section
	- Randy status report
	- patch/applypatch support with example
	- goto example
	- commandline example -- no, too intimidating

	Screenshot of the hosts command

cpan[1]> hosts
CPAN: YAML loaded ok (v0.62)
Log starts: Thu Jan  4 16:26:35 2007
Log ends  : Fri Feb  2 17:14:48 2007

Successful downloads:
   N       kB  secs      kB/s url
   1      504     1     360.3 ftp://ftp.kulnet.kuleuven.ac.be/pub/mirror/CPAN/
   1      501     1     254.7 ftp://ftp.rediris.es/mirror/CPAN/
   2      898     3     252.3 ftp://dl.iskon.hr/pub/CPAN/
   1      125     0     226.4 http://cpan.serveroffice.at/
   2      164     0     218.5 http://cpan.interprovide.de/
   1      501     2     182.8 ftp://cpan.mirrors.skynet.be/pub/CPAN/
   2       72     0     175.1 http://www.planet-elektronik.de/CPAN/
   1      218     1     167.4 ftp://cpan.provocation.net/
   2      309     2     130.9 ftp://ftp.cs.uu.nl/mirror/CPAN/
   1      126     1     119.0 http://cpan.blic.net/
   4      201     1     111.8 http://cpan.org.ua/
   2       43     0     105.6 http://www.chemmedia.de/mirrors/CPAN/
   1      121     1     104.0 ftp://cpan.mirrors.easynet.fr/pub/ftp.cpan.org/
   2      133     1      99.0 http://cpan.univ-paris.com/
   5      555     8      69.3 ftp://ftp.litnet.lt/pub/CPAN/
   2      203     3      59.3 ftp://ftp.flirble.org/pub/CPAN/
   1       88     1      58.6 ftp://ftp.cpan.nl/pub/CPAN/
   2       56     1      56.2 ftp://ftp.cs.tu-berlin.de/pub/lang/perl/CPAN/
   1       34     0      56.0 http://cpan.panu.it/
   1      125     2      55.9 ftp://no-more.kiev.ua/pub/CPAN/

Unsuccessful downloads:
   2 http://cpan.univ-paris.com/
   2 http://www.chemmedia.de/mirrors/CPAN/
   2 http://cpan.interprovide.de/
   2 ftp://ftp.uit.no/pub/languages/perl/cpan/
   2 ftp://gnu.kookel.org/ftp/CPAN/
   2 ftp://ftp.telepac.pt/pub/cpan/
   2 http://cpan.mirror.rokscom.nl/
   2 ftp://ftp.du.se/pub/CPAN/
   1 http://kvin.lv/pub/CPAN/
   1 http://cpan.enstimac.fr/
   1 http://cpan.org.ua/
   1 http://cpan.panu.it/


2007-02-04  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Got another mail from T. Need to close the issue. Better a WONTFIX
	than scenes like those we had on P5P at the end of the 90ies.

2007-02-03  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Feature request by self: introduce a lex TELS that ignores a failing
	Makefile.PL, declares the META.yml as authoritative (for lack of
	alternatives), and reruns the Makefile.PL; we should count how often we
	reran it and give it a final death shot after the second time.

	This solution should fit together with a refined model of the toolchain
	as recently pointed out by Adam Kennedy who said:

1. Configure Dependency
2. Build Dependency
3. Test Dependency
4. Install Dependency
5. Run-Time Dependency

For the current CPAN case, we can consider "requires" to cover
Run-Time Dependency, and "build_requires" to cover all other 4.

Since the Configure Dependency is required to be installed before
configuring, that means that we have to do build_requires before
running our configure script.

	And Schwern recently also said something in this direction.... Where did
	he post something? On P5P:

From: Michael G Schwern <schwern@gmail.com>
Subject: Re: $VERSION string of ExtUtils::MM_Unix
To: John Peacock <jpeacock@rowman.com>
CC: schwern@pobox.com, perl5-porters@perl.org, rgarciasuarez@gmail.com
Date: Sun, 14 Jan 2007 22:46:35 -0800
Reply-To: schwern@pobox.com

John Peacock wrote:
>> I'd say to send the patch, but I don't see the utility when C<$VERSION =
>> '1.23_01'; \n $VERSION = eval $VERSION> works fine and is a lot simpler to
>> maintain.  I remain open to convincing.
> 
> But Damian suggested C<use version; $VERSION = qv('1.2.3');>, which EU::MM isn't
> completely prepared to deal with.  Now that PAUSE has a way to reset the latest
> release, module authors can switch from numeric to extended versions (SVK just
> did that with v2.0.0).  Can EU::MM handle comparing those without version.pm around?

Ah ha, that's a horse of a different color.  This, I presume, is the VERSION_FROM problem?  Distribution Foo's Makefile.PL says "VERSION_FROM => 'lib/Foo.pm'" which says C<use version; our $VERSION = qv'1.2.3';>.  Even if Foo depends on version.pm the CPAN shells try to run the Makefile.PL before it resolves dependencies (something I'd like to change).

Ok, that's convincing.  Send it on.



	Even though I believe this is too complex to be solved in a one day
	timeframe, I'm tempted.

	* How come that I did get the impression that PREREQ_FATAL=0 fixes all
	the TELS distros that set PREREQ_FATAL to 1? Just tried with blead@30104
	and it does not help. At least not with TELS/math/bignum-0.18.tar.gz.

	So maybe I tried them out in the "right" order? Yes, this must have been
	the case. The "right" order seems to be: Math::BigInt, Math::BigRat.

	This means that we discovered a bug in MakeMaker (a
	non-commandline-overrideable parameter) and we need 4 patches for TELS.

	This is about the MakeMaker bug: http://rt.cpan.org/Ticket/Display.html?id=24774

	I'll first ask Tels himself before I go this route. [time passes] As
	expected, Tels is not ready to remove PREREQ_FATAL from his modules.

	* TELS has given all new Math modules the PREREQ_FATAL parameter. Trying
	now to counteract with PREREQ_FATAL=0. Yes, the commandline wins, so
	this gives a new distropref file. Update 2007-02-04: I was wrong.

	But with three big* packages upgraded DateTime::Util::Astro::Sun still fails.

	So when did Astro install successfully for the last time?

	for p in `~k/sources/Perl-Repository-APC/SVN/scripts/binsearchaperl --show-cache` ; do $p -e 'print $^X, $"'; $p tests/has-DateTime-Util-Astro.pl ; done | tee show-astro.out

	ergibt als letztes:
	
	/home/src/perl/repoperls/installed-perls/perl/pGoZsz3/perl-5.8.0@30044/bin/perl 0.040

	and this was:

	-rwxr-xr-x 2 k k 3850309 Jan 28 03:48 /home/src/perl/repoperls/installed-perls/perl/pGoZsz3/perl-5.8.0@30044/bin/perl*

	Running CPAN.pm with 30044:

	cpan[2]> r /big/

Package namespace         installed    latest  in CPAN file
Math::BigFloat                 1.51      1.53  TELS/math/Math-BigInt-1.79.tar.gz
Math::BigInt::FastCalc      0.10_01      0.11  TELS/math/Math-BigInt-FastCalc-0.11.tar.gz
Math::BigInt::GMP              1.18      1.19  TELS/math/Math-BigInt-GMP-1.19.tar.gz
Math::BigRat                   0.15      0.16  TELS/math/Math-BigRat-0.16.tar.gz
bigint                         0.07      0.08  TELS/math/bignum-0.18.tar.gz

cpan[4]> ls TELS/math/*
  172453 2007-01-28 TELS/math/Math-BigInt-1.78.tar.gz
  172135 2007-02-02 TELS/math/Math-BigInt-1.79.tar.gz
   41007 2007-02-02 TELS/math/Math-BigInt-FastCalc-0.11.tar.gz
   37602 2007-01-28 TELS/math/Math-BigInt-GMP-1.19.tar.gz
   34907 2007-01-28 TELS/math/Math-BigRat-0.16.tar.gz
   15933 2007-01-28 TELS/math/bignum-0.18.tar.gz

	I could prove for both bleadperl@30044 and maintperl@29832 that the
	failure is caused by an upgrade to Math-BigInt-1.79. Report written to
	Tels and DMAKI.

	SUMMARIZED at http://rt.cpan.org/Ticket/Display.html?id=24779

2007-02-02  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Tels has quickly released three more distros but
	DateTime::Util::Astro::Sun still fails. No time to investigate.

	* Yves has posted a patch that should fix the XML::Twig failures but the
	pumpkin has not yet reacted. Update 2007-02-04: Steve Peters has
	integrated it, problem solved. YAY!

	* what's the problem with Math::BigInt?

	bleadperl has 1.77, TELS has released 1.78. Running the tests for 1.78
	produces lots of warnings. DateTime::Util::Astro::Sun produces lots of
	failures with it but also when I downgrade to 1.77. Giving up for now.

2007-02-01  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Summary of the facts, also posted to Ken:

(1) perl is bleadperl @30080 (verified again with 30087)
(2) Module::Build is 0.2806
(3) distro is DMAKI/DateTime-Util-Calc-0.11.tar.gz
(4) Math::BigInt::GMP and Math::Pari must NOT be installed, so that y_n() is triggered
(5) I call 'perl Build.PL > /tmp/ttt' and it hangs forever and /tmp/ttt remains empty

	Continuing with experiments.

	Downgrading Module::Build to 0.2805 and the bug stays.
	Downgrading Module::Build to 0.2804 and the bug stays.
	Downgrading Module::Build to 0.2610 and the bug goes away.
	0.2801 not ok
	0.2612 ok
	0.27_09 ok
	0.27_10 ok
	0.28 not ok

	Studying the diff between 27_10 and 28:

+                  repository => 'http://svn.perl.org/modules/Module-Build/'

	Taking note of the repository for refined binary search. But watch out:

	trunk/tags/branches!

-0.27_11  Tue Mar 28 22:50:50 CST 2006
+0.28  Thu Apr 27 22:25:00 CDT 2006

	Where is 27_11?

	5978 is a test, 5977 talks about prompt and y_n, 5871...

	0.28     was 5994
	0.27_10  was 5850

	5870 died on that Build.PL
	5871 works correctly
	5976 works wrong
	5931 works wrong
	5919 works wrong
	5904 works correctly

	The diff between the two is interesting:

+sub _is_unattended {
+  my $self = shift;
+  return $ENV{PERL_MM_USE_DEFAULT} || ( !$self->_is_interactive && eof STDIN );
+}
+

	Sure, this hangs. REPORTED on the mailing list.
	
	* D/DM/DMAKI/DateTime-Util-Calc-0.11.tar.gz again. Ken wrote me to say
	that Module::Build does set $|, so I do the following:

2007-02-01 07:27  cd ~/.cpan/build/DateTime-Util-Calc-0.11-Or71Ir
2007-02-01 07:53  mv /home/src/perl/repoperls/installed-perls/perl/p8FWT5N/perl-5.8.0@30080/lib/site_perl/5.9.5/i686-linux-64int/Math/BigInt/GMP.pm
2007-02-01 07:53  /home/src/perl/repoperls/installed-perls/perl/p8FWT5N/perl-5.8.0@30080/bin/perl Build.PL >| /tmp/p8FWT5N.out2 2>&1

	This "hangs" and the file /tmp/p8FWT5N.out2 contains ONLY the following lines:

Math::BigInt::FastCalc is missing method '_from_oct' at /home/src/perl/repoperls/installed-perls/perl/p8FWT5N/perl-5.8.0@30080/lib/site_perl/5.9.5/DateTime/Util/Calc.pm line 9
Cannot load outdated Math::BigInt::FastCalc v0.10_01, please upgrade at /home/src/perl/repoperls/installed-perls/perl/p8FWT5N/perl-5.8.0@30080/lib/site_perl/5.9.5/DateTime/Util/Calc.pm line 9

	So I must repeat this in the debugger to find out who is waiting for what.

	I reach line 501:

  DB<4> 
Module::Build::Base::prompt(/home/src/perl/repoperls/installed-perls/perl/p8FWT5N/perl-5.8.0@30080/lib/5.9.5/Module/Build/Base.pm:501):
501:      local $|=1;
DB<4> 
Module::Build::Base::prompt(/home/src/perl/repoperls/installed-perls/perl/p8FWT5N/perl-5.8.0@30080/lib/5.9.5/Module/Build/Base.pm:502):
502:      print "$mess $dispdef";
DB<4> x $|
0  1

  So this seems correct.
  
	I change lines 501 and 502 to read:

  local $|=1;{my $s = fileno select;warn "Going to print message to selected filehandle[$s]. \$|[$|]";}
  print "$mess $dispdef";warn "Have printed message to selected filehandle";

	With that I retry and am quite surprised that again the output file
	looks like the first time.

	For my testing it seems better to not redirect STDERR but only STDOUT,
	so we can just look with 'ls -l' to see that the file is empty.

2007-01-30  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* http://rt.cpan.org/Ticket/Display.html?id=24673 Template fails.

	Maybe needs a binary search? DONE and REPORTED.

	* DMAKI/DateTime-Util-Calc-0.11.tar.gz hangs, but I do not see why.

  /usr/bin/patch -N --fuzz=3 -p1
patching file t/04-bigfloat.t
Prepending /home/k/.cpan/build/DBD-SQLite-1.13-PQHMS0/blib/arch /home/k/.cpan/build/DBD-SQLite-1.13-PQHMS0/blib/lib to PERL5LIB for 'make'

  CPAN.pm: Going to build D/DM/DMAKI/DateTime-Util-Calc-0.11.tar.gz


	So I start to believe that Module::Install (or who?) does not set $|. ps
	shows:

k        11717  0.0  0.3   7704  5488 pts/3    S+   00:52   0:00 /home/src/perl/repoperls/installed-perls/perl/peBfNb9/perl-5.8.0@30067/bin/perl Build.PL

	% lsof -p 11717|grep cwd
perl    11717    k  cwd    DIR    9,1    4096 11323846 /home/k/.cpan/build/DateTime-Util-Calc-0.11-oDcgJK

	By killing all jobs involved in this, I can find out more:

>06:31:09 k@k75:/home/src/perl/repoperls% kill 3391 3392 1458 1459 11717
>06:32:02 k@k75:/home/src/perl/repoperls% cd /home/k/.cpan/build/DateTime-Util-Calc-0.11-oDcgJK
>06:32:12 k@k75:~/.cpan/build/DateTime-Util-Calc-0.11-oDcgJK% /home/src/perl/repoperls/installed-perls/perl/peBfNb9/perl-5.8.0@30067/bin/perl Build.PL

================================================================================
+  You don't seem to have neither Math::BigInt::GMP and Math::BigInt::Pari
+
+  Many astronomical calculations require the arbitrary-precision math
+  libraries like GMP. Without it you might see occasional overflows
+  which will result in an incorrect calculation. It is recommended that
+  you install either one of the module (If both are installed, GMP will
+  be used)
+
+  To install GMP, you will be required to have installed GMP library from
+  http://www.swox.com/gmp/ prior to installing the Perl module
+
+  To install Pari, you will be required to have installed Pari from
+  http://www.parigp-home.de/ prior to installing the Perl module.
+
+  Proceed with installation without Math::BigInt::GMP or Math::BigInt::Pari? [n] 

	Why did I never before see this?

	Because Math::BigInt::GMP fails! See
	http://rt.cpan.org/Ticket/Display.html?id=24672

	Whatever the answer, this must go into distroprefs. DONE for both TELS
	and DMAKI.

	In the Build.PL I see:

	    my $proceed = Module::Build->y_n($message, "n");

	Looks to me that Module::Build should set $| within y_n? Yes? No?

	Missing $| reported to module build mailing list just now.

2007-01-28  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* My talk proposal http://www.perl-workshop.de/auth/my/edittalk?id=46

-Distroprefs: Module morphing, taming, killing, obedience, etc.
-CPAN::Reporter: Talkback.
-CPAN::SQLite: use less memory.
-dot distros: cpan DOT (bring your own)
-Persistent Shell. build_dir_reuse
-Permanent Shell. reload seems reliable now
-Upgrade.
-Test Now, Install Later. Is_tested, install_tested
-Interactive Configuration of single items.
-Color.
Bundle::CPANxxl - what is in there? sequence matters.
-hosts stats

	* Feature: On recursive dependency please dump the required version.
	DONE

	* Spreadsheet-ParseExcel-0.28 is broken for quite some time now.

	https://rt.cpan.org/Ticket/Display.html?id=24267 is about missing
	prerequisites. This explains two test failures but not the third:

t/examples/warning......
#   Failed test 'stderr is empty when running warning.pl'
#   at t/examples/warning.t line 10.
#          got: 'Character in 'c' format wrapped in pack at /home/k/.cpan/build/Spreadsheet-ParseExcel-0.28-ddCmVr/blib/lib/Spreadsheet/ParseExcel.pm line 1744.
# Character in 'c' format wrapped in pack at /home/k/.cpan/build/Spreadsheet-ParseExcel-0.28-ddCmVr/blib/lib/Spreadsheet/ParseExcel.pm line 1748.
# '
#     expected: ''
# Looks like you failed 1 test of 2.
dubious
	Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
	Failed 1/2 tests, 50.00% okay

	https://rt.cpan.org/Ticket/Display.html?id=7376 has something about it.

	* hunting XML::Twig/bleadperl test failures again. I started this once
	on 2007-01-06 and yesterday I let a binary search run against 3.29.
	28202 broke 3.29 but only with a test failure that later disappeared
	again, so this result is not interesting. I need a temporary patch that
	disables the testfile t/test_xml_split.t completely. Ah, this is quite
	easy with test/args distroprefs.

	Testing a temporary MIROD.XML-Twig.yml file that lists all test scripts
	individually (except the offending one). And it turns out that this
	functionality was missing in CPAN.pm. FIXED in SVK rev. 1807

	With              28202           the test test_xml_split  started failing
	Somewhere before  28319                    test_xml_split  stopped failing
	With              28319           the test test_errors     started failing
	Somewhere before  28785                    test_errors     stopped failing
  With              28785           the test test_3_27	     started failing
	Somewhere between 29274 and 29285 the test test_mark       started failing

	274 did not fail the mark test

	275 had problems to build XML::Parser, but why? Or better yet, why did
	274 have no problems building XML::Parser 2.34? I just retried, and yes,
	274 can build XML::Parser. 29275 seems to have a syntax error in
	/home/src/perl/repoperls/installed-perls/perl/poKEUxZ/perl-5.8.0@29275/lib/5.9.5/utf8_heavy.pl.
	Yes, it is very annoying, the syntax error is there and cannot be
	explained by anything but a disk drive error (and I had RAID break three
	times these days). It is a rotten build and must be removed.

	278 cannot be built due to two failing tests. We will ignore the failing
	tests ../ext/Time/HiRes/t/HiRes.t ../lib/perl5db.t for now. OK, it does
	not fail the mark test, just the 3_27.

	279 fails the mark test. Ready to write to P5P. And I must correct the
	temporarily manipulated test/args distroprefs file.
	
	285 failed the mark test

	29010 and 29220 have at least test_3_27.t and test_additional.t failing

	29411 and 29705 have at least test_mark failing

	30044 fails only test_3_27	and test_mark
	
	* Slaven tells me that he can confirm the Term::ReadLine::Gnu behaviour
	in the t/callback.t test that I find so annoying for 5.9.5(debugging)
	but not for 5.8.8. I.e. with 5.8.8 the window gets closed automatically
	while with 5.9.5 it stays.

	This would normally be solved with a binary search but as always with
	big distros there are risks. Tk under randomly picked 21846 segfaults
	during make test. Same for 23300.

	25302 dies quickly with

	/home/src/perl/repoperls/installed-perls/perl/pq4nEoU/perl-5.8.0@25302/bin/perl: symbol lookup error: /home/src/perl/tk/SVN/blib/arch/auto/Tk/Event/Event.so: undefined symbol: Perl_newXS_flags

	28810 dies quickly with

	Strange: could not load Tk library: Assertion (svtype)((_svi)->sv_flags & 0xff) >= SVt_PV failed: file "Event.xs", line 33 at /home/src/perl/repoperls/installed-perls/perl/pPOaCtI/perl-5.8.0@28810/lib/5.9.4/i686-linux-64int/DynaLoader.pm line 224.
Compilation failed in require at /home/src/perl/tk/SVN/blib/lib/Tk.pm line 13.
BEGIN failed--compilation aborted at /home/src/perl/tk/SVN/blib/lib/Tk.pm line 13.
Compilation failed in require at (eval 3) line 3.

	and 29411 similarly with

	Strange: could not load Tk library: Assertion (svtype)((_svi)->sv_flags & 0xff) >= SVt_PV failed: file "Event.xs", line 33 at /home/src/perl/repoperls/installed-perls/perl/pXADjKY/perl-5.8.0@29411/lib/5.9.5/i686-linux-64int/DynaLoader.pm line 226.
Compilation failed in require at /home/src/perl/tk/SVN/blib/lib/Tk.pm line 13.
BEGIN failed--compilation aborted at /home/src/perl/tk/SVN/blib/lib/Tk.pm line 13.


	* Speed things up by reading distroprefs less often or otherwise find
	out who is so slow here. What happens between 'Running make for
	<distro>' and 'Checksum for <distro> ok'? Time is spent in get(). Even
	though we now do negative caching of distroprefs for the time of one
	command, the get() is still slower for some reason. SEEMS AMENDED

	* if somebody else deletes a build_dir, we must offer a better solution
	than breakage 'can't chdir...'

	Suggest "maybe try 'force get $ID' to clean up the object in memory" or
	something like that. Or "to reset everything" or "to start with a fresh
	distro"... Nothing seems really good and correct. DONE

	* Catalyst would be another candidate for a large dependency list. INC'ED

	* hr ================ no todos below this line ================ /hr

	* hr ================ no todos below this line ================ /hr

	* hr ================ no todos below this line ================ /hr

	* Bug: batch jobs scan for sizes although they never delete anything. So
	either teach them to delete under certain conditions or do not scan for
	sizes. FIXED

	* Bug: "faileTAB" does not do completion

	Fixed in SVK rev. 1806

	*  NEELY/Data-Serializer-0.36.tar.gz            : make_test NO

	This distro appeared these days on the make_test-NO scene. But when I
	look closer, it turns out that it fails with the pretty old bleadperl
	22491.

2007-01-27  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* what's going on with JHOBLITT/DateTime-Format-ISO8601-0.0403.tar.gz?

	rt.cpan.org has the solution in ticket 24335. Patch by Aaron Crane (=ARC)

	Aaron's patch cannot be copy and pasted because of some whitespace
	problems. So I try to apply it manually.

	======================Dealing With Patches==================

	My procedure when I encounter a broken package:

    look DISTRO
    cd ..
    rsync -va DISTRODIR/ DISTRODIR.orig/
    # fix the distro in DISTRODIR
    diff -urp DISTRODIR.orig DISTRODIR > DISTRODIR-ANDK-01.patch
    gzip DISTRODIR-ANDK-01.patch

	I then upload the resulting patch to my CPAN patches/ directory and
	write a YAML file into my prefs_dir/ directory that contains roughly

    ---
    comment: "This patch fixes ..."
    match:
      distribution: "^DISTRO$"

    patches:
      - ANDK/patches/DISTRODIR-ANDK-01.patch

	That's all. From then I can install that distro for any perl version on
	that machine.

	Uploaded to CPAN and a new distropref file is made.
	
	* yesterday I built maintperl 29988 and somehow megainstall failed with
	Jifty-DBI asking auto-install questions. I suppose the question was
	asked by a different perl and an old CPAN because I do have a Jifty-DBI
	distropref file that should prevent questions asking.

	NO! The malfunctioning started exactly at 23:40 when the disk also
	started failing. So I suppose we can simply restart a megainstall on
	29988 now.

	No. Still hanging. No signs of being the wrong perl. Trying with 'make run'.

______________________ D i s t r o P r e f s ______________________
                      AUDREYT.Jifty-DBI.yml[0]                      
Running make for A/AU/AUDREYT/Jifty-DBI-0.32.tar.gz
  Has already been unwrapped into directory /home/k/.cpan/build/Jifty-DBI-0.32-LUlvH7
  '/home/src/perl/repoperls/installed-perls/maint-5.8/pLUMXwK/perl-5.8.0@29988/bin/perl Makefile.PL' returned status 2, won't make

	'fforce make ...' first scans the build_dir for sizes which takes a
	while, maybe the resync of the RAID is slowing it down. After that the
	distroprefs mechanics answer the auto-install question(s).

	But 'test Jifty::DBI' fails some tests. It tests many dependencies, so
	let's look at the summary:

  AUDREYT/Jifty-DBI-0.32.tar.gz
  /usr/bin/make test -- NOT OK
Failed during this command:
 JHOBLITT/DateTime-Format-ISO8601-0.0403.tar.gz: make_test NO
 AUDREYT/Jifty-DBI-0.32.tar.gz                : make_test NO

cpan[4]> is_tested 
Sat Jan 27 06:08:02 2007 /home/k/.cpan/build/FreezeThaw-0.43-MyeZXx
Sat Jan 27 06:08:07 2007 /home/k/.cpan/build/DBIx-DBSchema-0.31-Wrf6R4
Sat Jan 27 06:08:17 2007 /home/k/.cpan/build/Lingua-EN-Inflect-1.89-8UYDiB
Sat Jan 27 06:08:36 2007 /home/k/.cpan/build/Cache-Simple-TimedExpiry-0.27-rznB3I

	Ahja, just the normal autoinstall misbehaviour. Because something
	failed, it tries to go into recursion. My normal patch
	ANDK/Module-AutoInstall-in-inc-ANDK-01.patch seems to take the
	appropriate amount of care for that.

2007-01-26  Andreas J Koenig  <akoenig@iconmobile.com>

	* document build_requires and when you talk about prerequisites, name
	the option names explicitly. DONE

	* note/explain the improved behaviour on recursion detection in the
	Changes file. DONE.

	* Today I found a bug in Tk::Pod when trying with bleadperl:

	/..../tkpod -I lib CPAN

	Need to have a closer look some day.

	A test script also failed but I installed it with 'force notest install
	Tk::Pod' because I had more interest in getting _71 out.

	Sent a patch to Slaven today which commented out an else in line 190 or
	so.

2007-01-26  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* bug: 'fforce instTAB' doesn't do completion.

	FIXED in SVK rev. 1762

2007-01-23  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Today I also saw an uninstallable IO::AIO 2.32: the AIO.pm file was
	not found within blib although it was there in blib/lib/IO/IO/AIO.pm.
	Who is playing a false game? Diff between 3.31 and 2.32 shows:

+    PM           => {
+                   'AIO.pm'            => '$(INST_LIBDIR)/IO/AIO.pm',
+                    },

	Bug fixed and reported to Marc:

--- Makefile.PL~	2007-01-22 16:58:24.000000000 +0100
+++ Makefile.PL	2007-01-23 08:04:38.000000000 +0100
@@ -61,7 +61,7 @@
     VERSION_FROM => "AIO.pm",
     LIBS         => ['-lpthread -lrt', '-lpthread', '-lpthreads', ''],
     PM           => {
-    		    'AIO.pm'		=> '$(INST_LIBDIR)/IO/AIO.pm',
+    		    'AIO.pm'		=> '$(INST_LIBDIR)/AIO.pm',
                     },
     clean        => { FILES => "autoconf/config.h autoconf/config.log autoconf/config.status" },
 });


	* Today I saw this:

cpan[15]> install Coro
Running install for module 'Coro'
Running make for M/ML/MLEHMANN/Coro-3.41.tar.gz
  Has already been unwrapped into directory /home/k/.cpan/build/Coro-3.41-xlIZvI
  Has already been made
Running make test
  Couldn't chdir to '/home/k/.cpan/build/Coro-3.41-xlIZvI': No such file or directory
Running make install
  make test had returned bad status, won't install without force

	This was already somewhere in my Todo list: give up objects in memory
	that cannot fulfil some promise or at least offer the solution which is

	fforce install Coro # but no, this is not an appropriate suggestion

	Or remove the objects from memory while CacheMgr is running. Or both! If
	we delete it ourselves, the deletion from memory is appropriate

  --DONE in ~ SVK rev. 1760 --

	but if somebody else deletes it we must offer a better solution than the
	above breakage.

	Suggest "maybe try 'force get $ID' to clean up the object in memory" or
	something like that. Or "to reset everything" or "to start with a fresh
	distro"... Nothing seems really good and correct. LATER
	
	* Today Ken confirmed that _build/prereqs is safe to rely on. Good news,
	Thanks Ken!

	* Todo before 71: write a Changes file. Declare YAML::Tiny not supported
	DONE; support is_tested and install_tested and document them (DONE SVK
	rev 1763); integrate the distroprefs README into the manpage (DONE SVK
	rev. 1766); speed up distroprefs parsing with a cache DONE in SVK rev.
	1764;

	It would be nice to understand the failures that were reported through
	testers and the one I saw on my dev05 box and the ones I saw on OSX but
	it will again be a developer release after all, so maybe these will have
	to wait.

	The test failure on dev05 is not reproducable. OSX?

	OSX passes all tests with my first _71 test build.
	
	* Today I tried 1.88_69 on OSX wit 5.8.6 as it comes preinstalled.
	File::HomeDir has issues and I could not use CPAN::Reporter to write a
	report because it said there was no config file. Will have to revisit
	this.

	* For several days I have kept Kwalify out with dontload_list. Today I
	opened the door again and let 29923 work through megainstall. All's
	well.

2007-01-21  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* We need a speedup of the distroprefs stuff. Currently we're going
	through readdir and YAML::Load thousand times per module. We should
	probably cache the whole directory structure once per command and delete
	it from re-used build_dirs. DONE with negative per-command distroprefs
	cache.

2007-01-20  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Today I have a segv with 29895 when running CPAN.pm. It may be
	relevant that I erroneously left YAML::Tiny configured? I reconfigured
	to prefer YAML::Syck and ... the SEGV remains. Configuring limit
	coredumpsize 100m now. The SEGV seems to bring the box to its knees and
	the logfile of the first run of 29895 says 'Out of memory'. And the core
	file is indeed 100m and has no stack. Setting coredumpsize to 1000m now.
	The problem comes immediately after loading Kwalify 1.13

	29887 was the last before 895 and its logfile is large. It came to the
	place where it loaded YAML::Tiny and from there is broke but not with a
	SEGV. So something between 29887 and 29895 is evil. How ironic that most
	of these patches are related to CPAN.pm!

	The newest core file is 1000M large, gdb needs a long time to load it
	and again says "No stack" when I say 'bt'.

	Next idea is to 'o conf dontload_list push Kwalify'. Now we get a step
	further. CPAN tries to install Archive::Zip, then becomes very slow,
	grows to 55M and then starts scanning build_dir for sizes. From that
	point it succeeds in building and installing, just a bit slow it seems,
	but this may be just the normal distroprefs slowness. Bundle::CPANxxl is
	installed now and megainstall is running. After a while I discover that
	I made a typo for yaml_module and said YAML::Sync. Of course this leads
	to slowness. Interesting mistake though, we might want to guard against
	it. 'make megainstall' finishes just as we're used to.

	FirstTime warns on misspelled module names since SVK rev. 1761.

2007-01-15  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* DBIx::Class has DBD::SQLite as build_requires. Thus it is being built,
	not installed and CPAN::SQLite does not demand it as prerequisite
	because it finds it (?) but then the install_driver fails during the
	tests. Weird.

	As a first alternative I try to install DBD::SQLite explicitly
	immediately before CPAN::SQLite.

	* See the two fails on CPAN testers for 1.88_69!

	They are both MSWin32 and 397036 is 5.8.5 and fails

t/31sessions.......dubious
	Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED tests 10-11, 14, 22, 26
	Failed 5/30 tests, 83.33% okay

	Output impossible to read

	398304 is 5.8.8 and fails

t/31sessions.......# DEBUG: name[first]system["C:\strawberry-perl\perl\bin\perl.exe" "-IC:\strawberry-perl\.cpanplus\5.8.8\build\CPAN-1.88_69\t" "-Mblib" "-MCPAN::MyConfig" "-MCPAN" "-e" "@CPAN::Defaultsites = (); shell" > test.out] at t/31sessions.t line 147.

#   Failed test 'command[dump $::x=4*6+1]'
#   at t/31sessions.t line 162.
#                   'Lockfile removed.
# '
#     doesn't match '/= 25;/'
Use of uninitialized value in pattern match (m//) at t/31sessions.t line 162.


	It seems there is no output at all to parse.

	* Look into YAML::Tiny; doesn't seem to work. We need a better catch on
	the problem it is causing: currently I do not see where it is failing.

2007-01-14  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* learn something new every day: less -R preserves the ANSI color
	sequences. Best way to analyse the captured output.

	* maint@29776 breaks DBI, need to check with 29802. Failure mailed to
	P5P. Fixed by Nicholas.

2007-01-13  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* And the next new bug: again an endless loop between PDF::FromHTML and
	XML::Twig. I'm not sure in which state CPAN.pm was when this run
	started, so I rerun from scratch with 29779 and stop the usual loop.

	No, the bug is there. The distro of PDF::FromHTML is the next on the
	loop and it depends on XML::Twig. The latter fails its tests but
	nonetheless re-queing is done. Instead of simply continuing with normal
	business because we do not need to requeue. What a mess.

	OK, sure, by removing the "next" for sponsored modules we gave the
	option that things get requeued that have failed. Should also have an
	easy fix.
	
	Tomorrow: megainstall with maintperl@29776, blead@297{79,80}, etc.

	(aside: the stupid thing about dot distros is that they are being
	needlessly rerun)

	Maybe write a failed_within_this_command() method?

	Is it true that batch jobs scan for sizes and then do not delete
	anything from build_dir? It seems so. My first 'make run' after a while
	faces 3.3 GB and in all batch jobs I saw the dot painting "for sizes".

	(The last successful testshell protocol I have with Expect on is
	make-test-20061230T172249.)

	30shell fails and it is again hard to find the offending test. Another
	proof that new tests must go into 31sessions.t. But 31session does not
	finish. Easily reproducable by trying to install
	CPAN::Test::Dummy::Perl5::Make::CircDepeOne

	It seems that the recursion detection is now broken. We reach the limit
	of 100 in CPAN::Queue which should never be reached. If I say ^C there,
	then I see a seemingly endless loop of "Has already been...". Somehow we
	seem to bypass the color_cmd_tmps.

	It seems that everybody who puts something onto the queue is responsible
	for calling color_cmd_tmps? How silly if true :-( But it seems that we
	*are* calling color_cmd_tmps before jumpqueue in follow_prereqs. Yes,
	but we call it with $color=1 and this has already been called before we
	had the prereqs and so it returns early. We probably must call it with
	$color=2? How obfuscated if true :-( Yes, and by calling with $color=2
	and preventing an early return of all color_cmd_tmps when $color==2 I
	start to pass on 31sessions.t. Recursion detection is now even faster,
	we do not even arrive at testing which I consider a good thing.

	But it comes at a price. The disadvantage is that it is a die() and the
	usual "Failed during this command" gets lost. So what do we want?

	The result in older versions was:

Recursive dependency detected:
    CPAN::Test::Dummy::Perl5::Make::CircDepeOne
 => A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeOne-1.00.tar.gz
 => CPAN::Test::Dummy::Perl5::Make::CircDepeThree
 => A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeThree-1.00.tar.gz
 => CPAN::Test::Dummy::Perl5::Make::CircDepeTwo
 => A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeTwo-1.00.tar.gz
 => CPAN::Test::Dummy::Perl5::Make::CircDepeOne.
Cannot continue.
Failed during this command:
 ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeTwo-1.00.tar.gz: make_test NO one dependency not OK (CPAN::Test::Dummy::Perl5::Make::CircDepeOne)
 ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeThree-1.00.tar.gz: make_test NO one dependency not OK (CPAN::Test::Dummy::Perl5::Make::CircDepeTwo)
 ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeOne-1.00.tar.gz: make_test NO one dependency not OK (CPAN::Test::Dummy::Perl5::Make::CircDepeThree)

	Looking at that again it appears not a very clever answer because the
	"Failed" summary does not talk about the recursion detection. I think I
	prefer the die().

	On the other hand we need to help people in this situation and 'look
	Foo' should not fail because of recursion. This is easily fixable: we
	simply call color_cmd_tmps only for "make|test|install".

2007-01-12  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Hunting bugs. The first reliable way to produce the needless loop
	CBuilder<->File::Spec was to install a fresh maintperl@19726 and make
	mega_install on top. It takes a while. I need a quicker way better yet a
	testcase.

	The next best program which still runs for a long time is

	/home/src/perl/repoperls/installed-perls/*/p*/perl-5*@29726/bin/perl -Ilib -MCPAN -e 'CPAN::HandleConfig->load;$CPAN::DEBUG|=16;$CPAN::DEBUG|=32;$CPAN::DEBUG|=32768;install(qw(Expect Bundle::CPANxxl))' >& ttt.out

	Unfortunately this reproduces it only once. Fortunately I now understand
	the problem: CBuilder comes with a perfectly well suited Build.PL and
	with a Makefile.PL. My prefer_installer says "MB". But when MB is not
	yet installed, this must not be taken seriously. The bug is that CPAN.pm
	actually tries to execute the Build.PL and fails and then refuses to
	retry. This should have an easy fix in get() and now I believe, a
	testcase for this might be a bit too hard given that Module::Build will
	be in the core soon.

	I think I fixed it.

	Now I'm curious how this influences the Zlib bug. The endless loop
	problem was, after all, a completely separate bug, uniq to the situation
	described above. So I can remove the "next" in the sponsored_modules
	loop and expect that it delays the testing of Compress::Zlib?

	I seem to see a new bug now: CPAN::Reporter builds, tests, installs and
	immediately tests again. --> another investigation necessary

	But yes, the other bug is now also fixed by removing the "next" hack.

2007-01-10  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug: recursive dependency ExtUtils::CBuilder <-> File::Spec

	CPAN.pm gave me this puzzle today when trying to build on top of 5.8.9-tobe

  Recursive dependency detected:
      ExtUtils::CBuilder
   => K/KW/KWILLIAMS/ExtUtils-CBuilder-0.18.tar.gz
   => File::Spec
   => K/KW/KWILLIAMS/PathTools-3.24.tar.gz
   => ExtUtils::CBuilder.
  Cannot continue.

	But File::Spec 3.12 is installed, so the recursive dependency should be
	breakable.

	AND the dump command should not fail under recursive dependency.

	Interstingly, the problem went away without special intervention. I
	remember now that I have seen it before and that it disappeared. Hrm.

	* Bug: 5.8.9 cannot install Compress::Zlib 2.003

	----      PMQS/Compress-Zlib-2.003.tar.gz     ---- (0)
    IO::Compress::Gzip::Constants [requires]
    IO::Uncompress::Base [requires]
    IO::Compress::Base [requires]
    IO::Uncompress::Gunzip [requires]
    IO::Compress::Gzip [requires]
    Compress::Raw::Zlib [requires]
    IO::Compress::Base::Common [requires]

	[[[
    IO::Compress::Gzip::Constants PMQS/IO-Compress-Zlib-2.003.tar.gz (1)
    IO::Uncompress::Base          PMQS/IO-Compress-Base-2.003.tar.gz (2)
    IO::Compress::Base            PMQS/IO-Compress-Base-2.003.tar.gz (2)
    IO::Uncompress::Gunzip        PMQS/IO-Compress-Zlib-2.003.tar.gz (1)
    IO::Compress::Gzip            PMQS/IO-Compress-Zlib-2.003.tar.gz (1)
	  Compress::Raw::Zlib           PMQS/Compress-Raw-Zlib-2.003.tar.gz (3)
    IO::Compress::Base::Common    PMQS/IO-Compress-Base-2.003.tar.gz (2)

  (1)
----    PMQS/IO-Compress-Zlib-2.003.tar.gz    ----
    IO::Uncompress::Base [requires] (2)
    IO::Compress::Base [requires]   (2)
    Compress::Raw::Zlib [requires]  (3)

	(2) PMQS/IO-Compress-Base-2.003.tar.gz (OK: 44923)

	(3) PMQS/Compress-Raw-Zlib-2.003.tar.gz (OK: 45150)

	(1) PMQS/IO-Compress-Zlib-2.003.tar.gz (OK: 45329)
	
	(0 in 45401) Won't repeat unsuccessful test during this command
	
	]]]


43878:	[0mmake[1]: Entering directory `/home/k/.cpan/build/Compress-Zlib-2.003-z0UL8v'
PERL_DL_NONLAZY=1 /home/src/perl/repoperls/installed-perls/maint-5.8/prPS0AD/perl-5.8.0@29726/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/000prereq.....
#     Failed test (t/000prereq.t at line 46)
#     Tried to use 'Compress::Raw::Zlib'.
#     Error:  Can't locate Compress/Raw/Zlib.pm in @INC (@INC contains: t t/compress /home/k/.cpan/build/Compress-Zlib-2.003-z0UL8v/blib/lib /home/k/.cpan/build/Compress-Zlib-2.003-z0UL8v/blib/arch /home/src/perl/repoperls/installed-perls/maint-5.8/prPS0AD/perl-5.8.0@29726/lib/5.8.8/i686-linux-64int /home/src/perl/repoperls/installed-perls/maint-5.8/prPS0AD/perl-5.8.0@29726/lib/5.8.8 /home/src/perl/repoperls/installed-perls/maint-5.8/prPS0AD/perl-5.8.0@29726/lib/site_perl/5.8.8/i686-linux-64int /home/src/perl/repoperls/installed-perls/maint-5.8/prPS0AD/perl-5.8.0@29726/lib/site_perl/5.8.8 .) at (eval 3) line 2.

	Why does it try testing C-Z too early? Could we convince CPAN.pm to
	retry testing in 45401? Dump its state at both points in time?

	Update 2007-01-11 akoenig : Found a "next" at the end of unsat_prereq
	that skipped already sponsored modules. Removed it because it looks as
	if it were responsible for the above bug. After that the infinite
	recursion problem between CBuilder and File::Spec dominated the next run
	and the normal recursion detection mechanism did not help to break the
	loop. To put the bad to the ugly it turned out that the recursion
	between CBuilder and File::Path is a wrong recursion in that the
	available version of File::Spec in 5.8.9 is 1.12 and CBuilder does not
	specify a version number, so is really satisfied with 1.12 but somebody
	else seems to require 1.19 and so CPAN.pm is hunting for that without a
	real reason. So we have a big bug here and no time to fix it.

	See also the "next WHAT" in CPAN::Queue::jumpqueue. If we keep it, we
	keep the queue at 100 instances of File-Spec-XXX.tar.gz without growing.
	If we remove it, the queue grows. Both cases are infinite loops, so
	neither better than the other.

2007-01-09  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Watch the Module::Build space for updates to the question of calling
	M:B methods or parsing _build/*. Ken seemed to argue for the file (?)

	FINI

2007-01-08  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Todo: distroprefs mechanism is still inefficient in that it scans too
	often the whole distro_dir. (But it's super to have that while
	developing new rules). And it's a drag especially when people have only
	YAML and no YAML::Syck because they were not told or have no compiler or
	whatsoever. Or revisit the caching mechanism for the YAMLs and count the
	actual YAML activities.

	Also, reduce the default max counter for FTPstats to 1000 or 14 days or
	so and make it settable.

	* The speed factor that I wrote about a few times recently is due to the
	YAML::Syck being 100 times faster than YAML. Whenever for some reason
	YAML::Syck is missing, the whole CPAN.pm feels like running on a 386
	whatever we are doing, because we now have too many tasks delegated to
	YAML format. What to do?

	* 00.README into the manpage now? DONE

2007-01-07  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug: I say 'force test JHOBLITT/DateTime-Format-ISO8601-0.0403.tar.gz'

	and I see (with the usual noise around) in essence:

----    Unsatisfied dependencies detected during    ----
---- JHOBLITT/DateTime-Format-ISO8601-0.0403.tar.gz ----
    DateTime::Format::Builder [requires]
Running test for module 'DateTime::Format::Builder'
----    Unsatisfied dependencies detected during   ----
---- DROLSKY/DateTime-Format-Builder-0.7807.tar.gz ----
    Class::Factory::Util [requires]
    Params::Validate [requires]
    DateTime::Format::Strptime [requires]
Running test for module 'Class::Factory::Util'
  DROLSKY/Class-Factory-Util-1.6.tar.gz
  /usr/bin/make test -- OK
  DROLSKY/Params-Validate-0.86.tar.gz
  /usr/bin/make test -- OK
----   Unsatisfied dependencies detected during   ----
---- RICKM/DateTime-Format-Strptime-1.0700.tar.gz ----
    DateTime::TimeZone [requires]
    DateTime::Locale [requires]
    Params::Validate [requires]
---- Unsatisfied dependencies detected during ----
----   DROLSKY/DateTime-TimeZone-0.57.tar.gz  ----
    Class::Singleton [requires]
    Params::Validate [requires]
  ABW/Class-Singleton-1.03.tar.gz
  /usr/bin/make test -- OK
  DROLSKY/DateTime-TimeZone-0.57.tar.gz
  ./Build test -- OK
---- Unsatisfied dependencies detected during ----
----    DROLSKY/DateTime-Locale-0.33.tar.gz   ----
    Params::Validate [requires]
  DROLSKY/DateTime-Locale-0.33.tar.gz
  ./Build test -- OK
  RICKM/DateTime-Format-Strptime-1.0700.tar.gz
  /usr/bin/make test -- OK
  DROLSKY/DateTime-Format-Builder-0.7807.tar.gz
  ./Build test -- OK

	and after that: nothing. So the one we try to test does not get tested
	but all prerequisites run their tests.

cpan[12]> _is_tested
Sun Jan  7 08:05:21 2007 /home/k/.cpan/build/Class-Factory-Util-1.6-UVh2sJ
Sun Jan  7 08:05:23 2007 /home/k/.cpan/build/Params-Validate-0.86-kpMMto
Sun Jan  7 08:05:26 2007 /home/k/.cpan/build/Class-Singleton-1.03-HaqjYP
Sun Jan  7 08:05:50 2007 /home/k/.cpan/build/DateTime-TimeZone-0.57-Cg2NcL
Sun Jan  7 08:06:12 2007 /home/k/.cpan/build/DateTime-Locale-0.33-dSVn8d
Sun Jan  7 08:06:18 2007 /home/k/.cpan/build/DateTime-Format-Strptime-1.0700-6B7q6N
Sun Jan  7 08:06:31 2007 /home/k/.cpan/build/DateTime-Format-Builder-0.7807-VYcgLN

	This _is_tested command is wonderful. It show me that the bug is not in
	the is_tested area but in the unsatisfied part and I find the spot where
	inst_{file,version} was used instead of available_{file,version}

	FIXED in svk rev 1703.

2007-01-06  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	*  JHOBLITT/DateTime-Format-ISO8601-0.0403.tar.gz

	broke between 20061212T0332 (29527) and 20061213T1101 (29542)

	But when I visit 29527 I see many prerequisites were missing. Including
	Params::Validate.

	Installing YAML::Syck and then using 'fforce test
	JHOBLITT/DateTime-Format-ISO8601-0.0403.tar.gz' brings me an endless
	loop between DateTime-0.35, DateTime-Format-Builder, Class-Factury-Util,
	DateTime, Params-Validate. And is_tested grows and grows and grows.

	FIXED in rev 1703.

	* blead@28810 did not compile YAML 0.62? Did we know that? That was
	September. Is something more broken than just bleadperl? In any case I'm
	surprised that 28810 has had no YAML.pm. So I should simply run through
	whole cache and see at which time I started to build Bundle::CPAN on all
	bleads. Do not forget, we're now using ccache:

	       CCACHE_DISABLE
              If  you  set the environment variable CCACHE_DISABLE then ccache
              will just call the  real  compiler,  bypassing  the  cache  com-
              pletely.

	No, the 'dont_load_list' is preventing YAML to be loaded at the moment.

	* Release the bundles that are already rewritten for a while DONE

	* Todo: make auto_commit a mandatory attribute. DONE in rev 1706

	* XML::Twig 3.28 is out and fails with 29705

t/test_3_27.t               82    3  8-10
t/test_mark.t  255 65280    48    4  47-48

	% make test TEST_FILES="t/test_3_27.t t/test_mark.t " TEST_VERBOSE=1
[...]
ok 6
ok 7
not ok 8
trigger on e1[@#a]/b: expected 'b1b1', got 'b1'
Use of uninitialized value $got in string eq at t/tools.pm line 18.
not ok 9
Use of uninitialized value $got in concatenation (.) or string at t/tools.pm line 29.
trigger on e1[@#a]: expected 'e1-1', got ''
not ok 10
trigger on e1[!@#a]: expected 'e1-2', got 'e1-1e1-2'
ok 11
ok 12
[...]
t/test_mark....Assertion rx->sublen >= (s - rx->subbeg) + i failed: file "regcomp.c", line 4695 at /home/k/.cpan/build/XML-Twig-3.28-4ey2uH/blib/lib/XML/Twig.pm line 6385, <DATA> line 24.
1..48
[...]
ok 45
ok 46
dubious 
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 47-48
        Failed 2/48 tests, 95.83% okay


	Binary search is harder than ever because of different things in
	different blead versions.

	This happens with 28210:

t/test_wrapped......................ok                                       
t/test_xml_split....................xml_split compilation: 
t/test_xml_split....................NOK 1/18xml_merge compilation:           
t/test_xml_split....................ok 3/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58.
xml_merge  t/test_xml_split.xml: false
t/test_xml_split....................NOK 4/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 1.
xml_merge -i t/test_xml_split.xml: false
t/test_xml_split....................NOK 6/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 2.
xml_merge  t/test_xml_split.xml: false
t/test_xml_split....................NOK 8/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 3.
xml_merge -i t/test_xml_split.xml: false
t/test_xml_split....................NOK 10/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 4.
xml_merge  t/test_xml_split.xml: false
t/test_xml_split....................NOK 12/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 5.
xml_merge -i t/test_xml_split.xml: false
t/test_xml_split....................NOK 14/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 6.
xml_merge  t/test_xml_split_entities.xml: false
t/test_xml_split....................NOK 16/18Can't exec "/perl": No such file or directory at t/test_xml_split.t line 58, <FHSLURP> chunk 7.
xml_merge  t/test_xml_split_entities.xml: false
t/test_xml_split....................FAILED tests 1-2, 4, 6, 8, 10, 12, 14, 16, 18
        Failed 10/18 tests, 44.44% okay
t/test_xpath_cond...................ok                                       


	This happens with 28362 and 28498:

t/test_erase........................ok                                       
t/test_errors.......................dubious                                  
        Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 4-110
        Failed 107/110 tests, 2.73% okay
t/test_even_more_coverage...........ok                                       
t/zz_dump_config....................ok                                       
Failed Test     Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
t/test_errors.t    0    11   110  214  4-110
Failed 1/88 test scripts. 107/2143 subtests failed.
Files=88, Tests=2143, 93 wallclock secs (41.47 cusr +  2.21 csys = 43.68 CPU)
Failed 1/88 test programs. 107/2143 subtests failed.

	
	28810 already has the first of the failures above (and only those):

t/test_3_27.t               82    3  8-10

	29010 and 29220 have

t/test_3_27.t                     82    3  8-10
t/test_additional.t    0    11   647   16  640-647

	which means it's yet another variant!

	29411 then has already the same behaviour as 29705.

	* Watch Paul Johnson's
	
	http://pjcj.sytes.net/cover/cpancover-5.9.5/

	I tested the not-availables with 29703

	Carp-Assert-0.18                       superceded by 0.20 which wfm
	Catalyst-Engine-Apache-1.07            not tested
	Catalyst-View-TT-0.24                  not tested
	DateTime-Locale-0.32                   wfm
	File-Modified-0.07                     wfm
	IO-Pager-0.06                          wfm
	Image-Size-3.01                        wfm
	Object-Signature-1.05                  wfm
	PerlIO-eol-0.14                        wfm
	Template-Plugin-Number-Format-1.01     does not specify dependency on Number::Format
	                                       but if Number::Format installed, wfm
	Template-Timer-0.04                    fails for me too but fails with 5.8.8 too
	Test-JSON-0.02                         wfm

	* Some instability in recent bleads wrt YAML. As soon as YAML is loaded
	perl gets slow and CPAN cannot install Text::Glob, the first module to
	be installed after YAML according to current dependencies.

	Yesterday I resolved it by putting YAML on the dont_load_list. Today I
	would prefer to find some indications towards a possible reason. The
	program hangs while parsing or writing FTPstats.yml such that no other
	program can use CPAN.pm because it waits for the lock.

	(Note: 29704 has arrived while I'm investigating)

% gdb -p 17086
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
Attaching to process 17086
Reading symbols from /home/src/perl/repoperls/installed-perls/perl/pU42elH/perl-5.8.0@29672/bin/perl...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
[...]
Reading symbols from /home/src/perl/repoperls/installed-perls/perl/pU42elH/perl-5.8.0@29672/lib/5.9.5/i686-linux-64int/auto/B/B.so...done.
Loaded symbols for /home/src/perl/repoperls/installed-perls/perl/pU42elH/perl-5.8.0@29672/lib/5.9.5/i686-linux-64int/auto/B/B.so
Failed to read a valid object file image from memory.
0x08179c8b in Perl_leave_scope (base=497) at scope.c:627
627             switch (SSPOPINT) {
(gdb) bt
#0  0x08179c8b in Perl_leave_scope (base=497) at scope.c:627
#1  0x08177214 in Perl_pop_scope () at scope.c:99
#2  0x0818ddf8 in Perl_pp_return () at pp_ctl.c:2077
#3  0x080bd3eb in Perl_runops_debug () at dump.c:1875
#4  0x080ef6cc in S_run_body (oldscope=1) at perl.c:2398
#5  0x080eecfe in perl_run (my_perl=0x82d9008) at perl.c:2323
#6  0x0805e791 in main (argc=2, argv=0xbfd69b34, env=0xbfd69b40)
    at perlmain.c:113
(gdb) 

	By stepping with "n" I reach the seemingly endless loop:

1855            PERL_ASYNC_CHECK();
(gdb) 
1856            if (PL_debug) {
(gdb) 
1875        } while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX)));
(gdb) 
1855            PERL_ASYNC_CHECK();

	This is with 29672. I just retried to load YAML again and the hosts
	command did succeed, but it was slow (several minutes for 10000
	downloads)

	* Spreadsheet::ParseExcel broken recently. Also seems to affect
	Module::Plan::Lite. But binary search points to 29672 which cannot be to
	blame. SOLVED in rt.cpan.org

2007-01-05  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* is match/module compatible with SQLite? Is match/module the single
	cause for the slowness I encounter today? Is just 29679 broken? It
	cannot build PadWalker or it's just slow? Yes, it's only 29679. Something
	between YAML and the core. 78 and 80 are OK.

	I can add YAML to dont_load_list for 79, then build YAML::Syck and all
	goes well.
	
	* bug: force get on a dot distro removes {archived} which confuses make
	FIXED

	* distcc/ccache: I should use it for Tk. USING IT

	* Xvfb for testing Tk: Slaven writes

        Xvfb -fp /usr/X11R6/lib/X11/fonts/misc -ac :121 &
        env DISPLAY=:121 make test

	Also needed for POE which opens Tk windows.

2007-01-04  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* maybe have a is_tested command? The SVK revision 1694 is just a trial,
	probably needs a rollback. The problems come from concurrency. We
	currently are not supporting modules tested by a different process that
	runs simultaneously. So we should test it with a perl that has already
	finished megainstall.

	* Port auto_commit to 1.8803 . NOT NEEDED

2007-01-03  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Paul Johnson has put out Devel::Cover 0.60

	make test did not succeed for me on the SVN version. Must retry with
	0.60 proper. Same thing. Must try other perls.

	* concurrency: the most critical point at the moment seems to be the
	cleanup of the build directory and another process trying to access one
	of the directories with chdir to build_dir. This dies without a
	Distrostatus in

	Couldn't chdir to /home/k/.cpan/build/Term-ReadLine-Gnu-1.16-MacKnJ at lib/CPAN.pm line 8839

	Stupid use of croak(), we want die or confess and want to fix it when it
	happens again.

	Turned into confess in SVK rev. 1632

	* Are the dot directories documented? Where? Is chdir mentioned there?

	Yes, it was documented in the section "Integrating local directories"
	and I rewrote it a bit, it sounded too boring. It still sounds boring
	and leads me to the idea to support

	get:
	  commandline:

	I'll have to think some more about it. (Also consider Ingy's move to
	prefer SVN over CPAN)

	* somebody sending a Tk window during a test just waiting to be clicked
	away? Who is it? Tk itself? Maybe this was just a single revision? NO,
	it is Term::ReadLine::Gnu in t/callback.t. Wow, it compiles, apparently.
	But does it pass the tests? Can we disable this batch-unfriendly test?

	We cannot disable it without patching.

	We must click the window away and after that we still have tests failing.

	This looks ugly to me. I have Expect and can answer interactive
	questions but I have no robot to click a window away. For now I'll put
	T:R:Gnu before Tk in the megainstall. Needs a better solution.

	What was the name again of the environment variable for automated
	testing?

	David Golden once (2006-09-25 on perl-qa) stated 'AUTOMATED_TESTING --
	used by many authors to toggle tests for non-interactive situations', so
	it may be a de-facto standard. A long thread at the beginning of October
	more or less backed this proposal to signal unattended testing.

	ADDRESSED in rev. 1708

	* Remember to see after the Devel::Cover module. 0.60 fails tests and
	maybe needs a binary search again.

	* Hackaton in Munich? Slides for Munich!

	* Watch hosts statistics.

	* Todo: enable batch jobs to trigger cleanup of the build directory.
	Methods: scan_cache, tidyup, Variable: scan_cache. LOCK.

	No, only checklock needs to be made something official. Maybe rename to
	get_lock then.

	* Despite all the care that goes into the distroprefs directory, we
	always will fail on some distros that ask questions and hang forever.
	It's time to rethink a global way out of modules that hang in an IO
	operation.

	* 11-17 lists a few things for documentation.

	* make up your mind about install_tested.

2007-01-02  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* parrot is a bit of a mess, it seems. Why is CONTAINSMODS so tiny?

	At least I would expect

	CONTAINSMODS Inline::Parrot Inline::Parrot::parrot Parrot::Config Parrot::Embed Parrot::Interpreter Parrot::Test::Cardinal Perl::Critic::Policy::CodeLayout::UseParrotCoda SmartLink

	But *really* I'd expect several pages of output. But what I initially encountered was

	CONTAINSMODS Inline::Parrot Inline::Parrot::parrot

	Instead, I find quite a lot in

cpan[3]> d LTOETSCH/parrot-0.4.5.tar.gz
CPAN: LWP::UserAgent loaded ok (v2.033)
CPAN: Time::HiRes loaded ok (v1.9704)
CPAN: URI::URL loaded ok (v5.03)
Distribution id = L/LT/LTOETSCH/parrot-0.4.5.tar.gz
    CPAN_USERID  LTOETSCH (Leopold Totsch <lt@toetsch.at>)
    CONTAINSMODS Parrot::BuildUtil Parrot::Configure Parrot::Configure::Step::Base Parrot::Docs::Directory Parrot::Docs::File Parrot::Docs::Group Parrot::Docs::Item Parrot::Docs::POD2HTML Parrot::Docs::Section Parrot::Docs::Section::BigNum Parrot::Docs::Section::C Parrot::Docs::Section::Compilers Parrot::Docs::Section::Config Parrot::Docs::Section::Docs Parrot::Docs::Section::DynaPMCs Parrot::Docs::Section::EditorPlugins Parrot::Docs::Section::Examples Parrot::Docs::Section::IMCC Parrot::Docs::Section::Info Parrot::Docs::Section::Languages Parrot::Docs::Section::Libs Parrot::Docs::Section::Ops Parrot::Docs::Section::PMCs Parrot::Docs::Section::Parrot Parrot::Docs::Section::Perl Parrot::Docs::Section::Tests Parrot::Docs::Section::Tools Parrot::IO::Directory Parrot::IO::File Parrot::IO::Path Parrot::Op Parrot::OpTrans Parrot::OpTrans::C Parrot::OpTrans::CGoto Parrot::OpTrans::CPrederef Parrot::PIR::Formatter Parrot::Pmc2c Parrot::Pmc2c::Library Parrot::Revision Parrot::Test Parrot::Test::APL Parrot::Test::Harness Parrot::Test::PGE Parrot::Test::Perl6 Parrot::Test::Punie Parrot::Test::Python Parrot::Vtable
    UPLOAD_DATE  2006-06-19

	We have two bugs here. Only one is at CPAN.pm level.

	Oops, now I understand it: I had used ^C to break out of the slow loop.
	No wonder that I get less members.

	PROTECTED in rev. 1682

2007-01-01  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Is it possible that Tk gets installed twice per megainstall?

	Not in megainstall.20070102T1831.out

	But in megainstall.20070103T0336.out I see that 'NI-S/Tk-804.027.tar.gz'
	has 'make_test NO'. Looking at its YAML I see it is 'CALLED_FOR:
	Tk::HList'. So is Tk::HList lost in SVN?

	But this is again a case where browseentry failed and NOTHING got
	installed. Bug is reported, do not pay attention to more than one bug:)

	* Class::MethodMaker

lib/Class/MethodMaker.xs: In function 'XS_Class__MethodMaker_set_sub_name':
lib/Class/MethodMaker.xs:12: error: invalid lvalue in assignment
lib/Class/MethodMaker.xs:13: error: invalid lvalue in assignment

Module id = Class::MethodMaker
    DESCRIPTION  Create generic class methods
    CPAN_USERID  FLUFFY (Martyn J. Pearce <fluffy@cpan.org>)
    CPAN_VERSION 2.08
    CPAN_FILE    F/FL/FLUFFY/Class-MethodMaker-2.08.tar.gz
    UPLOAD_DATE  2005-11-26
    DSLIP_STATUS MdpOp (mature,developer,perl,object-oriented,Standard-Perl)
    MANPAGE      Class::MethodMaker - Create generic methods for OO Perl
    INST_FILE    (not installed)

	Given that https://rt.cpan.org/Ticket/Display.html?id=16241 is 12 months
	old, it seems abandoned.

	http://rt.cpan.org/Ticket/Display.html?id=22413
	http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/3342382

	The stupid thing is that there is a signature.t test and when we use
	distropref/patch to fix MethodMaker.xs, then the signature test breaks.
	Patching SIGNATURE does not help either because the file is signed. The
	solution is to patch 0-signature.t too and let it skip all tests.

	FINI.

	* Bug: The FTPstats file has been cleared once again. 1167639627.93624.
	Only 20 minutes ago. This must have happened when I killed the sluggish
	process. Now I made the writing of the FTPstats file atomic. FIXED in
	SVK rev. 1672

	* It seems that blead@20002 has difficulties with YAML or YAML::Syck.
	The binary search that I have running crawls and strace shows a lot of
	mremap activities and reading of FTPstats (maybe too often?) and long
	phases of no system calls at all. I kill the process and start again.
	Speed now seems normal. New zlib modules get installed. Some fail. There
	are many of them, all with 2.002 as version number--slightly confusing.
	Now CPAN::Injects demands prereqs. Compress::Bzip2 fails with "No rule
	to make target 'Makefile'". File-Find-Rule demands Number::Compare, gets
	it, finishes its own build and the tests and gets installed. Now for
	Data::Compare. It seems to get sluggish. CPAN::Checksums can't get
	installed because of missing Compress::Bzip2. Now somebody wants
	IPC::Run3 and we slowly seem to get it. I believe it is CPAN.pm which is
	losing too much time with some nonsense.

	* Somebody drops a daemon from a test running forever:

k        18692  0.0  0.0   2956  1328 pts/4    S+   Jan01   0:00 sh -c /home/src/perl/repoperls/installed-perls/perl/prOxRQY/perl-5.8.0@29651/bin/perl -Iblib/lib -Iblib/arch -I/home/src/perl/repoperls/installed-perls/perl/prOxRQY/perl-5.8.0@29651/lib/5.9.5/i686-linux-64int -I/home/src/perl/repoperls/installed-perls/perl/prOxRQY/perl-5.8.0@29651/lib/5.9.5 -I/home/src/perl/repoperls/installed-perls/perl/prOxRQY/perl-5.8.0@29651/lib/site_perl/5.9.5/i686-linux-64int -I/home/src/perl/repoperls/installed-perls/perl/prOxRQY/perl-5.8.0@29651/lib/site_perl/5.9.5 -I. examples/sslecho.pl 1212 examples/cert.pem examples/key.pem >>sslecho.log 2>&1

	lsof -p 18692
lsof: WARNING: can't stat() ext3 file system /dev/.static/dev
      Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE    SIZE     NODE NAME
sh      18692    k  cwd    DIR    9,1       0 11390681 /home/k/.cpan/build/Net_SSLeay.pm-1.30-KYd1Uh (deleted)

	cpan[4]> m Net::SSLeay
Module id = Net::SSLeay
    DESCRIPTION  Secure Socket Layer (based on OpenSSL)
    CPAN_USERID  FLORA (Florian Ragwitz <rafl@debian.org>)
    CPAN_VERSION 1.30
    CPAN_FILE    F/FL/FLORA/Net_SSLeay.pm-1.30.tar.gz
    UPLOAD_DATE  2005-12-26
    DSLIP_STATUS Rmcfr (released,mailing-list,C,functions,restricted_distribution)
    MANPAGE      Net::SSLeay - Perl extension for using OpenSSL
    INST_FILE    /home/src/perl/repoperls/installed-perls/perl/pSJpiak/perl-5.8.0@29656/lib/site_perl/5.9.5/i686-linux-64int/Net/SSLeay.pm
    INST_VERSION 1.30


	The queue in RT is called "Net_SSLeay.pm"

	The report is http://rt.cpan.org/Ticket/Display.html?id=24180

	FINI.
	
2006-12-31  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* new PAUSE and own key!

	* Todo: autosave/autocommit DONE

	* Why do I always see

Prepending /home/k/.cpan/build/Graphics-ColorNames-2.0_04-fxepKY/blib/arch /home/k/.cpan/build/Graphics-ColorNames-2.0_04-fxepKY/blib/lib /home/k/.cpan/build/HTML-Tidy-1.07_01-wuI8Hl/blib/arch /home/k/.cpan/build/HTML-Tidy-1.07_01-wuI8Hl/blib/lib /home/k/.cpan/build/YAML-Syck-0.72-BMlTTF/blib/arch /home/k/.cpan/build/YAML-Syck-0.72-BMlTTF/blib/lib to PERL5LIB for 'make'
	
	Graphics::ColorNames   is a goto and a Module::Build
	HTML::Tidy             is a goto
	YAML::Syck             nothing special visible, maybe an artefact
	                       because it is involved in writing and reading
	                       status information?

	There must a bug in the goto implementation.

	Yes, the bug is visible when doing a manual install of
	Graphics::ColorNames in that the test is run twice. A part of the reason
	seems to be that the distro stays on the queue when we have finished
	installing it. The solution might be to remove it within the goto method.

	DONE in SVK rev. 1652

	And for YAML::Syck I find indeed the artefact AND a bug in the reanimate
	routine. I wrote $obj->{make_install} but it should be {install}.

	FIXED in SVK rev. 1653

	* Todo: verify that CPAN_RUN_SHELL_TEST_WITHOUT_EXPECT=1 still works.

	It's incredible slow. Maybe the $prompt_re is inefficient? No, the
	problem is that the more tests we have, the longer is the string that
	needs testing. The output must be split on the prompt and then tested
	one piece at a time. This is a hard job because we do not know where to
	split. 31sessions.t seems better, let's move there and go away from
	30shell.t. For now we can short circuit after the first fail. This still
	is extremely slow.

	Found it. There was a /.../s in the wrong position, it modified the
	$expected regex. FIXED in rev 1654.

2006-12-30  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Todo: bring fforce, document force and fforce. DONE in SVK rev. 1650

	* New bug in testcover:

	t/31sessions.......ok 24/0Don't know which tests failed: got 26 ok, expected 0

	FIXED

	* Todo: bring back fforce. It was the SVK revision 1496 that
	extinguished it. And the subroutine itself was missing altogether. And
	1487 and 1490 introduced it. DONE

	* Paul Johnson is continuing his work on Devel::Cover but 30shell.t
	still triggers a bug somewhere , described in a P5P posting thusly:

	When I use bleadperl@29569 instead, the process grows to 38 MB virtual
	size and finishes after about 12 minutes. With blead@29570 I run into
	the timeout.

	I'm now trying to get more output from the running process:

	HARNESS_PERL_SWITCHES=-MDevel::Cover make test TEST_FILES=t/30shell.t TEST_VERBOSE=1

	It hangs after

	# NEXT: b Bundle::CpanTestDummies
	# EXPECT: \sCONTAINS.+?CPAN::Test::Dummy::Perl5::Make.+?CPAN::Test::Dummy::Perl5::Make::Zip(?s:.*?cpan[^>]*?>)

	Even if I turn on debug all, output stops there and memory consumption
	is infinite.

	It looks like Expect is holding back the output that could pinpoint the
	problem, so let's try with

	CPAN_RUN_SHELL_TEST_WITHOUT_EXPECT=1 HARNESS_PERL_SWITCHES=-MDevel::Cover make test TEST_FILES=t/30shell.t TEST_VERBOSE=1

	This prints "Out of memory" and dumps core, but I cannot find the core
	file. Sure, because the other process that parses the output just
	removes the whole dot-cpan directory in its END block. A die() does not
	cancel the END block!

	So we move the cleanup code out of the END so we can analyse the
	debugging statements from 'o debug all'.

	I replaced a $_ with a lexical and could run more tests after that.
	Before it was always failing after test 154, now it fails after 164:
	'force ls ANDK' is the last ok and the command that fails is 'test
	CPAN::Test::Dummy::Perl5::Make'. In the test.out I see that make goes OK
	and after that follows nothing.

	Here comes the big surprise: when I turn debugging on for this and the
	next command, the third one fails. Ahh yes, this is a bug in 30shell.t
	itself. The expected regexes must be longer to avoid false positives
	that hide bugs in the testsuite for a long while.

	And now, all of a sudden, the tests run through? No wild process
	anymore? Well, a lot of them fail but the crazyness is just over?

	Yes. We'll go back a few steps and forward and see if we can identify
	something.

	My impression is that the four lines in the chunk after 6981 are
	responsible where I replaced $_ with $dirent. We'll see.

	Update 2006-12-31: No, this change alone does not bring the bug back.

	What about svn up -r 1432? Is the nightmare reproducable at all? Yes.
	With bleadperl@29642 and devel-cover SVN rev. 190 and CPAN.pm SVN rev.
	1432 and the command

	HARNESS_PERL_SWITCHES=-MDevel::Cover make test TEST_FILES=t/30shell.t TEST_VERBOSE=1

	I can see the bug again: after test 154 I see this output:

	ok 154 -  (testing command 'b')
# NEXT: b Bundle::CpanTestDummies
# EXPECT: \sCONTAINS.+?CPAN::Test::Dummy::Perl5::Make.+?CPAN::Test::Dummy::Perl5::Make::Zip(?s:.*?cpan[^>]*?>)

	and then the process grows to 2.9 GB.

	FINISHED with a status report.

2006-12-29  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Between 29627 and 29637 we have a major breakage in perl. Perl builds
	fine but fails many tests. The first test that fails is io/open.t and it
	has not changed. It's something about my($f) and local($f) but I have
	not one liner yet that demonstrates it. make regen in any case does not
	help.

	Ahhh, here it is:

	eval {open my $f, '<', '/etc/hosts';};
  open local $f, '<', '/etc/passwd';

	This is silent in 27 and barks with 35 and 37:

	Can't localize lexical variable $f at tests/my-local.pl line 3.

	Now binary search runs..... 28 ok, 29 not ok.

	Jarkko reports these:

> Linux:
> http://www.nntp.perl.org/group/perl.daily-build.reports/43396    29609
> http://www.nntp.perl.org/group/perl.daily-build.reports/43381    29604
> 																														     
> AIX:																												     
> http://www.nntp.perl.org/group/perl.daily-build.reports/43428    29609
> http://www.nntp.perl.org/group/perl.daily-build.reports/43395    29604
> 																														     
> OpenBSD:																										     
> http://www.nntp.perl.org/group/perl.daily-build.reports/43414    29609
> http://www.nntp.perl.org/group/perl.daily-build.reports/43374    29599

	That's something different. So I reported the 29er to p5p. It's since
	been fixed in 29639.

2006-12-28  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Bug in SQLite: if I type "install TAB" I only get completion for the
	modules that have already been loaded:

cpan[5]> install             
Acme::Meta      Danga::Socket   POSIX           Sys::Syscall    Time::HiRes
DBD::mysql      IO::Poll        Socket          Test::More      fields

	Reported to and FIXED by Randy.

2006-12-27  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* #24114 by Steve says that we do not survive without YAML!

	Trying to fix with overloaded Exception classes leads to more changes
	than I feel comfortable with without writing new tests. So we need tests
	that test missing YAML and YAML::Syck. Maybe Test::Without::Module might
	help?

	No. The tricky way that CPAN.pm is using to load modules is not suited
	for T:W:M. I have tried it and I see YAML gets loaded without
	hesitation. But I recall we have dontload_list. Very nice.

	IMPROVED in SVK rev. 1639 and added tests in 31sessions.t since then.

	* document the major change to the force pragma and find tests that
	enforce that

	* document how test repete is supposed to work and find tests that
	enforce that

2006-12-26  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Paul Johnson has already fixed #24067 in his repository. Unfortunately
	he sends me a link to svnweb instead of the repository itself. Svnweb
	itself neither gives machine readable output nor does it provide a link
	to the repository.

	Fortunately one can guess it: svn ls http://pjcj.sytes.net/svn/Devel-Cover

	Repository version passes all tests.

2006-12-25  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* I don't know how to prevent SQLite dieing due to locked database.
	Because it happens such that a batch process reads the database and an
	interactive process tries to write the database. The latter does not
	know about the other. Both know nothing about each other beforehand.
	Then they clash and I cannot find out.

	FIXED (at least improved) by Randy

2006-12-24  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Todo: create a second shell test, say 31force.t that starts from
	scratch and studies the variants without having to wait for many minutes

	It would be good if we had a test script that allows us to visit
	multiple sessions. It would not really need Expect.pm! We make short
	sessions instead. 31sessions.t is it. Test::Base or what? No, it doesn't
	convince me but I don't know why.

	* after SVK rev. 1604 doing a megainstall from scratch a second time to
	study the differences tomorrow or in the late evening.

	Later... looks good. But crazy that we find both DBD::mysql 4.00 and
	3.0008 in the failed departement (Update 2006-12-26 akoenig : reported
	as http://rt.cpan.org/Ticket/Display.html?id=24096). And the second
	anomaly that .../svn/tk/. succeeded at 17:28 but not at 11:45. Not much
	for 5100 diff chunks.

	* Rethinking once again 'force test'. Right now I see "Has already been
	tested successfully" within one session but not when I start a session.

	This needs to change because our big force redesign should let us say
	'force test thing' when we really want just exactly that and should save
	us the time when we really know this has been tested OK.

	I think this happens in SVK rev.1604

	* Buglet: if I do a 'force get thing' then I get a new build_dir for the
	thing. If I had done a 'test thing' before then the old build_dir is in
	the is_tested hash/set/database and survives in the paths prepended to
	PERL5LIB

	FIXED in SVK rev. 1589

	But wait! If we have many variants of one distro in PERL5LIB, then all
	hell breaks loose because we possibly do not get the right one as the
	first. We need to sort by something. DONE in upcoming SVK rev. 1604.

	Oh, and we need to filter out the installed ones. So we really must tie
	the distros and the is_tested stuff together. Makes no sense to prepend
	test-directory-X to PERL5LIB when X is installed. FIXED for the
	make_install attribute: this was lost because there was an early return
	on success in CPAN::Distribution::install().

2006-12-23  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>

	* Remember to see after the Devel::Cover module

	http://rt.cpan.org/Ticket/Display.html?id=24067

	It seems to me that the CC to p5p did not come through. Need to re-check
	and forward it myself. But give it time to bite its way through.

2006-12-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* After misguided downgrade:

WebService::Bloglines          0.06      0.12  MIYAGAWA/WebService-Bloglines-0.12.tar.gz

	After upgrade back to 0.12:

WebService::Bloglines::Subscriptions      0.02      0.06  MIYAGAWA/WebService-Bloglines-0.06.tar.gz

	Similar case for YSAS and SWF::Builder::Shape. For both I use "reset
	version" on PAUSE directly. FIXED.

	* Todo: disable concurrent writes via SQLite or disable SQLite for the
	degraded second. See mails from Randy from today

2006-12-22  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* badtestcnt is buggy. color_command_temps(0) deletes it and the next
	command then will behave differently. Trying to stop deleting it I
	experience

	make-test-20061222T223413:
	    fails                              none
	    does delete badtc for distros?       no
	    test 199 sharp?                      no

	make-test-20061222T222907:
	    fails                              none
	    does delete badtc for distros?      yes
	    test 199 sharp?                     yes

	make-test-20061222T221432
	    fails                               199
	    does delete badtc for distros?       no
	    test 199 sharp?                     yes

	Working over the expected regular expressions seems necessary because
	some of them match too early and it becomes impossible to determine
	which test really fails.

	So now we have

	make-test-20061223T160632
	    fails:                              199
	    does delete badtc for distros?       no
	    test199 sharp?                      yes

	Apparently we once decided that badtestcnt shall be kept until a command
	is finished. To prevent repeating the same test within one command. And
	when the command finishes, in the very last moment, we would remove the
	badtestcnt so that the next command would test the same distro again.
	Because we hope that a failing test can turn into success due to
	external factors. From this point of view badtestcnt is programmed
	correctly.

	But I had changed strategy when persistence entered the game. I wanted
	to not repeat failed tests at all to speed things up, didn't I? And what
	did I encounter?

	Needs to be specified in full length first. Do we want to repeat testing?

	            command     session     restored_state
	Distro
	  OK          no          no          no
	  FAIL        no          yes         yes
	Module/Bundle
	  OK/FAIL     pass everything through to underlying distros

	The problem is, I think, that when we store state, we quite often get
	"badtestcnt" in the state because we store it before the command is
	finished. So if we simply delete badtestcnt when we restore state, we
	should be pretty much out of the danger zone.

2006-12-21  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Intermittent test failure on DateTime-Util-Calc:

20061203T2111.out:#   Failed test '0.901330 == 0.901330'
20061211T0716.out:#   Failed test '0.609380 == 0.609380'
20061212T2316.out:#   Failed test '0.592640 == 0.592640'
20061217T2212.out:#   Failed test '0.788770 == 0.788770'
20061219T0016.out:#   Failed test '0.154410 == 0.154410'
20061219T0530.out:#   Failed test '0.342450 == 0.342450'
20061219T2245.out:#   Failed test '0.874790 == 0.874790'
20061220T2321.out:#   Failed test '0.840630 == 0.840630'

	Reported as http://rt.cpan.org/Ticket/Display.html?id=24028

	FIXED

2006-12-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* integrate applypatch such that we determine where it lives and if a
	patch is written for applypatch we use it. DONE

2006-12-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Hackaton in Munich?

	* Bug: still the dependency on YAML::Syck in the Makefile DONE in SVK
	rev. 1560

	* Bug: hosts statistics was cut off before Dec. 17. For now I've added a
	mandatory debugging line to see it when it happens.

	Saw it again. I suspect that somebody without YAML gets an empty stats
	arrayref and later comes to the conclusion that he may write the first
	record.

	Most probably fixed now. The code that truncated did not check if we
	were really able to write afterwards. (Log starts: Mon Dec 18 14:19:10
	2006)

2006-12-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* See recent bugreport on modules against pause indexer and version
	objects and consider how it affects us here. SEEMS OK.

	* From an Email from Ingy to Steffen Mueller:

The idea is to make things a lot easier for a lot more people to be
involved. Well that's part of the plan anyway. Mostly I intend Kwiki to
be downloadable and installable via subversion rather than cpan.

While I don't intend to completely abandon cpan, I also am not so
interested in keeping cpan up to date. Really it should be automated
somehow. Anyway, all this is to say that if you want to shepard Kwiki on
cpan, you are most welcome to.

	An argument for "commandline" but maybe for even more.

	Commandline is DONE.

	* priorities today: force, commandline (DONE)

	* DBD::mysql: I'm sure there is just a defined() somewhere missing in
	the Makefile.PL. Seems to be FIXED by 4.00.

	* DBD::SQLite again: With bleadperl 29398 and current CPAN.pm I tried to
	install /home/src/perl/cpan-sql-stuff/CPAN-SQLite/. but again it failed
	because DBD::SQLite did not write its SQLite.xsi file. I fear there's
	something being (not) done in the Makefile.PL instead of during make.

	Yes. On the second try DBD::SQLite builds perfectly well. So one must
	make sure that they are installed in this order. Maybe this is normal
	for DBDs? I have never noticed this before. Hrm. This would be a case
	for re-running perl Makefile.PL after building the prereqs.

	If we had 'commandline', we would write

make:
	commandline: "$PERL Makefile.PL; make"

	Or something like that. Will test as soon as we have 'commandline'.

	DONE

	* priorities: bugfixing; SQLite; Kwalify;

	redesigning the force pragma: biggie; see showstopper alert

	distroprefs left over: single ersatzcommand for the test mantras: we
	currently can change the make command and the arguments at the end but
	the word test is always on the command line and this looks silly. But
	maybe not worth a new keyword. But I've also proposed ->{test}{skip}, so
	the two can be folded perhaps? ---- On the bycicle it occurred to me: we
	add "commandline" to each of get/make/test/install and then the user can
	even say "cvs up" or "perl -e 1". I like it.

	* I'm convinced now that we need more force flavors and that force shall
	be limited in scope

	force get     shall re-fetch
	force make    shall not re-fetch   but run make again
	force test    shall not make again but try to test again
	force install shall not test again but try to install

	* But when we have four different force flavors, we will demand a
	superforce that works like the force now does and sets all "lower" ones?

	* Todo: when fixing force note that the documentation about force is in
	three places: CPAN::{Bundle,Distribution,Module}::force.

	* Bug that has to do with install_tested or build_dir_reuse or degraded
	shell mode or some use of ^C at the wrong moment:

  PEREINAR/File-Which-0.05.tar.gz              : install NO

	But File::Which is installed. Maybe in a concurrent shell. When I ask
	for 'install File::Which' I get 'is up to date' and nothing gets
	repaired. When I ask for 'install PEREINAR/File-Which-0.05.tar.gz' then
	the thing gets tested but not installed because 'Already tried without
	success'.

	Are we in trouble?

	Maybe we must rethink how 'force test' works. It should not 'force get',
	and 'force make', it should just test and not refuse to do it.

	Or we must compute the COMMANDID better than we do during reanimate and
	treat negative COMAMNDIDs with more rigor in some constellations?

	The thing is that the module object for File::Which knows about the
	correct distro object but it gets the installed version from @INC and
	does not know who put it there and so should not be able to discard the
	distro object. Hmmm.

	Remember, we have the notest pragma! Maybe we can let install_tested
	support both the force and the notest pragma and are through?

	But no, even 'notest install ...' does not succeed because we need
	force, not notest, but force propagates down until we restart with get.
	This is, of course a last resort, but it's no fun:-(

	SHOWSTOPPER ALERT!

	At least I get the impression this extreme case happens only on ^C, but
	some other methods of dieing will certainly exist as well.

	* Observing in a shell in degraded mode: it wrote a new Metadata file.

	* Observing how install_tested behaves: within the same session it
	installs without retesting. In a new session it does retest. What
	*should* it do?
	
	Noting that the DH test runs forever again because GMP comes too late.

	* Investigate if I want Math::Bigint::GMP in the core. Think of
	Crypt::DH and the horrible test timings when Math::Bigint::GMP is not
	installed

	* find out why upgrade always upgrades
	Apache::Session::Generate::ModUniqueId and ...::ModUserTrack.

	Seems to be Apache-Session-1.81/Session/Generate/ModUniqueId.pm and
	Apache-Session-1.81/Session/Generate/ModUsertrack.pm

	SO OK, nothing to worry.

	* The Net::SSH::Perl test 03-packet still runs forever even with
	Math::Bigint::GMP. Maybe this is completely unrelated? Yes! No load!
	Report sent. But can we patch it? Maybe not as long as Math::Pari and
	Crypt::Random are prereqs and fail themselves.

	* In Crypt::DH rewrite the test so that TEST_VERBOSE tells us timings
	and Math::BigInt internals. No need! It's Math::Bigint again. Test is
	really quick with Math::Bigint::GMP installed. Note that Math::GMP is
	not enough. But can we patch it?

	* CPAN::Checksums -> Data::Compare -> File::Find::Rule ->
	Number::Compare
	
	* I wanted to watch some scenarios with persistent data. Especially with
	modules that work and that are being tested again and again with prereqs
	and without or within bundles and if they are retested or not, installed
	or not with persistence and within the same session.

	Write a megatest?

	* Study "pip" by Adam K (in Module-Plan-Base) and CPAN::Mini::Tested and
	CPAN::Mini::Phalanx100 and also see what we can do for
	Module::ThirdParty

	* Provide an API or documentation how to find out the CPAN::Config
	variables.

	* Now I know the first bug in install_tested: it re-tests already
	installed modules.

	* One thing we do not support yet in distroprefs is adding dependencies
	without patching. Shall we?

	* Bug in T:B:

	Text::Balanced            v1.99.1_1      1.98  DCONWAY/Text-Balanced-1.98.tar.gz

	Bug reported as http://rt.cpan.org/Ticket/Display.html?id=23968

2006-12-16  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug? Binary search seems to run incredibly slow today for
	POE::Component::Client::DNS and I had already the same impression
	yesterday for L:M:Gettext.

	Hopefully fixed by caching negative results of _sqlite_running.

	* Bug? I suddenly see less than 76 dots when we read 01mailrc.txt.gz:

Going to read /home/ftp/pub/CPAN/authors/01mailrc.txt.gz
............................................................................DONE

	Happening during a binary search with perl-5.8.0@20373.

	Oops, scratch that, this is exactly 80 colums and I just have a broader
	terminal:)))

2006-12-15  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* #23887 has a patch. DUPLICATE of 23933. #23933 ! ANSWERED

2006-12-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: enable batch jobs to trigger cleanup of the build directory.
	Methods: scan_cache, tidyup, Variable: scan_cache. LOCK.

	No, only checklock needs to be made something official. Maybe rename to
	get_lock then.

2006-12-11  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* #23887 has a patch. DUPLICATE of 23933.

2006-12-10  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Buglets with sqlite: does not correctly deal with SVN::Core and
	Bundle::Pause. Things not on CPAN.

	Something else coming from megainstall and some debugging code has been
	added to produce inspection evidence:

Panic: obj[--- 
reqtype: r
] cannot meth[install]

	So we somehow produce an empty object that has nothing but reqtype set.
	I saw this for the first time with SQLLite. Today, with megainstall,
	when I turn SQLite off, the bug does not happen. But the bug might be in
	CPAN.pm as well, we must trace it back to the origin of this weird hash.

	Update 2006-12-12: it is happening with SVN::Client

	The bug was hidden for a few days when DBI was broken but came back when
	DBI got a patch from  Nicholas.

	I think I just fixed it in exists. But still I find

Use of uninitialized value $fullid in substitution (s///) at /home/src/perl/repoperls/installed-perls/perl/ph5rQVg/perl-5.8.0@29559/lib/site_perl/5.9.5/CPAN/SQLite/Util.pm line 178.
Use of uninitialized value $fullid in concatenation (.) or string at /home/src/perl/repoperls/installed-perls/perl/ph5rQVg/perl-5.8.0@29559/lib/site_perl/5.9.5/CPAN/SQLite/Util.pm line 179.

	in the logfile. And now this has been fixed in C:S CVS version too.

	* From an Email from Ingy to Steffen Mueller:

The idea is to make things a lot easier for a lot more people to be
involved. Well that's part of the plan anyway. Mostly I intend Kwiki to
be downloadable and installable via subversion rather than cpan.

While I don't intend to completely abandon cpan, I also am not so
interested in keeping cpan up to date. Really it should be automated
somehow. Anyway, all this is to say that if you want to shepard Kwiki on
cpan, you are most welcome to.

	An argument for "commandline" but maybe for even more.

2006-12-09  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* On 1367 broke 30shell.t and up to 1372 it was not fixed. The failure
	at 1367 happens at

	test CPAN::Test::Dummy::Perl5::Build
	doesN'T match [[[test\s+--\s+OK(?s:.*?cpan[^>]*?>)]]]!

	at 1372 we come to

	install CPAN::Test::Dummy::Perl5::Build
	doesN'T match [[[is up to date|SAW MAKE[\s\S]+?SAW MAKE[\s\S]+?SAW MBUILD(?s:.*?cpan[^>]*?>)]]]!

	after tweaking 30shell.t to reveal the real difference between the two
	versions I find what is now new:

#   ANDK/CPAN-Test-Dummy-Perl5-Build-1.03.tar.gz
# Tests succeeded but one dependency not OK (CPAN::Test::Dummy::Perl5::Make::Zip)

	instead of previous:

#   ANDK/CPAN-Test-Dummy-Perl5-Build-1.03.tar.gz
#   ./Build test -- OK
# Running Build install

	So why is Zip not OK? Maybe because we "installed" it with a fake
	install command? It did not arrive in an install directory but it was
	removed from the "is_tested" directories and then not prepended to
	PERL5LIB?

	Yes, that seems the correct interpretation. The old test was not
	revealing that, the new code is. So we improved the code that much that
	it does not allow the faked-up test anymore.

	OK, this shows us how important it is that each test tests only one
	thing. This Build module tests a bit too much so we cannot easily
	recognize how to interprete a failure and we break the first rule of
	testing zen: tests are there to find bugs.
		
	* Todo: when fixing force note that the documentation about force is in
	three places: CPAN::{Bundle,Distribution,Module}::force.

	* integrate the use_sqlite and sqlite_dbname parameters before _65 DONE.

2006-12-07  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Another problem with goto is that if people say upgrade, the newer
	version will be tried again, will goto the other and then the same
	version as the installed one will be built and installed again. Probably
	too rare a case to worry about. Goto is always a temporary solution.

	* XML::Feed and XML::RSS cooperation continues to exhibit bugs: 

	t/05-atom10-link......ok
	t/06-atom10...........ok
	t/07-atom10-create....ok
	All tests successful.
	Files=7, Tests=171,  9 wallclock secs ( 7.08 cusr +  0.42 csys =  7.50 CPU)
	  BTROTT/XML-Feed-0.12.tar.gz
	Tests succeeded but one dependency not OK (XML::RSS)
	Running Build install
	  make test had returned bad status, won't install without force

	So although XML::RSS was installed successfully, it is not uptodate. But
	it's goodenough for XML::Feed which demands version 1.01. We have 1.12
	and CPAN has 1.21 but 1.21 is disabled now with a goto.

	Maybe we check for uptodateness in the wrong place?

	No, we checked if the newest distro completed its tests.

	FIXED in SVK rev. 1516

2006-12-06  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* http://rt.cpan.org/Ticket/Display.html?id=23588

	Not fixed with XML::RSS 1.21! Now re-reported as

	http://rt.cpan.org/Ticket/Display.html?id=23822

2006-12-05  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* With all the care that goes into the distroprefs directory, we always
	will fail on some distros that ask questions and hang forever. It's time
	to rethink a global way out of modules that hang in an IO operation.

	* Todo: make the distropref schema even easier accessible like with a
	manpage.

2006-12-04  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug reported by Sendu Bala: it can really happen that CPAN.pm deletes
	a build_dir while the owner is still in the queue.

	testshell-with-protocol cannot reproduce by setting build_cache to 0.1,
	not even with 0.001, and not even with 0.

	Recall: during the first "get" the cachemgr is introduced. It is global
	and gets never replaced and so should never be called again for
	scan_cache.

	I ask Sendu to explaint he circumstances and he brings an example where
	somebody calls CPAN.pm recursively. No, I don't consider this a bug. and
	besides, it won't happen in 1.89 anymore *although* I do not consider it
	a bug.
	
	* Bug: Goto does not work as it should for XML::RSS. Currently I see
	that XML::Feed is tested before XML::RSS is installed. First X:F has the
	prereq to X:R, so X:R is processed. It has a prereq of Test::Manifest
	which is processed and installed. Then comes X:R again but it says:

  /usr/bin/make  -- OK
Running make test
  Delayed until after prerequisites
Running make install
  Delayed until after prerequisites

	And then immediately comes X:F's test and fails. X:R is dropped from the
	queue somehow.

	And undelay and goto do not know each other. Because goto does not jump
	on the queue, I suppose.

	FIXED in SVK rev. 1508

	* Bug: The current Makefile has an implicit dependency on YAML::Syck

	This was a bug in MANIFEST.SKIP which excluded the .dd files in
	distroprefs/

	FIXED in SVK rev. 1506

2006-12-03  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Maybe I should undo the too far going changes I did in the preparation
	for a better force implementation and make a _64? Force could delay the
	next release considerably.

	OK, the three occurrences of fforce are gone. What else?

2006-12-02  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* find a way to treat kwalify such that the schema is documented and can
	be accessed directly. And such that not only YAML::Syck can read it.
	Current solution confuses YAML.

	After some rewriting of CPAN::Kwalify I'm stuck with this:

% /home/src/perl/repoperls/installed-perls/*/*/perl-*@29438/bin/perl -e '
use Kwalify; use File::Slurp qw(slurp);
my($schema,$data) = map { eval slurp $_ } @ARGV;    
Kwalify::validate( $schema, $data );
' ./lib/CPAN/Kwalify/distroprefs.dd ./distroprefs/RGIERSIG.Expect.dd  
[/make] Expected subschema (a hash)

	While this succeeds:

% /home/src/perl/repoperls/installed-perls/*/*/perl-*@29438/bin/perl -e '
use Kwalify; use YAML::Syck;
my($schema,$data) = map { YAML::Syck::LoadFile($_) } @ARGV;
Kwalify::validate( $schema, $data );
' ./lib/CPAN/Kwalify/distroprefs.yml ./distroprefs/RGIERSIG.Expect.yml

	The solution is to use $Purity=1 for Data::Dumper transformations as
	described in the Data::Dumper manpage. Thanks to Slaven for digging it
	out for me.
	
	* priorities today: force, expect, commandline

	backtrack: kwalify in separate package

	* My talk proposal http://www.perl-workshop.de/auth/my/edittalk?id=46

	Module Morphing. Module Taming. Module Killing. Talkback. cpan DOT
	(bring your own)! Persistent or Permanent Shell? Upgrade. Test Now,
	Install Later. Configure Your Pick. Color. Kovaric.

	Wasn't that Kolaric? Oops. My memory betrayed me.

2006-12-01  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: while trying a goto in KCLARK.SQL-Translator.yml that should
	point to JROBINSON/SQL-Translator-0.08_04.tar.gz nothing works as
	expected. CPAN tries to download pub/CPAN/authors/id/JROBINSON (without
	the J/JR/). All other 4 gotos still seem to work.

	Is this because it is from today or because JR has 9 letters?

	Testing JROBINSON/SQL-Translator-0.08_04.tar.gz directly is no problem.

	fixed in SVK rev 1474
	
	* Release the two new bundles

	* XML::Twig's tests fail and when looking around one eventually finds
	http://xmltwig.com/ where there is a 3.27 version. No repository access.
	Looks like another case for 'we want "get URL"'. Or theoretically
	someone could just release it to CPAN as 3.27_20061201.tar.gz and then
	treat it with a goto. But that smells.

2006-11-30  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todos reshuffled.

2006-11-29  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* DBD::mysql: I'm sure there is just a defined() somewhere missing in
	the Makefile.PL

	* Need to patch Module::AutoInstall and test antirecursion with an
	environment variable. Errr, I need to patch the inc/ directory of
	Plagger then. Done and patch for now in the patches directory.

	Remember that there's also a rant in 00.README -- No, this is already
	gone.

	http://rt.cpan.org/Ticket/Display.html?id=23735 now suggests a patch

2006-11-28  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* DBD::SQLite again: With bleadperl 29398 and current CPAN.pm I tried to
	install /home/src/perl/cpan-sql-stuff/CPAN-SQLite/. but again it failed
	because DBD::SQLite did not write its SQLite.xsi file. I fear there's
	something being (not) done in the Makefile.PL instead of during make.

	Yes. On the second try DBD::SQLite builds perfectly well. So one must
	make sure that they are installed in this order. Maybe this is normal
	for DBDs? I have never noticed this before. Hrm. This would be a case
	for re-running perl Makefile.PL after building the prereqs.

	If we had 'commandline', we would write

make:
	commandline: "make; $PERL Makefile.PL; make"

	Or something like that. Will test as soon as we have 'commandline'.

	* Observing that expect-in-any-order is much slower than expect (of
	course) and that one could safe minutes for Plagger if a timeout were
	set to 0.1 or so.

	Update 2006-12-17 akoenig : low global timeout value does not work
	because the first question has a few seconds to wait for whatever. So
	one would really need tiemouts per question and in the case of anyorder
	one would have toi calculate the current maximum for the timeout and
	while this would be doable it would be overspecification, too much to
	learn for the user with too little gain to be made. REJECTED

2006-11-27  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: if some other processes have deleted my build_dir while I was
	running, heck maybe I can do that even myself, react accordingly

	DONE.

2006-11-26  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* bug:

	force get /home/src/perl/cpan-sql-stuff/CPAN-SQLite/.

	goes through all of urllist and tries to download
	ftp://cpan.mirrors.skynet.be/pub/CPAN/authors/id//home/src/perl/cpan-sql-stuff/CPAN-SQLite/.
	etc.

	And after that we cannot work with the
	/home/src/perl/cpan-sql-stuff/CPAN-SQLite/. directory anymore, somehow
	the internal state has lost the connection to the real directory.

	Without the force it works nicely and says:

	Is already unwrapped into directory /home/src/perl/cpan-sql-stuff/CPAN-SQLite/.
	
	FIXED in SVK rev. 1487

2006-11-25  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* priorities: bugfixing; SQLite; Kwalify;

	redesigning the force pragma: biggie; see showstopper alert

	distroprefs left over: single ersatzcommand for the test mantras: we
	currently can change the make command and the arguments at the end but
	the word test is always on the command line and this looks silly. But
	maybe not worth a new keyword. But I've also proposed ->{test}{skip}, so
	the two can be folded perhaps? ---- On the bycicle it occurred to me: we
	add "commandline" to each of get/make/test/install and then the user can
	even say "cd .... && cvs up" or "perl -e 1". I like it.

	11-17 lists a few things for documentation.

	restructure the expect keyword family DONE

	TTL stuff

	make up your mind about install_tested.

2006-11-24  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* But when we have four different force flavors, we will demand a
	superforce that works like the force now does and sets all "lower" ones?

	* Todo: distroprefs mechanism is still inefficient in that it scans too
	often the whole distro_dir. (But it's super to have that while
	developing new rules)

2006-11-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* I'm convinced now that we need more force flavors and that force shall
	be limited in scope

	force get     shall re-fetch
	force make    shall not re-fetch   but run make again
	force test    shall not make again but try to test again
	force install shall not test again but try to install

2006-11-22  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* document build_requires and when you talk about prerequisites, name
	the option names explicitly.

2006-11-21  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-11-20  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Randy sent rkobes-cpan4.diff which should fit to cvs rev. 1.21 of
	CPAN/SQLite.pm.

2006-11-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-11-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* kwalify schema language: http://rubyforge.org/frs/?group_id=815&release_id=5513

	Docs: http://www.kuwata-lab.com/kwalify/users-guide.01.html

	Yaml mode: http://svn.clouder.jp/repos/public/yaml-mode/trunk

	cvs -d :pserver:anonymous@srezic.cvs.sourceforge.net:/cvsroot/srezic co Kwalify

	/home/src/perl/srezic/Kwalify/.

	Todo: integrate schemacheck into a test and put Kwalify into the Bundle

	for f in distroprefs/*.yml; do
	  /home/src/perl/repoperls/installed-perls/perl/pSI5eZY/perl-5.8.0@29319/bin/pkwalify -f cpan_distroprefs_schema.yml $f 
	done

2006-11-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* make _get_urllist a public method for Randy.

	* Write manpage for CPAN::HandleConfig, esp load().

	* I realize that CPAN::FTP::localize is undocumented and is what Randy
	wants.

2006-11-16  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-11-15  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Integrate hosts into $META like authors, distributions, and modules?
	If we're cautious, this might turn into an automatic optimization.

	If Coro does index downloads for us, we do not have to fear slow
	connections and can gather better data.

2006-11-14  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Randy says:

	The only data CPAN::SQLite really needs from CPAN.pm is:
	- a location to store the database file; for this,
	it's presently using $CPAN::Config->{cpan_home},
	which I believe is the same location as Metadata;
	- the name of the database file; in this I've been
	using a new config entry $CPAN::Config->{sqlite_dbname},
	or 'cpandb-sqlite', as a default;
	- the location (directory) beneath which the CPAN
	indices are kept; I've been using
	$CPAN::Config->{keep_source_where}, assuming
	it's a simple directory.
	
	The guessing for this in CPAN::SQLite comes when it's
	not being run under CPAN.pm.
	
	As for CPAN::SQLite providing data to CPAN.pm,
	that's being done solely in CPAN::SQLite::META,
	and it uses
	  $CPAN::META->instance($class => $id)->set(%data);
	for everything, except for CONTAINSMODS, where
	it uses
	  $d = $CPAN::META->instance($class => $id);
	  $d->{CONTAINSMODS} = \%list_of_mods;
	
	* Catalyst would be another candidate for a large dependency list.

	* Guessing of -p0/-p1 for patch maybe wrong if the patch tries to create
	a new file against, say, /dev/null.

	* Expect structure. We can leave expect as it is but expect-in-any-order
	needs a way to set the timeout. The structure must change, I fear.

	* Would be nice: integrate the config variable name into the init
	dialogs such that one has a chance to learn their names over time.

	* Would be nice: 'o conf /check/' to list all variables matching a regex.

	* I realize that it's quite pointless to try downloading with "fancy"
	when there is Net::FTP installed. OTOH, *sometimes* it may be clueful. I
	should explain in a FAQ that it makes sense to disable the externel
	programs once one has Net::FTP and LWP. The problem only appears if you
	have many hosts in the urllist and try to download a fresh file: here
	you want to try only with one method and cycle through the hosts
	quickly.

2006-11-13  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Randy Kobes needs an API to find out where the index files are
	located. And the whole SQLite needs to be integrated. First question is
	what do we use from it. Only the readonly stuff, I suppose. And the
	urllist. And all this might need to be combined with the TTL stuff and
	separate loading of index files.

	* Bug that has to do with install_tested or build_dir_reuse or degraded
	shell mode or some use of ^C at the wrong moment:

  PEREINAR/File-Which-0.05.tar.gz              : install NO

	But File::Which is installed. Maybe in a concurrent shell. When I ask
	for 'install File::Which' I get 'is up to date' and nothing gets
	repaired. When I ask for 'install PEREINAR/File-Which-0.05.tar.gz' then
	the thing gets tested but not installed because 'Already tried without
	success'.

	Are we in trouble?

	Maybe we must rethink how 'force test' works. It should not 'force get',
	and 'force make', it should just test and not refuse to do it.

	Or we must compute the COMMANDID better than we do during reanimate and
	treat negative COMAMNDIDs with more rigor in some constellations?

	The thing is that the module object for File::Which knows about the
	correct distro object but it gets the installed version from @INC and
	does not know who put it there and so should not be able to discard the
	distro object. Hmmm.

	Remember, we have the notest pragma! Maybe we can let install_tested
	support both the force and the notest pragma and are through?

	But no, even 'notest install ...' does not succeed because we need
	force, not notest, but force propagates down until we restart with get.
	This is, of course a last resort, but it's no fun:-(

	SHOWSTOPPER ALERT!

	At least I get the impression this extreme case happens only on ^C, but
	some other methods of dieing will certainly exist as well.

	* Todo: offer the choice between (readline) Gnu and Perl and Coro. See
	my trials in the bin/ directory (SVN only)

	* Mail::Send problem persists that Test::Reporter's mails do not arrive
	when sent with Mail::Send but do when sent with Net::SMTP (IIRC). In any
	case I must disable installation of Mail::Send somehow or debug.
	Test::Reporter has got a wish item via RT already some weeks ago.

	* Bug: Uuuuuh, pressing ^C and then trying an illegal command, ugliness:

	LWP failed with code[500] message[read timeout]
Trying to get away with old file:
6114541  500 -rw-rw-r--  1 1000     1000       504953 Nov  8 08:02 /home/k/.cpan/sources/modules/02packages.details.txt.gz
Going to read /home/k/.cpan/sources/modules/02packages.details.txt.gz
  Database was generated on Tue, 07 Nov 2006 12:25:12 GMT
.
Caught SIGINT, trying to continue
	
cpan> hosts
Refusing to autoload 'hosts' while signal pending at lib/CPAN.pm line 590.


	* if we make the TTLs setable, maybe we should make the TTL for
	CHECKSUMS file too. In any case we have the problem of imacat also when
	the TTL of the local copy of the CHECKSUMS file has not yet been
	reached!

	* Coro. See also notes below, search for anyevent	

	* Observing in a shell in degraded mode: it wrote a new Metadata file.

	* Observing how install_tested behaves: within the same session it
	installs without retesting. In a new session it does retest. What
	*should* it do?
	
	Noting that the DH test runs forever again because GMP comes too late.

	* Watch the Module::Build space for updates to the question of calling
	M:B methods or parsing _build/*. Ken seemed to argue for the file (?)

	* write a patch for Test::Reporter so you can choose the mail sending
	module? Reported 2005-07:
	http://rt.cpan.org/Ticket/Display.html?id=13836

	* Investigate if I want Math::Bigint::GMP in the core. Think of
	Crypt::DH and the horrible test timings when Math::Bigint::GMP is not
	installed

	* find out why upgrade always upgrades
	Apache::Session::Generate::ModUniqueId and ...::ModUserTrack.

	Seems to be Apache-Session-1.81/Session/Generate/ModUniqueId.pm and
	Apache-Session-1.81/Session/Generate/ModUsertrack.pm

	SO OK, nothing to worry.

	* The Net::SSH::Perl test 03-packet still runs forever even with
	Math::Bigint::GMP. Maybe this is completely unrelated? Yes! No load!
	Report sent. But can we patch it? Maybe not as long as Math::Pari and
	Crypt::Random are prereqs and fail themselves.

	* In Crypt::DH rewrite the test so that TEST_VERBOSE tells us timings
	and Math::BigInt internals. No need! It's Math::Bigint again. Test is
	really quick with Math::Bigint::GMP installed. Note that Math::GMP is
	not enough. But can we patch it?

	* The first thing that I encounter when I start testing instead of
	installing things is that test doesn't stop when the installed version
	is higher than or equal to the CPAN version. Ilya invented for that
	test_uptodate??

	* CPAN::Checksums -> Data::Compare -> File::Find::Rule ->
	Number::Compare
	
	* I wanted to watch some scenarios with persistent data. Especially with
	modules that work and that are being tested again and again with prereqs
	and without or within bundles and if they are retested or not, installed
	or not with persistence and within the same session.

	Write a megatest?

	* Study "pip" by Adam K (in Module-Plan-Base) and CPAN::Mini::Tested and
	CPAN::Mini::Phalanx100 and also see what we can do for
	Module::ThirdParty

	* replace 03 index file with YAML.

	* Provide an API or documentation how to find out the CPAN::Config
	variables.

	* Looks like a bug to me what I find in Bundle-SZABGAB-0.01.yml:
	CONTAINSMODS is empty because Gabor has a distro in the bundle.

	* Now I know the first bug in install_tested: it re-tests already
	installed modules.

	* One thing we do not support yet in distroprefs is adding dependencies
	without patching. Shall we?

	* Todo: clean up "XXX" in the code

	* M2 (Wishlist) separate the TTLs for 01,02,03. If somebody asks 'a
	FOO', we should only check for the authors database, etc.

	* E1 Todo: use 00whois.xml instead of mailrc, and follow the UTF-8 HOWTO to
	get rid of the term_is_latin variable. Test output with locales.

	* H4 branch 1.87-dbmdeep-hackery revive? It was very broken but I do not
	remember details. Hint: DBM::Deep promises significant memory savings
	and in that branch we tried to see how it can be made to work for us.

	* M3 RT 17353: Flag outdated CPAN sites and move them to the end of the
	list when they have reached 291 hours. (Note: $CPAN/authors/02STAMP)

	* E1: revisit rev 158:159, the introduction of "recent" and "perldoc".
	#21791 has its bugreport. I don't like that most of the subroutines are
	thrown into CPAN::Distribution either. OTOH, we have commands that have
	no central role within CPAN. One can always refuse to use them. Hrm.
	HTML::Display!

	* E5: (again and again) verify that the CPAN.pm-using modules continue
	to work:

	DMUEY/AltaVista-BabelFish
	MSCHILLI/CPAN-Unwind
	ULPFR/CPAN-WAIT
	RJRAY/Devel-Modlist
	SMUELLER/PAR-Dist-FromCPAN
	DAGOLDEN/Perl-Dist
	CRAKRJACK/Test-CPANpm

	* E5 watch RT for open tickets. This todo can never be closed.

	* E1 Todo: continue to close the Pod::Coverage gap. Currently only
	CPAN.pm is covered

	* E3 Todo: write a test for dot-cpan/Metadata usage. Hmmm. Important for
	the future of locking, the future of DBM::Deep, protocol changes. Not
	sure what to test.

	* M3 Todo: investigate what BUGHUNTING in Tarzip means "today": it's
	about a very old bug in Archive::Tar that is most probably fixed. Turn
	bughunting on with the command C< !print$CPAN::Tarzip::BUGHUNTING=1 >.
	It is slow but everything should just plain work. When we're confident
	that everything works, we could offer a tar_policy option that has
	options "ext" and "mod", for external programs vs. modules, default to
	"ext"?

	* M3 Reopened Bug: it seems that a user who is in /bin and has "." in
	the beginning of the path gets ./sh as his shell from FirstTime. If we
	encounter . in the path we should rather ignore it. But first we must
	verify the behaviour. Reported by Slaven Rezic on behalf of Tino
	Schulze. This has nothing to do with -I. but only with the shell and
	$ENV{PATH} and as we do not know which shell it was it seems we cannot
	test for the problem.

	* H1 These days developer TELS posted to perl5-porters that his newest
	release is available at

	    http://bloodgate.com/perl/packages/devel/Math-BigInt-1.78.tar.gz

	Suddenly it dawned on me that I want to support

	    install http://bloodgate.com/perl/packages/devel/Math-BigInt-1.78.tar.gz

	What am I missing?

	The other commands dealing with files would have to learn a bit.

	d http://      # fails as before with "No objects of...."

	               # alt: does a HEAD and tells user that the URL can e reached

	ls http://     # lists nothing

	               # alt: says that ls doesn't support URLs

	get http://    # this is probably all we need to implement. Maybe a new
	               # class needed that does as_string and as_glimpse as well?

	And maybe a pragma that turns this feature on? So that 'get http://...'
	never works but 'force get http://...' does? Alt: config variable to
	turn feature on, then a separate module that implements it.

	Brian likes the idea

From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: Welcome new user LOCAL
To: modules@perl.org
Date: Mon, 18 Sep 2006 14:52:48 -0500
Organization: Perl Authors Upload Server
Reply-To: modules@perl.org

In article <877j0361hl.fsf@k75.linux.bogus>, (Andreas J. Koenig)
<andreas.koenig.gmwojprw@franz.ak.mind.de> wrote:

> My spontaneous idea was to support the command
> 
>     cpan> get http://bloodgate.com/perl/packages/devel/Math-BigInt-1.78.tar.gz


oh, very interesting, especially if I already have the file:

   cpan> get file:///....

This makes CPAN::Mini::Inject a bit less useful because I no longer
need the middle man.


	* Make the "new -> ." symlink in scripts/ as outlined in a mail to kurt
	and jarkko

	* M2 feature request by Juergen Christoffel: have time stamps on the
	history and a history command to see them

	* hr ================ no todos below this line ================ /hr

	* hr ================ no todos below this line ================ /hr

	* hr ================ no todos below this line ================ /hr

	* SQL-Translator-0.07 has a broken signature
	(reported 9 months ago at
	https://rt.cpan.org/Ticket/Display.html?id=16852). When trying to
	install CLACO/Handel-0.99_15 I see this warning running by quite often
	instead of only once and testing of it again and again. And the same for
	Email-Valid and DBIx-Class-Validation.

	Why?

  CLACO/Handel-0.99_15.tar.gz
  /usr/bin/make test -- NOT OK
Failed during this command:
  LYOKATO/FormValidator-Simple-0.19.tar.gz     : make_test NO
  MIYAGAWA/Email-Valid-Loose-0.05.tar.gz       : make_test NO
  CLACO/DBIx-Class-Validation-0.01001.tar.gz   : make_test NO
  DROLSKY/DateTime-Format-MySQL-0.04.tar.gz    : make_test NO
  RICKM/DateTime-Format-Strptime-1.0700.tar.gz : make_test NO
  CLACO/DBIx-Class-UUIDColumns-0.01000.tar.gz  : make_test NO one dependency not OK (SQL::Translator)
  RJBS/Email-Valid-0.176.tar.gz                : make_test NO
  DROLSKY/DateTime-Format-Builder-0.7807.tar.gz: make_test NO
  KCLARK/SQL-Translator-0.07.tar.gz            : signature_verify NO
  CLACO/Handel-0.99_15.tar.gz                  : make_test NO

	Besides the need to find out why the tests are repeated so often, it may
	be a good idea to support check_sigs via distroprefs.

	DONE

	* receiving file list ...
14484 files to consider
./
5.9.0/diffs/
5.9.0/diffs/29196.gz
        1184 100%    1.13MB/s    0:00:00 (xfer#1, to-check=219/14484)
5.9.0/diffs/29413.gz
        2178 100%  708.98kB/s    0:00:00 (xfer#2, to-check=8/14484)
5.9.0/diffs/29414.gz
         848 100%    4.31kB/s    0:00:00 (xfer#3, to-check=7/14484)
5.9.0/diffs/29415.gz
        2540 100%   12.79kB/s    0:00:00 (xfer#4, to-check=6/14484)
5.9.0/diffs/29416.gz
         691 100%    3.46kB/s    0:00:00 (xfer#5, to-check=5/14484)
5.9.0/diffs/29417.gz
        1053 100%    3.02kB/s    0:00:00 (xfer#6, to-check=4/14484)
5.9.0/diffs/29418.gz
         546 100%    1.55kB/s    0:00:00 (xfer#7, to-check=3/14484)
5.9.0/diffs/29419.gz
         352 100%    1.00kB/s    0:00:00 (xfer#8, to-check=2/14484)
5.9.0/diffs/29420.gz
         845 100%    2.38kB/s    0:00:00 (xfer#9, to-check=1/14484)
5.9.0/diffs/29421.gz
       12248 100%   17.49kB/s    0:00:00 (xfer#10, to-check=0/14484)

	*&*^*&%%&%$!!!!!

The following patches had errors:
        29196

Errors while patching

	and before

----stdout+err patching 29196 (ret=256)---
The text leading up to this was:
--------------------------
|Index: depot/perl/pod/perlretut.pod
|--- depot/perl/pod/perlretut.pod#37~27989~     2006-04-28 01:41:25.000000000 -0
700
|+++ depot/perl/pod/perlretut.pod       2006-11-02 23:08:18.000000000 -0800
--------------------------
File to patch: 
Skip this patch? [y] 
5 out of 5 hunks ignored
----EOF----
PAPU: Registering as a failing patch d[29196] at /usr/local/perl/bin/patchaperlu
p line 374.


	Bug reported anfd promptly fixed by Philippe M. Chiasson (gozer).

	* Batch jobs without a lock should not be allowed to cleanup the cache
	directory. And then document the lock policy and that there are lockless
	batch runs. DONE

	* Observing what autoinstall does:

/home/src/perl/repoperls/installed-perls/perl/p6siswe/perl-5.8.0@29397/bin/perl 
"-Iinc" Makefile.PL --config= --installdeps=File::Find::Rule,0,UNIVERSAL::requir
e,0.1,Template::Provider::Encoding,0.04,Text::Tags,0,DateTime::Format::Mail,0,Da
teTime::Format::W3CDTF,0,DateTime::Format::Strptime,0,Cache::Cache,1.04,Module::
Pluggable::Fast,0,HTML::ResolveLink,0,MIME::Types,1.16,XML::Feed,0.12,XML::Atom,
0.23,Term::Encoding,0,Encode::Detect,1,HTTP::Cookies::Mozilla,0,XML::Liberal,0.1
4,XML::RSS::Liberal,0,HTML::TreeBuilder::XPath,0,HTML::FormatText,0,DateTime::Fo
rmat::Japanese,0,HTML::Scrubber,0,XML::Feed,0.09,XML::Atom,0.20,Net::SMTP::TLS,0
,Mail::Address,0,HTML::Scrubber,0,Time::Duration::Parse,0,WebService::Bloglines,
0.11,Cache::FastMmap,0,POE::Component::Client::HTTP,0,Xango,1.04,DateTime::Forma
t::Epoch,0,WWW::Mixi,0.48,SVN::Core,0,SVN::Client,0,WebService::YouTube,0,WWW::B
abelfish,0,Text::Emoticon,0,HTML::ResolveLink,0,Email::Address,0,Lingua::ZH::Han
Detect,0,Text::Language::Guess,0,IP::Country,0,Text::Hatena,0,Hatena::Keyword,0,
Image::Info,0,Text::Markdown,0,Regexp::Common::profanity_us,0,HTML::ResolveLink,
0.02,Text::Kakasi,0,Mail::SpamAssassin,0,URI::Find,0,URI::Find,0,Audio::Beep,0,P
OE::Component::IRC,0,POE::Component::IKC::Client,0,Net::NetSend,0,Text::CSV_PP,0
,Net::Delicious,0,Mail::IMAPClient,0,Template::Plugin::JavaScript,0,Net::Movable
Type,0,PDF::FromHTML,0,Palm::PalmDoc,0,Text::WrapI18N,0,Data::Serializer,0,Data:
:ICal,0,Search::Estraier,0,File::Grep,0,KinoSearch,0,DBIx::Class::Schema,0,XML::
FOAF,0,Config::INI::Simple,0,HTML::TreeBuilder::XPath,0,Lingua::EN::Summarize,0,
Text::Original,0,Lingua::JA::Summarize::Extract,0
CPAN: File::HomeDir loaded ok (v0.58)

	Yes, this goes really into recursion. Since I have "reuse" turned on,
	the damage is limited but if I had it not on, it would be a lot of
	expensive noops.

	The question is simply: how can I prevent autoinstall from going into
	recursion? I want it to do its detective work and return it to me. Ahhh,
	it does so! It writes them in traditional style into the Makefile. All I
	need to prevent is that this target (the "installdeps" target) is run
	during 'make'. Or that it is being run but does nothing. Or whatever
	that does not repeat what I have already done.

	* Broken: 30shell.t. Recently something changed this:

# NEXT: m /_NEXISTE_/
# EXPECT: Contact Author J. Cpantest Hietaniemi(?s:.*?cpan[^>]*?>)
# GOT: m /_NEXISTE_/
# Module    _NEXISTE_              (Contact Author J. Cpantest Hietaniemi <nospam@nospam>)
# Module    _NEXISTE_::_NEXISTE_   (Contact Author J. Cpantest Hietaniemi <nospam@nospam>)
# 2 items found

	to this:

# Module    _NEXISTE_              (N/A)
# Module    _NEXISTE_::_NEXISTE_   (N/A)
# 2 items found

	Who was it? First time I need a binary search on my own code:)

	Standing at HEAD: fail as above

	Switching back to 1310: fails with Looks like you planned 227 tests but
	only ran 163.

	Running forward with a quick obvious fix: Looks like you planned 227
	tests but only ran 159.

	Switching to 1300: Looks like you planned 227 tests but only ran 163.

	1290: completely broken
	To 1291: Looks like you planned 227 tests but only ran 159.

	To 1281: All tests successful

	1286: ok

	88 ok

	89 ok

	91 ok ???

	1300 ok ???

	1310 ok ???

	Obviously a timing related bug. The ls command seems expensive. Maybe
	perl is slower or the sqlite patch made CPAN.pm slower. Setting the
	default timeout to 30 and ripping out the sqlite patch brings us test ok
	again. Putting back in the sqlite stuff with the small obvious fix in
	the exists method brings test ok again. Setting timout back to 20 again
	and just increasing the timout for the 'ls ANDK' command to 30 brings
	test ok again. All of the successes in the SVN directory.

	* CPAN::SQLite has the dependency on LWP::Simple missing

	* observed a strange behaviour: trying

	test /home/src/perl/cpan-sql-stuff/CPAN-SQLite/.

	early, immediately after Bundle::CPANxxl. Dependency on SQLite is
	recognized, recursive dependency on DBI is recognized, but SQLite does
	not build a SQLite.xsi which seems to indicate that it did not find DBI.

	install helps, so we are still unfriendly to testers?

	* Why did I get no problem with Module::Pluggable before but now do?
	Hmm. Installing on naked 29367 gives no errors. Installing on
	module-rich 29376 gives one test failure:

t/02works_taint............NOK 3/5                                           
#   Failed test 'is deeply'
#   at t/02works_taint.t line 20.
#     Structures begin differing at:
#          $got->[0] = 'Module::Pluggable::Fast'
#     $expected->[0] = 'Module::Pluggable::Object'
t/02works_taint............NOK 5/5                                           
#   Failed test 'is deeply class'
#   at t/02works_taint.t line 29.
#     Structures begin differing at:
#          $got->[0] = 'Module::Pluggable::Fast'
#     $expected->[0] = 'Module::Pluggable::Object'
# Looks like you failed 2 tests of 5.
t/02works_taint............dubious                                           
        Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 3, 5
        Failed 2/5 tests, 60.00% okay

	Aha, seems to be a broken test.
	http://rt.cpan.org/Ticket/Display.html?id=23607

	* Now I have changed Plagger YAML file to answer y to all optional
	features and now it installs even Spamassassin.

	* 23315 rings a bell now..... eliminated many Tarzip exceptions by
	protecting with eval rev. 1386

	* Slaven reports bug: there is a yml file in dot directories named
	"..yml" FIXED in svk rev. 1390

	* Jifty 0.61123_01 is out and the tests fail on Module::Refresh missing
	and Test::Base as far as I can see.

	Kwalify is out.

	Jifty says what it would like to have:

- App::CLI                       ...missing. (would need 0.03)
- Email::Send                    ...missing. (would need 1.99_01)
- HTML::Mason                    ...missing. (would need 1.3101)
- HTML::Mason::Plugin            ...missing.
- HTTP::Server::Simple           ...missing. (would need 0.20)
- HTTP::Server::Simple::Recorder ...missing.
- XML::Simple                    ...missing.
- Module::Install::Admin         ...missing. (would need 0.50)
- Test::HTTP::Server::Simple     ...missing. (would need 0.02)
- Test::WWW::Mechanize           ...missing. (would need 1.04)
- Class::Accessor::Named         ...missing.
- Devel::Cover                   ...missing.
- Module::Install::Admin         ...missing. (would need 0.50)
- PAR::Dist::FromCPAN            ...missing.

	Now that I have Module::Refresh and Test::Base Jifty fails tests due to
	HTML::Mason.

	* Trying to get a binary search running for XML-Feed-0.12. I need to go
	before 20000 where I haven't been for quite a while and nothing works.

	I need to break a circular dependency ExtUtils::CBuilder => File::Spec
	=> PathTools => ExtUtils::CBuilder

	I'm hung at the moment with 19096: it cannot build
	Scalar-List-Utils-1.18 because it fails during perl Makefile.PL:

	Can't call method "load" on an undefined value at inc/Module/Install.pm line 180

	I have tried to install Module::Install myself but this did not help.

	Removing the whole inc directory does not help either. When I improve
	the code at line 180, it just gets reverted magically. This is what I
	tried to insert:

		my $obj = eval { $self->load($method) };
        if ($@) {
          my $err = $@;
          require Carp;
          confess $err;
        }
        $obj or return;

	Running in the debugger fails also because it fails at compile time.

	Giving up on 19096, trying 19523.

	Same thing but I realise that I can skip Scalar-List-Utils. Now I need
	to install LWP with notest. And XML::Atom fails because 'Undefined
	subroutine &utf8::is_utf8 called at t/18-unicode.t line 17.' Use notest
	again. And XML-Feed's test still fails with

t/01-parse............NOK 44/72                                              
#   Failed test at t/01-parse.t line 59.
#                   'Hello!...'
#     doesn't match '(?-xism:<p>Hello!</p>)'
t/01-parse............NOK 45/72                                              
#   Failed test at t/01-parse.t line 60.
#          got: undef
#     expected: 'Hello!...'
# Looks like you failed 2 tests of 72.
t/01-parse............dubious                                                
        Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 44-45
        Failed 2/72 tests, 97.22% okay

	Trying 19096 again. This time XML::Atom cannot write a Build file with
	the same Module::Install bug as above. Giving up.

	Maybe investigate within the maint branch?

	Yes! This shows us an interesting fact: under 29163 we see the same
	failure. Under my /usr/local/perl-5.8.8/ we do not see it. 27048 which
	is closest to 27040 (which would be 5.8.8 exactly).

	Same failure. So it's very likely a module dependency. Some recent
	module upgrade probably. my 5.8.8 installation might still have the old
	one and updating breaks? The successfully testing 5.8.8 says

  CPAN.pm: Going to build B/BT/BTROTT/XML-Feed-0.12.tar.gz

*** Module::AutoInstall version 1.02
*** Checking for Perl dependencies...
[Core Features]
- LWP                      ...loaded. (5.805)
- HTML::TokeParser         ...loaded. (2.35)
- Test::More               ...loaded. (0.62)
- Class::ErrorHandler      ...loaded. (0.01)
- Feed::Find               ...loaded. (0.06)
- URI::Fetch               ...loaded. (0.08)
- XML::RSS                 ...loaded. (1.10 >= 1.01)
- XML::Atom                ...loaded. (0.23 >= 0.08)
- DateTime                 ...loaded. (0.35)
- DateTime::Format::Mail   ...loaded. (0.30)
- DateTime::Format::W3CDTF ...loaded. (0.04)
- List::Util               ...loaded. (1.18)
*** Module::AutoInstall configuration finished.
Checking whether your kit is complete...
Looks good


	The failing one under 27048 says

*** Module::AutoInstall version 1.020
*** Checking for Perl dependencies...
[Core Features]
- LWP                      ...loaded. (5.805)
- HTML::TokeParser         ...loaded. (2.350)
- Test::More               ...loaded. (0.620)
- Class::ErrorHandler      ...loaded. (0.010)
- Feed::Find               ...loaded. (0.060)
- URI::Fetch               ...loaded. (0.080)
- XML::RSS                 ...loaded. (1.200 >= 1.01)
- XML::Atom                ...loaded. (0.230 >= 0.08)
- DateTime                 ...loaded. (0.350)
- DateTime::Format::Mail   ...loaded. (0.300)
- DateTime::Format::W3CDTF ...loaded. (0.040)
- List::Util               ...loaded. (1.180)
*** Module::AutoInstall configuration finished.
Checking whether your kit is complete...
Looks good

	Yes, and when I downgrade XML::RSS to 1.1, then the test failure goes
	away.

	Bingo. Another case for "goto".

	* I just wrote in a mail to Sendu Bala:

  > On a tangentially related note, are there any plans to make CPAN do
  > anything useful with the 'recommends'/'optional_features' information
  > in a META.yml file?

No. I never considered this a job for CPAN.pm. If I had the time,
inclination and fu to write talk-me-through-optional-features
software, I'd write it independently from CPAN.pm.

I think of CPAN.pm as the glue between the user and the CPAN mantras.
CPAN.pm 1.89 will allow the users to store their preferences about
optional things in any CPAN package, no matter how the packages
themselves manage them. If you play with 1.88_62 see the 00.README in
the distroprefs directory. But it's no
talk-me-through-optional-features software.

Or if you prefer a drawing:

     +----------+       +----------------+       +----------+
     |          |       |    mantras     |       |          |
     |          |       |perl Makefile.PL|       |          |
     |   user   |       |make            |       |  module  |
     |          |       |make test       |       |          |
     |          |       |make install    |       |          |
     +----------+  ^^^  +----------------+  ^^^  +----------+
                   |||                      |||   
                    ||Gap filled             ||Gap for
                     |by CPAN.pm              |options software


	* hosts statistics: the host with the most unsuccessful downloads is
	which? Of course the one that lead the urllist. That doesn't prove
	anything.

	* answer Sendu Bala two mails, one private, one on cpan-workers

	* From a mail I sent to Slaven about Tk:

Mit 20002 bekomme ich t/regexp.t     2   512    21    2  10-11
Mit 29332             t/regexp.t     0    11    21   36  4-21

Letzteres entspricht wohl Deinem Coredump.

Noch sehe ich keine wirklich saubere Strategie fuer binsearch. Die
bereits frueher angewendete mit 'notest install' zuerst und dann
nochmaligem test von regexp.t scheint die einfachste im Moment. Den
habe ich auch grade eben gestartet.

Sauber waere wohl, wenn man 'make test' dazu bringen koennte, nur
schlicht und einfach ein einziges Skript aufzurufen. --> Todo

	* After all the prereq hassles with XML::Atom I finally could install it
	for perl 20002 after many manual interventions but without overrule
	(except when we call the XML::LibXML=1.61003 decision as an overrule)

	After the same hassles under 29332 I see the test failure

t/02-content...........NOK 23/32                                             
#   Failed test at t/02-content.t line 62.
#          got: 'xml'
#     expected: 'base64'
# Looks like you failed 1 test of 32.
t/02-content...........dubious                                               
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 23
        Failed 1/32 tests, 96.88% okay

	This means that if I just got the proper prerequisites I'd have run a
	binarysearch in no time.

*** Module::AutoInstall version 1.030
*** Checking for Perl dependencies...
[Core Features]
- MIME::Base64             ...loaded. (3.07_0100)
- URI                      ...missing.
- Class::Data::Inheritable ...missing.
==> Auto-install the 2 mandatory module(s) from CPAN? [y] y
[Faster XML parsing with libxml]
- XML::LibXML              ...missing. (would need 1.54)
==> Auto-install the 1 optional module(s) from CPAN? [y] y
[Pure perl XML parsing with XML::XPath]
- XML::XPath               ...missing.
==> Auto-install the 1 optional module(s) from CPAN? [n] y
[Client/Server for Atom API]
- LWP                      ...missing.
- LWP::Authen::Wsse        ...missing.
- Digest::SHA1             ...missing.
- DateTime                 ...missing.
==> Auto-install the 4 optional module(s) from CPAN? [y] y
[Feed and API Auto-discovery]
- HTML::Parser             ...missing.
==> Auto-install the 1 optional module(s) from CPAN? [y] y
CPAN: File::HomeDir loaded ok
*** Dependencies will be installed the next time you type 'make'.
    (You may need to do that as the 'root' user.)
*** Module::AutoInstall configuration finished.

	Next step is to document what is wrong with the prereqs and present the
	findings to author.

	1. Test fails on XML::XPath.         requires bug
	2. Ditto on LWP::UserAgent           requires bug
	3. Ditto on Digest::SHA1             requires bug
	4. Ditto on DateTime                 requires bug
	5. Ditto on XML::LibXML not so obviously!) requires bug

	XML::XPath
	LWP::UserAgent
	Digest::SHA1
	DateTime
	XML::LibXML
	
	It may be the case that the author thought that a user that says no to
	an optional feature will accept failing tests. But I'd expect that if I
	say no to a feature then this feature is not tested at all. And I'd
	argue this is important because a user can usually not reliably
	differentiate proprely between failing tests due to bugs and failing
	tests due to missing prereqs. No bug on Module::AutoInstall side.

	Now our manual binary search stands at 27069(ok) and 29332(not ok) and
	our patch seems to be clear: add the above 5 modules to requires and not
	as optional modules.

	Done and it worked with 28618.

	* Need a way to specify a different distribution for a module. Say, we
	realize that the officially current XML::LibXML 1.62 is broken but some
	PAJAS/XML-LibXML-1.61003.tar.gz still works. I think, I'd like

	  ->{goto} = "PAJAS/XML-LibXML-1.61003.tar.gz"

	DONE

	* Need a way to specify notest from distroprefs. When we know Strptime
	doesn't pass a test but we know that the problem is harmless or can be
	ignored for some reason. I think, I'd like ->{test}{skip} = 1

	* Todo: LWP::Authen::Wsse is an optional prereq of XML::Atom but did not
	get installed. Need to find out how to signal to AutoInstall that I want
	all recommendations installed. Ahh, I find that XML::Atom not only uses
	AutoInstall but also Module::Build and that writes a _build/prereq file
	and I could read that. I would then find that 'recommends' hashref and I
	could then start installing what I find there.

	But how do I know that the user wants that the recommendations be
	installed?

	While watching what Module::Install is doing and trying out variations I
	get the impression that I have no chance to do the right thing. If the
	user says, he wants the recommendations, they still do not end up in
	META.yml or _build/prereqs or where else should I look?

	After the user has said that he wants everything, we see

Checking prerequisites...
 * Optional prerequisite LWP::Authen::Wsse is not installed
 * Optional prerequisite XML::LibXML is not installed
 * Optional prerequisite DateTime is not installed

	But nobody builds or installs them. I find them nowhere in the build
	directory stored away. And yet, when I test XML::Atom, it requires it
	magically and I have to install them manually.

	* Todo: the order of lines in the "failed" command or "failed" report
	section is, given identical command ID, I believe, random. Need a
	timestamp for finer granular sorting. That would make the listing much
	more useful because the first is the most important, all others may be
	followup errors.

	* Todo: write a Makefile target for the 3 *.dd files in distroprefs DONE

	* Todo: Storable support for distroprefs DONE

	* Since I fixed the bootstrapping problem of YAML/Expect/ReadLine by
	allowing fallback dd files, I thought that now I would be able to run
	binary searches more often for broken (or unexpectedly fixed) modules.
	My first victim should be DateTime::Format::Strptime. But binary search
	converged towards 2794[123] and it was so obvious from mere watching
	that this turning point was not the Strptime problem but some other
	Params::Validate related problem. P:V 0.86 broke at 27942 and so
	DateTime could not be built and Date::Time::Locale could not be built
	and Strptime could also not pass its tests.

	At some point in time later P:V worked again and so we have this
	eclipse: at 27942 the still working Strptime disappeared in the shadow
	of P:V and when P:V started to work again, Strptime was broken (or was
	it not?). If it broke we cannot see where it broke unless we start
	another higher level view that throws extra patches around.

	The good news is that we can determine the duration of the eclipse of
	P:V: it broke at 27942 and reappeared between 28156 and 28181 (closer
	examination pending).

	Very nice: Strptime worked with 28181 and so we can run another binary
	search between 28181 and 29312. Breakage at 28325 and report sent to P5P

	* why is reuse_old_builddir (sp?) turned off in degraded mode? I think
	there is no good reason. FIXED

	* Observed that the E of DONE is in the second line during "03". Take
	the algorithm in reanimate_build_dir() around line 4175 in all three
	index files. It's easier to read and workd even for @items < 76. DONE

	* display the commandid during the failed command -- just for a while. I
	want to see how big the holes are and if they look plausible. -- They
	have all the same number! FIXED

	* Bug: ~/.cpan/sources/modules is full with backup files FIXED in 1360

	* I just added the decicive line to Makefile.PL so that I can
	conveniently start messing around with CPAN::SQLite support:

	/home/src/perl/cpan-sql-stuff/CPAN-SQLite/.   # (!)

	% make run-with-sqlite
/home/src/perl/repoperls/installed-perls/perl/pDtzfB5/perl-5.8.0@29285/bin/perl -I$HOME/.cpan -Ilib -MCPAN::SQLite -MCPAN::MyConfig -MCPAN -e '$CPAN::Config->{use_sqlite}++; shell'
CPAN: Term::ANSIColor loaded ok (v1.11)

cpan shell -- CPAN exploration and modules installation (v1.8862)
ReadLine support enabled

cpan[1]> d MSCHILLI/Log-Log4perl-1.07.tar.gz                
CPAN: YAML::Syck loaded ok (v0.71)
Going to read /home/k/.cpan/build/
............................................................................DONE
Found 593 old builds, restored the state of 337
Updating database file ...
Can't exec "cpandb": No such file or directory at /home/src/perl/repoperls/installed-perls/perl/pDtzfB5/perl-5.8.0@29285/lib/site_perl/5.9.5/CPAN/SQLite/META.pm line 179.
system cpandb --update failed: -1 at /home/src/perl/repoperls/installed-perls/perl/pDtzfB5/perl-5.8.0@29285/lib/site_perl/5.9.5/CPAN/SQLite/META.pm line 179.
 at lib/CPAN.pm line 276
        CPAN::shell() called at -e line 1


	Uh. Patch rkobes-cpan3.diff backed out. Now I probably know where to start.

	* Integrate freshness into hosts stats. (#17353)

	* Allow dd or st files instead of yml in distroprefs for bootstrapping
	purpose. DONE

	* Todo: avoid ->can everywhere and replace with UNIVERSAL::can. See
	Adriano Rodrigues' bugreport. DONE

	* This looks silly:

	cpan[15]> o conf commit
commit: wrote '/home/k/.cpan/CPAN/MyConfig.pm'
Please use 'o conf commit' to make the config permanent!

	FIXED

	* write a dummy distro that reads arguments to Makefile.PL and another
	one that reads something from STDIN (or maybe both in one) DELAYED until
	the distroprefs stuff leaves the alpha stage.

	* The bug in Strptime is in the "ga" locale. Installing the ga locale on
	my box doesn't solve it. Manana.

	* "I hate Module::AutoInstall". See down under the hr when you ever have
	time.

2006-11-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* BUG: randomize_urllist cannot be set on the shell commandline: because
	it ends in "list", it becomes always an array:))

	FIXED

	* Todo: guess the patch option -p0 or -p1

	DONE

	* distroprefs with artificial intelligence: find out how to write a
	distropref with so much AI that it handles several different dialogues.
	I just realized that YAML::Syck talked me into a different dialogue on
	some older bleadperl that had YAML 0.60 installed:

*** WARNING ***

This release breaks compatibility with versions earlier than version 0.60 of
YAML::Syck and YAML.pm when serializing blessed references.

See the COMPATIBILITY file for more information.

*** Pre-0.60 version of YAML.pm (0.53) detected.
Continue installing YAML::Syck? [y]

	We would like to answer to this question yes if it comes. Or we would
	like to upgrade YAML first.

	One would think that Expect collects data and compares them to a pool of
	regular expressions each of which has an associated answer. As soon as
	one expression matches, its answer is given and it is taken out of the
	pool. On EOF do not even complain. Very similar to what we do now. Is it
	even worth to keep the current interface? Yes, because it has the
	potential to break. Because Expect itself does not provide it. We must
	write some code in between:

	Variant 1: match on /./, look at the whole collected string, do the
	match loop. On success do as we do now, on failure continue as we do
	now. On timeout do like we do now. On EOF exit the loop silently. As
	test write a distro that asks 12 questions in random order and dies if
	the wrong answer is given.

	Variant 2: match on /./ until timeout is reached. Now do your own
	matching. On success do as we do now, on failure give up. One question
	that we cannot answer is too much. There is no timeout error, just a "no
	prepared regex matches the question". On EOF exit the loop silently.

	Variant 2 is much better.

	Today I wrote CPAN-Test-Dummy-Perl5-Make-Expect-1.00.tar.gz for that.

	DONE

2006-11-11  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* So what does Randy's patch do?

	Disable {read,write}_metadata_cache
	Disable rd_{modlist,modpacks,authindex}
	sub sqlite_reload {
	On 'reload index' it runs its own sqlite_reload
	And 'exists' is patched.
	No patch to all_objects?

	How to use?

	o conf use_sqlite 1

% make run
/home/src/perl/repoperls/installed-perls/perl/peHlG5S/perl-5.8.0@29243/bin/perl -Ilib -MCPAN -eshell
CPAN: File::HomeDir loaded ok (v0.58)
CPAN: Term::ANSIColor loaded ok (v1.11)

cpan shell -- CPAN exploration and modules installation (v1.8861)
ReadLine support enabled

cpan[1]> o conf use_sqlite 1
Warning: unknown configuration variable 'use_sqlite'
    use_sqlite         [1]
Please use 'o conf commit' to make the config permanent!


cpan[2]> m CPAN             
CPAN: YAML::Syck loaded ok (v0.71)
Going to read /home/k/.cpan/build/
............................................................................DONE
Found 593 old builds, restored the state of 343
Updating database file ...
Can't exec "cpandb": No such file or directory at lib/CPAN.pm line 4152.
system cpandb --update failed: -1 at lib/CPAN.pm line 4152.
 at lib/CPAN.pm line 276
        CPAN::shell() called at -e line 1

	OK, let's patch the path to $^X in and retry:

% make run
/home/src/perl/repoperls/installed-perls/perl/peHlG5S/perl-5.8.0@29243/bin/perl -Ilib -MCPAN -eshell
CPAN: File::HomeDir loaded ok (v0.58)
CPAN: Term::ANSIColor loaded ok (v1.11)

cpan shell -- CPAN exploration and modules installation (v1.8861)
ReadLine support enabled

cpan[1]> o conf use_sqlite 1
Warning: unknown configuration variable 'use_sqlite'
    use_sqlite         [1]
Please use 'o conf commit' to make the config permanent!


cpan[2]> m CPAN
CPAN: YAML::Syck loaded ok (v0.71)
Going to read /home/k/.cpan/build/
............................................................................DONE
Found 593 old builds, restored the state of 343
Updating database file ...
Done!
Can't call method "set" on an undefined value at lib/CPAN.pm line 962.
 at lib/CPAN.pm line 276
        CPAN::shell() called at -e line 1


	Hmmm. So Randy wants to have use_sqlite to be set before we enter the
	shell and he wants it only within the shell. This is pretty likely
	wrong.

	Trying to set use_sqlite earlier with a tiny patch to Makefile.PL.
	Doesn't work because CPAN::SQLite loads MyConfig again according to the
	debugger:

	$ = require '/home/k/.cpan/CPAN/MyConfig.pm' called from file `/home/src/perl/repoperls/installed-perls/perl/peHlG5S/perl-5.8.0@29243/lib/site_perl/5.9.5/CPAN/SQLite.pm' line 50

	So we lose the switch again. Back to the drawing board.

	Either I need a way to use CPAN::SQLite without having it guess CPAN.pm
	internals all over the place. Or Randy needs a CPAN.pm that has API
	calls for all the CPAN.pm internals. I cannot allow a plugin that tries
	to reload the Config file and overwriting the Internals that I have
	currently set. This is happening and makes it hard to predict what will
	happen next.

	FIXED by Randy

	* Bug: When I tried to report MSCHWERN/B-Generate-1.06_2.tar.gz, it
	failed but did not try all 43 hosts.

Trying with "/usr/bin/lynx -source" to get
    http://mirror.eunet.fi/CPAN/authors/id/M/MS/MSCHWERN/B-Generate-1.06_2.tar.gz
Error while trying to rename '/home/k/.cpan/sources/authors/id/M/MS/MSCHWERN/B-Generate-1.06_2.tar.gz.tmp13806' to '/home/k/.cpan/sources/authors/id/M/MS/MSCHWERN/B-Generate-1.06_2.tar.gz': No such file or directory
 at lib/CPAN.pm line 267
        CPAN::shell() called at -e line 1

	Lynx again!

	Try
	/usr/bin/lynx -source http://mirror.eunet.fi/CPAN/authors/id/M/MS/MSCHWERN/B-Generate-1.06_2.tar.gz

	They send an error page that looks different than usual

	Fixed in SVK rev. 1298

	* degraded mode problems: I did an 'o conf commit' in degraded mode and
	blew away some config variables. We need a global that disallows commit
	from degraded shells. It would also disallow 'defaults' because that
	would restore the other config variables.

	DONE. But MAYBE we want to tie $CPAN::Config?

	* Bug: ~ expansion missing or warning demanded

	From: Adam Kennedy <cpan@ali.as>
Subject: Re: Trouble installing module: "LWP not available"
To: cpan-discuss@perl.org
Date: Wed, 08 Nov 2006 16:55:21 +1100

Andreas

Speaking of bad configs, I think I might be a good idea to start
adding some basic error checks.

Yesterday I got caught by the various paths not allowing the use of
tilde ~. Instead of my homedir, it installed to a directory called,
literally, "~".

Apart from being a little annoying, fixing it required I make the
scariest command I've ever done on a production system.

rm -rf "~"

:/

Adam K

	DONE in SVK rev. 1290


	* Bug: Still in the code: $pid = open README, "which $binary|" in
	_check_binary().

	Reported as #22893. See also File::Which.

	FIXED in rev.1294

	* "shall I try to run in degraded mode" should not come a second time
	within the same session. Currently it can happen.

	FIXED in SVK rev. 1292

2006-11-09  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Buglet: unshift of the recommended URL is not correct because then we
	have it twice in the array FIXED

	* Todo: write a hosts command that sums up what is in FTPstats. Offer
	randomness in the download selection. DONE

2006-11-08  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: somebody truncates the FTPstats file when YAML is not installed.
	Hopefully fixed in SVK rev. 1242

	* To: Florian Scharinger <florian@epcc.ed.ac.uk>
Cc: perl-qa@perl.org
Subject: Re: CPAN::Shell->install() downloads dependencies, but doesn't add them to @INC for tests
From: andreas.koenig.gmwojprw@franz.ak.mind.de (Andreas J. Koenig)
Gcc: nnml:sent
--text follows this line--
>>>>> On Wed, 08 Nov 2006 18:13:26 +0000, Florian Scharinger <florian@epcc.ed.ac.uk> said:

  > Hi perl-qa,
  > I'm trying to download missing Perl test modules automatically during
  > build time of my project, by using:

  >  use CPAN;
  >  CPAN::Shell->install("Test::Exception");

  > Test::Exception has dependencies, which the CPAN shell detects correctly:

  > ---- Unsatisfied dependencies detected during
  > [A/AD/ADIE/Test-Exception-0.24.tar.gz] -----
  >     Test::Builder
  >     Sub::Uplevel
  >     Test::Builder::Tester

  > The dependencies are downloaded and built, however, when then running
  > the tests for Test::Exception it doesn't include the path to the just
  > downloaded modules:

	ANSWERED.

	* Bug: 'o conf init urllist' it offered me lots of URLs without trailing
	slash, e.g. ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/CPAN but then
	some other code appended authors/ without inserting the slash:

cpan> reload index
Fetching with LWP:
  ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/CPANauthors/01mailrc.txt.gz
LWP failed with code[404] message[Can't chdir to CPANauthors]
Fetching with Net::FTP:
  ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/CPANauthors/01mailrc.txt.gz
  Couldn't cwd pub/Mirrors/CPANauthors: Failed to change directory.
Fetching with Net::FTP
  ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/CPANauthors/01mailrc.txt.gz.gz
  Couldn't cwd pub/Mirrors/CPANauthors: Failed to change directory.

	FIXED in SVK rev. 1240.

2006-11-07  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* randy kobes sent two patches--Thanks Randy, I'm swamped with work ATM

	* imacat writes in #22749:

	> I found that CPAN is NOT downloading CHECKSUMS alone with the
  > package file (*.tar.gz) from the SAME source.  This morning when I was
  > updating the newly-updated DBI-1.53, it cannot match CHECKSUMS with
  > DBI-1.53.tar.gz since they came from 2 different sources, and each has
  > its own mirror schedule.  The package file DBI-1.53.tar.gz came from a
  > mirror that has it, but CHECKSUMS came from another that doesn't have it
  > yet.  Shouldn't they be downloaded from the same mirror source?

	[the protocol shows how the fourth host succeeds for
	TIMB/DBI-1.53.tar.gz but CPAN.pm then fetches the CHECKSUMS file from
	the first]

	For young files there is often a short timespan within which there is no
	entry in the checksums file yet, even if they come from the same host.
	As you are always working with very young files, I'm surprised it
	doesn't happen more often to you.

	But in principle you are right, CPAN.pm should try to get checksums file
	from the same host because the likelihood is higher to get an uptpdate
	checksums file.

	sub _ftp_statistics
	sub _new_stats
	sub _add_to_statistics
	sub _recommend_url_for

	And then fill the stats hashref in each of the download methods
	individually:

	method, hosts tried with successmode, time finished, file size,
	timestamp!

	First working version with crappy stats (no nosuccess reflection) now
	tested with a couple of European sites in urllist and running

	!unlink "/home/k/.cpan/sources/authors/id/N/NW/NWCLARK/Acme-Meta-0.02.tar.gz"
	force test Acme::Meta

	in an endless loop looks good.

	Now todo: improve the statistics with above mentioned fields and with
	nosuccess data and actually honour the $file argument to
	_recommend_url_for() when a CHECKSUMS file is requested. Maybe make the
	randomness a selectable feature?

	FIXED
	
2006-11-04  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* https://rt.cpan.org/Ticket/Attachment/250710/107655/ is a bug in YAML
	combined with long strings. Would like to see if bleadperl also fails.

	Its parent is https://rt.cpan.org/Ticket/Display.html?id=22134
	
	I've put my findings in there. FIXED.

	* ALERT! A test in YAML turned red with blead??? It turns out that my
	YAML crashes bugs-rt when the URI module is installed and passes all
	tests when the URI module is not installed. The second test in bugs-rt.t
	has "skip_unless_modules: URI". So it's an older bug that I just did not
	see upto now. Bugreport to P5P written.

	* Da fällt mir ein, ich habs kürzlich anders gelöst, wenn du das nächste
  > mal testest, probier mal diese Lösung (mit AnyEvent, sinngemäß gehts
  > auch mit Coro):

  >    BEGIN { $ENV{PERL_RL} = "gnu" } use Term::ReadLine;

  >    my $rl = new Term::ReadLine "cfshell";

  >    my $w = AnyEvent->io (fh => $rl->IN, poll => 'r', cb => sub { $rl->callback_read_char });

  >    $rl->callback_handler_install ("$ARGV[0]> ", sub {
  >       $rl->add_history ($_[0]);
  >    }

  > Allein das $ENV...= läßt mich grausen, aber irgendjemand hat halt
  > entschieden, daß zwei völlig API-inkompatible module nicht getrennt
  > ladbar sein dürfen.

  > Ach ja, zum zwischendurch was ausgeben mache ich:

  >    $rl->crlf;
  >    print ...
  >    $rl->forced_update_display;

  > und beim exit muss man:

  >    $rl->crlf;
  >    $rl->deprep_terminal;

  > machen.

  > -- 
  >                 The choice of a
  >       -----==-     _GNU_
  >       ----==-- _       generation     Marc Lehmann
  >       ---==---(_)__  __ ____  __      pcg@goof.com
  >       --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
  >       -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE


2006-11-03  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-11-02  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Faszinating: Coro/eg/readline

2006-11-02  Andreas J Koenig  <akoenig@*c*nm*b*l*.com>

	* Oops! Something changed my
	t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Build-DepeFails-1.02.tar.gz

	!!! Ahh, that explains something! The copy I had here believed to be
	newer and "M", I should have reverted, I suppose.

	* 30shell fails because of missing checksum data after a force get.
	FIXED

	New ideas from Slaven: patch -p0/1/etc might be autodetected

	More match variables like all config variables or $^O ("os"?) and
	perlver.

	Finally: leaving back the .orig files (which I called -g0, why?) only
	when debugging turned on?? I think I'll remove -b and -g0 and use
	$ENV{PATCH_GET}=0 instead. Honorable mention: Text::Patch, unfortunately
	stalled.

2006-11-01  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Locking needs to be resolved soonish to enable safe concurrent
	megainstalls and concurrent running shells.

	I want to share the build_dir first because this is currently the most
	dangerous spot. I suppose we can have it by using File::Temp for the
	individual build_dir. We would have to turn off build_dir_reuse for the
	second process (Update 2006-11-17: Why?). Nobody would ever overwrite a
	build_dir. Some guys would remove old directories and this would do no
	harm. Should be done in rev. 1183.

	Even if the second uses the same perl as the first one, we could coexist
	because many commands scan the INC repeatedly. Things we do not scan
	again and again are ???

	historyfile: We would have to set histfile to nil for the second. DONE
	1181

	metadata: we would turn it off for the second. We could
	neither read nor write it safely without locking protocol. DONE 1181

	reading traditional index files: make writing atomic, let the second
	only read them (by setting expiration time to inf). DONE 1181 Actually,
	this was nonsense. the expiration time must not be changed. The user
	wants to read index files from time to time... REVERTED in 1188

	ability to reload index: turn off for the second DONE 1181

	storing/listing local bundles: risk REVISIT LATER

	local directories with the dot: risk REVISIT LATER

	shared source: make it atomic to download (if it isn't yet) DONE 1180

	Different perspective: batch jobs have not had a lock ever since CPAN.pm
	exists. They could break each other on any occasion. Did they write the
	histfile? Seems not so. Timestamp does not change with my tests and it
	does not say "Lockfile removed". Yes, checklock is only called from the
	shell (and from mkmyconfig but this is negligible). REVISIT mkmyconfig

	But they read metadata and shouldn't. Disable! DONE 1181

	And they reuse build_dir. Disable! DONE 1181

	But they MUST read the index files: make writing atomic! DONE 1180

	Is CPAN::FTP::localize doing its storage management atomicly? YES, since 1180

	Todo: consider setting scan_cache to "never" or maybe not.

	* Todo: compare the output of the 'failed' command within megainstall
	and after reentering the shell. DONE and found one bug and fixed it in
	rev. 1178

	* I wanted to watch some scenarios with persistent data. Especially with
	modules that work and that are being tested again and again with prereqs
	and without or within bundles and if they are retested or not, installed
	or not with persistence and within the same session.

	Write a megatest?

	* Wondering why I find this in the build directory in Crypt-CBC-2.22.yml:

  writemakefile: !!perl/hash:CPAN::Distrostatus 
    COMMANDID: 0
    FAILED: ''
    TEXT: YES

	Note the 0 in COMMANDID.

	A: The reason is that we only issued one command with 'make
	megainstall', so this is correct.

	* Does the shell still do locking? Under which circumstances is locking
	turned off? Console/terminal I suppose.

	A: yes.

2006-10-31  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* just a memo what I usually install:

	    install Bundle::CPANxxl Math::BigInt::GMP Plagger Bundle::Phalanx100 Jifty Coro Getopt::Euclid DBIx::Class IPC::PubSub Bundle::Pause PadWalker Graph::Easy

	YAML::Syck after Bundle::CPAN did not turn off interactivity.

	YAML::Syck before Bundle::CPAN worked well.

	CPAN::Reporter before YAML worked well but we want to catch the early
	YAML interactivity (which in turn can be avoided with YAML::Syck).

	Now all in "make megainstall" including logging.

	* Todo: some capture stuff maybe collected into the YAML files in
	build_dir that contains all relevant output of that distro so we can
	study the nonsense that currently goes on when I do my mega install on
	maint-5.8.

	For some reason some modules failed early in the cycle and then never
	got re-tested. And they broke others which also didn't get re-tested. In
	the end we had a lot of modules uninstalled that would test individually
	well but all refused to re-test without force.
	
	One simple solution was to 'force test Bundle::CPANxxl' but that took
	many minutes again.

	[What's the deal with PathTools? Ahh, the dependency on
	ExtUtils::CBuilder again. I have reported the bug but it is not yet
	fixed. FIXED in Bundle::CPAN by pulling CBuilder to the front,]

	For example the chain broke: CPAN::Checksums -> Data::Compare ->
	File::Find::Rule -> Number::Compare. I could install Number::Compare now
	when I asked for it (without force!), and then the chain could be
	resolved step after step.

	Something's fishy.

2006-10-30  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Q: Why is this: during install Bundle::Phalanx100 I get for
	DBD::Oracle a writemakefile NO
	'/home/src/perl/repoperls/installed-perls/perl/pIOeQkH/perl-5.8.0@29165/bin/perl
	Makefile.PL' returned status 65280

	When I leave the shell and start it again and call 'failed' it is gone.

	A: because we did not care for the state safe

	Fixed in rev. 1172

2006-10-30  Andreas J Koenig  <akoenig@*c*nm*b*l*.com>

	* From: "David Golden" <xdaveg@gmail.com>
Subject: CPAN::Reporter and Bundle::CPAN
To: "Andreas J. Koenig" <andreas.koenig.gmwojprw@franz.ak.mind.de>
Date: Mon, 30 Oct 2006 10:04:05 -0500                                           

With CPAN::Reporter 0.29, all the config items are switched over.  The
Todo backlog is still non-trivial, but I don't think any of the items
will cause back-compatibilty problems down the line.  Given that,
please feel free to add CPAN::Reporter to Bundle::CPAN whenever you
have a chance.

David

	* disable PerlMagick

2006-10-30  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* File::Slurp vs Pod::Coverage. Ticket opened:
	http://rt.cpan.org/Ticket/Display.html?id=22693
	
2006-10-29  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Need to write build_dir/*.yml files also if reuse is turned off. And
	also when we fail.

	* Need a 'disabled' keyword on distroprefs. The hack to use
	cpanconfig/make=false is both Unix centric and not obvious. ADDED in
	rev. 1159

	* distroprefs is harder to use with build_dir_reuse than before. We now
	need "force get" more often because the old prefs value is in the distro
	object. Force get can mean a network connection, so there's a need to
	decide how we want to deal with that.

	First idea is to remove the prefs from the serialized object but this is
	much worse in case a patch has been applied.

	* new method perl_fingerprint and _is_deeply or so to compare previous
	and current fingerprint. DONE in rev. 1158

	* Math::Pari was definitely broken by blead. Make it a bug report(?)
----Program----
eval {require Math::Pari};
print $@ ? "N/A" : Math::Pari->VERSION;
print "\n";

----Output of .../pAEBdqj/perl-5.8.0@24541/bin/perl----
2.010709

----EOF ($?='0')----
----Output of .../pIwwDvK/perl-5.8.0@24542/bin/perl----
N/A

----EOF ($?='0')----
Need a perl between 24541 and 24542

	This between Ilya and me:

> But bleadperl@29045 doesn't compile with:
> 
> cc -c  -I pari-2.1.7/src -Ipari-2.1.7/src/headers -Ipari-2.1.7/src -I./libPARI -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g   -DVERSION=\"2.010708\" -DXS_VERSION=\"2.010708\" -fPIC "-I/home/src/perl/repoperls/installed-perls/perl/pqbZHKu/perl-5.8.0@29045/lib/5.9.5/i686-linux-64int/CORE"  -DPARI_VERSION_EXP=2001007 -DDEBUG_PARI -DLSB_in_U32=0 -DLONG_SHORTER_THAN_IV -Derr=pari_err Pari.c
> Pari.xs:1219: error: 'XPVCV' has no member named 'xof_off'
> Pari.xs: In function 'XS_Math__Pari_DESTROY':

	xray searching for "Ilya CV attach" finds
	http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-02/msg00633.html

	Reading 24542.... Posting to P5P WRITTEN

	Answer received with a pointer to a previous discussion where Nicholas said

	|Assuming it is, in blead upgrading the PVCV to a PVFM and using
	| IV		xfm_lines;
	|instead should work. The structures are equivalent, except that PVFM
	|has that one extra IV at the end.

2006-10-28  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* think about the locking from a different angle: currently it is
	possible but unsafe to have concurrent access to the .cpan/build
	directory

	* go after the Module::Build errors in Error.pm and Mason: I suspect
	that's the set_perl5lib bug mentioned by Ilya. NO, it was not the
	set_perl5lib bug. The bug is that the two distros use subclassing in
	their Build.PL and so Module::Build's own methods are unable to provide
	the prerequisites. My workaround for now is to fall back to the content
	of META.yml, the bug persists and needs to be discussed with M:B people.

	* write a dummy distro that reads arguments to Makefile.PL and another
	one that reads something from STDIN (or maybe both in one) DELAYED until
	the distroprefs stuff leaves the alpha stage.

	* replace 03 index file with YAML.

	* Todo/buglet: turn on debug "CPAN" and find the reason why
	incommandcolor is quite often not reset. We had that further down but I
	fear it is not yet fixed.

	* H3 Locking: Linda W writes

	>I'm not sure I understand the reason for the lock file
	>placed in cpan_home.  If I have two different architectures
	>with different build directories, I'm not sure I understand
	>where the conflict is -- is it in storing/listing Bundles,
	>the history file, the Metafile or the shared source?
	
	>I can understand private history, but the Bundles aren't
	>updated often, the sources should be fairly static (unless
	>new files are downloaded), The metafile would be updated about
	>once a day (default).
	
	>If the build directories are separate, why would there be a
	>need for locking more in interactive use vs. batch use?

	And I promise to try out a more granular locking mechanism. This was
	between 2006-01-26 and 2006-02-01 (and I wrote a paragraph into the
	manpage how multiple ~/.cpan* directories could work)

2006-10-27  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Test if "reuse" works without metadata (timing issues because the
	entries do not exist yet?) No, it doesn't! FIXED in rev 1149

	* Investigate what happens if a user has CPAN 1.8802 and Module::Build
	0.2611 and tries to upgrade to 0.2805. Gabor says, it fails. If it
	fails, I'll have to coin a new phrase for the bug: install suicide? No
	need to worry, ATM it works more or less well, but it doesn't fail
	rightaway. CHECKED after rev. 1149 or so.

	* Rethink if Ilya's expire_old_builds is better the build_dir_reuse in
	that it sets an expiration date. His -1 is my 1. His 0 is my 0. I have
	nothing like his 30. The name of his variable is not good in that one
	could believe that setting expire_old_builds==0 might mean to do NOT
	expire them at all. Hmm. I think my build_dir_reuse is good enough.

	* Todo: invent a test for build_dir_reuse. It should construct a YAML
	file before test start that will then be picked up and lead to some
	"already in..." which we test for. And then we use force to actually get
	that distro. Or we do that for an inexistent distro so that we do not
	have to rewrite the test after each new release? DONE in rev. 1152

2006-10-25  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: if the user does not want to install a module (say a
	build_requires), give him options to use the already tested module even
	after he has left the shell.

	Ilya seems to say, people do NOT want to install a number of modules
	because they are not yet sure if they really need them. But they have
	tested them and have them still lying around in their ~/.cpan/build
	directory. So we should give them a chance to use them next time they
	come around with the same perl.

	DONE in rev. 1140 with build_dir_reuse

	* Todo: put the distro ID close to the OK or NOT OK line DONE in rev.
	1136 or so.

	* What was the deal with

Package 'CPAN' already declared with version '1.88_57'
ignoring new version ''.
Looks good

	again?

	http://www.mail-archive.com/module-build@perl.org/msg00340.html

	* Since DBI is fixed I see other interesting breakages: Class::DBI,
	RPC::PlServer, GD.

	GD fails with 5.8.8 and 5.8.3

	Class::DBI fails with 5.8.8

	RPC::PlServer fails with 5.8.8 and 5.8.3 but only if Crypt::DES is
	installed

	OK, so nothing new.

2006-10-24  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Coro 2.0 works with bleadperl Yay! YAML for Coro with default answers
	written.

	* bug with notest pragma: it seems to remain in the distro object. I did
	a report DAGOLDEN/CPAN-Reporter-0.28_51.tar.gz, then I did a "notest
	install" on it. Then I reloaded and tried a "report" on it again and
	CPAN refused to run the test because of the notest pragma.

	FIXED in rev. 1132 but what is a good test for it? test WRITTEN in 1133.

2006-10-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* The ->VERSION bug was back for a short while. It happens when
	version.pm is not installed and Module::Build loads its own version.pm
	from <data>. There it finds 0.661 and this does something that isn't
	fool proof, very hard to diagnose and to reproduce. Easy workaround: do
	not check for Module::Signature->VERSION anymore. The test was on 0.26
	and we now have 0.55, so I guess, I can remove the version test.

	As soon as I have means to not call into Module::Build, this bug will
	diappear for sure, so no need to hunt it down from here. FINISHED in
	rev. 1123

	So recall: one can turn off sig_check, then install version, then leave
	and enter CPAN.pm and the bug should disappear. Or we release 1.88_57
	now. Update: I released 1.88_57 immediately after that.

	* SMPETERS fixed DBI-1.52. Thank you! YAML for DBI with patch address
	written

2006-10-23  Andreas J Koenig  <akoenig@iconmobile.com>

	* make a list of cpanconfig variables that can be changed via
	distroprefs. Extend the list and document it, so that people can look it
	up and do not have to read the source and can file bug reports against
	it.

	I fear for example that the preferred builder is not configurable(?)
	latter half FIXED in rev. 1124

	First half done with rev. 1125

	* Write an executive summary of the state of affairs wrt. distroprefs so
	we can decide about future directions. Update the README file to better
	outline the executive summary. Update the examples to better reflect our
	powers and weaknesses.

	What we have:

	- Give the user a simple system to store per-distro preferences related
	to environment variables, commandline args and stdin for the four
	commands of our traditional mantra: perl Makefile.PL, make, make test,
	make install (and symmetrically for M:B modules)

	- Give the user the option to patch distros with arbitrary patches from
	local disk or CPAN

	What we aim at:

	- Give the users a simple means to exchange their preferences to reduce
	the overhead of maintaining them. As it currently stands, those YAML
	files devaluate quickly as new distros arrive.

2006-10-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* release a 1.8802 with the HTML::Mason workaround? Because it may take
	a while until 1.89 is ready to go. DONE in rev. 1120

2006-10-22  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: gzipped patches; DONE in rev. 1103

	* patches that are not separate files but live in the YAML file? REJECT
	unless somebody requests it.

2006-10-21  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* add CPAN::Reporter to Bundle::CPAN (which version of CPAN.pm needs
	CPAN::Reporter currently? -- 1.88) WAITING for OK from David Golden

	* Tina suggests: if the user has changed some config variable via 'o
	conf' mechanism and has not yet saved the new config via 'o conf commit'
	and is leaving the shell without saving, we could trigger a dialog.
	#22396 talks about this.

	After some thinking: maybe I prefer just a loud warning instead of a
	hanging terminal. Hmmm.

	This is a critical/showstopper thing because people perceive it as a
	bug. rev. 1114 FIXES

	* Todo: find out the remaining relevant pieces of Ilya's patch:

	(1) better logging (maybe with the help of CPAN::Reporter?) I said below
	that we have colors now, but fact is that you have to scroll back and if
	you install 100 modules, you cannot investigate without disturbing the
	process. One would like to study STDOUT and STDERR in a separate window.

	(2) "cpantok#" keep some test OK state between sessions. I see no strong
	need for this ATM.

	* just a memo what I usually install:

	    o debug CPAN Distribution
	    install YAML::Syck Expect YAML Bundle::CPAN Module::Signature CPAN::Reporter Math::BigInt::GMP Plagger Bundle::Phalanx100 Jifty

	YAML::Syck after Bundle::CPAN did not turn off interactivity.

	YAML::Syck before Bundle::CPAN worked well.

	CPAN::Reporter before YAML worked well but we want to catch the early
	YAML interactivity (which in turn can be avoided with YAML::Syck).

	* as long as HTML::Mason/Module::Build are broken, we should use
	Bundle::HTML::Mason? Alas, it doesn't list HTML::Entities. And after
	that it still fails on 07-interp.t. Ah, ok. Report sent. But can we
	patch it? DONE

	* Maybe add support for more CPAN::Config variables in distroprefs

	* Todo: document the trailing dot and that it is useful in a Bundle file
	and that there is a LOCAL.trailing_dot_distros.yml in the distroprefs
	directory. DONE in rev. 1093

	* Todo: extend patch ability to files from CPAN to be downloaded on the
	fly DONE in rev. 1089

2006-10-20  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* highest prio: patches. Easy to test with an example against one of my
	failing dummy distros. DONE in rev. 1086

	* add 'perl' to the matches stuff of distroprefs DONE in rev. 1087

	* When we have support for patches and apply patches, we should also
	disable reporting through CPAN::Reporter. DONE in rev. 1088

2006-10-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Ilya's patch

	svn cp -r 131 https://pause.perl.org:5460/svn/cpanpm/trunk https://pause.perl.org:5460/svn/cpanpm/branches/1.76-ilya200610

	https://pause.perl.org:5460/svn/cpanpm/branches/1.76-ilya200610 now lives in

	/home/k/sources/CPAN/SVN-branches/1.76-ilya200610/

	and the patch is applied and checked in. Ready for studying.

	Original discussion: google groups for prerequisites_policy expire_old_builds.

	Today I would suggest

	(1) prio 1!: organize patching into distroprefs, full path within the
	YAML file seems acceptable (DONE)

	(2) organize logging into distroprefs via redirection (might be easy but
	prio low because we have colors now)

	(3) keep the new meaning of the trailing dot, it does not interfere with
	patching as it is for *personal* distrodirectories (make sure it works
	with local bundles! (DONE[it did already])). For local distros one does
	not need patching (and if you do, you know what you're doing).

	(4) mark_tested_ok is similar to distcc/ccache and could probably be
	implemented as such. The time consuming step on perl distros is 'make
	test' and that makes it very complicated. One would need a checksum of
	perl AND all used modules during the test. Like for example File::Slurp
	failing with current combination of perl and Test::Pod::Coverage but
	succeeding without T:P:C

	Poor man's variant of it may be one that works only with a perl checksum
	or mtime as Ilya did. Still seems outside the scope of CPAN.pm but
	should be supported once it works outside with simple mantra.

	For now, distroprefs give you a different 'make' command for a
	permanently-known-to-be-tested module, that might be just 'true' on UNIX
	or something to do with distcc/ccache-like solution.

	That might be annoying if one works with different perls and want to
	have different modules marked as tested_ok. Maybe we need to add "perl"
	into the "match" structure? (Yes!) (DONE)

	(5) Faszinating is the idea to leave the shell and come back into the
	same state of already tested but uninstalled modules. But why are they
	not installed? Hrm, maybe because once installed, nobody will re-test
	them? Need further arguments.

	(6) install_tested is the normal default when running 'install' instead
	of 'test'. What's the deal?

	(7) containsdists is implemented but nowhere used, so what?

	(8) I have not yet understood the distinction between force_test and
	force_update and the call $self->test('install') seems bogus.

	* just a memo what I usually install:

	    o debug CPAN Distribution
	    force install Expect
	    install YAML Bundle::CPAN Module::Signature CPAN::Reporter Math::GMP Math::BigInt::GMP Plagger Bundle::Phalanx100 Jifty

	YAML::Syck after Bundle::CPAN did not turn off interactivity.

	YAML::Syck before Bundle::CPAN worked well.

	CPAN::Reporter before YAML worked well but we want to catch the early
	YAML interactivity (which in turn can be avoided with YAML::Syck).

	* From David Golden forwarded rt.cpan.org #20979

     head -13 C:/vanilla-perl/perl/lib/CPAN/Config.pm|tail -1
     'cpan_home' => q[C:\vanilla-perl\.cpan\],

		 The trailing backslash escapes the delimiter and creates a syntax
		 error. This is always reproducable for the latest release of CPAN:

	FIXED in rev. 1071.

	* In case somebody asks again, this is from Test::Harness 2.62

+2.62 Thu Jun  8 14:11:57 CDT 2006
+    [FIXES]
+    * Restored the behavior of dying if any subtests failed.  This is a
+      pretty crucial bug that I should have fixed long ago.  Not having this
+      means that CPANPLUS will install modules even if their tests fail. :-(
+

	This came into blead @28384.

2006-10-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Add Jifty to your regular testing.

2006-10-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Need to look after Math::Pari's errors DONE: 

	#ifdef LONG_SHORTER_THAN_IV
  #  error "LONG_SHORTER_THAN_IV not implemented"

	seems to be related to -Duse64bitint. Report to Ilya sent.

	* First thought: it would be cleaner if you just didn't pass any distro
  > with LOCAL as the author to CPAN::Reporter.  I'd rather leave the
  > logic of when CPAN::Reporter should be invoked to CPAN.pm.  (E.g.
  > Expect scripts)

	Good. I'll make that then.

	DONE in rev. 1061

	* More files to be marked with svn:ignore. DONE in rev. 1063

2006-10-16  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* two distroprefs files were in 1.88_55 but not in SVN:-( must write
	some code that prevents this bug from happening again.

	Snag is that ChangeLog, META.yml, SIGNATURE, and
	t/CPAN/authors/id/A/AN/ANDK/NotInChecksums-0.000.tar.gz are not intended
	to be checked in. --> svn:ignore DONE

	* new maint-5.8:
drwxr-xr-x  34 k k     8192 Oct 15 21:38 perl-m-5.8.0@29022/
drwxr-xr-x  35 k k     8192 Oct 15 21:19 perl-p-5.8.0@29023/

2006-10-15  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Investigate what's going on with Crypt::DH and Net::SSH::Perl. Both
	seem to hang during the tests. Might be a GMP issue. We must pull GMP to
	the front, otherwise Math::Bigint takes all the time (I suppose). Hrm,
	the DH test ran over hours even with GMP (but I'm not sure yet, need to
	make the observation control tighter).

	* Feature request by Slaven: build a patched thing. Reminds me of Ilyas
	words about something involving patches. Maybe (1) if the argument ends
	with a dot, it is a local directory: go there and build. (DONE in rev.
	1056) Maybe (2) keyword patch in distroprefs. (DELAYED indefinitely)

	* new maint-5.8:
	drwxr-xr-x  34 k k     8192 Oct 14 23:48 perl-m-5.8.0@29014/
	drwxr-xr-x  35 k k     8192 Oct 14 23:30 perl-p-5.8.0@29015/

2006-10-14  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Test installing Plagger with saying yes to all dependency questions.
	Needs 63 times "Y\n" :-) => say --defaultdeps instead of --installdeps=y
	DONE in rev. 1038

	* Add support for all(?) other CPAN::Config variables. Maybe by turning
	them all into methods in CPAN::Distribution, maybe via autoload, maybe
	with clever use of local(). Currently only "make",
	"make_install_make_command", and "build_requires_install_policy" are
	supported. The first two for PDL on freebsd, the last one was just for
	quick testing of the mechanism. Added test_report around rev. 1061

	* Randy Kobes' CPAN-Search-Lite lives at
	http://sourceforge.net/cvs/?group_id=101571 and on my local disk at
	/home/src/perl/cpan-search-lite/CPAN-Search-Lite. As it needs DBI, it
	cannot use bleadperl. Latest maint-perl is 28854.

	AI::Categorizer needed by t/basic.t, not listed as prereq. Needs in turn
	(unlisted?) Algorithm::NaiveBayes. Bug report to Ken sent.

	Warning: prerequisite Config::IniFiles 0 not found.
	Warning: prerequisite DBD::SQLite 0 not found.
	Warning: prerequisite File::Listing 0 not found.

	DBD::SQLite did not compile on the first try. But it did on the second.
	I think in between I installed libsqlite0-dev.

	Trying make test.

	No again: I have no Lingua::StopWords:=(
	No SOAP::Lite
	No Perl::Tidy
	No HTML::TextToHTML
	No Pod::Xhtml
	No XML::SAX::ExpatXS

	Finished installing prereqs, all tests except Mysql pass which is OK.
	(mysql fails for me only because my mysql has no password and you cannot
	specify on the commandline that it has no passwd. You can only specify A
	password but it must not be empty)

	make install is OK.

	First invocation of the indexer with

	/home/src/perl/repoperls/installed-perls/maint-5.8/pjTSIuN/perl-5.8.0@28854/bin/csl_index --config /home/src/perl/cpan-search-lite/cpan.conf --setup
Using config file "/home/src/perl/cpan-search-lite/cpan.conf"
Cannot retrieve /home/src/perl/cpan-search-lite/indices/ls-lR.gz from file:///home/ftp/pub/PAUSE/indices/ls-lR.gz at /home/src/perl/repoperls/installed-perls/maint-5.8/pjTSIuN/perl-5.8.0@28854/lib/site_perl/5.8.8/CPAN/Search/Lite/Index.pm line 198.

	Ouch, ls-lR.gz is used for what exactly? That's pure funet. I fetch it
	from there. It's huge (2.4M)! How often do they update it?

	/home/src/perl/repoperls/installed-perls/maint-5.8/pjTSIuN/perl-5.8.0@28854/bin/csl_index --config /home/src/perl/cpan-search-lite/cpan.conf --setup
Using config file "/home/src/perl/cpan-search-lite/cpan.conf"
Cannot retrieve /home/src/perl/cpan-search-lite/MIRRORED.BY from file:///home/ftp/pub/PAUSE/./MIRRORED.BY at /home/src/perl/repoperls/installed-perls/maint-5.8/pjTSIuN/perl-5.8.0@28854/lib/site_perl/5.8.8/CPAN/Search/Lite/Index.pm line 198.

	Gotta get this mirroredby file as well...

	% /home/src/perl/repoperls/installed-perls/maint-5.8/pjTSIuN/perl-5.8.0@28854/bin/csl_index --config /home/src/perl/cpan-search-lite/cpan.conf --setup
Using config file "/home/src/perl/cpan-search-lite/cpan.conf"
Argument "0.20a" isn't numeric in numeric comparison (<=>) at /home/src/perl/repoperls/installed-perls/maint-5.8/pjTSIuN/perl-5.8.0@28854/lib/site_perl/5.8.8/CPAN/Search/Lite/Util.pm line 274.
	[...]

	Ah, it's quite fast.
	

	* write a dummy distro that reads arguments to Makefile.PL and another
	one that reads something from STDIN (or maybe both in one) DELAYED until
	the distroprefs stuff leaves the alpha stage.

	* Measure kwalitee with Module::CPANTS::Analyse before uploading. That
	way we can catch bugs in M:C:A itself or in its dependencies. DELAYED
	because currently M:C:A doesn't pass its own tests.

	* write a test with new dummy modules PrerecqurseI and II (or CircDep?)
	Take t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make as the
	source and
	t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-CircDepeOne as
	target. DONE in rev. 1031

	* Schwern reopened 21144. Go resolve, I have promised before the next
	release. FIXED in rev. 1016 and 1018

2006-10-13  Andreas J Koenig  <akoenig@*c*nm*b*l*.com>

	* Slaven want direct support for $Config->{make} and
	make_install_make_command so that it can be set to gnumake for PDL on
	freebsd. DONE in rev 1015

	* Slaven says that no user knows the distroname as well as the module
	name. ==> Change the prefs hash structure. "qr" shall be replaced by
	"match" and contain "module" and/or "distro" which are ANDed conditions
	and each may contain a regex. We probably will rename all distroprefs
	files too. DONE in rev. 1013/14

2006-10-13  Andreas J Koenig  <akoenig@*c*nm*b*l*.com>

	* always check if *c*nm*b*l* has crept into the Todo file!

2006-10-13  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* check the version numbers since we rolled over rev. 1000. DONE, is OK

	* Fix what podcover found: prefs and yaml_loadfile DONE.

	* See if YAML::Tiny works and if so, mention it in FirstTime and maybe
	make it the default?? Doesn't seem to work out of the box. DONE and
	documented in FirstTime.

	* I hate Module::AutoInstall. Watching installation of Plagger:

  CPAN.pm: Going to build M/MI/MIYAGAWA/Plagger-0.7.13.tar.gz

make[1]: Entering directory `/home/k/.cpan/build/Plagger-0.7.13'
/home/src/perl/repoperls/installed-perls/perl/p4tTru3/perl-5.8.0@29004/bin/perl "-Iinc" Makefile.PL --config= --installdeps=File::Find::Rule,0,UNIVERSAL::require,0.1,Template,2.13,Template::Provider::Encoding,0.04,Text::Tags,0,DateTime::Format::Strptime,0,URI::Fetch,0.071,Cache::Cache,1.04,Module::Pluggable::Fast,0,HTML::ResolveLink,0,Date::Parse,0,MIME::Types,1.16,Net::DNS,0,XML::Feed,0.12,XML::Atom,0.23,Term::Encoding,0,XML::Liberal,0.14,XML::RSS::Liberal,0,HTML::Scrubber,0,XML::Feed,0.09,XML::Atom,0.20,HTML::Scrubber,0,Time::Duration::Parse,0,WebService::Bloglines,0.11
CPAN: File::HomeDir loaded ok (v0.58)
*** Installing dependencies...

	Holy crap! Recursive installation where we are just eager to maintain a
	clean and efficient queue of installation objects and could do it
	ourselves so easily? And besides that, the INC path is not our INC path,
	so I always get a different CPAN version. While the latter is only
	disturbing a minority, it's a BUUUUUUG to go recursive.

	Not only does it cost memory, this child is also uninformed about failed
	installations!

	This needs to be fixed.

	The manpage of M:AI says it checks if it is running under CPAN.pm. Maybe
	this check is wrong? Apparently yes.

2006-10-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* restructure the prefs YAML files to have cpanconfig as key and all
	CPAN.pm configs inside that. That gives room to cpanplus. DONE

	* why did MIYAGAWA/XML-Atom not work? -- Because it asked us twice but
	our yaml file only answered once FIXED.

	* improve feedback when you pick a file for prefs settings, maybe store
	the picked yaml file in the distro object. DONE.

	* test if you can get around single modules by specifying
	prefs->{make}{nosuchtarget}. Interesting for MailTools or DBI in current
	bleadperl. EXACTLY! (and tested)

	* test if the Test-Deep setting of brip works. DONE

2006-10-11  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* F/FD/FDALY/Test-Deep-0.096.tar.gz is just needed temporarily during building or testing. Do you want to install it permanently? (Y/n) [no] 

	* BTROTT/Crypt-DSA-0.14.tar.gz

==> Auto-install the 1 optional module(s) from CPAN? [n] 
==> Auto-install the 1 optional module(s) from CPAN? [n] 

	* PETDANCE/WWW-Mechanize-1.20.tar.gz

Do you want to install the mech-dump utility? [y] 

	* ABW/Template-Toolkit-2.15.tar.gz

Do you want to build the XS Stash module? [y] 

+ about 9 questions

	* BYRNE/SOAP-Lite-0.69.tar.gz

Press <enter> to see the detailed list.  

Do you want to proceed with this configuration? [yes] 

Do you want to perform these tests in addition to core tests? [no] 

	* RCAPUTO/POE-0.38.tar.gz

Would you like to skip the network tests?

(Any text other than Y or y will be taken as a no) [n] 

	* DBROBINS/Net-SSH-Perl-1.30.tar.gz asks

Which protocol(s) do you plan to use? [3] 
Enter your choices, separated by spaces: [1] 
Would you like to install it? (y/n) [y] 
Would you like to install it? (y/n) [y] 

	* ILYAZ/modules/Math-Pari-2.010706.tar.gz asks

Make sure you have a large scrollback buffer to see the messages.
Fetch? (y/n, press Enter) 

	* INGY/Inline-0.44.tar.gz asks for

Do you want to install Inline::C? [y] 

	* EESTABROO/IMAP-Admin-1.6.4.tar.gz asks me for...

Enter server: 
Enter login: 
Enter password: 
Test using SSL(y/n)? 
Test using CRAM(y/n)? 
Enter Port#: 

	* NIKIP/Authen-PAM: asks me for a password during testing and I enter
	"testing". Maybe I should enter exactly what he demands?

	* GBARR/perl-ldap-0.33 and ExtUtils::AutoInstall. Read source code. Same
	for GBARR/Authen-SASL-2.10 DONE

	* CHAMAS/SSLeay: the first distro that shows us that Expect needs a
	debugging aid. Maybe fixed in rev. 998 or so

	* Interesting bug occurred with current maint when I tried to upgrade
	everything. PathTools failed and I see this:

	cpan[3]> d  KWILLIAMS/PathTools-3.22.tar.gz 
Use of uninitialized value in sprintf at lib/CPAN.pm line 4258.
Distribution id = K/KW/KWILLIAMS/PathTools-3.22.tar.gz
    CPAN_USERID  P5P (The Perl5 Porters Mailing List <perl5-porters@perl.org>)
    CALLED_FOR   File::Spec
    CHECKSUM_STATUS OK
    CONTAINSMODS Cwd File::Spec File::Spec::Cygwin File::Spec::Epoc File::Spec::Functions File::Spec::Mac File::Spec::OS2 File::Spec::Unix File::Spec::VMS File::Spec::Win32
    UPLOAD_DATE  2006-10-10
    archived     tar
    build_dir    /home/k/.cpan/build/PathTools-3.22
    incommandcolor 0
    localfile    /home/ftp/pub/CPAN/authors/id/K/KW/KWILLIAMS/PathTools-3.22.tar.gz
    make         NO
    modulebuild  1
    prereq_pm    build_requires requires
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    prereq_pm_detected 1
	  ^^^^^^^^^^^^^^^^^^^^
    reqtype      c
    unwrapped    YES
    writemakefile YES
    yaml_content 

	But I cannot reproduce it. So I must have upgraded something that caused
	the bug. REVISITED after 1.88_54 and FIXED in 1043.

	* Since when fails a YAML test? 0.62 with blead @28990 fails today on
	rt-bugs.t or so. Reported to P5P. RESOLVED in blead @28997.

2006-10-10  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* put the distroprefs directory into MANIFEST. DONE in rev. 993

	* DistroPrefs:

	Variable           Comment                      Done in file

  pl env                                          DBROBINS.Net-SSH-Perl.01.yml
     args                                         GAAS.libwww.01.yml
     expect                                       JJORE.Carp-Clan.01.yml
  make env
       args
       expect
  test env           Tk-Getopt(BATCH=1)           SREZIC.Tk-Autoscroll.01.yml
       args
       expect        ReadLine                     ILYAZ.Term-ReadLine-Perl.01.yml
  install env
          args
          expect
	cpanconfig:
    build_requires_install_policy                 FDALY.Test-Deep.01.yml (???)


2006-10-09  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-10-08  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Nice to have: CPAN::MyDistroPrefs to store arguments and expect
	scripts to Makefile.PL/make/test/install based on regexes being matched
	against the distroname. (think libwww, ReadLine, perl-ldap, Apache-Test,
	and always questions from Module::AutoInstall, Carp::Clan asks if I want
	a prereq for testing from Makefile.PL, Net::DNS ask if I want to run
	tests over the internet, mod_perl or Apache::Test asks me for the apache
	executable, Authen-PAM asks me for a password, Module::Signature asks
	for importing the key)

	Name? DistroPrefs is good. Customize is not so good because one would
	expect that it is related to 'o conf'. Distro must be in the name.
	DistroCustomize is too long so DistroBuildEnv seems completely out of
	band. Only Prefs is tempting but again too easily confusable with 'o
	conf' stuff. Something completely different? Its about Env, Args, Stdin.
	BuildInput? Distrinput? Distrin? No. DistroPrefs the long word, prefs
	the short one. 'reload prefs' might be a command if we need it at all.

	ALL DONE in rev. 1015; well, left in alpha state

	* Todo/buglet: turn on debug "CPAN" and find the reason why
	incommandcolor is quite often not reset.

	First example is "Net::Stomp" with a prereq of Class::Accessor::Fast.
	After it and its prereq are installed, the module Class::Accessor::Fast
	and the distro K/KA/KASEI/Class-Accessor-0.25.tar.gz are both still in
	command state.

	So it's something with follow_prereqs.

	Seems to be fixed with rev. 980 but needs to stay on the watchlist

	No, I just tried Bundle::Phalanx100 and the majority of modules was in
	commandcolor and many were neither installed nor reported as failed, so
	the rev. 908 may be buggier than we ever were?? Maybe its just the "run
	it twice" problem due to late dependency resolving. Oh and watch the
	ugly bug that shows up when makeing Mason!

	AHHHH, that is fixable with eval! FIXED in rev. 981.

2006-10-07  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: clean up XXX

	* automatic testing? Is it anywhere documented what the impacts of
	$ENV{AUTOMATED_TESTING} are?

	* new keyword capture? CPAN::Reporter does not know the output of the
	commands before "test" and cannot report about compilation failures.
	This looks like a major flaw to me:-(

	* E1: Nice to have: make YAML vs. YAML::Syck switchable. Another
	advantage would be that we could remove YAML from the Bundle. DONE rev. 986

	* reload cpan should be based on timestamps. Fixed in rev. 979

	* Bug via Bundle::Phalanx100? Shortly after perl-ldap-0.33 I see 

Unknown require type for 'G/GB/GBARR/Convert-ASN1-0.20.tar.gz', setting to 'r'. This should not happen and is construed a bug.

	Later:
	
Unknown require type for 'A/AG/AGROLMS/GSSAPI-0.23.tar.gz', setting to 'r'. This should not happen and is construed a bug.

	Todo: see after it. I think it's AutoInstall.

	Fixed in rev. 979

2006-10-06  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: cpan[15]> install File::Copy::Recursive                   
Running install for module File::Copy::Recursive
Running make for D/DM/DMUEY/File-Copy-Recursive-0.28.tar.gz
  Is already unwrapped into directory /home/k/.cpan/build/File-Copy-Recursive-0.28
  Has already been processed within this session
Running make test
Prepending /home/k/.cpan/build/File-Copy-Recursive-0.28/blib/arch /home/k/.cpan/build/File-Copy-Recursive-0.28/blib/lib to PERL5LIB.
Sorry, test with a regular expression is not supported
Running test for module File::Copy::Recursive
Running make for D/DM/DMUEY/File-Copy-Recursive-0.28.tar.gz
  Is already unwrapped into directory /home/k/.cpan/build/File-Copy-Recursive-0.28
  Has already been processed within this session
Running make test
Prepending /home/k/.cpan/build/File-Copy-Recursive-0.28/blib/arch /home/k/.cpan/build/File-Copy-Recursive-0.28/blib/lib to PERL5LIB.
Refusing to autoload 'test' 'CPAN::Distribution=HASH(0x9b6ff30)' '/usr/bin/make test' in recursion
  /usr/bin/make test -- NOT OK
Running make for D/DM/DMUEY/File-Copy-Recursive-0.28.tar.gz
  Is already unwrapped into directory /home/k/.cpan/build/File-Copy-Recursive-0.28
  Has already been processed within this session
Running make test
  Won't repeat unsuccessful test during this command
  /usr/bin/make test -- OK
Running make install
Installing /usr/local/perl-5.8.8/lib/site_perl/5.8.8/File/Copy/Recursive.pm
Installing /usr/local/perl-5.8.8/man/man3/File::Copy::Recursive.3
Writing /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux-64int/auto/File/Copy/Recursive/.packlist
Appending installation info to /usr/local/perl-5.8.8/lib/5.8.8/i686-linux-64int/perllocal.pod

	What I had done was to install CPAN::Reporter but forgot the sudo for
	make. Then I added the sudo to make_install_make_command and did a
	'force get' and then the above. The install was successful in the end
	but the "Sorry" message was written in red and completely bogus and
	together with the 'Refusing to autoload' message was frightening.

	Showstopper!

	Trying to reproduce by setting both m*_install_*_command variables to
	"false", then install CPAN::Reporter. This gives a long list of failed
	installs at the end. Then 'install File::Copy::Recursive' works as
	expected: already tried without success. Then 'force get F:C:R' works as
	expected. And then again 'install File::Copy::Recursive' works as
	expected: tests again and tries to install.

	Shhhhhhh, so I cannot reproduce this, something must have been different.

	GIVEN UP: this did not show up again in any test

	* Who broke libwww recently?

	local/http-get........ok 1/20Use of uninitialized value in numeric eq (==) at local/http-get.t line 167, <DAEMON> line 1.
local/http-get........FAILED test 5                                          
        Failed 1/20 tests, 95.00% okay
local/http............ok 1/18Use of uninitialized value in numeric eq (==) at local/http.t line 158, <DAEMON> line 1.
local/http............FAILED test 5                                          
        Failed 1/18 tests, 94.44% okay


# HTTP/1.1 200 OK
# Date: Sat, 07 Oct 2006 04:16:57 GMT
# Server: libwww-perl-daemon/1.36
# Content-Type: text/html
# Last-Modified: Sat, 07 Oct 2006 03:29:15 GMT
# Client-Date: Sat, 07 Oct 2006 04:16:57 GMT
# Client-Peer: 192.168.0.75:45978
# Client-Response-Num: 1
# Title: En prøve
#
# <html><title>En prøve</title>
# <h1>Dette er en testfil</h1>
# Jeg vet ikke hvor stor fila behøver å være heller, men dette
# er sikkert nok i massevis.
not ok 5 # content_length=0


HERE [html] at ../blib/lib/LWP/MediaTypes.pm line 70.
size[0]mtime[1160191755] at ../blib/lib/HTTP/Daemon.pm line 531.

	Daemon.pm:
	sysopen(F, $file, 0) or 
	  return $self->send_error(RC_FORBIDDEN);
	binmode(F);
	my($ct,$ce) = guess_media_type($file);
	my($size,$mtime) = (stat _)[7,9];

	Tracked and reported to P5P. FINI.
	
	* Todo: Write a new test: If one prerequisite doesn't pass its tests, we
	sure want to test the dependent module but it must not be installed. I
	have no example at hand.

	First continue fixing dummy-Build and dummy-Make distros (and maybe
	more), then make one that is depending on dummy-Fails. DONE in rev. 973

	And write the new test for it. DONE in rev. 975
	
	* Gabor reports #21692: how to reproduce? Just get a 5.8.7 and call
	upgrade on it. No, take a 5.8.8 and silently replace B::Concise with the
	5.8.7 one. OR: take some maint-5.8 short before 5.8.8! Where to find the
	patch number for 5.8.8? Module::CoreList!

	% perl -MModule::CoreList -le 'use Data::Dumper;print Dumper(\%Module::CoreList::patchlevel);' 
	[...]
          '5.008008' => [
                          'maint-5.8',
                          27040
                        ],

	Paging through diff files in APC/5.8.1/ reveals: 25914 updated
	PPPort.pm, 26929 Pod::Simple, 26985 Archive::Tar, 26988 Pod::Man, so I
	expect 26984 a good test candidate.

	My current 26984 replies to "r" command with....no 5.8.8?

	Strange! Why no 5.8.8? Ahhh, because it had no Archive::Tar and Pod::Man
	is on podlators 2.0.5.

	Trying 26876: no good.

	26727: Good! 26727 wants to upgrade Dumpvalue and bring it ot
	perl-5.8.8. I upgrade everything in 26727 except for Dumpvalue. Being
	time consuming, this needs a backup generated with

	tar cvzf p-26727plus-near-588.tar.gz installed-perls/maint-5.8/pbyWflA/perl-5.8.0@26727

	Gabor requests less noise, otherwise he consideres behaviour correct.
	Hrm, think about it...

	FIXED in rev. 963.
	
	* Bug: during 'o conf defaults' I get

Debug(HandleConfig,HandleConfig.pm,95,[Shell,CPAN.pm,1401,edit]): self[CPAN::HandleConfig]args[defaults]
Can't locate CPAN/MyConfig.pm in @INC (@INC contains: _build/lib _build/lib _build/lib _build/lib /home/k/sources/CPAN/SVN/lib /home/src/perl/repoperls/installed-perls/perl/pGHVCgA/perl-5.8.0@28914/lib/5.9.4/i686-linux-64int /home/src/perl/repoperls/installed-perls/perl/pGHVCgA/perl-5.8.0@28914/lib/5.9.4 /home/src/perl/repoperls/installed-perls/perl/pGHVCgA/perl-5.8.0@28914/lib/site_perl/5.9.4/i686-linux-64int /home/src/perl/repoperls/installed-perls/perl/pGHVCgA/perl-5.8.0@28914/lib/site_perl/5.9.4 /home/k/sources/CPAN/SVN) at (eval 512) line 1, <GEN331> chunk 1.
Use of uninitialized value within %INC in concatenation (.) or string at /home/k/sources/CPAN/SVN/lib/CPAN/HandleConfig.pm line 285.
'' reread

	Fixed in rev. 958

	* Bug: cpan[4]> install CPAN::Reporter
Running install for module CPAN::Reporter
Running Build for D/DA/DAGOLDEN/CPAN-Reporter-0.24.tar.gz
  Is already unwrapped into directory /home/k/.cpan/build/CPAN-Reporter-0.24

  CPAN.pm: Going to build D/DA/DAGOLDEN/CPAN-Reporter-0.24.tar.gz

Creating custom builder _build/lib/Module/Build/WikiDoc.pm in _build/lib/Module/Build
Checking whether your kit is complete...
Looks good

Checking prerequisites...
Package 'CPAN' already declared with version '1.87_64'
ignoring new version ''.
 - ERROR: IO::CaptureOutput is not installed
 - ERROR: File::Copy::Recursive is not installed
 - ERROR: CPAN (1.87_64) is installed, but we need version >= 1.88

ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the versions
of the modules indicated above before proceeding with this installation

Creating new 'Build' script for 'CPAN-Reporter' version '0.24'
lib/CPAN/Reporter.pm -> blib/lib/CPAN/Reporter.pm
lib/CPAN/Reporter.pod -> blib/lib/CPAN/Reporter.pod
Manifying blib/lib/CPAN/Reporter.pod -> blib/libdoc/CPAN::Reporter.3
  ./Build  -- OK
Running Build test
  The version of your Test::Harness is only
  '2.56', you need at least '2.62'. Please upgrade your Test::Harness.
Running Build install
Installing /usr/local/perl-5.8.7/lib/site_perl/5.8.7/CPAN/Reporter.pm
Installing /usr/local/perl-5.8.7/lib/site_perl/5.8.7/CPAN/Reporter.pod
Installing /usr/local/perl-5.8.7/man/man3/CPAN::Reporter.3
Writing /usr/local/perl-5.8.7/lib/site_perl/5.8.7/i686-linux-64int/auto/CPAN/Reporter/.packlist
  sudo ./Build install --uninst 1 -- OK

	Showstopper II! The test refused to run with the reference to
	Test::Harness but the install succeeded nonetheless:(((

	Fixed in rev. 954.

	* Finish the debugging aid of reload. Current code (rev. 953)
	allows

% perl -Ilib -MCPAN -e '
my $ix = bless {}, CPAN::Index;
$ix->reload(shift)' /home/ftp/pub/PAUSE/modules/02packages.details.txt 
CPAN: File::HomeDir loaded ok
CPAN: Term::ANSIColor loaded ok
CPAN: LWP::UserAgent loaded ok
CPAN: URI::URL loaded ok
Going to read /home/ftp/pub/CPAN/authors/01mailrc.txt.gz
CPAN: Compress::Zlib loaded ok
............................................................................DONE
Going to read /home/ftp/pub/CPAN/modules/02packages.details.txt.gz
  Database was generated on Sun, 01 Oct 2006 18:39:54 GMT
............................................................................DONE
Going to read /home/ftp/pub/CPAN/modules/03modlist.data.gz
............................................................................DONE

	But it reveals unacceptable timing when run via 'reload index'. Timing
	is much better when called as above. Quite confusing is the fact that
	03modlist does not print dots during reload but does so on first time.
	So more debugging called for. FIXED in rev. 956

	* Bug: the line number in the Debug messages is very often wrong. FIXED
	in rev. 955

	* E3 prerequisites: require perl version xxx: we should not delete that
	information but honour it. DONE in rev. 952

	* Todo: do the right thing with prereq "perl". Find modules suited for
	testing.

	"5.8.3" : File-BOM-0.12, XML-DOM-Lite-0.08, Business-ReportWriter-0.09

	">= 5.8.0" : Devel-FIXME-0.01

	">= 5.008" : Data-Visitor-0.05

	"0" : Net-Address-IPv4-Local-0.12

	"" : Net-IRC2-0.27

	The full list of found requires to "perl" today is:

	5.002|5.000|>= 5|>= 5.6|5.6|5.8|5.8.4|>= 5.8.0|5.8.2|5.8.7|5.5.3|5.8.3|>= 5.6.0|5.004|>= 5.008|5.005_03|0|5.5.0|5.4.5|5.00307|5.00503|5.8.0|5.005|5.008|5.7.1|>= 5.005_04|5.007|5.8.1|5.005003|5.6.0|5.006|5.6.1|5.7.3|5

	DONE in rev. 952

	* Todo: investigate if we want a different amount of newlines depending
	on readline availability. Who is it who displays the extra newline as
	soon as readline is active? It is apparently coming from readline and I
	see no reason to interfere. REJECT

	* Todo: send a patch to P5P that adds Queue.pm to the MANIFEST.

	* Todo: add to 30shell the case of repeated testing that was fixed in
	rev 915

	* Attention when testing: Lingua::Alphabet::Phonetic::Password makes
	Test::Pod a "build_requires"; Lingua::Alphabet::Phonetic makes it a
	"requires" instead. So we have it both as "r" and "b" in the queue and
	the first one wins over the other. So once we have something not
	installed due to "b", we cannot install it anymore unless we use
	force:-( It would be nice to make this less confusing for the user and
	resolvable without force for the expert.

	This warrants new tests in 30shell. Let's do diamond dependency:
	CPAN-Test-Dummy-Perl5-Build shall build_require
	CPAN-Test-Dummy-Perl5-Make and require CPAN-Test-Dummy-Perl5-Make-Zip.
	And CPAN-Test-Dummy-Perl5-Make-Zip shall require
	CPAN-Test-Dummy-Perl5-Make. We have not tested install yet (I think) and
	we can try to set make_install_make_command to a perl oneliner or so.
	This constallation shall try to install CPAN-Test-Dummy-Perl5-Make
	because requires trumps build_requires.

	Interactive testing strategy right now:

	rm -f /home/src/perl/repoperls/installed-perls/perl/prCXKHM/perl-5.8.0@28904/lib/site_perl/5.9.4/CPAN/Test/Dummy/Perl5/Build.pm /home/src/perl/repoperls/installed-perls/perl/prCXKHM/perl-5.8.0@28904/lib/site_perl/5.9.4/CPAN/Test/Dummy/Perl5/Make/Zip.pm
	make run

	o debug Distribution Queue Shell Module
	o conf build_requires_install_policy no
	install CPAN::Test::Dummy::Perl5::Build

	DONE in rev. 941

	* H3 Todo: JV suggests treating build_dependencies differently

	To: Johan Vromans <jvromans@squirrel.nl>
	Cc: modules@perl.org
	Subject: Re: Module requirements
	X-Draft-From: ("king-2002" 44465)
	From: andreas.koenig.gmwojprw@franz.ak.mind.de (Andreas J. Koenig)
	Gcc: nnml:sent
	--text follows this line--
	>>>>> On Sun, 02 Apr 2006 14:59:33 +0200, Johan Vromans <jvromans@squirrel.nl> said:

		> andreas.koenig.gmwojprw@franz.ak.mind.de (Andreas J. Koenig) writes:
	 >> Would you really trust that the authors get it right? I didn't and so
	 >> threw the two sorts of dependencies into one basket.

		> Currently, there is no way to make the distinction so there is no real
		> incentive to make the distinction correctly. This could change if a
		> mechanism were available.

	Good point.

	 >> How much pain does the clobbering of the production environment
	 >> cause you?

		> The production environment is also the reference environment. If a
		> module requires something that is not in the production environment,
		> any additional requirements should be added very carefully. Every
		> extension to the production environment is something extra to
		> maintain, and I think it is a very valid argument to try to minimize
		> this.

	Very true.

		> Actually, this question was triggered when I recently tried to install
		> Bundle::CPAN. When it wanted to install a product called Spiffy I
		> decided to hit the cancel button and investigate.

	That brings me to the idea that it would be nice to add these
	build-dependencies into ./blib/bdep or some such idf they are not
	available. I put it on my Todo list.

	-- 
	andreas

	DONE in rev. 941

2006-09-28  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: test bundles and reqtype; especially when you do NOT install
	things because this opens new branches of code execution DONE

	* Todo: ... and finally we will have to carefully differentiate what we
	do with the things that we get off the queue: breqs shall not be
	installed. And we need a user pref here: treat build_requires as
	requires would have the advantage that the build_requires stuff be
	installed and may save time on the next occasion.

	This needs to be coordinated with David because it breaks
	CPAN::Reporter. Hi, Dave!

	New config option build_requires_install_policy: yes|no|ask/no|ask/yes

	DONE in rev. 916

	* Bug: build_requires that are not installed currently are being tested
	more than once within a single command. Maybe the same bug as described
	below under "Very stupid is CPAN.pm..." FIXED in rev. 915

2006-09-27  Andreas J Koenig  <akoenig@*c*nm*b*l*.com>

	* Todo: canonify usage of req/reqtype/etc. into "reqtype" and shorten
	the known reqtype to one letter: r,b,c and comment on them in
	Queue::reqtype DONE in rev.913

2006-09-27  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* New warnings

Use of uninitialized value in exists at lib/CPAN.pm line 3874, <FH> line 41067.
Use of uninitialized value $id in delete at lib/CPAN.pm line 793, <FH> line 41067.
Use of uninitialized value $id in delete at lib/CPAN.pm line 794, <FH> line 41067.

	?? Cannot reproduce, maybe due to excessively hitting ^C in the wrong moment?

2006-09-25  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* find out since when Expect has a failing test with bleadperl. Take
	test #38 alone and do a binary search on it. 26453 has already once been
	involved in an Expect case. Yes, this might mean we have to make
	suggestions for Expect too: which constants are imported erroneously and
	which correctly and how to make this valid for old and new perls? DONE
	see RT #21723.

2006-09-24  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* build_requires: fortunately the things on the Queue are objects with
	currently only one attribute "qmod", the string.

	    install Bundle::CPAN CPAN::Reporter Expect Module::Signature Devel::Symdump

	First step is to change the constructor to accept more arguments DONE in rev 889

	Next thing will be to go through the chain prereq_pm (where we must not
	merge req and breq)[DONE in rev. 900],
	CPAN::Distribution::color_cmd_tmps
	(where we must mark both req and breq)[DONE in rev. 900], unsat_prereq
	(where we must handle both req and breq)[STARTED in rev. 900, but still
	in need of a differentiation of @need_req and @need_breq or so; FINISHED
	in rev. 902] and follow_prereqs (where we must look closer on jumpqueue
	and handle req and breq differently and make sure that the inheritance
	is correct: reqs of breq are only breqs)[WIP when 910 is being checked
	in; finished in rev. 913] See continuation above "and finally we
	will..."

2006-09-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* So what was 886 about? Put CPAN::Queue in its own file.

	* Bug introduced between 881 and 886. If a Module::Build module fails,
	we happily take it as an OK. CPAN-Test-Dummy-Perl5-Build-Fails reveals
	the bug. Going back step by step with 'svn up -r XXX' we see what was
	broke too: 885, 884, 883, 882, 881!!!

	What!??? 881 was a release! Between 879 and 881 no code changed.

	878 was a bit different. And 877. And all have this bug suddenly.

	So I start to believe it is a bug in the maint-5.8 branch or in some
	module we installed since. My maint is 28854 right now.

	Testing again with bleadperl and 886: NOT BROKEN!

	The only two modules out of date in my blead are Class::Accessor and
	version.pm.

	Outdated modules in current maint-5.8:

	CGI CPAN Devel::PPPort Digest Encode ExtUtils::Command ExtUtils::Install
	ExtUtils::Manifest ExtUtils::ParseXS IO Locale::Maketext Math::Complex
	Sys::Syslog Term::ANSIColor Test::Builder Test::Harness Text::Balanced
	Text::Soundex Text::Tabs Tie::RefHash Time::HiRes Time::Local
	Unicode::Normalize threads threads::shared

	Updated as much as I could and ALL IS WELL.

	So now we don't know who was to blame. Restarting over and going step by
	step: it was Test::Harness 2.58. So we have a difficult-to-explain
	dependency here: CPAN + Module::Build-deploying modules + Test::Harness
	< 2.62 leads to not recognized test failures. I put Test::Harness into
	the Bundle::CPAN. Maybe I must verify the Test::Harness version before
	testing MB modules? FIXED by making T:H 2.62 a PREREQ_PM and testing
	again in the code. In rev. 888

	* Todo: 'dump symbol', say 'dump $CPAN::META'. But pipe into the pager
	for large datasets! DONE in rev. 885

	* build_requires: need two modules that have build_dependencies which I
	do not install and still both must build. This means, I inject the
	build_dependencies into the queue and flag them as build_dependency
	which then leeds to a simple make or test for them, never to an install.
	Up to now we use set_perl5lib during CPAN::Distribution::test. In the
	future we would need a similar vein during the two earlier stages,
	{Makefile,Build}.PL and make. Yes, this should do.

	Where are our build_requires? I keep forgetting the URL where Randy Sims
	provides so useful statistics. Here it is:
	http://thepierianspring.org/perl/meta/

	And the build_requires page is here:
	http://thepierianspring.org/perl/meta/fields_in_use/build_requires.html

	But manually skimming the 876 distros is tedious, so I need again my own
	script.

	One thing is complicated: when a module is a build_prereq, then all
	*its* prereqs are also degraded into build_prereqs unless they are
	already prereqs for something else:-! And then we have the diamond
	dependency: Foo build_requires Bar and requires Baz. Bar requires Frob,
	Baz requires Frob. So we make it a bit operation: REQ => 1, BREQ => 2?

	OK, candidates for my tests:

	MARCEL/Class-Null                         Test::Pod::Coverage

	Not suited for testing. It has a Build.PL that requires Project::Build
	which does not exist at all and when a user preferes Module::Build over
	ExtUtils::MakeMaker he fails immediately. It has a Makefile.PL that has
	Test::Pod and Test::Pod::Coverage as PREREQ_PM and it has a META.yml
	that tells me that Test::Pod and Test::Pod::Coverage are build_requires.
	But when I grep for Test::Pod and Test::Pod::Coverage, they are not
	mentioned anywhere. The solution would be to remove the Build.PL and the
	META.yml and remove the PREREQ_PM lines in the Makefile.PL.
	
	JFITZ/Lingua-Alphabet-Phonetic-Password   Test::Pod::Coverage

	Need to set prefer_installer MB because it comes with a Makefile.PL. The
	dependecy graph seems to get very large. Test::NoBreakpoints failes its
	tests. But in the end, L:A:P:P passes its four tests quickly and skips
	the one that need Test::NoBreakpoints. Vorbildlich!

	Very stupid is CPAN.pm when I repeat the 'test L:A:P:P' command: it
	repeats all tests for all dependencies and only then runs the test on
	L:A:P:P. This is time-consuming and may be a bug or a feature. Don't
	know the reason. FIXED in rev. 915
	
	ATRICKETT/Config-Trivial                  Test::Pod::Coverage

	ADIE/Test-Class          Test::Differences
	KCLARK/SQL-Translator    Test::Differences   # not good for testing
	SPOON/WWW-Yahoo-Groups   Test::Differences

	CHROMATIC/Class-StorageFactory  Test::Pod
	MTHURN/Net-Address-Ethernet     Test::Pod
	RCLAMP/Class-Persist            Test::Pod

2006-09-21  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* I have seen this bug with 5.6.2, 5.8.3, 5.8.4, 5.8.5; it seems not to
	effect bleadperl and 5.8.8, 5.8.6-RC1

	Once you have installed both Module::Signature AND CPAN::Reporter, you
	cannot test both of them in the same session. E.g. with 5.8.4 I do

	test Module::Signature
	--> tests ok, do you want to report? no,no,no
	test CPAN::Reporter
	--> tests ok, debug says "main: distribution\nmain:\
	comments\nCPAN::Reporter defines neither package nor VERSION--version\
	check failed at (eval 70) line 405."
	test Module::Signature
	--> tests ok, debug says "main: distribution\nmain:\
	comments\nCPAN::Reporter defines neither package nor VERSION--version\
	check failed at (eval 70) line 405."

	"version check failed" is in
	/usr/local/perl-redhat-5.8.5/lib/5.8.5/pod/perldiag.pod:

=item %s defines neither package nor VERSION--version check failed

(F) You said something like "use Module 42" but in the Module file
there are neither package declarations nor a C<$VERSION>.

	So I spot this line in CPAN::Reporter:

    $tr->via( 'CPAN::Reporter ' . CPAN::Reporter->VERSION );

	and I change it to

    $tr->via( 'CPAN::Reporter ' . $CPAN::Reporter::VERSION );

	and the bug is worked around.


2006-09-20  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* #  FAIL  DBIx-Timeout  1.01 350359 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)
# PASS Net-SDP 0.07 350354 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)
# PASS GIS-Distance 0.01000 350352 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)
# PASS Class-Measure 0.02 350351 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)
# PASS WWW-Pagination 0.35 350350 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)
# PASS Socket-Multicast6 0.01 350348 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)
# PASS IO-Socket-INET6 2.51 350347 5.8.8 on Netbsd 3.0 (i386-netbsd-thread-multi-64int)

	Repeating experiments with CPAN::Reporter and Net::SMTP and AUTOMATED_TESTING

	I just started with a fresh blead@28875 and the command

	    install CPAN::Reporter Bundle::CPAN Module::Signature Devel::Symdump

	and all reports that CPAN::Reporter offered were accepted by me. So
	tomorrow morning I expect reports on testers.cpan.org above the FAIL for
	DBIx-Timeout. Then I can install Mail::Send again and send a few reports
	and then I can set AUTOMATIC_TESTING and on the next perl I can do that
	in opposite order.

	7 hours later nothing shows up on http://testers.cpan.org/recent.html

	I'd better go subscribe to cpan-testers. Now I am subscribed and I
	re-tested with blead@28876 and while Mail::Send does send out messages
	since I added the MASQUERADE_AS line, they do not come back to me. I
	need to change the email_to to me on the next try.... And yes, the mail
	arrives. Apparently it is not accepted at testers, only Net::SMTP gets
	through. Maybe some MX thingie going on.

2006-09-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* repeating the exercise of testing CPAN::Reporter

	blead@28868: install CPAN::Reporter and its dependencies (no MailTools
	but Net::SMTP ist there). Testing TAPx::Parser fails miserably, the
	report seems to be sent. Testing CGI::Session succeeds with lots of
	SKIPs. The report seems to have been sent. Testing Module::Signature
	succeeds with just a single test, report seems to have been sent.
	Installing CPANPLUS::Dist::Build installs among many other dependencies
	CPANPLUS itself, the latter succeeds and I let CPAN::Reporter send a
	mail which seems to work.

	Now I install Mail::Mailer and succeed. The Mail is still sent by
	Net::SMTP and apparently succeeds.

	Now let's try IO::Tty. Tests succeed but it's a test.pl based distro, so
	CPAN::Reporter cannot send mail. To get to a quick end, I now test
	CPAN::Reporter itself. It pretends to send mail, from the debug output I
	recognize Mail::Mailer. And now I have two mails in the mqueue with
	"Could not resolve k75.linux.bogus". QED.

	MASQUERADE_AS(`franz.ak.mind.de')dnl in the sendmail.mc seems to have
	done the trick.

	* find out why CPAN::Reporter cannot send mail on my home machine

	Somebody seems to try to send mail and using the local address
	(k75.linux.bogus) in a HELO or something. I'm testing with
	Devel::Symdump.

	Installed modules? Mail::Send from MailTools? Net::SMTP from libnet?

	MailTools no, N:S yes.

	Ah, Test::Reporter says "If you have MailTools installed". Hmmm. This
	test succeeded today with blead@28866. Will have to wait again to see a
	fail.

	So now I have MailTools installed and now I see again the message

% mailq
MSP Queue status...
/var/spool/mqueue-client is empty
                Total requests: 0
MTA Queue status...
                /var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
k8J6VCVD013108     3070 Tue Sep 19 08:31 <k@k75.linux.bogus>
                 (Deferred: 450 Could not resolve k75.linux.bogus)
                                         <cpan-testers@perl.org>
                Total requests: 1

	This is the debugging output of {CPAN,Test}::Reporter:

Sending test report with 'pass' to cpan-testers@perl.org
Test::Reporter: debug
Test::Reporter: send
Test::Reporter: debug
Test::Reporter: from
Test::Reporter: debug
Test::Reporter::Mail::Util: _mailaddress
Test::Reporter: debug
Test::Reporter: report
Test::Reporter: debug
Test::Reporter: subject
Test::Reporter: debug
Test::Reporter: _verify
Test::Reporter: errstr
Test::Reporter: debug
Test::Reporter: _have_mail_send
Test::Reporter: debug
Test::Reporter: _mail_send
Test::Reporter: via
Test::Reporter: address
Test::Reporter: debug
Test::Reporter: from
Test::Reporter: debug
Test::Reporter::Mail::Util: _mailaddress
Test::Reporter: debug
Test::Reporter: subject
Test::Reporter: debug
Test::Reporter: mail_send_args
Test::Reporter: debug
Test::Reporter: _have_mail_send
Test::Reporter: debug
Test::Reporter: report

	Need to repeat the process and then report as a bug.

2006-09-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-09-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Test the urllist dialog. Requires a fake mirrored.by file. DONE in rev. 851

	* Todo: test many cases:

	if we have a urllist, if have none: can we always hit RETURN and reach
	the end, especially if we already have a previous pick? Once upon a time
	the user may have been able to reach the previous pick from the
	continent question. The hint is the $no_previous_warn variable.

	if we say 'o conf init'...yes/no (yes is what the shell test does, so
	there's no need here to investigate this branch)

	What's about the SPACE RETURN thing, is it broken and since when? It
	seems it works again, maybe since rev. ???

	* http://www.flight.us/misc/FirstTime.pm_AStrebkov.htm (E3) and
	http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/a3f172fedc02c280/5814e81793793b64#5814e81793793b64
	by Andrew Strebkov makes the URL selection nicer.

	It allows hyphenated ranges like 10-14. It also fixed the SPACE RETURN
	bug that seems to be fixed now anyway. DONE in rev 848

	* MAYBE change syntax for 'o conf init MATCH' to require two slashes for
	the regex version just for ortogonality. REJECTED because this argument
	does not have the same magic as other arguments that may be several
	different types of strings.

	* The $demobug thing is underdocumented! Go after the bug hidden there.
	FINISHED
	
	* Todo: write a test that checks if the keys in HandleConfig are all
	documented in the POD. DONE in rev. 831

2006-09-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* rev 807 broken (and _62 was most likely broken too): prompt namespaces
	now too much voodoo. FirstTime::_real_prompt is not defined everywhere.
	Goto the drawing board

	CPAN::Shell::colorable_makemaker_prompt used in package CPAN and
	CPAN::Distribution uses ExtUtils::MakeMaker::prompt

	CPAN::FirstTime::_real_prompt is local in CPAN::FirstTime::init for
	colorizable and later for a closure and yet later again directly for
	colorizable again

	CPAN::FirstTime::prompt is used within CPAN::FirstTime::init many times

	my_dflt_prompt uses prompt

	my_yn_prompt uses prompt

	my_prompt_loop uses prompt

	conf_sites uses prompt

	picklist uses prompt

	bring_your_own uses prompt

	prompt uses _realprompt

	Q.E.D. _real_prompt  may be undefined. Stupid. FIXED in rev. 825

	825 also fixes 5.8.0 which always matched each prompt twice. All I had
	to do was to change the tests so that no non-prompt-match ever matches a
	prompt accidentally

2006-09-11  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: again go testing with several perl versions.

	Especially the urllist dialog needs test cases. But older perls as well
	need attention.

2006-09-09  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Tempted to give up on Term::ANSIColor. If I turn on colorize_output in
	TestConfig.pm, then we do not pass tests. Somehow loading of
	Term::ANSIColor changes too much.

	utf8 handling wrong with ANSIColor; err, no, only an emacs issue.

	several '# Can't exec "./Build": No such file or directory at /home/k/sources/CPAN/SVN/blib/lib/CPAN.pm line 5477.'

	Yes, this is reproducable. The Makefile target
	testshell-with-protocol-twice runs the testsuite once with
	colorize_output off and once with on and we see that colorize breaks the
	tests. Todo: make the difference between colorize and not colorize as
	small as possible, then we know which lines we can blame.

	Yes, now I have it reproducable and the blame is clearly not on
	Term::ANSIColor but on some perl leakage. To demonstrate the bug, set
	the $demobug variable in CPAN.pm to a true value. Then run make
	testshell-with-protocol-twice. I seen the second run with
	colorize_output==TRUE fail. Maybe it's the use of the regex, I don;t
	know yet. Need to narrow down.

	But the important step is that I now have a workaround and can support
	colorization with just a small compromize. AND I can turn the bug on and
	investigate in many different contexts. FIXED all that in 809

	The $demobug thing is underdocumented!
	
2006-09-08  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: run everything with PRINT_ORNAMENTING turned on to see what is
	myprint and what is mywarn. Are both going to STDERR? We should document
	when to use myprint and mywarn. And we should not let anybody use print
	directly. DONE

2006-09-07  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bugs in FirstTime: print and warn not unified; needs to be
	investigated: two calls to warn replaced with print in rev. 803:
	somebody ate the warnings, they were not displayed for unknown reasons.
	Update: no, the warnings were not dropped but the global value of
	$CPAN::Config->{urllist} was emptied when I interrupted the selection
	process. Fixed in 804-807 or so.

2006-09-04  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* hr ================ no todos below this line ================ /hr

	* Todo: use 'o conf init MATCH' when only a few mandatory variables are
	missing so that people need not go through the whole cycle DONE in rev
	785

	* Bug: Your proxy_user? [] Or not?

	784,5,6 something terrible broken... FIXED in rev 788

2006-09-02  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: "o conf init novar" shall tell that it is not a config variable
	but 'o conf init var' shall only go to this variable's dialog, not
	everything that has this substring. DONE in rev 778

2006-09-01  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: why has the question for the ftp_proxy no square brackets? FIXED
	somewhere between 775 and 782

	* Todo: the prompt for keep_source_where seems bogus and people cannot
	choose it anyway. With a bit of rewording one could call it
	build_dir_intro and then we would find out that we have no prompt for
	the keep_source_where config variable. FIXED in rev 784

	* Todo: completion for 'o conf init MATCH' DONE in rev 776

2006-08-31  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* replace "no lib '.'" with rel2absing the INC if rel2abs is available
	(suggested by Slaven Rezic) DONE in rev 773

	* Todo: investigate why 'o conf init histsize' still asks two questions.
	Maybe we should write the test automatically with all available
	variables and see if one question is asked. STARTED for all but the
	_list and _hash stuff and for undocumented things like
	commandnumber_in_prompt and things we never ask like ftp_passive. It
	turned out that histsize really depends on histfile and they should be
	asked as a pair. But then I tried 'ftp' which hit several options,
	'^ftp$', '\bftp\b' which both did not match at all and I wondered if
	this needs to be addressed or not and how. Same for make. What about
	inactivity_timeout? why does it use prompt(), not my_default_prompt?
	index_expire? username? password? ALL FIXED between 775 and 784

	* Todo: document 'o conf init MATCH' and write a couple tests into
	30shell.t DONE

2006-08-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo: integrate branch
	https://pause.perl.org:5460/svn/cpanpm/branches/dagolden-cpan-reporter
	DONE by David in rev. 758

2006-07-29  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* As #20754 I requested bzip2 support from CPANPLUS. I should write the
	code for mldistwatch so that I just have to turn on the indexing of bz2
	files. DONE in rev 815 of the PAUSE repository.

	* Todo: add a command to list all scripts and use it to test-install all
	of them to get a good coverage for the new 'install <script>' support.
	DONE in revision 746

2006-07-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-07-22  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Jim Cromie suggests: tweak shell to allow cpan> o conf init @sections
	tweak FirstTime::init() interface to accept optional @sections

	put various interactive Qs into groups of conditionals: if ( !@sections
	     or grep /$this_sect_name/, @sections)

	candidate sections: progs - external prog selection make - all make
	options DONE in re 784

	* hr ================ no todos below this line ================ /hr

	* How do I merge the branch 1.87-install-scripts into current code base?

	The problem is, I do not remember where the branch started. Is this a
	problem? I have the branches already checked out in ../SVN-branches/.

	There I find the train hackathon result was in 689 and 686 was the copy
	that started the branch.

	So I guess the merge command would have to be

	svn merge -r 686:689 https://pause.perl.org:5460/svn/cpanpm/branches/1.87-install-scripts

	YES, this did it and is now to be checked in as rev. 733

	'install ANDK/keepcool-0.344' works now like a charm, the stored script
	name is even 'keepcool' and not 'keepcool-0.344'.

2006-07-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* From: Adam Kennedy <adam@phase-n.com>
	  Subject: Re: CPAN.pm, META.yml, PREREQ_PM and dynamic dependencies
	  To: "Andreas J. Koenig" <andreas.koenig.gmwojprw@franz.ak.mind.de>
	  Date: Tue, 11 Jul 2006 16:58:34 +1000
	  
	  Andreas
	  
	  dynamic_config was a major major design mistake, that they got
	  entirely backwards. It relies on authors to not forget to set the
	  dynamic flag, or it results in a failed install.
	  
	  But of course, nobody ever does remember to set it, and we have a huge
	  number of existing modules that don't do this properly.
	  
	  There is no problem at all in us having the requires values considered
	  to be "advisory" only, and then "localize" the dependencies.
	  
	  In short, the flag should have actually been the other way around
	  (i.e. static_config) and so dynamic_config should ALWAYS be 1, unless
	  you have it EXPLICITLY set to 0.
	  
	  We may or may not be able to get the spec revised later on, but in the
	  mean time, dynamic_config should aways be 1 unless you have an
	  explicit 0, not just when there is no requires field.
	  
	  This makes installation potentially a bit slower, and less able to
	  shortcut, but it makes sure that installation remains correct.

	I just tried to make this a Todo item but then checked the code and
	found it bahaves already as Adam suggests. ---> DONE

2006-06-15  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* make signature-checking a feature that can be turned on or off and
	which defaults to off. (requested by Adam Kennedy) DONE in rev. 726 or
	so

2006-04-26  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* apply patch by

From: "Enzer, Matisse BGI SF" <matisse.enzer@barclaysglobal.com>
Subject: CPAN 1.87 - proposed patch to add Basic Auth for non-proxy URLs
To: "Andreas Koenig" <andk@cpan.org>
Cc: "Thalhammer, Jeffrey BGI SF" <Jeff.Thalhammer@barclaysglobal.com>
Date: Tue, 25 Apr 2006 22:17:35 -0700

	which is stored at patches/enzer-matisse-CPAN-1.87.patch DONE in rev 729

2006-04-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Recap branches:

% svn ls https://pause.perl.org:5460/svn/cpanpm/branches
1.80_56plus/
1.87-dbmdeep-hackery/
1.87-install-scripts/

	Merge in 1.87-install-scripts without much further ado. DONE in rev. 733

	Try to recall how broken 1.87-dbmdeep-hackery was. It was very broken
	but I do not remember details.

	* dynamic_config => 1 means that I must throw away the contents of the
	META.yml and if the key is missing, I must default it to 1. DONE in rev
	720

2006-04-02  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-03-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* test the change that I made on Vassilii's suggestion in #18011,
	checked in as rev. 712.

2006-03-06  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* feature request by Martin Sluka: the upgrade command, as described
	further down; to catch the isa_perl issue, we must instantiate a
	Distrostatus object instead of the bare "return" in line 5077. And test
	thoroughly what happens the second time around and later when the user
	finally says "force"; DONE in rev. 727

2006-02-26  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* dslip status shows only 4 fields instead of 5. For license infos from
	META.yml see http://www.thepierianspring.org/perl/meta/. DONE in rev.
	669

2006-02-24  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Todo 30shell:

	Todo: rewrite the 30shell.t test for Open3 (or just a tempfile) by
	concatenating all regexes or split on the prompt. DONE

	Run the test 30shell on a freshly installed perl and see that only those
	tests fail that need prerequisites. Or better yet, no tests at all? DONE
	in rev. 663

	When we succeed with this, make a version that runs within the core of
	perl, maybe filter out just those tests that do not require additional
	resources. REJECT: provides no extra utility

	* To: Tyler MacDonald <tyler@yi.org>

	 >> If I understand the problem right, it is that you wish to use a module in the
	 >> current distribution (a subclass of Module::Build) to do the installing.
	 >> If this is correct, you only need to put a 'use lib "lib";' in your Build.PL
	 >> for it to be picked up properly.  (It does not need to be installed in the
	 >> standard places before you use it.)
	
		> 	Nope, that problem is handled already in
		> DBIx::Migration::Directories.
	
		> 	I now have a Schema::RDBMS::AUS package, which needs the subclass
		> that DBIx::Migration::Directories supplies.
		> DBIx::Migration::Directories::Build needs to be available at the time
		> Build.PL is run so that it can alter Module::Build's config and supply extra
		> actions.
	
	Add it to your "requires" hash, that way it will end up in META.yml and
	if people have YAML installed, they can read it.
	
	If people have YAML not installed they will call either the
	Makefile.PL or the Build.PL to hopefully find out what the
	prerequisites are. That way you get the prerequisites but as you have
	noticed, it is too late for your build process.
	
	I don't know how I will fix that. Suggestions welcome. I put it into my
	Todo file.
	
	* Feature request: when asking 'm /svn::notify/', then I would like to
	see in the list which of the modules are installed locally. Was that
	what Admin was doing?

  It would not work for distros, but for modules. Not for bundles either.

  3 states: not installed, not up-to-date, up-to-date  ... space,"<","="

  color codes: green=uptodate, yellow=not uptodate, black=not installed

	DONE in rev. 732

	* upgrade: new command that does nothing but
	CPAN::Shell->install(CPAN::Shell->r)? Do not forget that we still may
	have perl distros in the "r" list. DONE in rev. 727

	* DBM::Deep for a hash behind $CPAN::META. See 2005-12-28 for issues and
	branches/1.80_56plus for a few lines that probably went in the wrong
	direction. Split the loading of Authors/Modules/Distros/Bundles into
	separate pieces and make them lazy. Consider 'reload index', the
	storable Metadata file, readonly/readwrite, changes of the DSLIP thingy,
	offsets into an uncompressed 02xxx file. Remember RT #4943. Remove the
	code for "status" when finished

	* readline: offer the choice between Gnu and Perl

	* Bug: installing scripts without modules? How does it work? How
	should it work? getting the latest version ad-hoc?

	* hr ================ no todos below this line ================ /hr

2006-02-23  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Install without {My,}Config.pm, the rules should be:

	if there is no CPAN/MyConfig.pm already loaded, we must try to load a
	CPAN/Config.pm

	if there is no CPAN/Config.pm, we must initialize one immediately. If we
	are root, this should be something like
	/usr/local/perl-5.8.0@27277/lib/5.8.8/CPAN/Config.pm as I just tested it
	with 5.8.8.

	So if root installs CPAN without testing it, they have no CPAN/Config.pm.
	They start it and land immediately in the init process. Good.

	If he runs 'make test' it should succeed all tests. Currently it fails
	12cpan and skips 30shell because of 'no Expect'. ==> TODO. DONE with
	rev. 659

	If they have no CPAN/Config.pm and start cpan as an ordinary user, then
	they should get, without asking, a ~/.cpan/CPAN/MyConfig.pm and land in
	the init dialog. This is currently OK.

	* Todo: mention rt.cpan.org in the manpage. Oops, this was already DONE

2006-02-22  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* rethink if the CPAN/Config.pm file now is being built at all. Shouldn't
	it be built as a system-wide default? Yes, it is being built. DONE

2006-02-20  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: the new test 12cpan.t is not suited for 5.004_05:

t/12cpan............Unquoted string "qr" may clash with future reserved word at t/12cpan.t line 13.
Unquoted string "command" may clash with future reserved word at t/12cpan.t line 13.
syntax error at t/12cpan.t line 13, near "/,"
Unquoted string "qr" may clash with future reserved word at t/12cpan.t line 17.
Unquoted string "foo" may clash with future reserved word at t/12cpan.t line 17.
syntax error at t/12cpan.t line 17, near "+=>"
Unquoted string "bar" may clash with future reserved word at t/12cpan.t line 17.
Unquoted string "baz" may clash with future reserved word at t/12cpan.t line 17.
Unquoted string "foo" may clash with future reserved word at t/12cpan.t line 17.
Execution of t/12cpan.t aborted due to compilation errors.
# Looks like your test died before it could output anything.
dubious

	and not for 5.005_04:

t/12cpan..........Can't locate object method "catfile" via package "File::Spec" at t/12cpan.t line 3.
# Looks like your test died before it could output anything.
t/12cpan..........dubious                                                    
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-3
        Failed 3/3 tests, 0.00% okay

	FIXED

	* Bugalert: I saw the "awry" case without a reason.

cpan[10]> install Bundle::Spd
Signature for /home/k/.cpan/sources/authors/id/G/GA/GAAS/CHECKSUMS ok
Checksum for /home/k/.cpan/sources/authors/id/G/GA/GAAS/libwww-perl-5.805.tar.gz ok
libwww-perl-5.805/
libwww-perl-5.805/lib/
libwww-perl-5.805/lib/HTTP/
libwww-perl-5.805/lib/HTTP/Cookies.pm
[...]
libwww-perl-5.805/Changes
libwww-perl-5.805/AUTHORS
libwww-perl-5.805/README
libwww-perl-5.805/lwpcook.pod
Removing previously used /home/k/.cpan/build/libwww-perl-5.805
Package came without SIGNATURE

Running install for module HTML::HeadParser
Running make for G/GA/GAAS/HTML-Parser-3.50.tar.gz
LWP not available
Fetching with Net::FTP:
  ftp://localhost/pub/CPAN/authors/id/G/GA/GAAS/HTML-Parser-3.50.tar.gz
Signature for /home/k/.cpan/sources/authors/id/G/GA/GAAS/CHECKSUMS ok

Warning: No checksum for HTML-Parser-3.50.tar.gz in /home/k/.cpan/sources/authors/id/G/GA/GAAS/CHECKSUMS.

The cause for this may be that the file is very new and the checksum
has not yet been calculated, but it may also be that something is
going awry right now.
Proceed? [yes] Caught SIGINT
Got another SIGINT

cpan[11]> ls GAAS


	After that, the problem was not reproducable. Remove and reinstall perl,
	install CPAN, install Bundle::CPAN, install Bundle::Spd works.

	So we have a hard to reproduce bug.

	Running 'install Bundle::Phalanx100' gives after 20 minutes

Warning: No checksum for Net-Daemon-0.39.tar.gz in /home/k/.cpan/sources/authors/id/J/JW/JWIED/CHECKSUMS.

The cause for this may be that the file is very new and the checksum
has not yet been calculated, but it may also be that something is
going awry right now.
Proceed? [yes] 

	This time I look immediately into the CHECKSUMS file (which is the cached
	one!) and indeed there is no Net-Daemon-0.39.tar.gz in it. On the CPAN
	we do have a newer checksums file. Is this cool?

	So we have the root of the cause. Now for a solution?

	I can answer 'no' and then reproduce the problem. Note that the old
	CHECKSUMS file is 3 months old and its timestamp is 1 month old.

	Fixed in 638 with the new argument $sloppy for CHECKSUM_check_file, but
	test still missing. ... Test added by adding CHECKSUMS@588 in rev. 643

	Later renamed to CHECKSUMS.2nd (around rev. 1033)

2006-02-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: with 'o debug all' we did not reach 'Distribution seems to have
	never been unzipped/untarred, nothing done' but instead some "Unknown
	distribution" or so. Fixed in 625

	* Bug: in the last test run we did not detect that
	ANDK/CPAN-Test-Dummy-Perl5-Make-1.02.tar.gz was not in the CHECKSUMS
	file. We had the 

	#     CHECKSUM_STATUS NIL -- distro not in CHECKSUMS file

	in the "d" output but we did not pass he code that shouts. Fixed in 624

2006-02-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-02-17  Andreas J Koenig  <akoenig@cellular.de>

	* Bug: on a system without make installed, CPAN happily tries

	Checking if your kit is complete...
	Looks good
	Writing Makefile for CPAN
			-- NOT OK
	Running make test
		Can't test without successful make
	Running make install
		make had returned bad status, install seems impossible

	REJECT: this is a bugreport against an old CPAN.pm

2006-02-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* watch http://perlmonks.org/?node_id=530600

	Does anybody answer my question 'How do you run nmake when it is in a
	path that contains spaces?'? LEAVE WINDOWS ASIDE

2006-02-16  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-02-15  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-02-14  Andreas J Koenig  <akoenig@cellular.de>

	* Bug: inexistant distro leads to perl error; clean on uninstalled
	distro would be nice as a test case

	% perl -Ilib -MCPAN -e 'CPAN::Shell->$_("MARKSTOS/Test-XML-Valid-0.04345.tar.gz") for qw(clean d);'
Going to read /home/akoenig/.cpan/sources/authors/01mailrc.txt.gz
CPAN: Compress::Zlib loaded ok
Going to read /home/akoenig/.cpan/sources/modules/02packages.details.txt.gz
  Database was generated on Tue, 14 Feb 2006 02:18:00 GMT
CPAN: HTTP::Date loaded ok
Going to read /home/akoenig/.cpan/sources/modules/03modlist.data.gz
CPAN: Storable loaded ok
Going to write /home/akoenig/.cpan/Metadata
Running make clean
Distribution has no own directory, nothing to do.
Can't use string ("") as a HASH ref while "strict refs" in use at lib/CPAN.pm line 3857.

	Fixed in rev. 604

2006-02-14  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Foreign bug: Module-Build-0.27_07 fails the test runthrough.t with
	blead@27166:

t/runthrough......ok 14/28                                                   
#   Failed test 'Check version used to create META.yml: 0.2707 == 0.270700'
#   in t/runthrough.t at line 142.
#          got: '0.2707'
#     expected: '0.270700'
t/runthrough......NOK 19# Looks like you failed 1 test of 28.                
t/runthrough......dubious                                                    
        Test returned status 1 (wstat 256, 0x100)

	Ditto for 27154, 27016; 26919 is OK. Hmmm, several perls in between are
	OK. So far these are debugging perls. No, 27088 is another one that is
	OK and it is nondebugging.

	If YAML is not installed, the test is skipped, so I must make sure that
	YAML is installed, but this is difficult because YAML was broken by perl
	until recently.

	OK, looked into the code instead and wrote bug report to the M:B mailing
	list. DONE.

2006-02-13  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: Randal reports that Zoidberg has both a Makefile.PL and a
	Build.PL and he has prefer_installer EUMM and yet CPAN chose to run the
	Build.PL. rt #17612. RESOLVED as not a bug in CPAN.pm

2006-02-11  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug?: Somehow I managed to get POE to fail the installation, maybe
	AutoInstall was involved. I then installed LWP and then tried POE again.
	It succeeded in all tests, but make install said, it had "Already tried
	without success". In such a moment this is simply the wrong thing, we
	would much rather that CPAN.pm retried, especially as the test suite
	runs forever!

	So is this a bug? I cannot tell before I know why the first installation
	attempt failed.	Cannot reproduce.

	* Foreign bug: POE with bleadperl@27154 fails a few tests with

	*** glibc detected *** double free or corruption (!prev): 0x085ed6e0 ***
tests/30_loops/30_event/comp_tcp_concurrent.........dubious                  
        Test returned status 0 (wstat 6, 0x6)
DIED. FAILED tests 1-42
        Failed

tests/30_loops/10_select/comp_tcp    0     6    42   42 100.00%  1-42
tests/30_loops/20_poll/comp_tcp_c    0     6    42   42 100.00%  1-42
tests/30_loops/30_event/comp_tcp_    0     6    42   42 100.00%  1-42
44 tests and 16 subtests skipped.

	Does not fail with 5.8.8.	Blame? 27059! REPORTED

2006-02-10  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Foreign bug: t/37-translator-graph....Can't locate object method
	"is_trivial_link" via package "GLOB" at
	/home/k/.cpan/build/SQL-Translator-0.07/blib/lib/SQL/Translator/Schema/Graph.pm
	line 46.

	with bleadperl@17102 when trying to test SQL::Translator. Happends on
	blead, not on 5.8.8 but with 5.8.8 I have other (and much more) failures

	With #16852 I have already a ticket there for the signature.

	I regret that I did not include the full command needed to upload one's
	key. Here it is:

    gpg -a --keyserver hkp://pgp.mit.edu:11371 --send-keys YOURID

2006-02-08  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: when Running "Makefile.PL" fails, then the case is not reachable
	for the failed routine. Need another Naysayer category?? Try
	Digest-SHA-5.34.tar.gz under perl-5.004_05 before Module::Signature is
	installed. FIXED in rev. 580

2006-02-05  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: RDF::Simple installs although I see failing tests?

	./Build test returns true even if tests fail. This was not always the
	case or was it? No, it wasn't.

	I go into the Class-MethodMaker-2.08 directory and try

	perl Build.PL
	./Build test
	./Build clean

	If Module::Build is missing, I install it manually. No CPAN.pm involved.

	These perls behave (exit 255):
	
	/home/src/perl/repoperls/installed-perls/maint-5.8/pIPN6hB/perl-5.8.0@26560/bin/perl
	/home/src/perl/repoperls/installed-perls/maint-5.8/pcE7NPt/perl-5.8.0@24641//bin/perl
	/home/src/perl/repoperls/installed-perls/maint-5.8/piFZwYU/perl-5.8.0@27040//bin/perl
	/home/src/perl/repoperls/installed-perls/perl/pREyceB/perl-5.8.0@27088/bin/perl
	/home/src/perl/repoperls/installed-perls/perl/piR9qHb/perl-5.8.0@27016/bin/perl
	/usr/local/perl-5.8.0@27016/bin/perl

	These don't (shell returns true):

	/usr/local/perl-5.8.7/bin/perl
	/usr/local/perl-5.8.8/bin/perl

	Stepping in the debugger through bleadperl@27088 and 5.8.8:

	27088 has Test::Harness 2.56 while my 5.8.8 has 2.57_03. Apparently a
	Test::Harness bug. REPORTED as #17490
	
2006-02-02  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2006-01-31  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Visit the p5p thread C<replacing "inuse" Win files (was Re: Help with
	a Cwd.pm build error)> for our own cpan.bat. Currently Windows users
	cannot 'reload cpan' when they started the shell from cpan.bat, only
	when they used 'perl -MCPAN -eshell' (David Golden)

	* Feature request: integrate more than one source into a common index.

	* dontload: make a dontload_list and deprecate dontload_hash. It seems
	OK to keep $META->{dontload_hash} but it would be nice if changes on
	$Config->{dontload_list} would always adjust the dontload_hash. DONE in
	rev. 581

	* document and provide a dialog for commandnumber_in_prompt or provide a
	sprintf based solution. Or just leave it as it is. Just like
	inhibit_startup_message.

	* Todo: Write a bunch of distros and upload them with the sole purpose
	of testing CPAN.pm. Also helps Test::Prereq and others.
	PITA::Test::Dummy::Perl5::Make and PITA::Test::Dummy::Perl5::Build? A
	start is done in t/shell.t STARTED around rev. 519

	* Bug: with bleadperl and CPAN 1.83_62 I first install Bundle::CPAN.
	Then I try to install Net::LDAP and answer all questions from
	Module::Install with the default. It then installs Convert::ASN1
	successfully and then says

*** Convert::ASN1 successfully installed.                                       
*** ExtUtils::AutoInstall installation finished.                                
Writing Makefile for Net::LDAP                                                  
make: getcwd: No such file or directory                                         
make[1]: Entering directory `'                                                  
make[1]: *** No targets specified and no makefile found.  Stop.                 
make[1]: Leaving directory `'                                                   
  /usr/bin/make  -- NOT OK                                                      

	If I now start a new CPAN session, I can install Net::LDAP without problems.

	If I uninstall Convert::ASN1 and start a new CPAN session I can get
	nearly the same result:

make[1]: Leaving directory `/home/k/.cpan/build/Convert-ASN1-0.19'
  sudo make install UNINST=1 -- OK
*** Convert::ASN1 successfully installed.
*** ExtUtils::AutoInstall installation finished.
Writing Makefile for Net::LDAP
CPAN: YAML loaded ok
make[1]: Entering directory `/home/k/.cpan/build/perl-ldap-0.33'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory `/home/k/.cpan/build/perl-ldap-0.33'
  /usr/bin/make  -- NOT OK

	On the other hand, running same thing on a 5.8.7 with 1.83 succeeds, but
	it asks me if I want to run sudo (and I say no and again no).

	Now I tried bleadperl@27016 with its 1.8359: 'install YAML' then
	'install Net::LDAP' and got the same error.

	Now I try perl-5.8.8-RC1 with its 1.83: it succeeds but asks me again if
	I want to run sudo.

	5.8.8-RC1 with 1.8362: succeeds and asks me if I want to run sudo.

	blead@26447 with 1.8362: error.

	What is it about, the ExtUtils::AutoInstall line? ExtUtils::AutoInstall
	is NOT part of the core. Net::LDAP comes with version 0.59, Audrey has
	reached 0.63.

	I think it goes like so:

	have no perm -> ask sudo -> user says no -> success
	have perm       implicit yes             -> failure

	This is consistent with all of above.... After some more investigation
	reported as bug to Audrey and Graham

2006-01-30  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Revisit 17313: Module::Build people have promised to write a
	./Build.bat file instead of a ./Build file on Windows. Until this
	becomes true, hide mbuild_install_build_command from Windows users.

2006-01-29  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Foreign bug: broke perl again YAML? blead@26994 fails on test
	dump-perl-types.t of YAML-0.53. Wrote blame report about 26980--DONE

2006-01-27  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Foreign bug: Email::Field or which module was it that just produced
	more than 1000000 eval warnings? Cannot reproduce.

	* bug: if a META.yml specifies a prerequisite module that we do not
	know, the whole prereq_pm became undef. FIXED in rev. 480.

2006-01-26  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: illegal entries in the Config hash are never removed and a hash
	cannot be emptied. The latter is FIXED with rev. 475, the former with
	rev. 476.

	* Bug (Tyler MacDonald): OK, I've figured out what went wrong: 0.27_06
	isn't on www.cpan.org/pub/CPAN yet. However, *how* it went wrong is
	truly bizzare: LWP returned a "404 not found" error, yet somehow I still
	ended up with a .tar.gz and .tar file, and CPAN thinking it had actually
	downloaded something. This looks like a bug in CPAN.pm, both in the 1.7
	version that's distributed with 5.8.7, and the latest release, 1.83.

	In my environment, this comes from curl. After fixing the curl switches,
	the problem persists. This time is lynx to blame, but for lynx there is
	no commandline switch that propagates a 404 to a false. So we now read
	the file that lynx sends us and heuristically decide if it is an error
	message. FIXED in revision 477.

2006-01-25  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: META.yml may contain build_requires which for example File::BOM
	specifies. It doesn't matter that I believe that it is not a
	build_requires, it is really a requires because only tests fail, not the
	build process. But I must merge the two hashes. FIXED in rev. 471

	* Foreign bug: YAML with bleadperl fails a test which succeeds with
	maintperl. REPORTED

	* Bug: with 1.8358 from the core CPAN says after the start
	"lib/CPAN/Config.pm initialized" and goes into the init dialog. After ^C
	I find a lib/CPAN/Config.pm file.

	Ahhh, that's how 'o conf commit' had written my dontload_hash: producing
	a syntax error. FIXED in  rev. 466

2006-01-24  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* 5 new bugs from in RT: 17237 17238 17241 17242 17266

	17237 may be fixed with rev. 464 but not yet tested.

	rev. 465 continued to work on 17237 and I consider it fixed now.

	rev. 467 fixes 17238

	rev. 465 also is an answer to 17241 because this was most likely not a bug

	rev. 469 fixes 17266

	17242 is the request to work with Win32::OLE which I could only reply to
	with 'patches welcome'

	* Bug: setting "o conf dontload_hash ''" breaks the shell: C<Can't use
	string ("") as a HASH ref while "strict refs" in use at lib/CPAN.pm line
	833.> FIXED in rev 464.

2006-01-21  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* see if podlators 2.0.1 fixes the broken README and if so, switch back
	to ${PERL} in the Makefile.PL. FIXED in rev. 457

	* bug: while trying to install Bundle::CPAN, YAML was delayed "until
	after prerequisites" but later was not retried or maybe was retried but
	CPAN said, it was

Running make for I/IN/INGY/YAML-0.53.tar.gz
  Is already unwrapped into directory /home/k/.cpan/build/YAML-0.53
  Delayed until after prerequisites
Running make test
  Delayed until after prerequisites
Running make install
  Delayed until after prerequisites

	So the installation of Bundle::CPAN was not really tried to finish.

	The dependency chain is as follows:

	  YAML depends on Class::Spiffy and Test::Base
    Test::Base depends on Spiffy

	Bug is that ->{later} is not double checked when encountered. Fixed in
	rev. 454.

2006-01-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Foreign Bug: RDF::Simple has LWP::UserAgent as undeclared prereq???

	Running make against RDF::Simple pulls in a lot but it finally comes to
	an end. When I then run test, the whole load of modules starts testing
	and three fail their tests:

  ABW/AppConfig-1.56.tar.gz                    : make_test NO
  FLUFFY/Class-MethodMaker-2.08.tar.gz         : make_test NO
  ZOOLEIKA/RDF-Simple-0.22.tar.gz              : make_test NO

	paging back reveals: all the RDF::Simple tests fail due to missing
	LWP::UserAgent, RDF::Simple::Serialiser, and Class::MethodMaker. The
	latter two do not appear when I test against 5.8.8-tobe. REPORTED via
	RT.

	AppConfig fails due to "Can't modify non-lvalue subroutine call at
	t/file.t line 112, <DATA> line 69." This is a 5.9.3 issue, we succeed
	with 5.8.8-tobe (@26917) REPORTED via p5p.

	Class-MethodMaker tests fail complaining that they cannot find
	Class::MethodMaker. This is also a 5.9.3 issue. Fully automated binary
	search is impossible unless I find a smaller test case. 26492 ok, 26493
	not ok. Ha! It is a Makefile.PL vs Build.PL issue! On RT #16241 I have
	added this observation.

2006-01-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* rt #17089 suggests that we have to care for M:B being installed when
	we find a distro that has only a Build.PL and no Makefile.PL

	AFAIR only CPAN::Metadata::RDF is a module that comes with Build.PL and
	without Makefile.PL, so it is the only one to test the bugreport. This
	takes *quite* a while because of prerequisites (Class::MethodMaker,
	Template::Toolkit, DateTime::TimeZone, DBD::SQLLite, LWP, etc.). And of
	course after all the prerequisites, we HAVE Module::Build, so must
	remove it again. FIXED in rev. 433

	* Foreign Bug? I must investigate DateTime::TimeZone separately. It
	wanted to install Module::Build on its own and then failed giving as a
	reason that Module::Build was not installed???

	It turns out the prereq_pm is undef for some reason. But prereq_pm is
	only built during the 'make' step and then not resetted during a 'force
	get'. The 'prereq_pm_detected' bit is set and I must leave/enter the
	shell to debug this. OK. I see a Makefile.PL that simply fails because
	Module::Build is not installed. At least it says what it wants, but we
	must be better prepared for such an attack. OK, I'll file a bugreport
	against both DateTime::TimeZone and Module::Build -- somebody has to
	confess that it is a prereq and write it into the META.yml. That's what
	I would say. DONE

2006-01-13  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: when ~/.cpan/sources/authors/id/A/AN/ANDK/CPAN-1.83_54.tar.gz is
	not a tar file (because I mistyped a URL and got something else), then
	even "force get ANDK/CPAN-1.83_54.tar.gz" does not overwrite the bogus
	file. The stupid program just keeps complaining that the file is not a
	tarfile and I must remove it manually.

	Ahh, this bug needs not be fixed because it only happens when you have
	no Digest::SHA available. REJECT

	* Bug: $CPAN_config_loaded should be replaced with something like
	$INC{"CPAN/Config.pm"} || $INC{"CPAN/MyConfig.pm"} so that loading one
	of the two before starting the shell will do. Then revert patch 411.
	FIXED in rev. 418

	* Todo: see the newest cpan by brian. DONE (BDFOY/cpan-1.51.tar.gz)

2006-01-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: We cannot determine the prereequisites of File::Find::Rule
	because we have no YAML installed and Richard uses Module::Build, so we
	have no Makefile to parse. There is some MB interface to get them. fixed
	in rev. 396

	* Bug: "install Bundle::CPAN Expect Test::Pod" currently failes
	correctly when we reach YAML because we cannot verify the signature. But
	we must not die, we must only set the correct status so the rest of the
	gang can be installed. Fixed in rev. 384

2006-01-11  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* what happens to "failed" when we reload the index? TESTED OK

	* force: I'd expect 'force ls' to always fetch fresh CHECKSUMS
	files. Currently it doesn't. FIXED in rev. 401

	* optimize "ls dowens": currently fetches D/CHECKSUMS and D/DO/CHECKSUMS
	even if we already have D/DO/DOWENS/CHECKSUMS. Is it worth fixing? NO

	* get rid of the summary currently provided by install bundle, its
	superceded by failed(). REJECT, maybe it's useful

	* Todo: document "failed" (and "status"?) DONE for failed, REJECT for status

	* today's rev. 374 of CPAN.pm should be partially reverted: while
	failed() looks good most of the time, it looks ugly that 'force install
	version' installs version and still failed reports:

Writing /usr/local/perl-5.8.0@26774/lib/site_perl/5.9.3/i686-linux-64int/auto/version/vxs/.packlist
  ./Build install --uninst 1 -- OK
Failed installations in this command:
  JPEACOCK/version-0.53.tar.gz                 : make_test NO

cpan> failed               
Failed installations in this session:
  BDFOY/Test-Prereq-1.029.tar.gz               : make_test NO
  JPEACOCK/version-0.53.tar.gz                 : make_test NO

	Correct behaviour should be that the 'make_test NO' bit be nuked. FIXED
	in rev. 387

	Above that, the "prompt" change was only interesting during debugging.
	Nobody wants to see the internal number of commands in his prompt. FIXED
	in rev. 388

	* Bug: YAML fails to unpack because of bad signature. Retrying leads to
	prereq Test::Base failing due to bad signature. Retrying leads to
	running make test on YAML. dump reveals that somehow SIG_STATUS was set
	to YES. Ahh, that's the signature on the CHECKSUMS file. Need a new
	attribute for broken signatures. FIXED in rev. 374

2006-01-09  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* document CPAN_SHELL_LEVEL DONE

	* find out why Expect is so noisy and when this did start DONE

	* Slaven suggests: How to discover that we are in the subshell?
	Environment? Prompt? Level? PS1 as an environment variable? How does
	Debian's apt-get solve that? HALF-DONE in rev. 360: We now have the
	envariable CPAN_SHELL_LEVEL but I'd still like to make a change to the
	prompt. Update: Debian does not mangle the prompt, they just say 'Type
	exit when you're done':

	*** dvorak (Y/I/N/O/D/Z) [default=N] ? z
Type `exit' when you're done.
Abstaining from writing .zhistory, is younger than stats.dbhash at /root/bin/commandhistory.pl line 513.
Zsh version 4.3.0-dev-2
Linux dev05 2.6.12.6-xen0 #2 Tue Jan 10 17:34:37 CET 2006 i686 GNU/Linux

	So this Todo can also be CLOSED.

	* Rename Releasenotes to Changes and make the ChangeLog in the
	traditional format, there is some XSLT stylesheet somewhere that does
	this. Ah here: http://ch.tudelft.nl/~arthur/svn2cl/svn2cl-0.5.tar.gz
	DONE up to rev. 352

2006-01-01  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Give every command a number and store that number in the object,
	something like incommandcolor but without removing it at the end of the
	command. With such a number we can make failed(commandnumber) filter on
	that commandnumber and have instant per-command-failed. DONE in rev 374

2005-12-31  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: I install Archive::Extract and it has the prerequisite
	Module::Load::Conditional declared but nobody installs it.
	FIXED in rev. 329

2005-12-30  Andreas J Koenig  <akoenig@cellular.de>

	* FirstTime needs a structure over each question or questiongroup so
	that we can ask single questions. Structure was brought by Jim Comie
	around rev. 355

	* Bug: "reload cpan" does not work if the old and the new CPAN.pm
	have a different path. I installed a new CPAN.pm from CPAN and it
	did remove the old /usr/share/perl/5.8/CPAN.pm but installed the
	new one as /usr/local/share/perl/5.8.7/CPAN.pm. The reload then
	always just said "0 subroutines redefined". FIXED in rev. 321

	* rev 315 fixed a path/permission problem with the use of basename() and
	I could see that the error message gets much better than before but we
	need a test case that shows that this strategy can really work in some
	cases. Maybe we need to store the tar file somewhere else to keep the
	tmp/ directory tidy. Also we must see what happens when we cannot remove
	the tmp/ directory. The list of broken distros in
	eg/find-module-install-sudo-bugs.pl will help. DONE

	* add eg/ to the MANIFEST? Not yet, the script is too much focused on a
	problem that is not of interest to others. REJECT

	* Bug: checksum mismatch on a file is being reported even when the
	file has 0 bytes. 0 bytes should clearly constitute the right/the
	duty to overwrite. FIXED in rev. 320

2005-12-29  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug suspected in Module::Install: it seems to run CPAN.pm in a
	subshell with sudo and so we get directories under build/ that we do not
	own. No release before this bug is traced down! Bugreport sent to Audrey
	a few minutes ago (already Friday, 0:30 Berlin time). Bug confirmed and
	has already been fixed in 0.37 and old distros must be redistroed. DONE

	* branching and merging: make current HEAD a branch "1.80_56plus" and
	roll HEAD back to contain only the zero-risk stuff (for maybe later
	releasing that as 1.81?) DONE

2005-12-21  Andreas J Koenig  <akoenig@cellular.de>

	* complete 'o conf' does not show commit. FIXED in rev 291

	* Bug: Module::Install writes into META.yml "perl: 5.004" and we take it
	as a Module requirement. Whose bug? WORKAROUND in rev 290

	* Can't locate object method "prettyprint" via package "CPAN::Config" at
	lib/CPAN.pm line 1246, <STDIN> line 2. FIXED in rev 288

2005-12-19  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Documentation of sudo, ls *, Module::Build, bzip2, YAML; DONE

	* Sudo for Build? Ask mailinglist if we need a
	build_install_build_command or what we need there. DONE

2005-12-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* add to the Bundle: YAML, Text::Glob, Module::Build, Digest::SHA FIXED in rev 280

	* 'make release' is broken. Apparently I have to follow some sequence to
	make release:-( MAYBE FIXED

	* Bug: The following prints "incommandcolor" which should never happen:

perl -Ilib -MCPAN -e 'CPAN::Shell->$_("MARKSTOS/Test-XML-Valid-0.04.tar.gz") for qw(clean d);'
CPAN: LWP::UserAgent loaded ok
CPAN: URI::URL loaded ok
Going to read /home/ftp/pub/CPAN/authors/01mailrc.txt.gz
CPAN: Compress::Zlib loaded ok
Going to read /home/ftp/pub/CPAN/modules/02packages.details.txt.gz
  Database was generated on Sun, 18 Dec 2005 00:23:31 GMT
Going to read /home/ftp/pub/CPAN/modules/03modlist.data.gz
CPAN: Storable loaded ok
Going to write /home/k/.cpan/Metadata
Running make clean
  Has no own directory
Distribution id = M/MA/MARKSTOS/Test-XML-Valid-0.04.tar.gz
    CPAN_USERID  MARKSTOS (Mark Stosberg <mark@summersault.com>)
    CALLED_FOR   M/MA/MARKSTOS/Test-XML-Valid-0.04.tar.gz
    CONTAINSMODS Test::XML::Valid
    UPLOAD_DATE  2004-06-01
    incommandcolor 0

	FIXED in rev 279

2005-12-17  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* make selectable in the config if M:B should be chosen over
	Makefile.PL. prefer_installer DONE in rev 271

	* Bug: tolerance on colon only works with m command but not with install command:

cpan> install Class:Container
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
  Database was generated on Sat, 17 Dec 2005 10:06:33 GMT
Warning: Cannot install Class:Container, don't know what it is.
Try the command

    i /Class:Container/

to find objects with matching identifiers.

cpan> m Class:Container      
Module id = Class::Container
    CPAN_USERID  KWILLIAMS (Ken Williams <ken@mathforum.org>)
    CPAN_VERSION 0.12
    CPAN_FILE    K/KW/KWILLIAMS/Class-Container-0.12.tar.gz
    MANPAGE      Class::Container - Glues object frameworks together transparently
    INST_FILE    /usr/local/share/perl/5.8.7/Class/Container.pm
    INST_VERSION 0.12

	FIXED in rev 269

	* switch back and forth between preferring Build.PL or Makefile.PL; find
	12 modules that are good for testing Module::Build:

	SVN::Notify::Mirror  failed a test with "could not exec svnnotify" but it
                       worked on the commandline

	SVN::Notify::Config  is the whole family of SVN::Notify a mess, dependency-wise?

	SVN::Notify          must be installed first???

	Text::Lorem HTTP::Proxy Workflow Calendar::Simple DateTime::HiRes
	CGI::Wiki::Kwiki Class::Container HTML::TagCloud
	Data::FormValidator::Util::HTML

	DONE for rev 269

2005-12-15  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: what? we still do not support Build.PL? Didn't anybody send
	me a patch? Try 'install CPAN::Metadata::RDF' and see how this can
	be fixed as quickly as possible.

	Try:        look CPAN::Metadata::RDF
	then there: perl Build.PL;./Build;./Build install

	This does nothing for the prerequisites. We could lookup META.yml either
	then or beforehand. FIXED although only minimal tested in rev 269

	* YAML for dependency checking in rev 268

	* bz2 support: testobject is ARTURAZ/Net-Vypress-Chat-0.72.1.tar.bz2
	DONE in rev 264

	* Todo: sha256 DONE in rev 263

	* Todo: 4th colmn in the 'r' command has not the canonical name
	but the unneeded D/DC/ stuff. DONE in rev 262.

	* Globbing on the ls command: completion? REJECTED

2005-12-12  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Feature request: if I type 'm CGI:Session' (note the missing second
	colon) I get

	No objects of type Module found for argument CGI:Session

	I believe, CPAN could supply the missing colon in this case. DONE

2005-11-30  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: when the Metadata file has been read with the old version and
	CPAN reads the new index it does not update the version. Witness
	Crypt::Khazad. Once the Metadata are removed completely and built up
	correctly, everything is OK.

	Can be tested by running

	!print $CPAN::META->{readonly}{"CPAN::Module"}{"Crypt::Khazad"}{"CPAN_VERSION"} = "1.0"
	reload index

	This may have nothing to do with multidot versions, just some
	pessimization in the code dealing with replacement of META when
	re-reading index files. FIXED

2005-11-22  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* From: David Golden <david@hyperbolic.net>:

	> Also, "lack of distname support" is overblowing the situation.
	> Distnames are supported perfectly fine as long as you put it in the
	> proper syntax with author's ID and version.
	
	I think the problem Jim encountered is that "proper syntax" is part of
	the arcana of CPAN.  It's not obvious from the help:
	
	>  a,b,d,m  WORD or /REGEXP/  about authors, bundles, distributions, modules
	>  i        WORD or /REGEXP/  about anything of above
	>  r        NONE              reinstall recommendations
	>  ls       AUTHOR            about files in the author's directory
	
	Something that clarifies that AUTHOR/DIST-VERSION is a valid format
	would help.  Or rather, some specific example of what that WORD can be:
	
	  where WORD is either a module, bundle or author name or a
	  distribution name of the form AUTHOR/DISTRIBUTION-VERSION
	
	It's vaguely alluded to in the CPAN perldoc, but only in the section
	describing the four CPAN::* classes.
	
	A doc patch would be a quick fix for this.

2005-11-07  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* globbing on the ls command: only ls 'GBARR/Scalar*', or even 'ls
	*/makepatch'? 2005-12-12: DONE 

	* script to copy relevant files to the perl tree. DONE

2005-11-04  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* is version in script/cpan OK? It was 1.3 in perl @25981! Same
	for Nox.pm FIXED

	* PAUSE key 2005? DONE

2005-11-03  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Need Releasenotes, the ChangeLog is a big mess with the numerous
	checkins that all were just testing the release cycle itself and
	not generating anything useful for the user. DONE

2005-11-02  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: why did the release only contain a ChangeLog up to release
	206 when we were at 212? Ah, I see, the disttest target does not
	make a to-be-released file, must be done by make dist. So the
	whole release was @206. No harm done because between 206 and 212 I
	only worked on the release target. I think I need a disttest of my
	own that takes the dist.tar.gz already built and tests it, not the
	one that builds a dist from the air again into the air and tests
	that. I want a real test of that file that is going to be
	released. Then I can live with 'make release' running both dist
	and disttest. I think. DONE
	
	* Bug: as a non-root user and first-time caller (no ~/.cpan/
	directory) I said "not ready for interactive configuration" and
	then said 'o conf init'. I got no questions asked but into a fast
	endless loop like so:

(1) Africa
(2) Asia
(3) Central America
(4) Europe
(5) North America
(6) Oceania
(7) South America
Select your continent (or several nearby continents) []

Sorry! since you don't have any existing picks, you must make a
geographic selection.

(1) Africa
(2) Asia
(3) Central America
(4) Europe
(5) North America
(6) Oceania
(7) South America
Select your continent (or several nearby continents) []

Sorry! since you don't have any existing picks, you must make a
geographic selection.


	until I hot ^C. *Very* Clever tricks with prompt?

	Reproducable as described. Leaving the shell and entering it again
	make it not reproducable. I must 'rm -rf ~/.cpan
	lib/CPAN/Config.pm' to reproduce. FIXED in rev 214

2005-10-28  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

2005-10-21  Andreas J Koenig  <akoenig@cellular.de>

	* cpan> m Apache::AuthAny 
	Can't call method "upload_date" on an undefined value at /usr/perl-5.8.4/lib/5.8.4/CPAN.pm line 5761.

	FIXED in rev 186.

	* Slaven suggests a variable "permanently_connected" that helps to
	decide if a connection to the internet is available. Do ask the
	community if people care about such stuff. Slaven expects, some
	will care that the the 'm' and 'd' commands now make a connection
	to the internet. FIXED by introducing do_ls_on_m_and_d.

2005-10-20  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* ChangeLog needs to be written by svn during make dist, and the
	dependencies must care for a rerun of 'perl Makefile.PL' when
	CPAN.pm gets edited. This would be 'svn log -r HEAD:131' for the
	ChangeLog, I think. FIXED

2005-10-18  Andreas J. Koenig  <andreas.koenig.gmwojprw@franz.ak.mind.de>

	* Bug: installing SWETH/IPv4.pm did not seem to work anymore.
	FIXED in revision 172.

	* Bug: there is a directory ZTANG/Text-PORE-102/ on CPAN with a
	single file README in it. ls chokes on ZTANG because of this. Is
	it a bug that the directory exists or is it a bug that it has no
	CHECKSUMS file? FIXED by simply removing the README file from
	CPAN.

2005-10-12  Andreas J Koenig  <akoenig@cellular.de>

	* Bug: the nonsense command 'force ls andk' should just do a plain
	'ls andk'. Instead it complains: C<Warning: Cannot ls andk, don't
	know what it is.> FIXED in rev. 180

2005-10-11  Andreas J Koenig  <akoenig@cellular.de>

	* Bug: "o conf foo bar" should complain about invalid key "foo".
	It does instead set "foo" to "bar" and it happened to me to set
	"debug" to "all" and then I wondered why debugging was not turned
	on. Would it have complained, I would have found the correct
	command ("o debug all") much quicker. FIXED in rev. 178.

	* Same effect can be illustrated by changing to the source's root
	directory, running 'perl -Ilib -MCPAN -e shell', 'install
	Tie::CPHash' (or something else???) and then 'reload cpan'....
	Ahhh, this latter example it is a matter of somebody having turned
	off $^W globally:-)...FIXED

2003-08-13  Andreas J Koenig

	cpan script should accept arguments as suggested by Matt Sergeant:
	   cpan install My::Foo
	
	Cache manager should read youngest directories first and start
	deleting without measuring as soon as the cache limit is reached.
	
	Rename 'o conf' to 'set' and 'o debug' to 'set debug'.
	
	Profiling?
	
	Provide something, so that the next "o conf commit" will not overwrite
	the config file. maybe "myconfig_readonly"?
	
	I have a patch by Jochen Wiedmann that implements a per-distribution
	permanent configuration directory. The new containsmods() method in
	1.52 should help to fit the patch with the rest of CPAN.pm.
	
	Option to skip testing (Ask Bjoern Hansen).
	
	Default Argument for make,test,look,etc. could be the last argument???
	
	Make a preferred download method configurable (allow further download
	methods via plugin?)
	
	Allow different site preferences for index files and other files
	
	Replace make with Make
	
	Maintain the cache at runtime. Currently we only check it at startup.
	
	Distribute compressed CHECKSUM files
	
	Security layer
	
	make plugins configurable, adjust @ISA
	
	Make configurable that multiple additional index files can be
	integrated (for Intra-CPANs). I believe CPAN::Site did it right
	anyway, so we might skip this.
	
	Make the 'make' command itself configurable as suggested by Rujith de
	Silva <rujith.desilva@ps.net>, who wants to run 'sudo make install'
	instead of 'make install'. (Fixing this is delayed, because it
	interacts with Make.pm)

	* What does E1, E2, E3, E4, E5, M1, M2, M3, M4, M5, H1, H2, H3, H4, H5
	mean?
	
	E=Easy
	M=Middle
	H=Hard
	1 = unimportant
	5 = important
	
	

	Local Variables:
	mode: change-log
	change-log-default-name: "Todo"
	tab-width: 2
	left-margin: 2
	End:
