Re: libsn/sn.h error with x11/tint

[Kevin Oberman]

On Wed, Apr 6, 2016 at 2:05 PM, tatoolz--- via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> I use FreeBSD 10.3 on AMD64.
> When i will install x11/tint, stop with this error:
> [ 21%] Building C object
> src/tint2conf/CMakeFiles/tint2conf.dir/__/util/common.c.oIn file included
> from
> /usr/ports/x11/tint/work/tint2-0.12.7/src/server.c:28:/usr/ports/x11/tint/work/tint2-0.12.7/src/server.h:17:10:
> fatal error: 'libsn/sn.h' file not found#include  ^In
> file included from
> /usr/ports/x11/tint/work/tint2-0.12.7/src/panel.c:30:/usr/ports/x11/tint/work/tint2-0.12.7/src/server.h:17:10:
> fatal error: 'libsn/sn.h' file not found#include  ^1
> error generated.--- CMakeFiles/tint2.dir/src/server.c.o ---***
> [CMakeFiles/tint2.dir/src/server.c.o] Error code 1
> make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error
> generated.In file included from
> /usr/ports/x11/tint/work/tint2-0.12.7/src/util/common.c:33:/usr/ports/x11/tint/work/tint2-0.12.7/src/util/../server.h:17:10:
> fatal error: 'libsn/sn.h' file not found#include  ^---
> CMakeFiles/tint2.dir/src/panel.c.o ---***
> [CMakeFiles/tint2.dir/src/panel.c.o] Error code 1
> make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7In file included
> from
> /usr/ports/x11/tint/work/tint2-0.12.7/src/config.c:43:/usr/ports/x11/tint/work/tint2-0.12.7/src/server.h:17:10:
> fatal error: 'libsn/sn.h' file not found#include  ^1
> error generated.--- CMakeFiles/tint2.dir/src/config.c.o ---***
> [CMakeFiles/tint2.dir/src/config.c.o] Error code 1
> make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.73 errors
> make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7---
> CMakeFiles/tint2.dir/all ---*** [CMakeFiles/tint2.dir/all] Error code 2
> make[3]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error
> generated.--- src/tint2conf/CMakeFiles/tint2conf.dir/__/util/common.c.o
> ---*** [src/tint2conf/CMakeFiles/tint2conf.dir/__/util/common.c.o] Error
> code 1
> make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error
> make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7---
> src/tint2conf/CMakeFiles/tint2conf.dir/all ---***
> [src/tint2conf/CMakeFiles/tint2conf.dir/all] Error code 2
> make[3]: stopped in /usr/ports/x11/tint/work/tint2-0.12.72 errors
> make[3]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7*** [all] Error
> code 2
> make[2]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error
> make[2]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7===> Compilation
> failed unexpectedly.Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
> reporting the failure tothe maintainer.*** Error code 1
> Stop.make[1]: stopped in /usr/ports/x11/tint*** Error code 1
> Stop.make: stopped in /usr/ports/x11/tint
> Someone has a tip?
>

To state the obvious, the build could not find libsn/sn.h. It should be in
/usr/local/include/startup-notification-1.0/libsn/sn.h and should have been
installed as a part of x11/startup-notification. The Makefile does look for
this file and should have installed startup-notificattion if it was not
already installed. Is startup-notification installed? Is
/usr/local/include/startup-notification-1.0/libsn/sn.h present and
readable? Is startup-notification installed?

What command did you use to build tint?
Do you have any customizations to your environment that might have
triggered this.

I can say that it builds just fine on my 10-Stable system that was update
about a bit after 10.3 was branched.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

libsn/sn.h error with x11/tint

[tatoolz--- via freebsd-ports]

I use FreeBSD 10.3 on AMD64.
When i will install x11/tint, stop with this error:
[ 21%] Building C object 
src/tint2conf/CMakeFiles/tint2conf.dir/__/util/common.c.oIn file included from 
/usr/ports/x11/tint/work/tint2-0.12.7/src/server.c:28:/usr/ports/x11/tint/work/tint2-0.12.7/src/server.h:17:10:
 fatal error: 'libsn/sn.h' file not found#include          ^In file 
