Phil has already posted the announcement, but I think this is also worth a blog entry.
We've finally fixed all our blockers for the alpha release of F-16 for PowerPC, got all packages properly signed and synced to the mirrors !
So, if anyone has a PowerMac or an IBM PowerPC that is catching dust because you don't know what to do with it, now is your chance to get the latest Fedora version on it and help out with testing.

You can grab the DVD or netboot images from one of the mirrors for F-16 Alpha for PPC (32bit) or for PPC64 (64bit). PPC64 is our main platform that we develop and test our packages and installer on, 32bit installs are unfortunately completely untested as we don't have the necessary hardware for that.

Report any issues that you find during testing in bugzilla, but please make sure that you set the architecture to 'powerpc' so that we can find your report.

Automatic rebuilds with koji-shadow have started, so I'd expect that the number of older packages continues to drop even more in the next few days:



Martin Gracik has almost completed his work on PPC support for lorax, that's our tool to populate the new unified ramdisk.
This means that we can start looking into boot and install issues now.

Steady progress, 2126 packages older than the latest package with the same name on primary arch dist-f15, 7543 have the same N-V-R, 250 are newer than its counterpart (sometimes we have to use packages from dist-f15-updates-candidate).



'Older' means the latest RPM of a package is older on PPC then on the primary archs.
'Same' and 'newer' are for the reader to figure out.
'total_missing' is calculated like this: primary arch has the RPMs foo-1.0-1.fc15, foo-1.0-2.fc15 and foo-1.0-3.fc15, PPC has only foo-1.0-1.fc15, so that's 2 missing builds. And when foo-1.0-3.fc15 is built on PPC, the missing_builds counter goes to zero, it's the worst case number

6860 packages done, 2800 more required to catch up with the primary archs:



'Older' means the latest RPM of a package is older on PPC then on the primary archs.
'Same' and 'newer' are for the reader to figure out.
'total_missing' seems to be calculated like this: primary arch has the RPMs foo-1.0-1.fc15, foo-1.0-2.fc15 and foo-1.0-3.fc15, PPC has only foo-1.0-3.fc15, so that's 2 missing builds.

Noarch imports are done, now only real rebuilds are counting. Adrian is doing the mass rebuild while I concentrate on looking through the build failures and fix whatever needs to be fixed:



'Older' means the latest RPM of a package is older on PPC then on the primary archs.
'Same' and 'newer' are for the reader to figure out.
'total_missing' seems to be calculated like this: primary arch has the RPMs foo-1.0-1.fc15, foo-1.0-2.fc15 and foo-1.0-3.fc15, PPC has only foo-1.0-3.fc15, so that's 2 missing builds.

It looks much better after almost all noarch packages have been imported:

This is a shameless copy of Dan's idea to present the s390x rebuild progress, only this one is for PPC.



'Older' means the latest RPM of a package is older on PPC then on the primary archs.
'Same' and 'newer' are for the reader to figure out.
'total_missing' seems to be calculated like this: primary arch has the RPMs foo-1.0-1.fc15, foo-1.0-2.fc15 and foo-1.0-3.fc15, PPC has only foo-1.0-3.fc15, so that's 2 missing builds.


The F-15 mass rebuild put us back quite a bit, but I've started importing all those noarch packages that won't need a rebuild on PPC. Meanwhile Adrian Reber is making good progress with the rebuilds, now that most of the initial bootstrapping issues are resolved.

We're getting closer to a release candidate of F-14 for mainframes. The latest packages and boot images have been uploaded to the s390x secondary arch directory.

There's a new image (~600Mb) for the Hercules emulator for those without access to a real mainframe. We also have instructions on how to install an s390x system from scratch in the Hercules emulator.

VIM-7.3 (in Rawhide and f12-testing) has a nice new feature: persistent undo.

In earlier versions undo wouldn't work after a vim buffer or vim itself got closed. VIM-7.3 can be configured to keep the undo history. Here's what I currently have in my ~/.vimrc file:

set undodir=/home/karsten/.vim/undodir
set undofile

You need to manually create the undodir directory manually, vim won't do that for you.

VIM's help has more information if you'd like to learn more about this new persistent undo feature with

:h persistant

fedpkg definitely is an important step in the right direction and I appreciate the work that already has been done, but it has some shortcomings that will need to be addressed. I hope no one thinks I'm criticizing here, that's not my intention at all.
Below are a few issues that I've run into so far:

- As we don't use tags anymore, there's no easy way to determine the koji commandline. With CVS the commandline to build p.e. hwdata-0.227-1.fc14 would have been

 /usr/bin/koji build dist-f14 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/hwdata/F-14#hwdata-0_227-1_fc14'

.
A simple script that replaces all '.' with '_' could convert all package n-v-r's on the primary archs into build commands for the secondary archs. Now something like

/usr/bin/koji build dist-f14 "git://pkgs.fedoraproject.org/ed?#d88647a72f2d11f4a623465802c3f97c3773f1f8"

needs to be done, but ATM there doesn't seem to be a way in koji (without using the koji API) to get the git commit info for a specific n-v-r that can then be used to build that same package on the secondary archs.

- There doesn't seem to be support for secondary archs in fedpkg. koji allows parameters like '-c ~/.koji/s390-config' to build packages for the mainframe, the only way I could trick fedpkg to build there was to link '~/.koji/s390-config' to '~/.koji/config', but that sucks if you frequently have to switch between primary and secondary archs.

- There currently is no dist-f14-updates-candidate on the s390x secondary arch koji hub. Sure, we should probably add this target, but atm there's no way in fedpkg to specify the koji build target so that packages can be built directly into dist-f14. The python-2.7 mass rebuild in a different koji target is another example why it might be useful to be able to overwrite fedpkg's defaults.