Milter-greylist

Hello,

I try to build it with:
rpmbuild --define "build_postfix 1" --define "build_user smmsp" -tb milter-greylist-4.2.7.tgz
but it fails:

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -DUSE_POSTFIX -D_BSD_SOURCE -I. -I.    -c -o macro.o macro.c
bison -y -p`echo conf_yacc.c|sed 's/^\([^_]\{1,\}_\).*$/\1/'` conf_yacc.y
flex -oconf_lex.c conf_lex.l
bison -y -p`echo dump_yacc.c|sed 's/^\([^_]\{1,\}_\).*$/\1/'` dump_yacc.y
mv y.tab.c dump_yacc.c
flex -odump_lex.c dump_lex.l
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -DUSE_POSTFIX -D_BSD_SOURCE -I. -I.    -c -o conf.o conf.c
mv y.tab.c conf_yacc.c
mv: nepavyksta patikrinti \u201ey.tab.c\u201c: No such file or directory

I think it uses make -j2, and 2nd bison overwrites the 1st bison's output (y.tab.c).
It builds if I remove %{?_smp_mflags} from the spec file:

--- milter-greylist.spec.orig	2012-03-28 03:30:25.000000000 +0300
+++ milter-greylist.spec	2012-03-28 03:41:28.000000000 +0300
@@ -109,7 +109,7 @@
 	--with-libGeoIP \
 %endif
 
-%{__make} %{?_smp_mflags}
+%{__make}
 
 
 %install


Does anyone know how to deal with such situations "oficially"? Or is it OK to just remove %{?_smp_mflags}?

Regards,
Nerijus

Nerijus Baliunas <nerijus@...> wrote:

> Does anyone know how to deal with such situations "oficially"? Or is it OK
> to just remove %{?_smp_mflags}?

I have no problem removing them since I don't use the .spec file :-) 
Anyone against that change?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On 03/27/2012 07:48 PM, Nerijus Baliunas wrote:
> Hello,
>
> I try to build it with:
> rpmbuild --define "build_postfix 1" --define "build_user smmsp" -tb
> milter-greylist-4.2.7.tgz
> but it fails:
>
> gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables -Wall -DUSE_POSTFIX -D_BSD_SOURCE -I. -I.
> -c -o macro.o macro.c
> bison -y -p`echo conf_yacc.c|sed 's/^\([^_]\{1,\}_\).*$/\1/'` conf_yacc.y
> flex -oconf_lex.c conf_lex.l
> bison -y -p`echo dump_yacc.c|sed 's/^\([^_]\{1,\}_\).*$/\1/'` dump_yacc.y
> mv y.tab.c dump_yacc.c
> flex -odump_lex.c dump_lex.l
> gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables -Wall -DUSE_POSTFIX -D_BSD_SOURCE -I. -I.
> -c -o conf.o conf.c
> mv y.tab.c conf_yacc.c
> mv: nepavyksta patikrinti \ufffdy.tab.c\ufffd: No such file or directory
>
> I think it uses make -j2, and 2nd bison overwrites the 1st bison's
> output (y.tab.c).
> It builds if I remove %{?_smp_mflags} from the spec file:
>
> --- milter-greylist.spec.orig 2012-03-28 03:30:25.000000000 +0300
> +++ milter-greylist.spec 2012-03-28 03:41:28.000000000 +0300
> @@ -109,7 +109,7 @@
> --with-libGeoIP \
> %endif
>
> -%{__make} %{?_smp_mflags}
> +%{__make}
>
>
> %install
>
> Does anyone know how to deal with such situations "oficially"? Or is it
> OK to just remove %{?_smp_mflags}?
>
> Regards,
> Nerijus

I've just run into something similar. I'm trying to build an RPM for 
RHEL6 x86_64. I ran:

rpmbuild --define "build_sendmail 1" -tb \
  ../SOURCES/milter-greylist-4.3.9.tgz

I also get:

flex -oconf_lex.c conf_lex.l
bison -y -p`echo dump_yacc.c|sed 's/^\([^_]\{1,\}_\).*$/\1/'` dump_yacc.y
milter-greylist.c:2493: warning: 'last' may be used uninitialized in 
this function
mv y.tab.c dump_yacc.c
flex -odump_lex.c dump_lex.l
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall 
-DHAVE_DATA_CALLBACK -DCONFFILE=\"/etc/mail/greylist.conf\" 
-DDUMPFILE=\"/var/milter-greylist/greylist.db\" -D_BSD_SOURCE -I. -I. 
  -c -o conf.o conf.c
