Re: [gentoo-dev] Making new ebuild for cyrus-imapd-2.2.5 (current stable sources)

[Paul de Vrieze]

On Sunday 13 June 2004 02:24, Kevin wrote:
> Hi All-
>
> I'm trying to write a new ebuild script for cyrus-imapd-2.2.5 (which is
> the most current version of the stable source branch).  I'm basing it
> on the ebuild script in portage for cyrus-imapd-2.2.3 which was
> apparently considered a beta level package and is thus masked in the
> masked.packages file.
>
> In preparation for this project, I first unmasked 2.2.3 and emerged it
> (just in case there were bugs in the 2.2.3 ebuild script itself).
> There were no apparent problems during the emerge process itself (I
> haven't configured or run the server program), so I took that as
> reasonable proof that the 2.2.3 ebuild script was bug-free (at least
> enough so to serve my purposes).
>
> I then made a /usr/local/portage/net-mail/cyrus-imapd directory, copied
> the 2.2.3 ebuild script to this directory and renamed it for 2.2.5,
> thinking that my task just might end up being no more involved than
> that (as far as changes to the ebuild script itself).  I also copied
> the files in the /usr/portage/net-mail/cyrus-imapd/files
> to /usr/local/portage/net-mail/cyrus-imapd/files, renamed
> cyrus-imapd-2.2.3-db4.patch found therein to
> cyrus-imapd-2.2.5-db4.patch and edited that file (replacing all
> instances of "2.2.3" with "2.2.5") so that the patch process would
> patch the berkdb.m4 file in the 2.2.5 directory tree (not sure if patch
> would have been able to figure that out otherwise).  I also edited
> cyrus-imapd-libwrap.patch and noticed that this file was apparently
> based on version 2.1.11 (bug?) and replaced all instances of "2.1.11"
> with "2.2.5" in case patch could not figure it out on its own.
>
> Then I ran
> # ebuild cyrus-imapd-2.2.5.ebuild digest
> and figured that just might complete the project.
>
> But as you've guessed, it doesn't (else why would I be writing, right?).
>
> In case it's important, I'll mention that I also set up some of my own
> configure script parameters in the ebuild script.  The config.log file
> reports executing the following configure command:
>
> ./configure --prefix=/usr --host=i686-pc-linux-gnu
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --sysconfdir=/etc --localstatedir=/var/lib --enable-murder
> --enable-listext --enable-netscapehack --enable-krb5afspts
> --with-extraident=Gentoo --with-service-path=/usr/lib/cyrus
> --with-cyrus-user=cyrus --with-cyrus-group=mail --with-com_err=yes
> --with-auth=krb5 --with-ldap=/usr --with-zephyr --with-gss_impl=mit
> --with-sasl
>
> The
> # ACCEPT_KEYWORDS="~x86" emerge -v cyrus-imapd
> command fails with:
>
> ================
> Calculating dependencies ...done!
>
> >>> emerge (1 of 1) net-mail/cyrus-imapd-2.2.5 to /
> >>> md5 src_uri ;-) cyrus-imapd-2.2.5.tar.gz
> >>> Unpacking source...
> >>> Unpacking cyrus-imapd-2.2.5.tar.gz
>
> to /var/tmp/portage/cyrus-imapd-2.2.5/work
>  * Applying cyrus-imapd-libwrap.patch...
> [ ok ]
>  * Applying cyrus-imapd-2.2.5-db4.patch...
> [ ok ]
>  * Recreating configure...
> [ ok ]
> sed: can't read configure: No such file or directory
>
> !!! ERROR: net-mail/cyrus-imapd-2.2.5 failed.
> !!! Function src_unpack, Line 71, Exitcode 2
> !!! sed failed
> ================
>
> The problem comes from the last line of the src_unpack() function:
>
> ===================
> src_unpack() {
>   unpack ${A} && cd "${S}"
>
>   # Add drac database support.
>   if [ "`use drac`" ] ; then
>           epatch "${S}/contrib/drac_auth.patch"
>   fi
>
>   # Add libwrap defines as we don't have a dynamicly linked library.
>   if [ "`use tcpd`" ] ; then
>           epatch "${FILESDIR}/${PN}-libwrap.patch"
>   fi
>
>   # DB4 detection and versioned symbols.
>   epatch "${FILESDIR}/${P}-db4.patch"
>
>   # Fix master(8)->cyrusmaster(8) manpage.
>   for i in `grep -rl -e 'master\.8' -e 'master(8)' "${S}"` ; do
>           sed -e 's:master\.8:cyrusmaster.8:g' \
>                   -e 's:master(8):cyrusmaster(8):g' \
>                   -i "${i}" || die "sed failed"
>   done
>   mv man/master.8 man/cyrusmaster.8
>   sed -e "s:MASTER:CYRUSMASTER:g" \
>           -e "s:Master:Cyrusmaster:g" \
>           -e "s:master:cyrusmaster:g" \
>           -i man/cyrusmaster.8 || die "sed failed"
>
>   # Recreate configure.
>   export WANT_AUTOCONF="2.5"
> # sh   # added by me for troubleshooting
>   rm -f configure config.h.in
>   ebegin "Recreating configure"
>   sh SMakefile &>/dev/null || die "SMakefile failed"
>   eend $?
>
>   # When linking with rpm, you need to link with more libraries.
>   sed -e "s:lrpm:lrpm -lrpmio -lrpmdb:" -i configure || die "sed failed"
> }
> ===================
>
> This sed command expects to find a file named, "configure" and it
> doesn't.
>
> The reason that it finds no configure file is that it wasn't recreated
> with the "sh SMakefile &>/dev/null || die "SMakefile failed" line.
>
> To figure out why, I uncommented the "# sh   # added by me..." line,
> commented the "rm -f" line and the "sh SMakefile" line and did some
> experimenting.
>
> First, I just tried doing what the ebuild script would do:
> # rm -f configure config.h.in
> # sh SMakefile
>
> The SMakefile step fails with:
> ===============
> sh-2.05b# sh SMakefile
> aclocal -I cmulocal
> autoheader
> Can't locate object method "path" via package "Request"
> at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 111.
> autoheader-2.58: /usr/bin/autom4te failed with exit status: 1
> autoconf
> Can't locate object method "path" via package "Request"
> at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 111.
> ===============
>
> I'll admit to having an extremely limited understanding of autoconf and
> automake and so here's where I'm stuck.
>
> I've been able to figure out that we're deleting the configure and
> config.h.in files because we're patching some of the scripts that go
> into making these files, and we thus need to regenerate them.  For
> example, if we try skipping the rm -f step and sh SMakefile step, then
> the emerge fails with complaints of not being able to find db_create in
> the ldb libraries.  When berkdb.m4 is patched and configure and
> config.h.in are regenerated, then the configure process searches for
> and finds the db_create_4001 functions in ldb---this I learned because
> after trying the above (sh-2.05b# sh SMakefile), I started another
> shell, did a
> # cd /var/tmp/portage/cyrus-imapd-2.2.5/work/cyrus-imapd-2.2.5/ and then
> did a
> # sh SMakefile
> from there.  This succeeds, but makes a broken configure script---it
> includes stuff that was apparently brought in directly from
> configure.in.  For example, it looks like every line from here:
> AH_TOP([
> on down in configure.in is just copied into configure.
>
> So with that in place, I went back to the first shell (invoked by the
> ebuild script) and exited from it, thus continuing the emerge process
> which then fails with:
>
> =================
> ...
> checking for net-snmp-config... no
> checking for sprint_objid in -lsnmp... no
> checking UCD SNMP libraries... no
> ./configure: line 8228: syntax error near unexpected token `newline'
> ./configure: line 8228: `AH_TOP('
>
> !!! ERROR: net-mail/cyrus-imapd-2.2.5 failed.
> !!! Function econf, Line 365, Exitcode 2
> !!! econf failed
>
> =================
>
> I don't understand why
> # sh SMakefile
> invoked from a shell called by the ebuild script fails (undoubtedly in
> the same way and for the same reason that it fails when called directly
> in the ebuild script but the output is redirected to the bit bucket),
> but does not fail when invoked from a separate shell (perhaps it needs
> environment variables that are not present in the shell invoked by the
> ebuild script?).  Furthermore, why does running sh SMakefile from the
> other script make a broken configure script?
>
> To try and understand why, I did pretty much the same thing as above but
> with the 2.2.3 ebuild script.  What I found was that the "sh SMakefile"
> step in the ebuild for 2.2.3 _does_ succeed and generates a completely
> functional configure script which can then be used to emerge the
> package.  But when I shell out of the ebuild script, start another
> shell, cd to the working directory, and then do a # sh SMakefile, this
> process also makes a broken configure script (broken in the same was as
> for 2.2.5).
>
> Can anyone tell me what's going on here and how to fix it?
>
> I started reading the info pages for automake and autoconf and it looks
> like I would be doing that for quite a long time and possibly not
> solving the problem by doing so, so I'm hoping someone here can give me
> some pointers.
>
Probably the script is for a different version of autoconf. Try to read the 
original configure file (before it is deleted/changed) and look which version 
was used to create it. Then force it such a way that a version similar to 
that is used. (WANT_AUTOCONF=2.1 for example)

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@××××××.nl
Homepage: http://www.devrieze.net