Displaying 20 results from an estimated 2000 matches similar to: "Missing File Makefile.in"
2006 Aug 23
0
compiz after today update
today i upgraded compiz and i get this error.
compiz: GLX_EXT_texture_from_pixmap is missing
compiz: Failed to manage screen: 0
compiz: No managable screens found on display :1.0
my compile command is
> PKG_CONFIG_PATH=/opt/Xgl/lib/pkgconfig ACLOCAL='aclocal -I
> /opt/Xgl/share/aclocal' ./autogen.sh --prefix=/opt/Xgl
> --with-gl-libs="/opt/Xgl/_tmp_/mesa/lib/libGL.a
2010 May 18
1
problem compiling pigeonhole + my fix
hello,
yesterday I tried to package dovecot-2.0beta5 + pigeonhole from Mercurial repository.
I put pigeonhole as a subdir in the dovecot sourcetree.
Following http://hg.rename-it.nl/dovecot-2.0-pigeonhole/raw-file/tip/INSTALL
I called ./autogen.sh; ./configure --with-dovecot=..; make
In the buildprocess I saw this output ( from autogen.sh ):
Putting files in AC_CONFIG_AUX_DIR, `..'.
2017 Aug 01
0
configure.ac
If you check developer.r-project.org, you'll find links to the scripts that we use for building releases and pre-releases of R. These are usually run on a Mac, but shouldn't require much change for Linux. In particular, notice this lead-in in the prerelease script:
rm -rf BUILD-dist
mkdir BUILD-dist
cd R
aclocal -I m4
autoconf
cd ../BUILD-dist
....etc....
-pd
> On 1 Aug 2017, at
2006 Sep 29
1
undeclared identifier 'space' in function MetaButtonSpace
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DORBIT2=1 -pthread
-I/opt/Xgl/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/gconf/2 -I/usr/include/orbit-2.0
-I/usr/include/libwnck-1.0 -I/opt/Xgl/include
-I/usr/include/metacity-1 -I/usr/include/gtk-2.0
2019 Jan 13
0
[FTS Xapian] Beta release
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 ?
On 2019-01-13 21:01, Tuomi, Aki wrote:
> You copied your Makefile.am there. Stephan made you a working version, can you try that?
>
>
2019 Jan 14
0
[FTS Xapian] Beta release
Thank you Stephan.
The version here shall be up and running :
https://github.com/grosjo/fts-xapian
On 2019-01-14 00:07, Stephan Bosch wrote:
> 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
2019 Jan 14
0
[FTS Xapian] Beta release
THank you Odhiambo. I updated accordingly
On 2019-01-14 08:07, Odhiambo Washington wrote:
> 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
2019 Jan 14
0
[FTS Xapian] Beta release
Can you send the log part that includes the "init" of the plugins
(something similar as below) ?
WHich version of Xapian are you on ?
Jan 14 09:10:04 gjserver dovecot[31082]:
indexer-worker(admin at grosjo.net)<14725><apZfHexRPFy9QAAA0thIag:UL+TNOxRPFyFOQAA0thIag>:
FTS Xapian: Partial=2, Full=20
DB_PATH=/data/mail/grosjo.net/admin/xapian-indexes
Jan 14 09:10:04 gjserver
2017 Aug 01
3
configure.ac
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
2019 Jan 14
0
[FTS Xapian] Beta release
Just to remind that now that there is a github repo for fts-xapian, you
could maybe open these issues there instead?
Aki
On 14.1.2019 14.29, Odhiambo Washington wrote:
> 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..?
2019 Jan 13
3
[FTS Xapian] Beta release
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 :
2019 Jan 14
2
[FTS Xapian] Beta release
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
2019 Jan 13
3
[FTS Xapian] Beta release
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
2019 Jan 14
2
[FTS Xapian] Beta release
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
2019 Jan 14
3
[FTS Xapian] Beta release
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:
2016 Oct 18
6
CyberPower SX650G no driver.
Got the:
git clone git://github.com/networkupstools/nut.git
To work. Had to all so do this:
apt-get install autoconf
apt-get install libtool
Did put driver = usbhid-ups in the /etc/nut/ups.conf file like you said.
Here is what I got for it all:
root at odroid-u2:~/nut# ./autogen.sh
Calling autoreconf...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying
2019 Jan 14
3
[FTS Xapian] Beta release
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
2018 Jul 28
2
Error building nbdkit on RHEL 7.5 - possibly undefined macro: PKG_CHECK_VAR
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
2018 Jul 28
0
Re: Error building nbdkit on RHEL 7.5 - possibly undefined macro: PKG_CHECK_VAR
On Sat, Jul 28, 2018 at 09:26:06PM +0300, Nir Soffer wrote:
> 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:
2009 Aug 12
1
[PATCH libguestfs] build: enable automake's color-tests option
Only marginally useful, but some like it...
This makes tests print "PASS" in green, and "FAIL" in red, when possible:
The autogen.sh snippet ensures that this automake-1.11 feature
is disabled when building-from-clone on a system with too-old automake.
This *does* modify a source file (and a version-controlled one at that),
but only when building from source on e.g. RHEL*