Date: Wed, 27 Aug 2014 17:30:22 -0500 From: "Lawrence K. Chen, P.Eng." <lkchen@ksu.edu> To: freebsd-ports@freebsd.org Subject: Re: Building subversion-1.8.10 under poudriere Message-ID: <53FE5BFE.5050101@ksu.edu> In-Reply-To: <53FDE021.5030108@egr.msu.edu> References: <53FDCBD8.4060306@digiware.nl> <7C47458A-8B41-47FB-8091-00CA301DDA5B@FreeBSD.org> <53FDD88A.9030001@digiware.nl> <53FDE021.5030108@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/27/14 08:41, Adam McDougall wrote:
> On 08/27/2014 09:09, Willem Jan Withagen wrote:
>> On 2014-08-27 14:41, Dimitry Andric wrote:
>>>
>>> This is a problem in the devel/apr1 port. It checks for modf(), finds
>>> it in libc, then assumes isnan() also comes from libc. However, that
>>> does not work for static linking.
>>>
>>> Please apply the attached patch for apr1, which I have been using for
>>> some time now.
>>
>> Hi Dimitry,
>>
>> So this is due to me wanting to link things static?
>> Then I'll reconfig subversion to dynamic linking.
>> Because I don't have a clue (yet) as to how to get (and keep) custom
>> patches in a poudriere environment.
>>
>> Thanx for the reply,
>> --WjW
>>
>
> I keep custom patches this way:
>
> /usr/local/etc/poudriere.d/my-appropriate-make.conf:
>
> .if ${.CURDIR:M*/mail/mutt}
> EXTRA_PATCHES+= /distfiles/mypatches/patch-mail-mutt-fix-imap-append
> .endif
>
> You may also be interested in things like:
> .if ${.CURDIR:M*/security/krb5}
> CONFIGURE_ARGS+= --localstatedir=/var/db
> WITH_OPENSSL_PORT=yes
> .endif
>
> I suggest using this method in poudriere's make.conf for port building
> options:
> DEFAULT_VERSIONS= perl5=5.16 php=5.4 mysql=5.5 apache=2.2 pgsql=8.4
> # Global port options
> OPTIONS_UNSET+=AVAHI BONJOUR CUPS MDNS PULSEAUDIO
> # specific port options:
> mail_dovecot_SET=GSSAPI
> mail_dovecot_UNSET=MANAGESIEVE
>
> That way you only change the options you desire and aren't hardcoding
> any of the other port options in case the default changes in the future,
> possibly in a critical way (threading for example).
>
> The path to the patch must be a proper path within port building jails
> and I believe poudriere mounts it's distfiles directory on /distfiles.
> It has to be a path that is available within port building jails. I
> picked distfiles because it is available. One thing I like about
> EXTRA_PATCHES is it will cause a port build to fail if the file is not
> found, so if that happens I will know to correct the problem rather than
> produce unpatched packages. I add my "mypatches" directory to my
> standard server backups so it is easy to restore if needed. Beware
> running poudriere distclean since it will wipe out unreferenced files in
> distfiles.
>
>
Hmmm, wonder why I didn't think of that?
I've been trying to get poudriere working....I did go through the ugly
exercise of going through all my servers to attempt to unify port options.
Currently trying to go with two sets....one for my headless servers and one
for servers with heads :) Though there's still enough difference that it
might not be possible. Though I've also thought of additional sets to
generate packages for updates I haven't done yet (which is one of reasons
driving trying to get things working, I haven't upgraded from apache 2.2 to
2.4 yet)
What I settled on instead of to create a tree with my extra patches, and use
portshaker to merge....
Other delays in getting this going, is that I've been trying to use CFEngine
to handle the consolidation of options and pkglists and driving portshaker and
poudriere....
I did a bulk run of everything from my headless servers this morning....of
622, only one failed, one skipped, and one ignored.
The failed port was 'x11-toolkits/ocaml-lablgtk2', could probably get around
it by changing port option for no-X11 for unison on these servers. The
skipped port was unison, where the failed port is a dependency. Probably
don't need X11 graphics support in unison on these servers.... (even though
one of the servers starts Xvfb during boot....because it runs an application
that needs X during startup, but never again once its running....Linux version
probably has the same weird issue, except none of my Linux servers were
headless...so it was never noticed. Killed off the last Linux server on
August 10th...) Which is why I didn't do "OPTIONS_UNSET= X11" in make.conf
for this set....but I almost did.
The ignored port was because I had missed setting a required setting in
make.conf (its missing on all my servers...but haven't had to update that port
since it got installed, so didn't notice the settings had disappeared.)
Now I'm having trouble because I have ports installed (namely gnome related)
that had long ago disappeared....
Wonder if there's still time to now see what ports I have installed that
haven't been staged yet?
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53FE5BFE.5050101>