UPDATE: Dovecot 1.1.1
Here is an update to Dovecot 1.1.1. This is not the
version that will be commited as I'm waiting for
1.1.2, but I would like to have some initial testing
of the update as is and to also check things like
Kerberos and Sieve which I do not use.
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot/Makefile,v
retrieving revision 1.99
diff -u -p -r1.99 Makefile
--- Makefile22 Jun 2008 18:36:46 - 1.99
+++ Makefile30 Jun 2008 04:40:00 -
@@ -5,9 +5,9 @@ SHARED_ONLY=Yes
COMMENT-server= compact IMAP/POP3 server
COMMENT-sieve= sieve mail filtering for Dovecot
-V_MAJOR= 1.0
-V_DOVECOT= 1.0.15
-V_SIEVE= 1.0.3
+V_MAJOR= 1.1
+V_DOVECOT= 1.1.1
+V_SIEVE= 1.1.5
PKGNAME= dovecot-${V_DOVECOT}
PKGNAME-server=dovecot-${V_DOVECOT}
@@ -31,7 +31,7 @@ PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WANTLIB-server=c crypto gssapi krb5 ssl z
+WANTLIB-server=c crypto gssapi krb5 rpcsvc ssl z
WANTLIB-sieve=
MODULES= converters/libiconv
Index: distinfo
===
RCS file: /cvs/ports/mail/dovecot/distinfo,v
retrieving revision 1.59
diff -u -p -r1.59 distinfo
--- distinfo22 Jun 2008 18:36:46 - 1.59
+++ distinfo29 Jun 2008 08:33:52 -
@@ -1,10 +1,10 @@
-MD5 (dovecot-1.0.15.tar.gz) = qjnBHBjfa5W2TU8E15PXeg==
-MD5 (dovecot-sieve-1.0.3.tar.gz) = y+Q2GJn/tNnLYhUctEQntg==
-RMD160 (dovecot-1.0.15.tar.gz) = 2ILj2+1gy8us3LYCPQwSIToNNaw=
-RMD160 (dovecot-sieve-1.0.3.tar.gz) = tXWhGB+yOJpH20zdKBWkei/jC5E=
-SHA1 (dovecot-1.0.15.tar.gz) = Th9A43Rh+EhFnfnd6AkJf+9Gw3Y=
-SHA1 (dovecot-sieve-1.0.3.tar.gz) = SPZ8M8CGicUKJUvG+u7LpAfRIpQ=
-SHA256 (dovecot-1.0.15.tar.gz) = K02HINX1ho1X3ylDUO4PWo0nI+mTfase6iCER4rOlZc=
-SHA256 (dovecot-sieve-1.0.3.tar.gz) =
P54jq8ZOeucDQxRLmiD42lCqEC49m4V3Td2KwNFID+E=
-SIZE (dovecot-1.0.15.tar.gz) = 1783347
-SIZE (dovecot-sieve-1.0.3.tar.gz) = 455806
+MD5 (dovecot-1.1.1.tar.gz) = I5ByNl5Pw1uKcWL4QcsHyQ==
+MD5 (dovecot-sieve-1.1.5.tar.gz) = tDYt7+P8GIZduM+OHJQLEw==
+RMD160 (dovecot-1.1.1.tar.gz) = vlIrCA8iHb9lXZr6Hz+xp4bUw7I=
+RMD160 (dovecot-sieve-1.1.5.tar.gz) = glqOwH1JUn2FUctfP4a2OP3br70=
+SHA1 (dovecot-1.1.1.tar.gz) = A5mT2HaSN919HAw+8ndzT3ATxms=
+SHA1 (dovecot-sieve-1.1.5.tar.gz) = ZyrfCi8WJ9lvl/xj/srwJN2fekI=
+SHA256 (dovecot-1.1.1.tar.gz) = k2mC0CWQNbOAMVWZZo03J2z6XdJviJEm9QzMA/7Pn14=
+SHA256 (dovecot-sieve-1.1.5.tar.gz) =
7B6pQxHV+2y13X5FFyh4Svs5UhpqWA9kC00hFVBaXd8=
+SIZE (dovecot-1.1.1.tar.gz) = 2273779
+SIZE (dovecot-sieve-1.1.5.tar.gz) = 468913
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/mail/dovecot/patches/patch-Makefile_in,v
retrieving revision 1.18
diff -u -p -r1.18 patch-Makefile_in
--- patches/patch-Makefile_in 22 Jun 2008 18:36:46 - 1.18
+++ patches/patch-Makefile_in 30 Jun 2008 04:20:36 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-Makefile_in,v 1.18 2008/06/22 18:36:46 brad Exp $
Makefile.in.orig Sat Jun 21 09:12:39 2008
-+++ Makefile.inSat Jun 21 16:19:23 2008
-@@ -648,7 +648,7 @@ install-data: install-data-recursive
+--- Makefile.in.orig Sun Jun 22 07:02:51 2008
Makefile.inSun Jun 29 04:34:10 2008
+@@ -661,7 +661,7 @@ install-data: install-data-recursive
uninstall: uninstall-recursive
install-am: all-am
Index: patches/patch-configure_in
===
RCS file: /cvs/ports/mail/dovecot/patches/patch-configure_in,v
retrieving revision 1.11
diff -u -p -r1.11 patch-configure_in
--- patches/patch-configure_in 28 Apr 2008 09:51:10 - 1.11
+++ patches/patch-configure_in 30 Jun 2008 04:20:32 -
@@ -1,31 +1,50 @@
$OpenBSD: patch-configure_in,v 1.11 2008/04/28 09:51:10 bernd Exp $
configure.in.orig Sun Mar 9 11:45:25 2008
-+++ configure.in Fri Apr 25 12:32:06 2008
-@@ -12,6 +12,7 @@ AC_PROG_CPP
+--- configure.in.orig Sun Jun 22 07:02:27 2008
configure.in Mon Jun 30 00:20:25 2008
+@@ -13,6 +13,7 @@ AC_PROG_CXX # lucene plugin needs this
AC_HEADER_STDC
AC_C_INLINE
AC_PROG_LIBTOOL
+LIBS=${LIBS} -liconv
AM_ICONV
- AC_CHECK_HEADERS(strings.h stdint.h unistd.h dirent.h \
-@@ -1471,33 +1472,14 @@ fi
+ AC_CHECK_HEADERS(strings.h stdint.h unistd.h dirent.h malloc.h inttypes.h \
+@@ -1655,74 +1656,14 @@ fi
have_gssapi=no
- if test $want_gssapi = yes; then
+ if test $want_gssapi != no; then
- AC_CHECK_PROG(KRB5CONFIG, krb5-config, YES, NO)
- if test $KRB5CONFIG = YES; then
- # we have a kludgy check here to check that we have
- # version = v1.3. Although this doesn't work right with
- # non-MIT kerberos versioning..
-- if `krb5-config --version|grep -v '1\.2' /dev/null`; then
-- AUTH_LIBS=$AUTH_LIBS
Re: webkit-gtk2 and midori port
On Sat, Jun 28, 2008 at 08:38:52PM -0400, James Turner wrote: Attached are two new ports, one for webkit-gtk2 and the other midori. Both were built and tested on amd64. Webkit doesn't have a formal release but the attached port is for the latest nightly dated today. I've been using midori as my main browser for a couple weeks now. Since it is still in active/heavy development it does tend to segfault every once and awhile. DESCR: WebKit is an open source web browser engine. Midori is a lightweight web browser that uses WebKit for it's rendering engine. Thanks for this submission, i'll take care of it, After a first look it needs some fixes/tweaks, will repost updated ports soon. Landry
DJBware ports
Hi guys, I'm willing to port all DJB's public domain software, including djbdns, qmail, daemontools, etc. If made, It can be easily accepted on ports or, for historical reasons, i will not be imported? Regards, -- Eduardo Alvarenga
Re: Ports with possible 64-bit problems
On Mon, Jun 30, 2008 at 8:31 AM, Christian Weisgerber [EMAIL PROTECTED] wrote: A grep over a recent set of amd64 bulk build logs shows these ports generating warnings that indicate possible 64-bit problems: I'm looking at the Erlang port's build logs, and I see some warning: cast from pointer to integer of different size messages. Are there any other messages to look out for?
Re: DJBware ports
Eduardo Alvarenga wrote: Hi guys, I'm willing to port all DJB's public domain software, including djbdns, qmail, daemontools, etc. If made, It can be easily accepted on ports or, for historical reasons, i will not be imported? I'm not a porter, I don't have final say in this at all, but: 1) DJBDNS is my DNS tool of choice. 2) I think BIND sucked before I learned BIND. 3) I think BIND sucks even more since I have learned it. 4) BIND sucks less since they learned a little from DJB 5) I highly respect DJB's I'm doing it as I know is right, I don't care what you think attitude. ;) So, I'm a fan of DJBDNS, but, I have to ask: Why?!? Here are some of the issues that I know you will run into: Do you normalize his directory layout, or do you maintain his suggested layout (which has its merits, but is VERY non-hier(7)). IF you normalize his layouts, you annoy the current DJBDNS users and confuse the new ones. How do you propose to announce this to the port user and orient them appropriately? IF you don't normalize his directory layouts...I doubt they will be imported when you slop three new directories in /. Do you maintain the DJBDNS dependency on daemontools, even though djbdns is one (er..two!) app(s) that just doesn't need to be restarted when it fails (because it doesn't)? IF you separate them, again, you will need to develop docs. IF you leave them together...what value do you add to the port? This app was developed ON OpenBSD...it installs on OpenBSD as well or better than any other OS. On the probably the slowest machine you would be likely to want to run a DNS server on (a P100 with a really slow disk attached to a really slow IDE controler (wdc(4)!), it took ten minutes to build, install and test. An experienced user might spend close to that trying to figure out where things went, and a new user won't find their life simplified. LONG, LONG ago, probably around the 2.7 days, I used a DJBDNS port on OpenBSD, and seriously regretted it. It was SO much easier to simply install following DJB's instructions than it was to find where things were put by the well-meaning porter. I don't see how a port of the stock DJBDNS benefits anyone. People who know and love DJBDNS won't use it, new users who should learn it will be confused by it...so what is the point? That being said, I do believe there are some people who are working on taking the PD'ed DJBDNS package and bringing it up-to-date. Assuming they normalize the directory layout and document it appropriately and don't screw it up beyond all recognition (those are three big IFs there) I'd have no objection to that being made a port, and in fact, I'd welcome it, but not a port just so we can say, look! DJBDNS in ports!. I think similar arguments can be made against a qmail port. Some of his utility programs (ucspi-tcp) would be really handy ported, and I can not think of any issues involved there. So there's a partial yes. :) Nick.
Will you update amavisd-new to 2.6.1 in -current?
Hi, Amavisd-new released 2.6.1 several days ago, support DKIM. Will you update it in -current? -- Best Regards. Zhang Huangbin - Mail Server Solution for Red Hat(R) Enterprise Linux CentOS 5.x: http://iRedMail.googlecode.com/
grip
Grip is one of the ports that's listed as having 64-bit issues. The current stable version is 3.2.0, but the development version (3.3.1) was released over three years ago. Should I just fix it, or update it to 3.3.1 and fix it?
Sarg problem on 4. 3 AMD64
Hi everyone, I got this error on Sarg running on 4.3 amd64: SARG: sarg version: 2.2.3.1 Jan-02-2007 SARG: Maximum file descriptor: cur=128 max=1024, changed to cur=2 max=2 SARG: Reading access log file: /var/squid/logs/access.log SARG: (util) tbuf=30Jun2008, reading: 0.00% SARG: (util) period=30Jun2008- SARG: Records in file: 1163, reading: 100.00% SARG:Records read: 1163, written: 1163, excluded: 0 SARG: Squid log format SARG: (util) data=30/06/2008 SARG: (util) tbuf=30Jun2008 SARG: (util) period=30Jun2008-30Jun2008 SARG: Period: 30Jun2008-30Jun2008 SARG: pre-sorting files SARG: (util) dirname=/var/www/htdocs/sarg/30Jun2008-30Jun2008 SARG: (util) wdir=/var/www/htdocs/sarg/30Jun2008-30Jun2008 SARG: Making period file SARG: Making file: /tmp/sarg/127.0.0.1 SARG: Sorting file: /tmp/sarg/127.0.0.1 SARG: Reading DansGuardian log file: /var/log/dansguardian/access.log SARG: Sorting file: /tmp/sarg/dansguardian.log Segmentation fault (core dumped) I can run fine on i386. Problem is only on amd64. thanks!
