Ubuntu 8.04 64-bit build (Hardy A4)

[dijichi2]

Not just gnu make, gnu patch, gnu tar, gnu sed, gnu grep/egrep etc all required. For the solaris port, I've created a get_plat_env.sh alongside get_plat_tag.sh that sets a whole bunch of variables according to the platform (make/tar/patch/sed/sudoers/etc) and then altered the codebase throughout to refer to these variables - this way it is picked up both at buildtime and at runtime.

In this script I also set the cpu architecture and bitsize so we can then test for these later on and do things dependent on that. Currently the method of doing this is a bit clunky.

[ironstorm]

[QUOTE=ironstorm;79389]

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

Looks like this is caused by hardcoded references to /opt/zimbra/java, easiest solution is to replace the /opt/zimbra/java with the native JRE... right now I do this by hacking the install.sh to get things going...

--- install.sh.org      2008-02-22 12:50:59.000000000 -0500
+++ install.sh  2008-02-22 12:50:46.000000000 -0500
@@ -212,6 +212,9 @@
 echo "${D}: INSTALL SESSION START" >> /opt/zimbra/.install_history
 for i in $INSTALL_PACKAGES; do
        installPackage "$i"
+        if [ ! -z "`echo $i|grep core`" ]; then
+          sudo rm /opt/zimbra/java && sudo ln -s /usr/lib/jvm/java-6-sun /opt/zimbra/java
+        fi
 done
 D=`date +%s`
 echo "${D}: INSTALL SESSION COMPLETE" >> /opt/zimbra/.install_history

[dijichi2]

Looks like this is caused by hardcoded references to /opt/zimbra/java, easiest solution is to replace the /opt/zimbra/java with the native JRE... right now I do this by hacking the install.sh to get things going...

eek. don't do this, or your previous bodge of gettting 1.6.0_03 out of debian repositories. Download the pukka 1.6.0_04 tarballs from Sun, unpack and retar as you have done and place in ThirdPartyBuilds/<platform>/java directory. The corebuild target then takes what it needs from this tar and places it into the main package tree. The installer (postinstall or setup, can't remember which) then symlinks /opt/zimbra/jdk1.6.... /opt/zimbra/java.

[ironstorm]

Originally Posted by dijichi2

eek. don't do this, or your previous bodge of gettting 1.6.0_03 out of debian repositories.

I have no intention of leaving this hack in install.sh... In all honesty it takes a really long time to build everything, so I am hacking the crap out of the packages that have already been built which I'm deploying on my test deploy server.

Once I have them running on the deploy server, I'll roll the necessary changes back into the build environment and do a proper patch.

At this point, for the java thing, my approach will most likely to add a deb dependency to zimbra-core for sun-java6-jre on Ubuntu and symlink /opt/zimbra/java to the Ubuntu JRE JAVA_HOME as part of the deb post-install script.

After the changes w/ Java work in a fresh build, I'm going to look at debianizing the Apache configuration and possibly the Mysql config, so I can use Ubuntu versions of those packages... (I already have the Ubuntu versions of these packages installed on my personal "prod" server and I'd like to avoid wasting the extra memory and moving ports around)

-G

[dijichi2]

At this point, for the java thing, my approach will most likely to add a deb dependency to zimbra-core for sun-java6-jre on Ubuntu and symlink /opt/zimbra/java to the Ubuntu JRE JAVA_HOME as part of the deb post-install script.

After the changes w/ Java work in a fresh build, I'm going to look at debianizing the Apache configuration and possibly the Mysql config, so I can use Ubuntu versions of those packages... (I already have the Ubuntu versions of these packages installed on my personal "prod" server and I'd like to avoid wasting the extra memory and moving ports around)

I don't work for Zimbra so I'm only guessing, but if you go down this route I would have thought your patches in terms of an ubuntu hardy port have between tiny and zero chance of going anywhere. Why don't you seperate the two tasks of a) ubuntu8.04 port, and b) using existing system components?

a) is pretty straightforward and can be done quickly.

b) is a whole other can of worms. it's certainly something that has been asked umpteen times of zimbra and is definitely worth looking at but will be fraught with difficulty.

[dijichi2]

I have no intention of leaving this hack in install.sh... In all honesty it takes a really long time to build everything, so I am hacking the crap out of the packages that have already been built which I'm deploying on my test deploy server.

btw, once you've got everything built the first time, you can fix bits here and there in the codebase and rebuild very quickly. you can rebuild seperate packages (if you're using the standard Makefile in ZimbraBuild) with:

make core
make mta
etc

and to rebuild the main tarball:
make zcs_stage

[ironstorm]

Originally Posted by dijichi2

I don't work for Zimbra so I'm only guessing, but if you go down this route I would have thought your patches in terms of an ubuntu hardy port have between tiny and zero chance of going anywhere. Why don't you seperate the two tasks of a) ubuntu8.04 port, and b) using existing system components?

I don't work for Zimbra either, my interest in this is selfish, I'm focused on getting something that's useful for my environment. I'm not going to spend time sorting/polishing patches so they applied to cleanly close one bug or the other. I'm hoping Quanah (or another Zimbra eng) will want to take the patch bits, review them, clean them up and apply them in a logical fashion to the repo.

Reason for doing Apache and MySQL first is they should be pretty easy ("low hanging fruit"). With Apache, should only need to take the Zimbra httpd.conf, chunk it into pieces and drop it into the /etc/apache/conf directory, and perhaps symlink some modules to be enabled. With Mysql, it'll be moving the DB to /var and adding some permissions. I'm less familiar with how other components are usually debianized.

-G

[ironstorm]

Originally Posted by dijichi2

make core
make mta

and to rebuild the main tarball:
make zcs_stage

Thanks! That's going to be quite helpful!