Re: [HEADSUP] change in default openssl coming

[olli hauer]

On 2016-07-08 08:26, Mathieu Arnold wrote:
> Hi,
> 
> During this summer (sometime in August I think) I will be changing the
> default OpenSSL for the ports tree from the base system version to
> security/openssl.
> 
> I will also, because it goes with it, change the default GSSAPI from base
> to something else, I think the consensus was to use the MIT version, which
> is security/krb5.
> 
> Before I do that, it would be nice if people who actually use Kerberos (so,
> that's the two of you at the back) could provide some feedback if it
> changing this will break things.
> 

Looking at the next release of openssl (1.1.x) and the deprecation of 
SSL2/SSL3/MD2 I want to throw in the following question.
Are there any plans to adjust the default OPTIONS for security/openssl before / 
during the phase it will become the default for ports?

It would be a good time to adjust the OPTIONS because the next release don't 
support them any longer

___
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: base components should always be default (Re: change in default openssl coming)

[Kevin Oberman]

On Fri, Jul 8, 2016 at 12:20 PM, Grzegorz Junka  wrote:

>
> On 08/07/2016 16:29, Mikhail T. wrote:
>
>> On 08.07.2016 02:26, Mathieu Arnold wrote:
>>
>>> During this summer (sometime in August I think) I will be changing the
>>> default OpenSSL for the ports tree from the base system version to
>>> security/openssl.
>>>
>> The short answer is "Why?!" The longer reaction is: "please don't".
>>
>> Certainly not without a lengthy and exhaustive discussion (or flame-war,
>> if you will), which shall arrive at a consensus -- and, if it does not,
>> then no change shall happen.
>>
>> Generally, we should be eating our own dog-food -- using base-provided
>> components for everything by default where at all possible. If the base
>> OpenSSL is in some way(s) deficient, well, that's an argument for
>> updating the base. The base comes with not just the libraries, but withe
>> accompanying header-files -- meaning, the developers are free to use
>> those libraries. So the ports certainly should be doing just that.
>>
>> Our ports and the packages derived from them are part of FreeBSD -- and
>> the various components need to remain tightly integrated.
>>
>> Yes, I understand, you intend for there to remain an option, which the
>> holdouts like myself will be able to use to retain the old behavior. But
>> that's not good enough -- if the default packages will be built
>> differently, then bitrot will creep in and building against the base
>> will slowly become more and more difficult.
>>
>> I will also, because it goes with it, change the default GSSAPI from base
>>> to something else,
>>>
>> Sorry, what goes with what? Are you saying, Heimdal can't be built with
>> port's OpenSSL or vice versa?
>>
>>  -mi
>>
>>
>>
> The only reason I heard why base isn't updated with the proper package
> from ports is because of security implications. Older versions are more
> security-tested and therefore safer. If there is a vulnerability in the
> base it's much more hassle to update the base than ports.
>
> I don't have my opinion and sometimes it's annoying to not be able to use
> the base version, but putting everything into base is certainly an option
> if only the process of updating the base was light and quick enough. Is it
> like that now? Maybe with the incoming release cycle from FreeBSD-11?


Not really, though it is an issue. The issue with OpenSSL (and other
contributed code that is also part of ports) is that that the base is
limited to being updated with major releases if ABI changes are involved.
This keeps base well behind the current release and ports often require the
newer version in ports. It also means Building some ports with the base
system and some with the ports version leads to a chaotic situation where
one library is linked to the port shareable and another to the base one.
Then another port links to both of those libraries and that makes it
non-runnable as rtld won't load an image if it requires two different
versions of  shareable. Very awkward to clean up this mess. I know, having
had to do so a couple of times.
--
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"

Re: base components should always be default (Re: change in default openssl coming)

[Grzegorz Junka]

On 08/07/2016 16:29, Mikhail T. wrote:

On 08.07.2016 02:26, Mathieu Arnold wrote:

During this summer (sometime in August I think) I will be changing the default 
OpenSSL for the ports tree from the base system version to security/openssl.

The short answer is "Why?!" The longer reaction is: "please don't".

Certainly not without a lengthy and exhaustive discussion (or flame-war,
if you will), which shall arrive at a consensus -- and, if it does not,
then no change shall happen.

Generally, we should be eating our own dog-food -- using base-provided
components for everything by default where at all possible. If the base
OpenSSL is in some way(s) deficient, well, that's an argument for
updating the base. The base comes with not just the libraries, but withe
accompanying header-files -- meaning, the developers are free to use
those libraries. So the ports certainly should be doing just that.

Our ports and the packages derived from them are part of FreeBSD -- and
the various components need to remain tightly integrated.

Yes, I understand, you intend for there to remain an option, which the
holdouts like myself will be able to use to retain the old behavior. But
that's not good enough -- if the default packages will be built
differently, then bitrot will creep in and building against the base
will slowly become more and more difficult.


I will also, because it goes with it, change the default GSSAPI from base to 
something else,

Sorry, what goes with what? Are you saying, Heimdal can't be built with
port's OpenSSL or vice versa?

 -mi




The only reason I heard why base isn't updated with the proper package 
from ports is because of security implications. Older versions are more 
security-tested and therefore safer. If there is a vulnerability in the 
base it's much more hassle to update the base than ports.


I don't have my opinion and sometimes it's annoying to not be able to 
use the base version, but putting everything into base is certainly an 
option if only the process of updating the base was light and quick 
enough. Is it like that now? Maybe with the incoming release cycle from 
FreeBSD-11?


Grzegorz
___
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: Wxlua / Zbstudio

[Raymond Cheung]

Hi Torsten,

This is also my first time to use cmake. My guess is to use these variables
to set path.
CMAKE_LIBRARY_PATH
CMAKE_INCLUDE_PATH

Alternatively, you can try to use gcc, instead of clang.

According to my experience on torch7, clang (I tested with versions: 3.4,
3.8 and 3.9) doesn't work properly to find Open BLAS. I have to switch to
gcc with these lines:
export LD_LIBRARY_PATH=/usr/local/lib/gcc48:$LD_LIBRARY_PATH
export CC=gcc
export CXX=g++

Blas, lapack and cpow can be used in th with gcc. All torch.test() and
nn.test() are passed.

I tested to compile torch distro with luajit, lua51, lua52 and lua53 on
FreeBSD 11.0. However, only luajit are working properly.

Maybe you try luajit with wxlua.

I'm also trying to build zbstudio/wxlua from the source. I'll post the
results afterwards.

Thanks for your help.

Raymond
On Jul 7, 2016 23:51, "Torsten Zuehlsdorff" 
wrote:

> Hello Raymond,
>
> I'm a developer of Lua/torch. Currently, I use Ubuntu to write my codes.
>> However, Ubuntu has frequent updates and make my environment unstable.
>>
>> I tried to install Ghost BSD and compile wxlua and zbstudio but both
>> failed. Do you have any plan to port these two to FreeBSD?
>>
>
> I started some work on an wxlua port. I got some small progress, but i'm
> hacking at this error:
>
> [  7%] Building CXX object
> modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxstc_bind.cpp.o
> In file included from
> /usr/ports/x11-toolkits/wxlua/work/wxLua-2.8.12.3-src/modules/wxbind/src/wxgl_bind.cpp:19:
> In file included from
> /usr/ports/x11-toolkits/wxlua/work/wxLua-2.8.12.3-src/modules/wxbind/include/wxgl_bind.h:47:
> In file included from /usr/local/include/wx-3.0/wx/glcanvas.h:192:
> In file included from /usr/local/include/wx-3.0/wx/gtk/glcanvas.h:14:
> /usr/local/include/wx-3.0/wx/unix/glx11.h:13:10: fatal error: 'GL/glx.h'
> file not found
> #include 
>
>
> Since i never wrote cmake ports before, i do not know how to tell cmake,
> that the file is there:
>
> $ ls -lah /usr/local/include/GL/glx.h
> -rw-r--r--  1 root  wheel14K  3 Jun 16:18 /usr/local/include/GL/glx.h
>
> Any idea?
>
> Until now i can say i just works with lua 5.1. 5.2 fails because of
> missing compat-mode. 5.3 is untested.
>
> Makefile of port looks currently like this:
>
> === Start ===
>
> PORTNAME=   wxlua
> PORTVERSION=2.8.12.3
> CATEGORIES= x11-toolkits
> MASTER_SITES=   SF/${PORTNAME}/${PORTNAME}/${PORTVERSION}
> DISTNAME= wxLua-${PORTVERSION}-src
>
> MAINTAINER= t...@freebsd.org
> COMMENT=Follows later
>
> RUN_DEPENDS=wxgtk30:x11-toolkits/wxgtk30
>
> CMAKE_ARGS=
>  -DwxWidgets_CONFIG_EXECUTABLE=/usr/local/bin/wxgtk2u-3.0-config
> CMAKE_ARGS+=-DwxLua_LUA_INCLUDE_DIR=${LUA_INCDIR}
> CMAKE_ARGS+=-DwxLua_LUA_LIBRARY=${LUA_LIBDIR}
> CMAKE_ARGS+=-DwxLua_LUA_LIBRARY_USE_BUILTIN=FALSE
>
> CMAKE_BUILD_TYPE=   Release
>
> USES=   cmake:outsource lua:51
>
> .include 
>
> .include 
>
> === End ===
>
> Greetings,
> Torsten
>
___
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: php56-pgsql dependency

[Matthew Seaman]

On 07/08/16 17:41, Paul Pathiakis wrote:
> This seems to (also) depend on postgresql93-client.  Could this be
> bumped to postgresql94-client?
> 

postgresql-9.3.x is the default version of postgresql in the ports at
the moment.  If you build your own packages it's pretty simple to change
to a newer version: something like

DEFAULT_VERSIONS+= pgsql=94

in make.conf will do the trick.

However, so long as you aren't trying to install postgresql94-server on
the same machine, there really isn't a huge amount of difference between
any of the postgresqlXX-client packages.  If you do need an instance of
postgresql94-server on the same hardware that's tricker.  Probably the
best bet at the moment is imaginative use of jails to separate your
web-tier from your database tier.  It's not just easier to manage the
dependencies, but it makes good security sense too.

Having said that, I'd be happy to see the default version of Postgresql
bumped up to 95 nowadays.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

phppgadmin dependency

[Paul Pathiakis]

Hi,

The package seems to rely on postgresql93-client.  Could this be bumped 
to postgresql94-client?


Thank you,

P.

___
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"

php56-pgsql dependency

[Paul Pathiakis]

Hi,

This seems to (also) depend on postgresql93-client.  Could this be 
bumped to postgresql94-client?



Much appreciated!

Thank you,

P.

___
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"

base components should always be default (Re: change in default openssl coming)

[Mikhail T.]

On 08.07.2016 02:26, Mathieu Arnold wrote:
> During this summer (sometime in August I think) I will be changing the 
> default OpenSSL for the ports tree from the base system version to 
> security/openssl.
The short answer is "Why?!" The longer reaction is: "please don't".

Certainly not without a lengthy and exhaustive discussion (or flame-war,
if you will), which shall arrive at a consensus -- and, if it does not,
then no change shall happen.

Generally, we should be eating our own dog-food -- using base-provided
components for everything by default where at all possible. If the base
OpenSSL is in some way(s) deficient, well, that's an argument for
updating the base. The base comes with not just the libraries, but withe
accompanying header-files -- meaning, the developers are free to use
those libraries. So the ports certainly should be doing just that.

Our ports and the packages derived from them are part of FreeBSD -- and
the various components need to remain tightly integrated.

Yes, I understand, you intend for there to remain an option, which the
holdouts like myself will be able to use to retain the old behavior. But
that's not good enough -- if the default packages will be built
differently, then bitrot will creep in and building against the base
will slowly become more and more difficult.

> I will also, because it goes with it, change the default GSSAPI from base to 
> something else,
Sorry, what goes with what? Are you saying, Heimdal can't be built with
port's OpenSSL or vice versa?

-mi


___
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: gnu screen incompatibility?

[Cy Schubert]

In message <1b91ff12-f4b3-bff8-be2c-58ef378f3...@freebsd.org>, Andriy Gapon 
wri
tes:
> On 08/07/2016 09:50, Greg Rivers wrote:
> > On Friday, July 08, 2016 09:43:17 Andriy Gapon wrote:
> >> It seems that screen 4.4.0_1 can not connect to sessions started with
> >> the previous version 4.3.x.  At least that was the case for me.
> >>
> > I noticed that too, but:
> > 
> > $ pkg info -D screen
> > screen-4.4.0_1:
> > Always:
> > =
> > 
> > As of GNU Screen 4.4.0:
> > 
> > Note that there was fix to screen message structure field
> > responsible for $TERM handling, making it impossible
> > to attach to older versions.
> > 
> > =
> 
> Oh, I overlooked this...
> I checked UPDATING and there was nothing related in it.  It would be
> nice to get this kind of a message before a package is actually
> upgraded, not after, as happens with pkg.

I just added an UPDATING entry as well, though that doesn't help pkg users. 
Producing a message before the package installs would be better. Is there a 
way to produce pkg-message before install without too many gymnasitics?


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: FreeBSD Port: lang/maude

[Eduardo Morras via freebsd-ports]

On Fri, 8 Jul 2016 13:08:33 +0200
Kurt Jaeger  wrote:

> Hello,
> 
> > Hello, I'm not on the list, reply me directly. Note I'm not a
> > Maude user/developer.
> > 
> > Current source:
> > 
> > http://maude.cs.illinois.edu/w/images/2/2d/Maude-2.7.tar.gz
> > 
> > Homepage:
> > 
> > http://maude.cs.illinois.edu/
> 
> Please look at 
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210018
> 
> where an upgrade is discussed and it looks like providing a patch
> is non-trivial.

Opps, sorry for the noise and thanks for pointing I must check bugzilla before 
mailing about ports status.

> -- 
> p...@opsec.eu+49 171 3101372 4
> years to go !


---   ---
Eduardo Morras 
___
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: FreeBSD Port: lang/maude

[Kurt Jaeger]

Hello,

> Hello, I'm not on the list, reply me directly. Note I'm not a
> Maude user/developer.
> 
> Current source:
> 
> http://maude.cs.illinois.edu/w/images/2/2d/Maude-2.7.tar.gz
> 
> Homepage:
> 
> http://maude.cs.illinois.edu/

Please look at 

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

where an upgrade is discussed and it looks like providing a patch
is non-trivial.

-- 
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"

FreeBSD Port: lang/maude

[Eduardo Morras via freebsd-ports]

Hello, I'm not on the list, reply me directly. Note I'm not a Maude 
user/developer.

Current source:

http://maude.cs.illinois.edu/w/images/2/2d/Maude-2.7.tar.gz

Homepage:

http://maude.cs.illinois.edu/

---   ---
Eduardo Morras 
___
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: [HEADSUP] change in default openssl coming

[Matthew Seaman]

On 07/08/16 10:45, Mark Millard wrote:
> Mathieu Arnold mat at FreeBSD.org wrote on Fri Jul 8 06:26:33 UTC 2016:
> 
>> > I will be changing the
>> > default OpenSSL for the ports tree from the base system version to
>> > security/openssl.
> 
> This could be odd for something like ports-mgmt/pkg if it currently
> uses the base system version: needing to have had already built
> security/openssl in order to build/use pkg.
> 
> pkg tends to depend on the base system or have its own copies of
> things so that it is largely self contained --at lest that is my
> general understanding.
> 
> I'm only using ports-mgmt/pkg as an illustration of an idea: I might
> be wrong about it using openssl for example. There might be other
> things besides ports-mgmt/pkg that might have such a relationship to
> the base system, sort of a bootstrapping issue.
> 
> I'll note that I sometimes use powerpc and/or powerpc64 where
> source-based builds are required: no binary distributions are
> generally available for ports for them.

Yes -- that is a problem with pkg(8).  We don't want pkg(8) to have any
dependencies on other packages (outside of the base system), as that
complicates bootstrapping.  So there are three possible solutions here:

   * Use a statically linked version of pkg(8).  This is already done
 for bootstrapping pkg itself, but it's not favoured in general as
 static linkage prevents some of the other pkg functionality
 working.

   * Move pkg into the base system.  This is probably going to happen
 eventually, but the reasons for keeping pkg(8) separate are still
 valid: if pkg(8) development is tied to the OS release cycle, and
 consequently there are numerous different versions in use, it's
 going to slow down development, make supporting all the different
 OS release versions with binary packages much harder and make it
 much more difficult to push out bug fixes to pkg(8) specifically.

   * Make an exception for pkg(8) and allow it to continue using SSL
 libraries from the base system.

   * Import some sort of SSL library directly into the pkg(8) sources,
 in the same way that pkg(8) already pulls in libfetch and sqlite3.

One of the last two is going to be the solution for the foreseeable
future, with the 'move pkg(8) into base' solution being a much longer
term goal, once the pace of development on pkg(8) has stabilized.

Pkg(8) really is an exception here though.  Once pkg(8) is in place,
then *any* *other* package can be handled with whatever arbitrarily
complicated dependency tree is required.  It's already possible to
compile your own ports against the ports version of openssl or even to
use libressl instead.  Works like a charm, and switching between any of
these scenarios is something that  pkg(8) already handles gracefully for
you. (I speak from experience.) The only concern is people being too
timid to update everything that needs this treatment at once -- in which
case there are some unusual scenarios in which you could get two
different copies of openssl shlibs dynamically loaded into one program
image, and that generally results in instant program abort and core
dump.  The Kerberos libs Mat mentioned are simply the most prominent
example of that sort of thing in the ports at the moment.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: [HEADSUP] change in default openssl coming

[Franco Fichtner]

> On 08 Jul 2016, at 11:45 AM, Mark Millard  wrote:
> 
> Mathieu Arnold mat at FreeBSD.org wrote on Fri Jul 8 06:26:33 UTC 2016:
> 
>> I will be changing the
>> default OpenSSL for the ports tree from the base system version to
>> security/openssl.
> 
> 
> This could be odd for something like ports-mgmt/pkg if it currently uses the 
> base system version: needing to have had already built security/openssl in 
> order to build/use pkg.

This needs to be built against base if it doesn't want to bundle the
library.  On a slightly related note, bapt@ added that pkg(8) doesn't
necessarily need OpenSSL, but the implementation of required algorithms
are faster than available alternatives.  And it's just that OpenSSL
is such a large project that bundling makes it difficult.

A large portion of work in early 2015 focused on making OpenSSL ports
build dependencies reliable, because LibreSSL from ports wasn't really
working as many ports supposedly using OpenSSL from ports were using
OpenSSL from base.  Things have changed considerably in 1.5 years.

I think the main motivation here is: fixing security issues faster
and depending less on base where possible to allow major upgrades to
take place of said SSL libraries.

The other one was that base OpenSSL should be more private, for that
same reason or another.

As another example of how this might be useful: HardenedBSD can build
LibreSSL base, but for people still needing OpenSSL in order not to
jeopardise their job security the default of using the ports version
would be the way to go.

On OPNsense, we even build parallel tracks for OpenSSL and LibreSSL
from ports and it's therefore possible to migrate from one track to
the other as pkg(8) thinks it's upgrading to a new version where shared
library dependencies changed.  ;)