included from 
/usr/ports/x11/tint/work/tint2-0.12.7/src/panel.c:30:/usr/ports/x11/tint/work/tint2-0.12.7/src/server.h:17:10:
 fatal error: 'libsn/sn.h' file not found#include          ^1 error 
generated.--- CMakeFiles/tint2.dir/src/server.c.o ---*** 
[CMakeFiles/tint2.dir/src/server.c.o] Error code 1
make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error generated.In 
file included from 
/usr/ports/x11/tint/work/tint2-0.12.7/src/util/common.c:33:/usr/ports/x11/tint/work/tint2-0.12.7/src/util/../server.h:17:10:
 fatal error: 'libsn/sn.h' file not found#include          ^--- 
CMakeFiles/tint2.dir/src/panel.c.o ---*** [CMakeFiles/tint2.dir/src/panel.c.o] 
Error code 1
make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7In file included from 
/usr/ports/x11/tint/work/tint2-0.12.7/src/config.c:43:/usr/ports/x11/tint/work/tint2-0.12.7/src/server.h:17:10:
 fatal error: 'libsn/sn.h' file not found#include          ^1 error 
generated.--- CMakeFiles/tint2.dir/src/config.c.o ---*** 
[CMakeFiles/tint2.dir/src/config.c.o] Error code 1
make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.73 errors
make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7--- 
CMakeFiles/tint2.dir/all ---*** [CMakeFiles/tint2.dir/all] Error code 2
make[3]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error generated.--- 
src/tint2conf/CMakeFiles/tint2conf.dir/__/util/common.c.o ---*** 
[src/tint2conf/CMakeFiles/tint2conf.dir/__/util/common.c.o] Error code 1
make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error
make[4]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7--- 
src/tint2conf/CMakeFiles/tint2conf.dir/all ---*** 
[src/tint2conf/CMakeFiles/tint2conf.dir/all] Error code 2
make[3]: stopped in /usr/ports/x11/tint/work/tint2-0.12.72 errors
make[3]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7*** [all] Error code 2
make[2]: stopped in /usr/ports/x11/tint/work/tint2-0.12.71 error
make[2]: stopped in /usr/ports/x11/tint/work/tint2-0.12.7===> Compilation 
failed unexpectedly.Try to set MAKE_JOBS_UNSAFE=yes and rebuild before 
reporting the failure tothe maintainer.*** Error code 1
Stop.make[1]: stopped in /usr/ports/x11/tint*** Error code 1
Stop.make: stopped in /usr/ports/x11/tint
Someone has a tip?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: New release 0.140 of newsreader Pan / FreeBSD port

[Kurt Jaeger]

Hi!

> > a new release of Pan is available:
> > 
> > http://pan.rebelbase.com/download/releases/0.140/source/
> > 
> > How can I trigger the maintainer to update the FreeBSD port of Pan?
> 
> The best approach is providing a patch and submitting it
> via bugs.freebsd.org, probably with a changelog about it ?

Here we go:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208585

If you want to test it, grab the patch in that PR, build 0.140
and add some comment about the run-test to the PR.

Until then, we wait for gnome@ to comment/approve it.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: New release 0.140 of newsreader Pan / FreeBSD port

[Kurt Jaeger]

Hi!

> a new release of Pan is available:
> 
> http://pan.rebelbase.com/download/releases/0.140/source/
> 
> How can I trigger the maintainer to update the FreeBSD port of Pan?

The best approach is providing a patch and submitting it
via bugs.freebsd.org, probably with a changelog about it ?

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Committer needed for PR 208029

[Michelle Sullivan]

Jim Ohlstein wrote:

Hello,

On 4/6/16 12:39 PM, Mathieu Arnold wrote:

+--On 6 avril 2016 12:00:47 -0400 Jim Ohlstein  wrote:
| Hello,
|
|> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold  wrote:
|>
|> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein  wrote:
|> | Hello,
|> |
|> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
|> |> Hi!
|> |>
|> |>> Actually, I just noticed (when compiling the port), that the 
Makefile

|> |>> now says:
|> |>>
|> |>> WITH_OPENSSL_PORT=yes
|> |>
|> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
|> |> now as IGNORE with a message explaining how to do it for 9.x.
|> |>
|> |
|> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option 
is there

|> | for just this purpose and is used in many ports.
|>
|> No, the WITH_OPENSSL_PORT knob is a global one, and must not be 
used in
|> ports makefiles.  The fact is, there are ports using it, true, it 
does

|> not mean it is the right thing to do.
|>
|
| Then there are many ports being committed incorrectly, as well as, no
| doubt, many *official* packages.
|
| I really have no dog in this fight. I use it globally and build all 
of my
| own packages with poudriere, but either it shouldn't be there at 
all, or
| it should be ok to use. Having it available as an option to porters 
and

| then saying it shouldn't be used seems a bit silly.

Well, it is not available for the porters as it is a global 
directive, they

use it anyway.

Anyway, like I said, working on it.



Maybe an edit to portlint is in order. That way they might know. As of 
now, portlint does not so much as emit a warning.


I don't entirely disagree with the premise that all ports that require 
OpenSSL should be built against the version in ports. As I said, I do 
it and it also makes port maintenance simpler. However, as long as it 
is actually an option, as it is now, then it should be availed when 
desired.
I don't agree or disagree for what it's worth... What I do say though is 
where ever possible all ports should be compiled against one version.. 
of course GSSAPI support is a 'special case' in point that might have to 
break that rule of thumb.




Further down the road (but not all that far) I foresee other, perhaps 
bigger problems if using this strategy. OpenSSL 1.1.0 is in beta and 
will be released within the next month or two. It is not completely 
backward compatible. 


100% there...!

At some point it will become the official ports version and/or two 
versions will need to be maintained in ports, 1.0.2 (LTS until 2019) 
and 1.1.x. This will create the problem of some/many ports not 
building against 1.1.x and some ports or port options _requiring_ 
1.1.x. Assuming 1.1.x is the main OpenSSL in ports, there will be 
ports that would build properly against OpenSSL in base (but cannot be 
built that way if using the ports version is mandated), and do not 
compile against OpenSSL 1.1.x. Most can no doubt be patched, but 
waiting for upstream providers to do so may be problematic, and many 
porters lack the skills.


Personally I'm surprised there is not more than one major version of 
openssl in the ports tree already.. perhaps there should be...


--
Michelle Sullivan
http://www.mhix.org/

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

Re: Committer needed for PR 208029

[Michelle Sullivan]

Kurt Jaeger wrote:

Hi!


This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
for just this purpose and is used in many ports.

In 9.x this is sometimes a problem, if port X builds in variant 1
and port Y depends/links on X, but builds in variant 2. So it's
a temporary solution for 9.x and will be solved when 9.x is EOL'ed.


I have run into exactly this.


I'm not sure how this is solved in 10.x/11.x, probably the base SSL
is much more up2date.


Still has the same problem... though at the moment with 10.x being so up 
to date its not noticable when OpenSSL 1.0.3+ comes out it'll only be a 
matter of time before the same problems come up... and for the record, I 
think based on the FreeBSD policy, putting in an IGNORE or BROKEN for a 
too early version of openssl in base is the best policy ... not 
forgetting that the user doesn't have to specify system-wide options, 
they can do it on the command line.



Forcing users who want to use this port to use OpenSSL from ports for
ALL ports is overkill.
Think about official packages. Are ALL packages built against OpenSSL
from ports, or only those that need them? It's the latter, of course.
Are they incompatible in production? No.
Actually I think you'll find with the intent of compiling and using the 
new pkg (at least until variants are done) it's a hell of a lot worse 
(you can't use pkg upgrade with the risk of something that you need 
getting replaced by something you have chosen to configure... that 
said.. you have the same problem even if you have USE_OPENSSL_PORTS 
defined anyhow...)



