Re: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc

2013-12-22 Thread Bernhard Fröhlich
Am 22.12.2013 21:57 schrieb "Dirk Meyer" :
>
> Bernhard Fröhlich schrieb:,
>
> > Am 22.12.2013 12:13 schrieb "Jos=E9 Garc=EDa Juanino" <
jjuan...@gmail.com>:
> > > I have running a recent FreeBSD 10.0-RC2, and I get the following
> > scenario:
> > >
> > > www/opera depends on lang/gcc46
> > > devel/kBuild depends on lang/gcc
> > >
> > > But both gcc46 and gcc are incompatible, so I cannot install opera and
> > > kBuild. However, lang/gcc and lang/gcc46 install the same versi=F3n
compi=
> > ler
> > > 4.6.4. Any idea to fix this conflict? I am using  pkgng to install the
> > > ports.
> >
> > kBuild is using USE_GCC=3Dyes which uses lang/gcc right now in version
4.6.
> >
> > Opera has a strict dependency on on FreeBSD 10 for gcc4.6 because of
> > libstdc++.so.6.
>
> In C++ you can not reuse your libraries without recompilation.
> This breaks the goal of object oriented design as stated in several books.

Why does opera work fine with libstdc++ from gcc 4.2 then?

> Opera has an option to pick your poison.
> you can set COMPAT9, which does conflict with virtualbox.

No it does not conflict anymore. That has been fixed already.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


check-stagedir.sh and %%PORT{DOCS,EXAMPLES}%%

2013-12-22 Thread Raphael Kubo da Costa
The usual advice for ports that support staging is to remove the checks
for ${PORT_OPTIONS:MDOCS} and friends and unconditionally create
${STAGEDIR}${DOCSDIR} and copy files there (the same applies to
MEXAMPLES and EXAMPLESDIR).

This seems to work fine in the default case (ie. DOCS and EXAMPLES are
set in the port's configuration). If I take a simple port such as
textproc/chpp, unset any of those two options and run something like
`make DISTDIR=/tmp clean stage check-orphans`, check-stagedir.sh
complains about missing plist entries protected by
%%PORT{DOCS,EXAMPLES}%% even though they are actually present.

Other ports just set PORTDOCS and PORTEXAMPLES in the Makefile, and the
same thing happens.

Is this a bug in the script or is there something obvious I'm missing?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Resolving circular dependencies

2013-12-22 Thread Scot Hetzel
On Sun, Dec 22, 2013 at 11:22 AM, Erick Turnquist
 wrote:
> On 2013-12-22 09:51, Scot Hetzel wrote:
>>
>> The best way to solve this would be to create 3 ports that would
>> create the appropriate gssapi mech:
>>
>> security/cyrus-sasl2-mech-gssapi-base <- Kerberos Support from
>> /usr/lib/libkrb5.a
>> security/cyrus-sasl2-mech-gssapi-krb5 (slave port)
>> security/cyrus-sasl2-mech-gssapi-hemidal (slave port)
>
>
> What would the exact dependencies be in this case? I feel like I've missed
> something important, because both openldap24-sasl-client and cyrus-sasl2
> still actually depend on the MIT Kerberos libraries, would we not end up
> with a circle of four packages instead of three?
>
> Before:
> openldap24-sasl-client -> cyrus-sasl2 -> krb5 -> openldap24-sasl-client
>
> After:
> openldap24-sasl-client -> cyrus-sasl2 -> cyrus-sasl2-mech-gssapi-krb5 ->
> krb5 -> openldap24-sasl-client

The dependencies should be:

krb5 -> openldap24-sasl-client -> cyrus-sasl2
cyrus-sasl2-mech-gssapi-krb5 -> krb5

The cyrus-sasl2-mech-gssapi-krb5 should be the only one depending on
the MIT Kerberos Libraries.

-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Resolving circular dependencies

2013-12-22 Thread Erick Turnquist

On 2013-12-22 09:51, Scot Hetzel wrote:

The best way to solve this would be to create 3 ports that would
create the appropriate gssapi mech:

security/cyrus-sasl2-mech-gssapi-base <- Kerberos Support from
/usr/lib/libkrb5.a
security/cyrus-sasl2-mech-gssapi-krb5 (slave port)
security/cyrus-sasl2-mech-gssapi-hemidal (slave port)


What would the exact dependencies be in this case? I feel like I've 
missed something important, because both openldap24-sasl-client and 
cyrus-sasl2 still actually depend on the MIT Kerberos libraries, would 
we not end up with a circle of four packages instead of three?


Before:
openldap24-sasl-client -> cyrus-sasl2 -> krb5 -> openldap24-sasl-client

After:
openldap24-sasl-client -> cyrus-sasl2 -> cyrus-sasl2-mech-gssapi-krb5 -> 
krb5 -> openldap24-sasl-client

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Resolving circular dependencies

2013-12-22 Thread Scot Hetzel
On Sat, Dec 21, 2013 at 6:41 PM, Erick Turnquist
 wrote:
> Hi List,
>
> A few weeks ago, I submitted a patch to build security/krb5 with LDAP
> support (adding a dependency on security/openldap24-sasl-client). All was
> well.
>
> Now, I've realized that security/cyrus-sasl2 (which the OpenLDAP client
> depends on) is going to need a knob to control which Kerberos implementation
> to use. My first thought was to simply LIB_DEPENDS+=security/krb5, but that
> leaves me with a circle (need to install krb5 before building cyrus-sasl2,
> but can't install krb5's dependency openldap24-sasl-client without
> cyrus-sasl2).
>
> I've tried searching, but can't find any advice on resolving issues like
> this. I'm sure this sort of thing has been encountered before. What's the
> best way to deal with it?
>
The non-Poudriere of dealing with this is to:

