On Mon, 31 Dec 2007 12:56:16 +0100 Riemer Palstra riemer@palstra.com wrote:

On Mon, Dec 31, 2007 at 06:49:53AM -0500, Gerard wrote:

...

Might I suggest the following:

1. Contact the Dovecot port maintainer and inform him/her of your problem. They may not be aware of it, or it might be something else.

But isn't the problem that the OP is *not* using the port? Assuming that e.g. make will always be GNU make, or tar always being GNU tar, isn't the best bet on most platforms.

If he is not using the port and I fail to see any any good reason not to, then he is pretty much on his own. Putting a 'WARNING' notice up on 'wiki' probably would not be a bad idea. It might server to prevent other users from wasting this forum's time with these sort of postings. Expecting Timo to craft a special build niche build is absurd. He already is working far too hard keeping Dovecot ahead of the pack.

There is also the possibility that the OP needs some special function or handling of Dovecot that the port does not support. Informing the maintainer would be a good way of getting this sort of matter taken care of. The OP did not express any special needs, and my crystal ball is off for the holidays, so I am not able to fathom what they might or might not be.

By the way, I would have thought that it was obvious that make != gmake.

--

Gerard gerard@seibercom.net

Wethern's Law:

Assumption is the mother of all screw-ups.

hi mikkel,

Now the point of releasing the betas is that the users should test them. That may be somewhat difficult if the users are told to bugger off when they complain that the betas won't compile.

1st, thanks for the comments :-) certainly no skin off my nose -- that's why newsreaders have killfiles ;-)

but just to clarify, there was neither "complaint" on my part, nor even 'just' an 'it doesn't work' statement. rather, a simple point was raised and documented, and a solution/workaround was proposed.

now, hopefully, back to our "originally scheduled program".

cheers.

On Mon, 31 Dec 2007 16:46:26 +0100 "Frank Behrens" frank@pinky.sax.de wrote:

mikkel@euro123.dk mikkel@euro123.dk wrote on 31 Dec 2007 14:44:

...

There are many good reasons for not using the port.

Dovecot is constantly releasing new betas that should be tested and it might not be feasible to wait for them to go into ports.

Yes, that's true. But I had never problems to test new versions with a modified port. I copied the port files to a new directory and changed the Makefile, e.g.:

WRKDIR= ${.CURDIR}/work DISTDIR= ${.CURDIR} PACKAGES= /var/ports/packages

PORTNAME= dovecot DISTVERSION= 1.1.beta8 CATEGORIES= mail ipv6 MASTER_SITES= http://www.dovecot.org/releases/1.1/beta/

You can test snapshots with:

#DISTVERSION= 20071023 #MASTER_SITES= http://www.dovecot.org/nightly/ #WRKSRC= ${WRKDIR}/dovecot-20070522 #CONFIGURE_ARGS+= --with-storages=mbox,maildir

This works on FreeBSD-7 in a jail.

That looks like an excellent idea. I have tinderbox installed, which I occasionally use to test different builds. Either way, at least you can tell if something is going to build or not.

--

Gerard gerard@seibercom.net

To be considered successful, a woman must be much better at her job than a man would have to be. Fortunately, this isn't difficult.

On Mon, 31 Dec 2007 08:12:24 -0800 snowcrash schneecrash+dovecot@gmail.com wrote:

hi frank,

...

Yes, that's true. But I had never problems to test new versions with a modified port. I copied the port files to a new directory and changed the Makefile, e.g.: (snip) This works on FreeBSD-7 in a jail.

that's good to know. thanks!

(btw, what were your base JAIL buildworld make.conf specs for the dovecot-containing jail? if you can share, please email me offlist ...)

nonetheless, isn't it a bit ironic -- in this thread, anyway -- after being told "you're on your own" for using recommended/supported procedures, and barked @ for not using the standard port, that doing something completely unsupported, which works fortuitously, especially since there are some significant differences between v109 an v11bXXX, is deemed "like an excellent idea"? lol.

I fail to see a contradiction. Frank described one very useful method of testing a beta product derived from an existing FBSD port. I use tinderbox myself, but that is irrelevant. If the OP had asked that question on the FBSD forum, he might well have received a satisfactory response also.

The OP, whom obviously is not fully aware of the build intricacies on a FBSD system -- not that I claim to be either -- wanted Timo to invest his time in building a custom product for him to test. Now that I consider absurd.

--

Gerard gerard@seibercom.net

Heisenberg may have been here.

On 12/31/2007, Jeff Grossman (jeff@stikman.com) wrote:

I disagree with that statement. I think the OP was stating that the build instructions on the wiki never mention anything about possibly having to use gmake instead of make in a FreeBSD system. I think it was very usual information that should be added to the wiki for anybody who uses FreeBSD to build that might have the same setup as the OP.

What is all the hubbuh??

Its a WIKI, for criminys sake... EDIT IT if you think it needs changing...

--

Best regards,

Charles

On Mon, 31 Dec 2007 06:35:34 -0800 snowcrash schneecrash+dovecot@gmail.com wrote:

[snip]

...

By the way, I would have thought that it was obvious that make != gmake.