I think what's bad now is that the SSL port chosen is exclusive to
the repository due to files installed.  Switching to OpenSSL from
ports will prevent ports that do depend on LibreSSL's shared library
libtls.so from working, because OpenSSL is so deeply tied into today's
software that it will be on almost any default installation.


Cheers,
Franco
___
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: [HEADSUP] change in default openssl coming

[Mark Millard]

Mathieu Arnold mat at FreeBSD.org wrote on Fri Jul 8 06:26:33 UTC 2016:

> I will be changing the
> default OpenSSL for the ports tree from the base system version to
> security/openssl.


This could be odd for something like ports-mgmt/pkg if it currently uses the 
base system version: needing to have had already built security/openssl in 
order to build/use pkg.

pkg tends to depend on the base system or have its own copies of things so that 
it is largely self contained --at lest that is my general understanding.

I'm only using ports-mgmt/pkg as an illustration of an idea: I might be wrong 
about it using openssl for example. There might be other things besides 
ports-mgmt/pkg that might have such a relationship to the base system, sort of 
a bootstrapping issue.

I'll note that I sometimes use powerpc and/or powerpc64 where source-based 
builds are required: no binary distributions are generally available for ports 
for them.

===
Mark Millard
markmi at dsl-only.net

___
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"

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
+-+
math/giacxcas   | 1.2.2-57| 1.2.2-69
+-+


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"

