CPAN
view release on metacpan or search on metacpan
And here is the relevant output of Marc's Makefile.PL:
Warning: prerequisite AnyEvent 2.51 not found.
Warning: prerequisite Event 1.06 not found.
Warning: prerequisite IO::AIO 2.3 not found.
*** Event not found, not build Event support.
This seems like a bug to me. He should ask if Event support is wanted
and if yes, make Event a prerequisite. At least from my point of view he
should do so.
It has already lead to a wrong bugreport by chris on cpantesters.
And I have now written to Marc (with CC cpantesters) if he would change
things accordingly). Miscommunication happened and so I need to give up:-(
* Locale::TextDomain needs a binary search. Yay, the first one for a
long time that goes back before 20000. We are compiling perls in the
[16904,17122] interval! Ouch: 16916, 16951, 16953, 16991, 17022, 17058,
17075 do not want to be compiled!
This needs more attention. Yes, it's DB_File that fails nowadays with
these old perls. And we always used -Ui_db. For binsearchaperl the full
argument then is
--config="-Dinstallusrbinperl=n -Uversiononly -Doptimize=-g -des -Duse64bitint -Dusedevel -Ui_db"
----Program----
eval {require Locale::TextDomain};
print $@ ? "N/A" : "OK";
print "\n";
----Output of .../pm3UiPL/perl-5.7.3@16904/bin/perl----
OK
----EOF ($?='0')----
----Output of .../pN2DxS9/perl-5.7.3@16905/bin/perl----
N/A
----EOF ($?='0')----
Change 16905 by jhi@alpha on 2002/05/30 20:26:32
Subject: [PATCH perl@16893] lib/blib.t tweak for VMS
From: "Craig A. Berry" <craigberry@mac.com>
Date: Thu, 30 May 2002 16:22:40 -0500
Message-Id: <a05111703b91c44a6865f@[172.16.52.1]>
Impossible. This patches a test file in core perl, this cannot have
consequences on user code.
So it's likely to depend on a module.
diff -u =(sort /home/k/.cpan/Bundle/Snapshot_2007_04_14_00.pm) =(sort /home/k/.cpan/Bundle/Snapshot_2007_04_14_01.pm) | less
Nothing obvious. So let's study the test itself.
It's about how the Austrians say to the month February. Why on earth is
16904 able to dig that word "Feber" out of the locale system but 16905
not? The files that contain "Feber" are specifically being delivered by
Locale::TextDomain, so seem not dependent on my Linux version or the
state of my locale installations.
https://rt.cpan.org/Dist/Display.html?Queue=libintl-perl is empty.
So if I cannot find a negative module dependency, it's something in
perl?
Wow: my 16904 was compiled on Gentoo! But comparing the configs does not
reveal anything yet.
Maybe it helps to run the same program in two debuggers step by step?
One day has passed and when I retry today in a fresh directory, then
both 16904 and 16905 succeed on this test while 30952 fails. Heisenbug?
I'll start with a new binary search. Apparently I did something wrong
yesterday. I realize comments in the test output that escaped me
yesterday. The new test script filters those comments out
(t04find_domain_bug.t).
With this I'm told that 29052 succeeds but 29053 fails with an Assertion
failure. I rerun with new boundary and now the assertion failure did not
go away up to 29543 and 29544 was then failing on the
04find_domain_bug.t.
So this seems more logical and proves yesterday's recherche was bogus,
most probably not a Heisenbug.
Update 2007-05-05 akoenig: Locale::TextDomain succeeded @31148!
2007-04-13 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
* Devel::ebug again. failed with 30943 but on retry success. The logfile
reports
t/return.........YAML Error: Invalid characters in stream. This parser only supports printable ASCII
Code: YAML_PARSE_ERR_BAD_CHARS
Line: 0
Document: 0
at /home/src/perl/repoperls/installed-perls/perl/pCufuHQ/perl-5.8.0@30943/lib/site_perl/5.9.5/YAML.pm line 33
# Looks like your test died before it could output anything.
dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-13
Failed 13/13 tests, 0.00% okay
[...]
t/return.t 255 65280 13 26 1-13
Remember that "20070330T2346 perl 30791" already had a problem. But it
was not in the same test. It was
t/break_point....YAML Error: Invalid characters in stream. This parser only supports printable ASCII
Code: YAML_PARSE_ERR_BAD_CHARS
Line: 0
Document: 0
at /home/src/perl/repoperls/installed-perls/perl/p6oBwLf/perl-5.8.0@30791/lib/site_perl/5.9.5/YAML.pm line 33
# Looks like you planned 27 tests but only ran 15.
# Looks like your test died just after 15.
dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 16-27
* 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
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?
* 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>
( run in 0.498 second using v1.01-cache-2.11-cpan-ceb78f64989 )