There are grey areas, and I guess it will be like that for 9.x.




--
Michelle Sullivan
http://www.mhix.org/

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

Re: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

On 4/6/16 12:39 PM, Mathieu Arnold wrote:

+--On 6 avril 2016 12:00:47 -0400 Jim Ohlstein  wrote:
| Hello,
|
|> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold  wrote:
|>
|> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein  wrote:
|> | Hello,
|> |
|> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
|> |> Hi!
|> |>
|> |>> Actually, I just noticed (when compiling the port), that the Makefile
|> |>> now says:
|> |>>
|> |>> WITH_OPENSSL_PORT=yes
|> |>
|> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
|> |> now as IGNORE with a message explaining how to do it for 9.x.
|> |>
|> |
|> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
|> | for just this purpose and is used in many ports.
|>
|> No, the WITH_OPENSSL_PORT knob is a global one, and must not be used in
|> ports makefiles.  The fact is, there are ports using it, true, it does
|> not mean it is the right thing to do.
|>
|
| Then there are many ports being committed incorrectly, as well as, no
| doubt, many *official* packages.
|
| I really have no dog in this fight. I use it globally and build all of my
| own packages with poudriere, but either it shouldn't be there at all, or
| it should be ok to use. Having it available as an option to porters and
| then saying it shouldn't be used seems a bit silly.

Well, it is not available for the porters as it is a global directive, they
use it anyway.

Anyway, like I said, working on it.



Maybe an edit to portlint is in order. That way they might know. As of 
now, portlint does not so much as emit a warning.


I don't entirely disagree with the premise that all ports that require 
OpenSSL should be built against the version in ports. As I said, I do it 
and it also makes port maintenance simpler. However, as long as it is 
actually an option, as it is now, then it should be availed when desired.


Further down the road (but not all that far) I foresee other, perhaps 
bigger problems if using this strategy. OpenSSL 1.1.0 is in beta and 
will be released within the next month or two. It is not completely 
backward compatible. At some point it will become the official ports 
version and/or two versions will need to be maintained in ports, 1.0.2 
(LTS until 2019) and 1.1.x. This will create the problem of some/many 
ports not building against 1.1.x and some ports or port options 
_requiring_ 1.1.x. Assuming 1.1.x is the main OpenSSL in ports, there 
will be ports that would build properly against OpenSSL in base (but 
cannot be built that way if using the ports version is mandated), and do 
not compile against OpenSSL 1.1.x. Most can no doubt be patched, but 
waiting for upstream providers to do so may be problematic, and many 
porters lack the skills.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

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

Re: Committer needed for PR 208029

[Mathieu Arnold]

+--On 6 avril 2016 12:00:47 -0400 Jim Ohlstein  wrote:
| Hello,
| 
|> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold  wrote:
|> 
|> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein  wrote:
|> | Hello,
|> | 
|> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
|> |> Hi!
|> |> 
|> |>> Actually, I just noticed (when compiling the port), that the Makefile
|> |>> now says:
|> |>> 
|> |>> WITH_OPENSSL_PORT=yes
|> |> 
|> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
|> |> now as IGNORE with a message explaining how to do it for 9.x.
|> |> 
|> | 
|> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
|> | for just this purpose and is used in many ports.
|> 
|> No, the WITH_OPENSSL_PORT knob is a global one, and must not be used in
|> ports makefiles.  The fact is, there are ports using it, true, it does
|> not mean it is the right thing to do.
|> 
| 
| Then there are many ports being committed incorrectly, as well as, no
| doubt, many *official* packages. 
| 
| I really have no dog in this fight. I use it globally and build all of my
| own packages with poudriere, but either it shouldn't be there at all, or
| it should be ok to use. Having it available as an option to porters and
| then saying it shouldn't be used seems a bit silly. 

