?

Log in

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

Status of F-11 on s390x

I'm currently looping over all F-11 packages in CVS and building them on s390x.
There are still not all build dependencies satisfied, so I'd expect quite a few failures.
Mails to the maintainers have been enabled again, and I already got some offers to
help. Thanks a lot for that ! The maintainers usually can fix those bugs much faster
than I as they know their packages much better than I after taking just a short look.
I'll try to keep away from all java related stuff for a while, these build dependencies
are driving me insane.
On the other hand some maintainers didn't even fix their packages after Jesse Keating's
F-11 mass rebuild and I'll have to fix those too to get a complete F-11 tree on s390x:
http://jkeating.fedorapeople.org/failed-f11-rebuilds.html

Maybe we should have dropped those packages from F-11 to give these guys a reminder that
adding packages to Fedora isn't the only responsibility of a maintainer. That's the easy
and most fun part. Keeping those packages up-to-date and fixing bugs is more important IMHO.