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

02-20-2008, 01:08 AM

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.

02-20-2008, 07:14 AM

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...

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.

02-20-2008, 10:33 AM

ironstorm

Quote:

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.

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

02-21-2008, 02:41 PM

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

02-21-2008, 08:29 PM

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.

02-21-2008, 08:37 PM

ironstorm

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

I've put in a fix there already.

02-21-2008, 09:37 PM

ironstorm

Code:

/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

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:

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