Re: gnu screen incompatibility?
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: [HEADSUP] change in default openssl coming
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: Torch7 ports (Was: Wxlua / Zbstudio)
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"
FreeBSD ports you maintain which are out of date
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: [HEADSUP] change in default openssl coming
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"
Re: [HEADSUP] change in default openssl coming
> 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
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
FreeBSD Port: lang/maude
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: FreeBSD Port: lang/maude
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"
Re: FreeBSD Port: lang/maude
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: gnu screen incompatibility?
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"
base components should always be default (Re: change in default openssl coming)
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"
php56-pgsql dependency
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"
phppgadmin dependency
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"
Re: php56-pgsql dependency
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
Re: Wxlua / Zbstudio
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: base components should always be default (Re: change in default openssl coming)
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: base components should always be default (Re: change in default openssl coming)
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: [HEADSUP] change in default openssl coming
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"
