Hebe is described on its homepage as:

Hebe is a new KDE 4.4 front-end GUI for the Hercules z/Arch emulator. It was designed to have a modern look, like the VirtualBox interface; there are no dials! Hebe provides two consoles, one for Hercules and one for the SCP (system control program), AKA, the operating system. Input is automatically routed to the correct receiver. You can start as many instances of Hercules as your hardware can support.

I am not a big KDE fan, but I have all the libraries installed, as they come with Slackware, so the program works fine even under Xfce.

Using the standard cmake-template.SlackBuild, I put together a script in just a couple of minutes, which I submitted to SlackBuilds.org.

The resulting program looks really nice:

One really nice feature is the capability to run several copies of Hercules at the same time through one single interface.

For the inpatient, pre-built packages can be downloaded from my site.

So what better to do than finally test the 64-bits version of Slack/390?

I wrote an 11-part post about installing Slack/390 on Hercules more than a year ago, and it is still valid and can be used for installing the newer version of Slack/390 as well – at least for about 90%.
I did encounter some problems though, but the 64-bits version of Slack/390 is still in the testing phase, so we should give it some credit.

What went wrong:

• The “ramdisk_size” from the supplied parmfile.txt is way too small, I made it 64000 to work
• Some packages were missing (sgml-tools / bin86 / clisp / gcc-gnat), but no show-stoppers
• The “etc” package was not installed, causing some problems with standard users and groups
• The symlink “sh” pointing to “bash” was missing, so none of the rc.* scripts would work (created it manually)
• The “/etc/slackware-version” file was missing

I managed to solve all problems one by one and installed SlackPkg from /extra afterwards to update my installation with the latest packages.
I sent my findings to the maintainers of Slack/390 to that future users won’t have the same challenges that I had

I might write a new series of posts on installing Slack/390, with updated information, but I’ll probably wait until the new version is a bit more stable.

For now, I’m having fun with my new 2x 64-bits emulated Mainframe running Slackware!

After almost two years without activiry, the maintainers have released some patches / upgrades for Slack/390 – both the -stable and the -current versions.
Since I use SlackPkg on my other Slackware installations (12.1, 12.2 & -current), I wanted to use this same tool in my Slack/390 installation.

First i tried with the version that is included in /extra in Slack/390, but it is quite old (1.4, from 2005) and it simply didn’t work.

The first problem is that the big majority of packages on the Slack/390 mirrors do not have the associated xxxx.tgz.asc file, which contain the GPG ckecksum of the package.
This was simple to resolve, setting CHECKGPG=off in /etc/slackpkg/slackpkg.conf

But the second problem I encountered was with the naming of some files on the Slack/390 mirrors that differs from the ‘main’ Slackware version:

• The MANIFEST.bz2 files are called MANIFEST.s390.bz2 in Slack/390
• The CHECKSUM.md5 files are called CHECKSUM.s390.md5 in Slack/390
• The PACKAGES.TXT files are called PACKAGES.s390.TXT in Slack/390
• The FILELIST.TXT file is called FILELIST.TXT.s390 (yes, at the end) in Slack/390

I remembered from the newer versions that there was an option for the ‘architecture’, so I decided to try SlackPkg 2.70.5 from slackware-12.2
It can be downloaded here or any valid Slackware mirror.
Since SlackPkg is written as a collection of scripts and marked as “noarch”, I expected no problems.

So I downloaded the package, upgraded the 1.4 version with upgradepkg and edited /etc/slackpkg/slackpkg.conf
I commented out the ’standard’ x86 architecture and uncommented the ARCH=s390 line.
But no luck yet… Still the same problems with the differences in the file names.

At this moment I reached the conclusion that I had to ‘hack’ the SlackPkg scripts to get it working.

I ended up modifying two files, /usr/bin/slackpkg & /usr/libexec/slackpkg/core-functions.sh

The first patch is to the main slackpkg script and defines a variable ’subARCH’ to insert the “.s390″ text in the filenames in case the ARCH is s390:

--- slackpkg.orig 2009-04-10 23:44:49.000000000 -0300
+++ /usr/sbin/slackpkg 2009-04-10 23:57:28.000000000 -0300
@@ -40,6 +40,7 @@
SOURCE=$(grep -e "^\([a-z]\)" $CONF/mirrors)
. $CONF/slackpkg.conf
ARCH=${ARCH:-i[3456]86}
+[ "$ARCH" = "s390" ] && subarch=".s390"
LOCAL=0
KERNELMD5=$(md5sum /boot/vmlinuz 2>/dev/null)
TMPDIR=$(mktemp -p /tmp -d slackpkg.XXXXXX 2>/dev/null || echo "FAILED")


The second patch is to the core-functions script and inserts the $subARCH variable in the filenames:

--- core-functions.sh.orig 2009-04-10 23:53:19.000000000 -0300
+++ /usr/libexec/slackpkg/core-functions.sh 2009-04-11 00:02:49.000000000 -0300
@@ -618,16 +618,16 @@
#
echo -e "\t\tList of all files"
for i in $FIRST $SECOND $THIRD $FOURTH $FIFTH ; do
- getfile ${i}/MANIFEST.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
+ getfile ${i}/MANIFEST${subARCH}.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
dirs="$dirs $i"
done

# Format FILELIST.TXT


With these changes, I got SlackPkg working in my Slack/390 installation!

There are still some problems, but they depend on some cleaning up of the Slack/390 mirrors.
In the following image you can see that SlackPkg wants to “upgrade” some packages to older versions:

The fact that SlackPkg want to “downgrade” itself to version 1.4 is understandable, as it is the official version for Slack/390.
The suggestions to downgrade abiword, gftp and gucharmap are caused by the fact that these packages exist two times on the mirrors, once in slackware/gnome (the older versions) and once in slackware/xap (the newer versions).
I wrote about these inconsistencies to s390support@slackware.com but unfortunately have not received any answers yet.

Even with these minor problems, keeping your Slack/390 installation is a lot simpler now with a working SlackPkg!

I recently managed to patch a current version of SlackPkg to work on Slack/390 (the version included in /extra does not work).
I’ll try to organize my notes during the following days and publish the patch so that everyone can keep Slack/390 updated with this wonderful tool

I use SlackPkg, a wonderful tool that since long has been included with Slackware as an extra, but since the release of 12.2 is part of the standard installation.
SlackPkg can check for updates to the -current or stable branch and then upgrade or add the available packages and patches.

This week (April 15th) a new version of the ‘pkgtools’ package was released, fixing some small bugs. While trying to upgrade the package with SlackPkg, it complained that the md5sum was not matching.
After researching some of the code, I found out that in the ‘checkpkg’ function in /usr/libexec/slackpkg/core-functions.sh the ‘MD5ORIGINAL’ variable receives the md5sum of both the package to be installed and the source package (source/a/pkgtools/pkgtools-12.34567890-noarch-2.tgz).

A temporary work-around was to disable md5sum checking in SlackPkg, changing CHECKPKG=on to CHECKPKG=off in /etc/slackpkg/slackpkg.conf

I posted the problem at LinuxQuestions and the same day Alan Hicks responded with a patch that basically filters out the source-packages when getting the md5sum.

The trick is in the included ‘grep -v’. In /usr/libexec/slackpkg/core-functions.sh the line:
MD5ORIGINAL=$(grep "/${NAMEPKG}$" ${WORKDIR}/CHECKSUMS.md5| cut -f1 -d \ )
was changed to:
MD5ORIGINAL=$(grep "/${NAMEPKG}$" ${WORKDIR}/CHECKSUMS.md5| grep -v '/source/'| cut -f1 -d \ )

It seems to be a rare occurrence of having an installation package and source package with exactly the same name.

The patch lets SlackPkg install the package, but it is still not perfect, as it tries to install it twice.
But I’ll leave this to PiterPunk to fix, as it is no serious problem.