Well, it is not available for the porters as it is a global directive, they
use it anyway.

Anyway, like I said, working on it.

-- 
Mathieu Arnold

pgpsUuW01kLS1.pgp
Description: PGP signature

Re: Committer needed for PR 208029

[Christoph Moench-Tegeder]

## Kurt Jaeger (li...@opsec.eu):

> In 9.x this is sometimes a problem, if port X builds in variant 1
> and port Y depends/links on X, but builds in variant 2. So it's
> a temporary solution for 9.x and will be solved when 9.x is EOL'ed.

We have also seen that problem on 10.x:
https://lists.freebsd.org/pipermail/freebsd-emulation/2015-March/012390.html

Regards,
Christoph

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

Re: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold  wrote:
> 
> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein  wrote:
> | Hello,
> | 
> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
> |> Hi!
> |> 
> |>> Actually, I just noticed (when compiling the port), that the Makefile
> |>> now says:
> |>> 
> |>> WITH_OPENSSL_PORT=yes
> |> 
> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
> |> now as IGNORE with a message explaining how to do it for 9.x.
> |> 
> | 
> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
> | for just this purpose and is used in many ports.
> 
> No, the WITH_OPENSSL_PORT knob is a global one, and must not be used in
> ports makefiles.  The fact is, there are ports using it, true, it does not
> mean it is the right thing to do.
> 

Then there are many ports being committed incorrectly, as well as, no doubt, 
many *official* packages. 

I really have no dog in this fight. I use it globally and build all of my own 
packages with poudriere, but either it shouldn't be there at all, or it should 
be ok to use. Having it available as an option to porters and then saying it 
shouldn't be used seems a bit silly. 

> There is work going on to always use OpenSSL from ports, but it also needs
> to take into account GSSAPI, and it's a mess.

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

Re: Committer needed for PR 208029

[Mathieu Arnold]

+--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein  wrote:
| Hello,
| 
| On 4/6/16 12:44 AM, Kurt Jaeger wrote:
|> Hi!
|> 
|>> Actually, I just noticed (when compiling the port), that the Makefile
|>> now says:
|>> 
|>> WITH_OPENSSL_PORT=yes
|> 
|> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
|> now as IGNORE with a message explaining how to do it for 9.x.
|> 
| 
| This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
| for just this purpose and is used in many ports.

No, the WITH_OPENSSL_PORT knob is a global one, and must not be used in
ports makefiles.  The fact is, there are ports using it, true, it does not
mean it is the right thing to do.

There is work going on to always use OpenSSL from ports, but it also needs
to take into account GSSAPI, and it's a mess.

-- 
Mathieu Arnold

pgpaLDaT4nC3w.pgp
Description: PGP signature

Re: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

> On Apr 6, 2016, at 10:47 AM, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there 
>> for just this purpose and is used in many ports.
> 
> In 9.x this is sometimes a problem, if port X builds in variant 1
> and port Y depends/links on X, but builds in variant 2. So it's
> a temporary solution for 9.x and will be solved when 9.x is EOL'ed.
> 
> I'm not sure how this is solved in 10.x/11.x, probably the base SSL
> is much more up2date.
> 
>> Forcing users who want to use this port to use OpenSSL from ports for 
>> ALL ports is overkill.
> 
>> Think about official packages. Are ALL packages built against OpenSSL 
>> from ports, or only those that need them? It's the latter, of course. 
>> Are they incompatible in production? No.
> 
> There are grey areas, and I guess it will be like that for 9.x.

Not only 9.x. 10.x has OpenSSL 1.0.1. Some ports require 1.0.2 which is in 
ports. Openssl 1.1.0 is soon to be released but almost certainly won't be in 
11. It's likely to always be an issue. It's up to each individual maintainer to 
make certain his or her ports behave correctly if binaries link to one another. 
For a port like this the proper solution is to use the least intrusive option. 

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

