?

Log in

No account? Create an account

PPC secondary arch progress

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

PPC secondary arch progress

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.

PPC secondary arch progress

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.

PPC secondary arch progress

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

PPC secondary arch progress

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.

Persistent undo in VIM-7.3

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

Tags:

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.

F-14 on mainframe finally boots

It took quite a while, but the anaconda install images finally boot on s390x with just two workarounds.

- There is a special case for s390x in anaconda that lower the recommended swap size to 1. Automatic partitioning then tries to create a lv_swap logical partition with 0 extents which lvcreate correctly refuses to do. Setting the suggested swap size to p.e. 256MB works around it, although the proper fix would be to check is the size of the logical partition is 0 and then skip lvcreate.

- The other problem is that the s390x installer fails to start rsyslogd, but anaconda relies on it and aborts with a traceback. Starting the logger daemon from a second shell works around that for the moment.

Of course there are some of other issues like glib errors on the console or vnc not starting, but at least it finally installs and even the reboot afterwards works.

First boot of F-11 on s390x

I've managed to do a manual update of a minimal RHEL-5.3 installation to F-11 on zSeries. All packages have been replaced by their F-11 counterparts, only the RHEL-5 kernel remained as a fallback. The first attempt with the root FS on a software raid with some of the raid members being FCP devices failed to boot . The system just hangs after the DASD detection. I've then installed on a single DASD and voila, the kernel boots successfully. The drawback is that it doesn't give me a shell in the x3270 terminal and that it fails to set up the network when I boot into runlevel 3. Runlevel 1 at least gives me a shell and I was able to manually configure the network, although the procedure is slightly more complicated than on other archs:

modprobe qeth
cd /sys/bus/ccwgroup/drivers/qeth
echo 0.0.0600,0.0.0601,0.0.0602 > group
echo 1 > 0.0.0600/online
ifconfig eth0 IP
route add default gw GW-IP

0.0.0600 - 0.0.0602 are called the 'subchannels' used by the qeth network device. They need be grouped and the device must be made available to the system via the /sys interface.

The next steps are:
- fixing the userland stuff which won't give me a shell and network
- fix anaconda and NetworkManager to be able to set up a F-11 s390x system from scratch