Ubuntu 8.04 64-bit build (Hardy A4)

[ironstorm]

Hi all,

I have completed a build on Ubuntu 8.04 64-bit Hardy A4 from the public Zimbra P4 cache. I'd like to package it up, but I'm stumped as to what make target I need to call (something in coretargets.def?) in order to kick off the debianization of the built files.

It looks like this might be undocumented territory as I've not found any wiki or forum posts that explicitly mention how to invoke the packaging process to create RPMs or DEBs from the build scripts. If anyone could fill me in on the missing step it would be much appreciated.

When I finish my work, I'll be posting a patch with modifications required to build on Hardy + 64-bit.

Cheers,
-G

[dijichi2]

packaging debs is already fully supported in the various debian and ubuntu builds. your best bet is just to copy an existing debian or ubuntu .def in ZimbraBuild/defs and use that. doing a full build will automagically package everything for you in ZimbraBuild/i386 and ZimbraBuild/zcs-xxx.

[ironstorm]

So much for being done I had a "Build Successful" message, seems building with "sudo make -j 2" is somewhat unpredictable...

When I rerun with just "sudo make" I get an error with SpamAssassin...

...
/opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf
cp /opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/com.zimbra.zcs.plist /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf
cp /opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/postfix_recipient_restrictions.cf /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf
cp -Rf /opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/externaldirsync /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf/externaldirsync
cp -Rf /opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/build/dist/conf/msgs /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf/msgs
mkdir -p /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf/spamassassin
cp /opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/spamassassin/[^C]* /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf/spamassassin
cp: cannot stat `/opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/spamassassin/[^C]*': No such file or directory
make: *** [/opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf] Error 1

[dijichi2]

there's not supposed to be a space between the -j and the number is there?

as for this:

cp /opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/spamassassin/[^C]* /opt/zimbra-src/main/ZimbraBuild/corebuild/opt/zimbra/conf/spamassassin
cp: cannot stat `/opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/spamassassin/[^C]*': No such file or directory

I have long since changed this in my patches, [^C] doesn't seem to do anything useful as there is nothing present that would match that regexp. Check that you're using bash, not dash as ubuntu seems to like to use for unknown reasons as this might provoke this problem.

[ironstorm]

there's not supposed to be a space between the -j and the number is there?

it's fine, man says "-j [jobs], --jobs[=jobs]"... it would have complained that there was no "2" build target. Idea was to take advantage of SMP to help speed up compiling.

/opt/zimbra-src/main/ZimbraBuild/../ZimbraServer/conf/spamassassin/[^C]*

I had thought at the time, that the error was because it was expecting to find something starting with "C" to ignore but there was nothing starting with "C". Upon further reflection that thought seems a bit silly, as it shouldn't care if something is not there if it wants to exclude it anyway...

It make sense that this is a shell expansion problem where dash is bollocking up [^C]* as a real file name instead of expanding it like Bash would do... (I haven't replaced the default shell with bash, forgot that Dapper symlinked sh -> dash). If you wouldn't normally see "C*" files, then I may just change that to cp * instead. [I'm trying to avoid changing stuff in the base distro where possible]

Cheers,

-G

[ironstorm]

Got everything built into debs and packed into a ZCS tarball...

Still have some work to do, zimbra-core refuses to install because "x86_64 is a unknown OS"...

Cheers,

-G

[quanah]

You need to make sure there is a defined platform tag, and check what's done for 64-bit ubuntu as well, as for some of the stuff it has to be defined as amd64 and not x86_64.

[ironstorm]

The problem is a check in:
ZimbraBuild/rpmconf/Install/Util/modules/packages.sh

I've put in a fix there already.

[ironstorm]

/opt/zimbra/bin/zmshutil: line 39: Error: command not found

line #39 in /opt/zimbra/bin/zmshutil is:
if ! eval `${zmlocalconfig} -q -m export`; then

I think is actually cause by Java not working during a call to /opt/zimbra/bin/zmlocalconfig a few lines up

Setting local config zimbra_java_home to /opt/zimbra/java
*** Running as zimbra user: /opt/zimbra/bin/zmlocalconfig -f -e zimbra_java_home='/opt/zimbra/java' 2> /dev/null
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

notroot@ubuntu:~/zcs-5.0.3_GA_2006.UBUNTU8_64.20080221074351$ sudo /opt/zimbra/bin/zmlocalconfig
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

I can background the installer and hack-in sun-java6-jre to zmlocalconfig (sun java6 jre will then work for that command in the shell) but I still get zmshutil line #39 error message during the install when I foreground it again...

This is what I was doing to try to roll my own java tarball replacement:

# Download Ubuntu's Java "Source" package and repack as "jdk1.6.0_04.tgz"
cd /opt/zimbra-src/${RELEASE}
sudo mkdir -p ./ThirdPartyBuilds/x86_64/java
sudo wget http://archive.ubuntu.com/ubuntu/pool/multiverse/s/sun-java6/sun-java6_6-03.orig.tar.gz -O ./ThirdPartyBuilds/x86_64/java/sun-java6_6-03.orig.tar.gz

cd ./ThirdPartyBuilds/x86_64/java
sudo tar -zxvf sun-java6_6-03.orig.tar.gz
sudo chmod +x sun-java6-6-03/jdk-6u3-dlj-linux-amd64.bin
sudo sun-java6-6-03/jdk-6u3-dlj-linux-amd64.bin
# type "yes" to Sun's Java license
sudo mv jdk1.6.0_03 jdk1.6.0_04
sudo tar -zcvf jdk1.6.0_04.tgz jdk1.6.0_04
sudo rm -rf jdk1.6.0_04

[ironstorm]

Here is the current patch...

Stuff to consider:

• CPAN repo changed to a public accessible one
• JAVA_HOME changed, guessing here...
• In general you'd want to try to detect longer strings UBUNTUx_64 before going for shorter ones UBUNTUx, I haven't done any of that type of clean up (everything is equals this or equals that or equals something else in the shell scripts)
• I assume GNU make is a requirement, though I don't know if that's stated for Solaris/BSD people... "ifeq ($(findstring" is used a couple of times