Considering that it is on OSX,

ls -al which make which gmake which gnumake -rwxr-xr-x 1 root wheel 316576 2007-09-23 16:05 /usr/bin/gnumake lrwxr-xr-x 1 root wheel 7 2007-10-02 13:58 /usr/bin/make -> gnumake lrwxrwxrwx 1 sc wheel 13 2007-03-22 18:12 /usr/local/bin/gmake -> /usr/bin/make

and,

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/make...

as well as on linux,

http://man.he.net/?topic=make§ion=all

no, it wasn't "obvious" at all.

The implication was that that this was being built on a FBSD machine, correct?

~ $ ls -al which make which gmake which gnumake -r-xr-xr-x 1 root wheel 292512 Dec 19 14:20 /usr/bin/make* -r-xr-xr-x 1 root wheel 156624 Jun 22 2007 /usr/local/bin/gmake*

The interesting thing is that I checked the ports Makefile, and there is no directive to use gmake, so I am somewhat perplexed by your inability to build it. It might be a system specific problem and not something that affects other users. If I actually get the ambition, I'll try it myself tomorrow when I have more time.

--

Gerard gerard@seibercom.net

Telling the truth to people who misunderstand you is generally promoting a falsehood, isn't it?

A. Hope

I can't reproduce this with FreeBSD 6.2. unicodemap.c is distributed in the tarball, so I don't know why it would give that error.

it's fully reproducible here.

note that i'm not using the tarball. rather, pulling the hg 11b13 tag clone. there, there's apparently *no* unicodemap.c included:

find . | grep unicodemap ./dovecot/.hg/store/data/src/lib/unicodemap.pl.i ./dovecot/src/lib/unicodemap.pl

on two separate FreeBSD 6.2 boxes (1) host w/ jail (2) standalone host

doing,

cd /usr/local/build
rm -rf   dovecot*
mkdir -p dovecot
cd       dovecot

hg clone -r1.1.beta13 http://hg.dovecot.org/dovecot
hg clone -r1.1.2      http://hg.dovecot.org/dovecot-sieve-1.1

cd /usr/local/build/dovecot/dovecot
unsetenv CFLAGS CPPFLAGS CXX CXXFLAGS LDFLAGS LDDLFLAGS LIBS LD_PREBIND \
		 EXTRA_LDFLAGS EXTRA_LIBS ACLOCAL AUTOHEADER AUTOMAKE AUTOCONF

setenv LDFLAGS "-L/usr/local/lib/db46 -L/usr/local/lib/mysql

-L/usr/local/lib -lpthread" setenv CPPFLAGS "-I/usr/local/include/db46 -I/usr/local/include/mysql -I/usr/local/include" setenv SQL_LIBS "-lsqlite3"

clear

./configure \
--prefix=/usr/local \
--sysconfdir=/usr/local/etc/dovecot \
--with-moduledir=/usr/local/dovecot-plugins \
--with-libiconv-prefix=/usr/local \
--with-ssl=openssl --with-ssldir=/var/ssh/MAIL_CERTS \
--disable-static --enable-shared \
--config-cache \
--disable-debug --enable-maintainer-mode \
--enable-ipv6 \
--with-db \
--with-mysql \
--with-sqlite \
--with-ioloop=best \
--with-sql-drivers=mysql,sqlite \
--with-deliver \
--with-pop3d \
--with-storages=maildir,mbox,dbox,cydir,raw

then

make

yields on BOTH boxes,

make  all-recursive
Making all in src
Making all in lib
make: don't know how to make unicodemap.c. Stop
*** Error code 1

Stop in /s/usr-local/build/dovecot/dovecot/src.
*** Error code 1

Stop in /s/usr-local/build/dovecot/dovecot.
*** Error code 1

Stop in /s/usr-local/build/dovecot/dovecot.

whereas, again on both boxes,

gmake

reports,

gmake  all-recursive
gmake[1]: Entering directory `/usr/local/build/dovecot/dovecot'
Making all in src
gmake[2]: Entering directory `/usr/local/build/dovecot/dovecot/src'
Making all in lib
gmake[3]: Entering directory `/usr/local/build/dovecot/dovecot/src/lib'
test -f UnicodeData.txt || wget

http://www.unicode.org/Public/UNIDATA/UnicodeData.txt UnicodeData.txt 100% of 1014 kB 236 kBps perl ./unicodemap.pl < UnicodeData.txt > unicodemap.c gmake all-am gmake[4]: Entering directory `/usr/local/build/dovecot/dovecot/src/lib' ...

and completes without error.

noting,

ls -al `which make` `which gmake`
	-r-xr-xr-x  1 root  wheel  350904 Dec 21 13:50 /usr/bin/make*
	-r-xr-xr-x  1 root  wheel  199808 Dec 21 16:51 /usr/local/bin/gmake*

hi timo,

Oh, that's different then. The Makefiles generated by autotools pretty much require GNU make.

then it's known/understood. great.

Only after I make a release with "make dist" the generated Makefiles work with all makes.

ah. good to know.

I'll add a note of this to the wiki page.

nice & simple.

thank you! & happy new year!