Re: Committer needed for PR 208029

[Kurt Jaeger]

Hi!

> This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there 
> for just this purpose and is used in many ports.

In 9.x this is sometimes a problem, if port X builds in variant 1
and port Y depends/links on X, but builds in variant 2. So it's
a temporary solution for 9.x and will be solved when 9.x is EOL'ed.

I'm not sure how this is solved in 10.x/11.x, probably the base SSL
is much more up2date.

> Forcing users who want to use this port to use OpenSSL from ports for 
> ALL ports is overkill.

> Think about official packages. Are ALL packages built against OpenSSL 
> from ports, or only those that need them? It's the latter, of course. 
> Are they incompatible in production? No.

There are grey areas, and I guess it will be like that for 9.x.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

On 4/6/16 12:44 AM, Kurt Jaeger wrote:

Hi!


Actually, I just noticed (when compiling the port), that the Makefile now says:

WITH_OPENSSL_PORT=yes


Yes, sorry, my fault. Fixed, and as suggested by mat: It is
now as IGNORE with a message explaining how to do it for 9.x.



This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there 
for just this purpose and is used in many ports. There's no reason some 
binaries can't be linked to one version of OpenSSL and others to 
another, so long as they aren't expected to work as one (I'd imagine a 
dynamically loaded module that is linked to a different library might 
cause a problem). That is the reason that ports contains a more current 
version than base. This is from the ports/www directory:


#  grep WITH_OPENSSL_PORT */Makefile
aws/Makefile:WITH_OPENSSL_PORT= yes
drood/Makefile:WITH_OPENSSL_PORT=   yes
h2o/Makefile:WITH_OPENSSL_PORT= no
h2o/Makefile:WITH_OPENSSL_PORT= yes
mod_tsa/Makefile:WITH_OPENSSL_PORT= yes
nginx-devel/Makefile:WITH_OPENSSL_PORT= yes
nginx-devel/Makefile:WITH_OPENSSL_PORT= yes
nginx/Makefile:WITH_OPENSSL_PORT=   yes
nginx/Makefile:WITH_OPENSSL_PORT=   yes
obhttpd/Makefile:WITH_OPENSSL_PORT=yes
owncloud/Makefile:WITH_OPENSSL_PORT=yes
spdylay/Makefile:.if ${OSVERSION} < 100 && !defined(WITH_OPENSSL_PORT)
tengine/Makefile:WITH_OPENSSL_PORT= yes
tomcat-native/Makefile:WITH_OPENSSL_PORT=   yes

I'm sure there are dozens of others.

Forcing users who want to use this port to use OpenSSL from ports for 
ALL ports is overkill.


Think about official packages. Are ALL packages built against OpenSSL 
from ports, or only those that need them? It's the latter, of course. 
Are they incompatible in production? No.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

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

Re: Committer needed for PR 208029

[Mathieu Arnold]

+--On 6 avril 2016 07:33:50 +0200 Michelle Sullivan 
wrote:
| Kurt Jaeger wrote:
|> Hi!
|> 
|>> Actually, I just noticed (when compiling the port), that the Makefile
|>> now says:
|>> 
|>> WITH_OPENSSL_PORT=yes
|> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
|> now as IGNORE with a message explaining how to do it for 9.x.
|> 
| Not sure about the IGNORE vs BROKEN but looks a *lot* better now. Would
| be interested as to an explanation of why the distinction between the
| two... especially as the port is 'broken' if you try and compile it
| against the wrong version of SSL...  Mathieu?

I'm sorry, I don't understand what you are asking.

-- 
Mathieu Arnold

pgpGkL3SlHb9m.pgp
Description: PGP signature

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
audio/qjackctl  | 0.4.1   | 0.4.2
+-+
audio/qsampler  | 0.3.1   | 0.4.0
+-+
deskutils/recoll| 1.21.5  | 1.21.6
+-+
textproc/elasticsearch-plugin-marvel| 1.3.1   | 2.3.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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