1.  install security/cyrus-sasl2 with krb5 support disabled
2. install security/openldap24-sasl-client
3. install security/krb5 with LDAP enabled
4. re-install security/cyrus-sasl2 with krb5 support enabled

I looked thru the security/cyrus-sasl2/Makefile, and it currently
doesn't have a LIB_DEPENDS on any of the Kerberos ports.  So the above
doesn't create a circular dependency.

The best way to solve this would be to create 3 ports that would
create the appropriate gssapi mech:

security/cyrus-sasl2-mech-gssapi-base <- Kerberos Support from
/usr/lib/libkrb5.a
security/cyrus-sasl2-mech-gssapi-krb5 (slave port)
security/cyrus-sasl2-mech-gssapi-hemidal (slave port)

That way you could use Poudriere to build these 4 ports (cyrus-sasl2,
openldap24-sasl-client, krb5 and cyrus-sasl2-mech-gssapi-krb5).

Now if someone could sit down and code these mech ports. ;-)

-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc

2013-12-22 Thread Bernhard Fröhlich
Am 22.12.2013 12:13 schrieb "José García Juanino" :
>
> Hello,
>
> I have running a recent FreeBSD 10.0-RC2, and I get the following
scenario:
>
> www/opera depends on lang/gcc46
> devel/kBuild depends on lang/gcc
>
> But both gcc46 and gcc are incompatible, so I cannot install opera and
> kBuild. However, lang/gcc and lang/gcc46 install the same versión compiler
> 4.6.4. Any idea to fix this conflict? I am using  pkgng to install the
> ports.

kBuild is using USE_GCC=yes which uses lang/gcc right now in version 4.6.

Opera has a strict dependency on on FreeBSD 10 for gcc4.6 because of
libstdc++.so.6.

RUN_DEPENDS+=   ${LOCALBASE}/lib/gcc46/libstdc++.so.6:${PORTSDIR}/lang/gcc46

I am not sure if opera really needs to be that strict on which libstdc++ it
uses since it also seems to be happy with libstdc++ from gcc 4.2 on FreeBSD
9.

I've cc'd the opera maintainer so let's see what he thinks.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc

2013-12-22 Thread José García Juanino
Hello,

I have running a recent FreeBSD 10.0-RC2, and I get the following scenario:

www/opera depends on lang/gcc46
devel/kBuild depends on lang/gcc

But both gcc46 and gcc are incompatible, so I cannot install opera and
kBuild. However, lang/gcc and lang/gcc46 install the same versión compiler
4.6.4. Any idea to fix this conflict? I am using  pkgng to install the
ports.

Best regards
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Lightning (For Thunderbird)

2013-12-22 Thread Tijl Coosemans
On Sat, 21 Dec 2013 15:06:26 + James Griffin wrote:
> On 12/21/2013 15:02, Matthew Seaman wrote:
>> On 21/12/2013 14:49, James Griffin wrote:
>>> I wanted to install Lightning from ports for use with Thunderbird but it
>>> appears there no longer is a port for this software. Is this the case;
>>> and if so, will there be at some point in the near future?
>>
>> It's included by default with mail/thunderbird already.
>
> Yeah I thought so, but even though I selected that option from make 
> config, it's not on my Thunderbird. So I thought it must be a separate 
> port, and Thunderbird is compiled with support for it to be added.

Can you see the add-on under the menu Tools->Addons and is it enabled?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"