Nicholas Clark writes:
A short report this month as less work got done, due to illness and disruption.
The single largest item of the month was spent getting my head around the state of cross compilation. Mostly this was figuring out the history and state of various cross compilation approaches in the core codebase, to help Jess Robinson refine a potential TPF grant application for cross compilation (particularly to Android). At the time of writing most of this is still groundwork (and intangible), such as studying her x-compile-android work at https://github.com/castaway/perl and the various existing *nix cross-compilation approaches in the core, but hopefully it should soon materialise into the actual published grant application, approval, and then visible code and progress. We think we can see an approach to take that has a good chance of working out long term, by being as simple as possible within the existing build setup.
I also diagnosed the likely cause of File::Glob failures we're seeing on some HP-UX machines. It looks like another C compiler bug handling bool. Pesky new fangled C99 and its complex new features. 12 years is clearly not long enough for compiler writers to be sure to have all the bugs squished. However, I've not had time to investigate further and be confident that my initial "top of my head" fix is the best long term plan, so this build failure is not yet resolved.
I spent some time starting to prune the core's todo list. Historically, the core's list of todos was recorded in the perltodo man page. This really isn't the best place for it, as installing snapshot that becomes increasingly out of date isn't that useful to anyone. So the 5.15.9 is the end of an era in this respect. The todo list is now in Porting/todo.pod, and the man page replaced with a small placeholder that points the reader to the git repository for the current version. Currently the version in blead is unchanged, but in a branch I've culled about 10% of the todos, those that are either done, mostly done, or no longer relevant. There are still a few to be updated where we have a better idea of how to do it, and the document needs restructuring to make it easier to spot appropriate "starter" tasks.
Whilst looking at some older bugs I needed to build various CPAN modules on OpenBSD against older versions of perl. Bootstrapping (older) CPAN didn't turn out be as easy it could have been, partly thanks to command line tools somehow managing to double gzip tarballs. The following approach might be useful to others in a similar situation on a recalcitrant setup:
1) manually get a tarball of the current CPAN.pm onto the machine and unpack it
2) Run its Makefile.PL. For now, don't worry about the missing pre-requisites warnings. Build it. (Run tests.) Install it.
3) Run the newly installed cpan client on the checked out tarball, as 'cpan .' If you need proxies for HTTP and FTP, set HTTP_PROXY and FTP_PROXY appropriately in your environment. Configure the CPAN client as prompted. This will fetch the missing pre-requisites, build and install them.
This approach is far more likely to succeed than trying to get the older version's installed cpan client to get a new CPAN.pm, as the older version doesn't incorporate the bug fixes and work arounds for awkward command line tools.
A more detailed breakdown summarised from the weekly reports. In these:
16 hex digits refer to commits in http://perl5.git.perl.org/perl.git
RT #... is a bug in https://rt.perl.org/rt3/
CPAN #... is a bug in https://rt.cpan.org/Public/
BBC is "bleadperl breaks CPAN" - Andreas König's test reports for CPAN modules
ID YYYYMMDD.### is an bug number in the old bug system. The RT # is given afterwards.*
|0.75||HP-UX build failure|
|1.75||ID 20010303.010 (#5956)|
|0.25||ID 20010929.014 (#7765)|
|1.50||Testing on OpenBSD|
|0.50||checking accuracy of git tags|
|6.25||minor changes for 5.15.9|
|3.75||process, scalability, mentoring|
|6.75||pruning the todo list|
|pruning the todo list, Pod::HTML|
|17.75||reading/responding to list mail|
73.00 hours total
* One can convert old system numbers to RT ticket numbers using the form at
https://rt.perl.org/perlbug/ The old system numbers are mostly a historical curiosity, but they can be useful when searching git logs and the mailing list archives.