Re: Torch7 ports (Was: Wxlua / Zbstudio)

[Raymond Cheung]

I found the solution by use gcc.

https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-April/001150.html

On install.sh, add
export LD_LIBRARY_PATH=/usr/local/lib/gcc48:$LD_LIBRARY_PATH
export CC=gcc
export CXX=g++

On trepl-scm-1.rockspec, add
  unix = {
modules = {
   ['readline'] = {
   sources = {'readline.c'},
   libraries = {'readline'},
   incdirs = {"/usr/local/include"},
   libdirs = {"/usr/local/lib"}
}
}
 }


On Sun, Jul 3, 2016 at 2:33 AM, Raymond Cheung 
wrote:

> I'm using FreeBSD 11.0-ALPHA5 to test.
>
> If I use clang/clang++ with the official distro, then nn.test() are passed
> but torch.test() are error/failed.
>
> If I use gcc/g++ for pkg/torch and others with clang/clang++ (and run exec
> '/usr/local/bin/lua51' -e  ...), then two tests (max and min) of
> torch.test() are error/failed:
> max
> error in torch.max (value) - NaNs
> BOOL violation condition=false
>
> min
> error in torch.min - NaNs
> BOOL violation condition=false
>
> But I can't require 'nn':
> install/lib/lua/5.1/ffi.so: Undefined symbol "cpow"
>
>
> On Thu, Jun 30, 2016 at 9:19 AM, Raymond Cheung 
> wrote:
>
>> Hi all,
>>
>> I tried the Jan's git ports. However, I got 21 errors out of 127 torch
>> tests. It said FFI can't point to some structures. Also, I can require nn
>> even it was installed via luarocks. It said the tester suite is missing.
>>
>> Are the blas finding codes located at math/TH? Thanks.
>>
>> Raymond
>> On Jun 24, 2016 17:12, "Raymond Cheung"  wrote:
>>
>>> Hi Jan and Torsten,
>>>
>>> Thanks a lot for your help.
>>>
>>> I will try it later after taking a break. As I lack knowledge on C/C++,
>>> I spent a month to retry many ways on FreeBSD 10/11. I feel tried.
>>> Fortunately, I got some clues.
>>>
>>> During this month, I also learnt a lot on FreeBSD. As least I can build
>>> and install new world/kernel from GhostBSD 10.3 to 11 Alpha 4.
>>>
>>> Thanks again for your help.
>>>
>>> Raymond
>>> On Jun 24, 2016 06:41, "Jan Beich"  wrote:
>>>
 Torsten Zuehlsdorff  writes:

 > Hello Raymond,
 >
 >> OpenBlas (make config; # with OpenMP option), OpenMP, Lapack & ++,
 GotoBlas
 >> are installed. Header files of OpenBlas is also included to
 >> $CMAKE_LIBRARY_PATH. However, I still got the same error message,
 missing
 >> lapack.
 >
 > There are various variables to set to specify where to look vor the
 > libs, like lapack.
 >
 > Sadly i'm out of time. Tomorrow i'm heading into vacation. When back i
 > will come back to your request and try to create a port for
 > this. Maybe we could success together (with more time).

 I did some work in the past on Torch7 ports before losing interest[1].
 Check math/TH if you want to see how it detects OpenBLAS (default).

   $ git clone https://github.com/jbeich/freebsd-ports torch-ports
   $ export PORTSDIR=$PWD/torch-ports
   $ cd $PORTSDIR/devel/lua-trepl
   $ make install
   $ th51

 --
 [1] Many Torch pkgs rely on luarocks to build and resolve dependencies
 and some have a hard dependency on luajit. My approach didn't scale
 as writing such ports often required translating *.rockspec files
 which can quickly grow into maintenance nightmare, so an infra work
 had to be done beforehand.

>>>
>
___
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: [HEADSUP] change in default openssl coming

[Andrea Venturoli]

On 07/08/16 08:26, Mathieu Arnold wrote:

Hi,

During this summer (sometime in August I think) I will be changing the
default OpenSSL for the ports tree from the base system version to
security/openssl.

I will also, because it goes with it, change the default GSSAPI from base
to something else, I think the consensus was to use the MIT version, which
is security/krb5.


Hello.

Could you please elaborate?
Like:
_ why this is done/what problems should it solve?
_ what problems can arise and what is the suggested upgrade procedure 
(or the procedure to still go the old way, if possible)?

_  what will happen to base OpenSSL and Kerberros;
_ is this expected to be done and work on all versions (still thinking 
about 9.3);

_ etc...

Thanks a lot

 bye
av.
___
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: gnu screen incompatibility?

[Andriy Gapon]

On 08/07/2016 09:50, Greg Rivers wrote:
> On Friday, July 08, 2016 09:43:17 Andriy Gapon wrote:
>> It seems that screen 4.4.0_1 can not connect to sessions started with
>> the previous version 4.3.x.  At least that was the case for me.
>>
> I noticed that too, but:
> 
> $ pkg info -D screen
> screen-4.4.0_1:
> Always:
> =
> 
> As of GNU Screen 4.4.0:
> 
> Note that there was fix to screen message structure field
> responsible for $TERM handling, making it impossible
> to attach to older versions.
> 
> =

Oh, I overlooked this...
I checked UPDATING and there was nothing related in it.  It would be
nice to get this kind of a message before a package is actually
upgraded, not after, as happens with pkg.

-- 
Andriy Gapon
___
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: gnu screen incompatibility?

[Greg Rivers]

On Friday, July 08, 2016 09:43:17 Andriy Gapon wrote:
> It seems that screen 4.4.0_1 can not connect to sessions started with
> the previous version 4.3.x.  At least that was the case for me.
> 
I noticed that too, but:

$ pkg info -D screen
screen-4.4.0_1:
Always:
=

As of GNU Screen 4.4.0:

Note that there was fix to screen message structure field
responsible for $TERM handling, making it impossible
to attach to older versions.

=

-- 
Greg
___
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"

gnu screen incompatibility?

[Andriy Gapon]

It seems that screen 4.4.0_1 can not connect to sessions started with
the previous version 4.3.x.  At least that was the case for me.

-- 
Andriy Gapon
___
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"

[HEADSUP] change in default openssl coming

[Mathieu Arnold]

Hi,

During this summer (sometime in August I think) I will be changing the
default OpenSSL for the ports tree from the base system version to
security/openssl.

I will also, because it goes with it, change the default GSSAPI from base
to something else, I think the consensus was to use the MIT version, which
is security/krb5.

Before I do that, it would be nice if people who actually use Kerberos (so,
that's the two of you at the back) could provide some feedback if it
changing this will break things.

-- 
Mathieu Arnold

pgp8SczYhAegk.pgp
Description: PGP signature