Paul's Blog Entries for June 2009

Monday 1st June 2009

Fedora Project

PPTP Client Project

Local Packages

Tuesday 2nd June 2009

Local Packages

Thursday 4th June 2009

Fedora Project

Local Packages

Friday 5th June 2009

Local Packages

Finally got round to making perl-PPI 1.203 build successfully across all of my supported releases. On Red Hat Linux 9 and Red Hat Enterprise Linux 3 it was failing multiple tests with "Can't use an undefined value as an ARRAY reference" errors like in this test case. This appears to be a bug in perl 5.8.0, or at least the Red Hat version of it, and I was able to fix it with this patch: 

--- PPI-1.203/lib/PPI/Lexer.pm  2008-05-14 05:14:00.000000000 +0100
+++ PPI-1.203/lib/PPI/Lexer.pm  2009-06-05 15:39:19.000000000 +0100
@@ -278,7 +278,7 @@
        # Checking once at the end is faster than adding a special
        # case check for every statement parsed.
        my $v6 = $self->{Tokenizer}->{v6};
-       if ( @$v6 ) {
+       if ( defined($v6) && @$v6 ) {
                my $includes = $Document->find( 'PPI::Statement::Include::Perl6' );
                foreach my $include ( @$includes ) {
                        unless ( @$v6 ) {

On Fedora Core 3 and 4, the 14_charsets.t test just got stuck in an infinite loop gobbling up memory as per CPAN RT#35917, which was easily fixed by updating the test to the one in the 1.204_02 developer release, which simply skips the test on perls older than 5.8.7.

Monday 8th June 2009

Fedora Project

Local Packages

Today I got started on a project that I've been meaning to implement for a very long time, namely moving the repository source into a version control system. I've chosen subversion for this, mainly because of my familiarity with it and also because there's no need at this time to use a distributed VCS as I'm the only person likely to be making commits. I'll also be able to use the very nice repository browser that comes with trac when I set up the repository bug tracker (coming soon).

Anyway, here's what I did. The subversion repository is going to live on subversion.city-fan.org, so I logged in there and became root, then did: 

# yum install subversion mod_dav_svn
# mkdir -p /srv/subversion/repos
# chcon -R -t httpd_sys_content_rw_t /srv/subversion/repos
# chown apache:apache /srv/subversion/repos
# su - -s /bin/sh apache
$ svnadmin create --fs-type fsfs /srv/subversion/repos/cfo-repo
$ logout
# cd /srv/subversion/repos/cfo-repo/conf
# htpasswd -c htpasswd paul
(set my password)
# chgrp apache htpasswd
# chmod 640 htpasswd
# vi authz
# vi /etc/httpd/conf.d/subversion.conf
# service httpd reload

/etc/httpd/conf.d/subversion.conf: 

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

#
# Example configuration to enable HTTP access for a directory
# containing Subversion repositories, "/var/www/svn".  Each repository
# must be readable and writable by the 'apache' user.  Note that if
# SELinux is enabled, the repositories must be labelled with a context
# which httpd can write to; this will happen by default for
# directories created in /var/www.  Use "restorecon -R /var/www/svn"
# to label the repositories if upgrading from a previous release.
#

#
# To create a new repository "http://localhost/repos/stuff" using
# this configuration, run as root:
#
#   # cd /var/www/svn
#   # svnadmin create stuff   
#   # chown -R apache.apache stuff
#

<Location /repos>
   DAV svn
   SVNParentPath /srv/subversion/repos

   # Limit write permission to list of valid users.
   <LimitExcept GET PROPFIND OPTIONS REPORT>
      # Require SSL connection for password protection.
      # SSLRequireSSL

      AuthType Basic
      AuthName "City-Fan.Org Package Repository"
      AuthUserFile /srv/subversion/repos/cfo-repo/conf/htpasswd
      Require valid-user
   </LimitExcept>
</Location>

<Directory "/srv/subversion/repos">
   Options Indexes FollowSymLinks
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

/srv/subversion/repos/cfo-repo/conf/authz: 

### This file is an example authorization file for svnserve.
### Its format is identical to that of mod_authz_svn authorization
### files.
### As shown below each section defines authorizations for the path and
### (optional) repository specified by the section name.
### The authorizations follow. An authorization line can refer to:
###  - a single user,
###  - a group of users defined in a special [groups] section,
###  - an alias defined in a special [aliases] section,
###  - all authenticated users, using the '$authenticated' token,
###  - only anonymous users, using the '$anonymous' token,
###  - anyone, using the '*' wildcard.
###
### A match can be inverted by prefixing the rule with '~'. Rules can
### grant read ('r') access, read-write ('rw') access, or no access
### ('').

[groups]
svn-admin = paul

[/]
@svn-admin = rw
* = r

Tuesday 9th June 2009

Local Packages

Wednesday 10th June 2009

Local Packages

I have also now set up a bug tracker and subversion repository browser using trac, which is mainly for my own convenience though of course any users of my packages are welcome to create accounts there and report issues.

Thursday 11th June 2009

Local Packages

Wiki

Monday 15th June 2009

Local Packages

A couple of the perl module packages were unusually troublesome today.

Firstly, perl-XML-NamespaceSupport tries to use the CPAN module by default during installation due to the use of Module::AutoInstall, so that would be an extra build requirement (no too bad) and loads of extra redundant text in the build logs due to the CPAN module trying to configure itself. However, the biggest problem with the use of CPAN in an RPM-based distro is that it might pull in modules that don't get registered in the RPM database, leading to potentially unreproducible builds. Fortunately this could be prevented by adding the --skipdeps parameter to the Makefile.PL invocation.

Secondly, perl-Array-Compare failed to build on anything older than Fedora Core 5, trying to run Build.PL (which requires Module::Build, not in the buildroot). Adding a buildreq of perl(Module::Build) didn't help either, resulting in this strange output: 

Checking if your kit is complete...
Looks good
Writing Makefile for Array::Compare
+ /usr/bin/make -j2
/usr/bin/perl "-Iblib/arch" "-Iblib/lib" Build.PL Build
cp lib/Array/Compare.pm blib/lib/Array/Compare.pm
Manifying blib/man3/Array::Compare.3pm
Too early to specify a build action 'Build'.  Do 'Build Build' instead.
make: *** [Build] Error 2

Looking at what had changed in Makefile.PL since the previous version, I saw that it had been auto-generated by Module::Build::Compat version 0.32, whereas the previous version was auto-generated by Module::Build::Compat version 0.2808_01. The only other change was that the PL_FILES entry was missing from the WriteMakefile call. Adding this back using this patch fixed the problem: 

--- Array-Compare-1.18/Makefile.PL      2009-06-14 18:59:54.000000000 +0100
+++ Array-Compare-1.18/Makefile.PL      2009-06-15 10:55:38.000000000 +0100
@@ -9,6 +9,7 @@
                            'Carp' => 0
                          },
           'INSTALLDIRS' => 'site',
+          'PL_FILES'  => {},
           'EXE_FILES' => []
         )
 ;

Tuesday 16th June 2009

Local Packages

Wednesday 17th June 2009

Local Packages

Thursday 18th June 2009

Local Packages

Fedora Project

SELinux Reference Policy

Friday 19th June 2009

Local Packages

Saturday 20th June 2009

Local Packages

Having noticed that there was a kernel update available for CentOS 5, I tried updating one of the CentOS 5 boxes at work. Whilst there were no problems with the CentOS updates, it reported an error regarding one of the packages from my repo: 

Error Downloading Packages:
  php-Smarty-2.6.25-1.rhel5.noarch: failure: php-Smarty-2.6.25-1.rhel5.noarch.rpm from city-fan.org: [Errno 256] No more mirrors to try.

This was unexpected because I updated php-Smarty to 2.6.26 yesterday. It's no surprise that 2.6.25 wasn't there but a it shouldn't have been looking for it at all. The first thing I tried was to force-update the metadata for my repo: 

# yum --disablerepo=\* --enablerepo=city-fan.org clean metadata
# yum update php-Smarty
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * epel: ftp.heanet.ie
 * base: mirror.bytemark.co.uk
 * addons: mirror.bytemark.co.uk
 * updates: mirror.bytemark.co.uk
 * extras: mirror.bytemark.co.uk
city-fan.org                                                                            | 2.3 kB     00:00     
primary.sqlite.bz2                                                                      | 186 kB     00:00     
http://download.virtensys.com/mirrors/city-fan.org/yum-repo/rhel5/i386/repodata/primary.sqlite.bz2: [Errno -3] Error performing checksum
Trying other mirror.
primary.sqlite.bz2                                                                      | 186 kB     00:00     
http://download.virtensys.com/mirrors/city-fan.org/yum-repo/rhel5/i386/repodata/primary.sqlite.bz2: [Errno -3] Error performing checksum
Trying other mirror.
Error: failure: repodata/primary.sqlite.bz2 from city-fan.org: [Errno 256] No more mirrors to try.

Then I recalled that Fedora 11 (which I've recently migrated by build system to) had a feature of stronger hashes, which includes the RPM package and repository metadata signature algorithms - I was generating repository metadata using the new algorithm (SHA256 in this case) that wasn't understood by older distributions. After some googling I found the solution I needed, a so-far undocumented --checksum option to createrepo that could be used to force the use of the old algorithm. So I changed my repo-building script generator's call to createrepo from this (it's written in awk): 

printf "createrepo --update -d .\n"

to this: 

if (dist ~ "^fc[1-9][0-9]$") {
        printf "createrepo --update -d .\n"
} else {
       printf "createrepo --update -d --checksum sha .\n"
}

This used the new algorithm for the Fedora 10 repos onwards (F-10's yum should be fine with that) and the old one everywhere else. I rebuild the repository and it improved things but there was still a problem:

Monday 22nd June 2009

Local Packages

Tuesday 23rd June 2009

Local Packages

Wednesday 24th June 2009

Local Packages

Thursday 25th June 2009

Local Packages

Fedora Project

I looked to see if anyone else had reported the proftpd issue and found Bug #506735, which was related to capabilities but was actually a problem I'd found a fix for two years ago and had never gotten round to submitting the patch upstream. I commented in the bug and asked MatthiasSaou if he'd mind if I became co-maintainer and fixed the problem myself, and he didn't mind at all. So I'm now co-maintainer of proftpd in Fedora.

Monday 29th June 2009

Local Packages

Tuesday 30th June 2009

Local Packages

Previous Month: May 2009
Next Month: July 2009