mv y.tab.c conf_yacc.c
mv: cannot stat `y.tab.c': No such file or directory
make: *** [conf_yacc.c] Error 1
make: *** Waiting for unfinished jobs....
error: Bad exit status from /var/tmp/rpm-tmp.nRIRgr (%build)


RPM build errors:
     Bad exit status from /var/tmp/rpm-tmp.nRIRgr (%build)

I took your advice and:

[tcameron@spamcatcher SPECS]$ diff -u milter-greylist.spec 
milter-greylist.spec.orig
--- milter-greylist.spec	2012-05-05 22:59:08.896982213 -0500
+++ milter-greylist.spec.orig	2012-05-05 22:58:59.554233864 -0500
@@ -109,7 +109,7 @@
  	--with-libGeoIP \
  %endif

-%{__make}
+%{__make} %{?_smp_mflags}

But now when I try to build it, I get:

test -f 
/home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/etc/mail/greylist.conf 
-o 	\
		-f 
/home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/etc/mail/greylist.except 
|| 	\
	     /usr/bin/install -c -m 644 ./greylist.conf 
/home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/etc/mail/greylist.conf
/usr/bin/install -c -d -m 755 -o root 
/home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64`dirname 
/var/milter-greylist/greylist.db`
/usr/bin/install: cannot change owner and permissions of 
`/home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/var/milter-greylist': 
Operation not permitted
make: *** [install-db] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.KtSEYc (%install)


RPM build errors:
     Bad exit status from /var/tmp/rpm-tmp.KtSEYc (%install)

The same will happen if I set the user to smmsp. Now, best practice is 
to build RPMs as a non-root user. Any clues for building an RPM for this 
thing as a non-root user? I worked around it by changing the build user 
and installation user as my Linux username, but that is less than 
optimal, you know?

Thoughts?
Thomas

Hi,

In <4FA5F85B.4060406@...>
  "Re: [milter-greylist] cannot build rpm on SMP machine" on Sat, 05 May 2012 23:04:43 -0500,
  Thomas Cameron <thomas.cameron@...> wrote:

> I also get:
> 
> flex -oconf_lex.c conf_lex.l
> bison -y -p`echo dump_yacc.c|sed 's/^\([^_]\{1,\}_\).*$/\1/'` dump_yacc.y
> milter-greylist.c:2493: warning: 'last' may be used uninitialized in 
> this function
> mv y.tab.c dump_yacc.c
> flex -odump_lex.c dump_lex.l
> gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall 
> -DHAVE_DATA_CALLBACK -DCONFFILE=\"/etc/mail/greylist.conf\" 
> -DDUMPFILE=\"/var/milter-greylist/greylist.db\" -D_BSD_SOURCE -I. -I. 
>   -c -o conf.o conf.c
> mv y.tab.c conf_yacc.c
> mv: cannot stat `y.tab.c': No such file or directory
> make: *** [conf_yacc.c] Error 1
> make: *** Waiting for unfinished jobs....
> error: Bad exit status from /var/tmp/rpm-tmp.nRIRgr (%build)

Here is a patch against milter-greylist itself to support
"make -j":

--
--- Makefile.in.~1.69.~	2012-05-06 15:21:14.000000000 +0900
+++ Makefile.in	2012-05-06 15:54:38.921097972 +0900
@@ -148,8 +148,14 @@ realclean:	clean
 .l.c:
 	${LEX} -o$@ $<
 .y.c:
-	${YACC} -p`echo $@|${SED} 's/^\([^_]\{1,\}_\).*$$/\1/'` $<
-	${MV} y.tab.c $@
+	prefix=`echo $@|${SED} 's/^\([^_]\{1,\}_\).*$$/\1/'`; \
+	${RM} -Rf $${prefix} && \
+	${INSTALL} -d $${prefix} && \
+	(cd $${prefix} && \
+	 ${YACC} -p$${prefix} ../$< && \
+	 ${MV} y.tab.c ../$@); \
+	${RM} -Rf $${prefix}; \
+	${TEST} -f $@
 
 # This is a target for debugging
 start:	milter-greylist
--

This is another solution.

> But now when I try to build it, I get:
> 
> test -f 
> /home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/etc/mail/greylist.conf 
> -o 	\
> 		-f 
> /home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/etc/mail/greylist.except 
> || 	\
> 	     /usr/bin/install -c -m 644 ./greylist.conf 
> /home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/etc/mail/greylist.conf
> /usr/bin/install -c -d -m 755 -o root 
> /home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64`dirname 
> /var/milter-greylist/greylist.db`
> /usr/bin/install: cannot change owner and permissions of 
> `/home/tcameron/rpmbuild/BUILDROOT/milter-greylist-4.3.9-1.x86_64/var/milter-greylist': 
> Operation not permitted

You can avoid the problem by passing "USER=$USER" to
"%{__make} install".

  https://github.com/kou/rpms/blob/milter-greylist-4.2.7/specs/milter-greylist/milter-greylist.spec#L46


Thanks,
--
kou

Kouhei Sutou <kou@...> wrote:

> Here is a patch against milter-greylist itself to support
> "make -j":

