similar to: v2.1.rc3 released

Hi, Just a quick mail to mention that I cannot generate a new configure script using autoconf or autoreconf. I had edited the configure.ac and thought ... "oh, that's my fault", but then I tried it on R-patched and R-3.4.1 without touching configure.ac and had the same problems. The "building R packages" documentation seems to suggest that "autoconf" should take

You copied your Makefile.am?there. Stephan made you a working version, can you try that? (sorry for dup) Aki -------- Original message --------From: Joan Moreau <jom at grosjo.net> Date: 13/01/2019 21:39 (GMT+02:00) To: Stephan Bosch <stephan at rename-it.nl> Cc: Aki Tuomi <aki.tuomi at open-xchange.com> Subject: Re: [FTS Xapian] Beta release I used the skeleton from Aki :

Series of cleanups to autotools build config files to utilize the available xorg-server macros, defaults and more closely match other modern Xorg drivers. Notable improvements: - gitignore fully covers potential build artifacts - Simplify logic given stated minimum required version of xorg-server 1.8 - Remove use of deprecated, outdated or no longer required macros - Utilize xorg macros where

Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot: > > I tried to combined it, the "autoreconf" errors are solved > > Now, when I type "make install", the lib is not pushed into dovecot > folder, but somewhere in /usr/local/... > > How to adjust this to have it arriving in the proper folder ? > Depends on your system. It mostly a matter of setting

Charles, When running autoreconf in the trunk, I get a couple of additional files since I upgraded to openSUSE 11.1. Most likely, this is due to a newer version of the auto(whatever) tools that are used. Or I never looked at this more closely before. libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file

In your README.md, perhaps "This project intends to provide a straightforward and simple *procedure *to configure FTS plugin for Dovecot, leveraging the efforts by the Xapian.org team." is better?? Also in the part after cloning from git: ./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This /path/to/dovecot is not obvious. Is it the dovecot binary or what??] On Mon, 14 Jan

Hello, I can compile metadata plugin using debian squeeze + wheezy. But build on suse enterprise server 9,10 and 11 failed. The metadata plugin require autoconf-2.65 which i too new. On the other side I can build the dovecot-2.2.4 and pigeonhole-0.4.0 plugin without problems: dovecot require autoconf-2.59 and pigeonhole does not require any specific autoconf version. I asked the authors of the

When building the HG checkout, I'm getting: ... libtoolize: Consider adding AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding -I m4' to ACLOCAL_AMFLAGS in Makefile.am.a Making distclean in doc My build command looks like this: hg pull hg update ./autogen.sh make -j distclean

With automake, we collectively need to check to see if 'make distcheck' still works after adding or removing files. Basically, nothing will make its way into the NUT distribution tarball unless it is somehow mentioned in one of the Makefile.am files. See the packaging/RedHat directory for an example. Niels, thank you for spotting the extra nut.spec file in SVN; however, it needs to be

Testing a compile on FreeBSD. gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src' /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I.. -I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o fts-backend-xapian.lo fts-backend-xapian.cpp libtool:

This patch series modernizes various aspects of the autotools based build system. There is a lot more that could and should be done, but I tried to stay conservative for now and just resolve some of the most obvious issues. Max Horn (5): configure: replace XIPH_C_FIND_ENDIAN by AC_C_BIGENDIAN autogen.sh: replace this by a simple call to autoreconf configure: always print

Hi Reid, > On Tue, 2006-04-11 at 21:03 -0500, Tanya Lattner wrote: > > It it necessary for dist-check to run make dist? > > Y'know, when I typed that, I knew you were going to ask that. It > doesn't make sense to me either. Seems a bit overkillish to me. I think a `make distcheck' should do a `make dist' because it checks that a tarball can reproduce itself.

There were a few "infelicities" that kept the "make distcheck" test from passing. These three patches combine to fix all of them, punting on only one by disabling the install-data-hook rule. >From 7504acedcb71bd80d99abe412e6669b267cade38 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Fri, 21 Aug 2009 13:37:18 +0200 Subject: [PATCH 1/3]

>From my log today: May 22 07:38:48 postamt dovecot: imap-login: Disconnected (no auth attempts): rip=141.42.245.68, lip=141.42.4.250 May 22 07:39:29 postamt dovecot: imap-login: Disconnected (no auth attempts): rip=141.42.245.68, lip=141.42.4.250 May 22 07:39:50 postamt dovecot: imap-login: Disconnected (no auth attempts): rip=141.42.245.68, lip=141.42.4.250 May 22 07:39:50 postamt dovecot:

Hi, I installed and tested your version, but the indexer process crashes reproducible with the following command after about 2000 messages were indexed: doveadm index -u paul at iwascoding.com -q \* Jan 14 09:26:15 mail dovecot: indexer-worker(paul at iwascoding.com)<16777><IKpfOqBHPFyJQQAADYqDFA>: Debug: Mailbox sent: UID 2038: Opened mail because: fts indexing Jan 14 09:26:15 mail

Op 14-1-2019 om 13:40 schreef Aki Tuomi: > > Just to remind that now that there is a github repo for fts-xapian, > you could maybe open these issues there instead? > Although README.md currently says: "Please feel free to send your questions, together with the dovecot log file, to jom at grosjo.net <mailto:jom at grosjo.net> or to the dovecot ML dovecot at dovecot.org

I'm trying to build upstream source on RHEL 7.5 and get this error: # autoreconf -i libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying

After applying two patches: 1. http://lists.xiph.org/pipermail/flac-dev/2008-August/002570.html 2. http://wolf-u.li/4567/fehler-waehrend-der-kompilierung-von-flac-memcmp-was-not-declared-in-this-scope/ I was able to build flac without error, and noticed that shared library is silently skipped. After searching the logs I found this line as suspect: "libtool: link: warning: undefined

Dear NUT developers, I have converted NUT's build system to Automake/Libtool. Right now, the new build system is contained in the "automake" branch, at: ssh://svn.debian.org/svn/nut/branches/automake I plan to merge this into the main branch after a period of testing, if there are no objections. Here are some highlights: * automatic dependency tracking: no more need to do this

I am working on getting the CentOS 3/Red Hat Enterprise 3 buildbot going, but I have hit a problem with the latest SVN build. Running './configure' works without any errors, (but I do note that it takes a long time on the drivers directory Makefile). Here is a copy of the configuration summary: Configuration summary: enable SSL development code: yes enable IPv6 support: yes build CGI