Sorry for not replying, I am back from vacations. 
Is the discussion settled? Should this patch be checked in? Another one?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Kouhei Sutou <kou@...> writes:

  Here is a patch against milter-greylist itself to support
  "make -j":

  --
  --- Makefile.in.~1.69.~	2012-05-06 15:21:14.000000000 +0900
  +++ Makefile.in	2012-05-06 15:54:38.921097972 +0900
  @@ -148,8 +148,14 @@ realclean:	clean
   .l.c:
          ${LEX} -o$@ $<
   .y.c:
  -	${YACC} -p`echo $@|${SED} 's/^\([^_]\{1,\}_\).*$$/\1/'` $<
  -	${MV} y.tab.c $@
  +	prefix=`echo $@|${SED} 's/^\([^_]\{1,\}_\).*$$/\1/'`; \
  +	${RM} -Rf $${prefix} && \
  +	${INSTALL} -d $${prefix} && \
  +	(cd $${prefix} && \
  +	 ${YACC} -p$${prefix} ../$< && \
  +	 ${MV} y.tab.c ../$@); \
  +	${RM} -Rf $${prefix}; \
  +	${TEST} -f $@

   # This is a target for debugging
   start:	milter-greylist

I don't follow this.  Are you writing to the prefix, or just using
install for something else.  Can you explain the problem - is it just
the collision of y.tab.c.  Can't you just use the -o option?  yacc on
NetBSD supports that, so I suspect it's pretty normal.

Hi,

In <rmiaa17hf1n.fsf@...>
  "Re: [milter-greylist] cannot build rpm on SMP machine" on Wed, 16 May 2012 19:39:00 -0400,
  Greg Troxel <gdt@...> wrote:

> 
> Kouhei Sutou <kou@...> writes:
> 
>   Here is a patch against milter-greylist itself to support
>   "make -j":
> 
>   --
>   --- Makefile.in.~1.69.~	2012-05-06 15:21:14.000000000 +0900
>   +++ Makefile.in	2012-05-06 15:54:38.921097972 +0900
>   @@ -148,8 +148,14 @@ realclean:	clean
>    .l.c:
>           ${LEX} -o$@ $<
>    .y.c:
>   -	${YACC} -p`echo $@|${SED} 's/^\([^_]\{1,\}_\).*$$/\1/'` $<
>   -	${MV} y.tab.c $@
>   +	prefix=`echo $@|${SED} 's/^\([^_]\{1,\}_\).*$$/\1/'`; \
>   +	${RM} -Rf $${prefix} && \
>   +	${INSTALL} -d $${prefix} && \
>   +	(cd $${prefix} && \
>   +	 ${YACC} -p$${prefix} ../$< && \
>   +	 ${MV} y.tab.c ../$@); \
>   +	${RM} -Rf $${prefix}; \
>   +	${TEST} -f $@
> 
>    # This is a target for debugging
>    start:	milter-greylist
> 
> I don't follow this.  Are you writing to the prefix, or just using
> install for something else.  Can you explain the problem - is it just
> the collision of y.tab.c.  Can't you just use the -o option?  yacc on
> NetBSD supports that, so I suspect it's pretty normal.

The problem is the collision of y.tab.c as you metioned. We
can just use the -o option. But I don't know whether the -o
option is portable. So I wrote the above patch. If we can
assume that yacc on all supported platforms supports the -o
option, I agree with using the -o option.


Thanks,
--
kou

On 17.5.2012 3:41, Kouhei Sutou wrote:
> The problem is the collision of y.tab.c as you metioned. We
> can just use the -o option. But I don't know whether the -o
> option is portable. So I wrote the above patch. If we can
> assume that yacc on all supported platforms supports the -o
> option, I agree with using the -o option.

yacc on Solaris does not support -o option.

-- 
  Leena Heino              University of Tampere / Computer Centre
  ( liinu at uta.fi )      ( http://www.uta.fi/laitokset/tkk )

Leena Heino <Leena.Heino@...> writes:

> On 17.5.2012 3:41, Kouhei Sutou wrote:
>> The problem is the collision of y.tab.c as you metioned. We
>> can just use the -o option. But I don't know whether the -o
>> option is portable. So I wrote the above patch. If we can
>> assume that yacc on all supported platforms supports the -o
>> option, I agree with using the -o option.
>
> yacc on Solaris does not support -o option.

So there is the possibility of insisting on a new enough yacc at
configure time, and forcing bison as a dependency for solaris.  This is
a tough call, having to separate what's behind vs. what's normal.

Alternatively, posix says that yacc must support -b for prefix, so that
could be used instead.  If Solaris doesn't conform to posix, I am
relatively unsympathetic and making Solaris people install bison seems
ok :-)

http://pubs.opengroup.org/onlinepubs/009695399/utilities/yacc.html

On Mon, 21 May 2012, Greg Troxel wrote:

> So there is the possibility of insisting on a new enough yacc at
> configure time, and forcing bison as a dependency for solaris.  This is
> a tough call, having to separate what's behind vs. what's normal.
>
> Alternatively, posix says that yacc must support -b for prefix, so that
> could be used instead.  If Solaris doesn't conform to posix, I am
> relatively unsympathetic and making Solaris people install bison seems
> ok :-)

Solaris yacc does support -b

-- 
   Leena Heino              University of Tampere / Computer Centre
   ( liinu at uta.fi )      ( http://www.uta.fi/laitokset/tkk )