Re: textproc/kibana50 and version of node.js
Tom Judge wrote on 2017/03/30 18:43: On Mar 30, 2017, at 11:27 AM, Miroslav Lachman <000.f...@quip.cz> wrote: Bradley T. Hughes wrote on 2017/03/30 11:10: On 30 Mar 2017, at 10:00, Miroslav Lachman <000.f...@quip.cz> wrote: Hi, Hi! :) we are using npm + node in version 7.8.0 and ElasticSearch in version 5.0.2. Now we need Kibana and Kibana X-Pack but official Kibana has bundled node v0.10 or v0.12, FreeBSD port of Kibana has dependency on node v4. It is conflicting with already installed and used node v7. This mail caught my eye. Since Node.js v0.10 and v0.12 have reached end-of-life, I wanted to see if I could find out why they were bundling such an old version. Looking at Github, it actually looks like Kibana is bundled with Node.js v6.9.5: https://github.com/elastic/kibana/blob/v5.3.0/package.json#L243-L246 I am sorry, it was my fault. It was information for older version of Kibana (4.4.1, 4.3.2, 4.1.5) https://discuss.elastic.co/t/kibana-4-4-1-4-3-2-4-1-5-updated-node-js-versions-due-to-upstream-vulnerabilities/41643 I created Kibana 5.0.2 package with poudriere with modified Makefile to: RUN_DEPENDS=node>=0.8.0:www/node Kibana is up and running with Node.js 7.8. I hope it will be stable :) Miroslav Lachman Please open a bug with this information and I will include it in the port with the next update to 5.3. Done. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218250 Please also look at X-Pack problem - it is installed in to wrong directory and Kibana ignores it. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216848 Thank you for your work on Kibana and ElasticSearch! Miroslav Lachman ___ 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: Recent devel/libclc update breaking graphics/dri - it seems
Hi, yip - that did it. Thanks On Fri, 31 Mar 2017, Walter Schwarzenfeld wrote: Try Makefile: +MESA_LLVM_VER= 39 ___ 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Recent devel/libclc update breaking graphics/dri - it seems
Now it is the question, why it happens on your system. MAKE_LLVM_VER= 39 is explicit set in the masterport (lib/libGL) and compiles with llvm39 without problems on my system (10.3amd64). For the problem with llvm40 (I don't know if it is really relevant in the moment cause of MAKE_LLVM_VER) I opened a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218251 ___ 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: Recent devel/libclc update breaking graphics/dri - it seems
typo: should be graphics/libGL. ___ 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: Recent devel/libclc update breaking graphics/dri - it seems
Hi, I guess it was the way I updated. First updating libclc, it pulled llvm40 in. Then I thought - ok, so llvm40 is the game now - removing llvm39 and doing a: "portmaster -o devel/llvm40 llvm39". Afterwards graphics/dri failed updating. I rolled back to the snapshot before these tasks were executed, then running a simple "portmaster -a" and things went through. Guess by "pressing" in llvm40 as replacement for llvm39 things started to go very wrong. Kind regards On Fri, 31 Mar 2017, Walter Schwarzenfeld wrote: Now it is the question, why it happens on your system. MAKE_LLVM_VER= 39 is explicit set in the masterport (lib/libGL) and compiles with llvm39 without problems on my system (10.3amd64). For the problem with llvm40 (I don't know if it is really relevant in the moment cause of MAKE_LLVM_VER) I opened a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218251 ___ 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@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 +-+ devel/libtermkey| 0.19| 0.20 +-+ www/uwsgi | 2.0.14 | 2.0.15 +-+ 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: Recent devel/libclc update breaking graphics/dri - it seems
On Fri, 2017-03-31 at 11:22 +0200, Walter Schwarzenfeld wrote: > Now it is the question, why it happens on your system. MAKE_LLVM_VER= > 39 > is explicit set in the masterport (lib/libGL) and compiles with > llvm39 > > without problems on my system (10.3amd64). > > For the problem with llvm40 (I don't know if it is really relevant > in > the moment cause of MAKE_LLVM_VER) I opened a PR: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218251 > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.o > rg" I was also surpride why my xserver doesn't start and I saw that is llvm37 installed again.. Why? I don't know. My system is FreeBSD 11- release (amd64) and I am using Synth. ___ 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"
databases/mariadb101-client upgraded in wrong order, resulted in missing files
I don't know if it was "pkg" fault or mariadb101-server and mariadb101-client conflict. I did standard "pkg upgrade" and at the end I have half files of mariadb101-client missing: # pkg check -Ba Checking all packages: ... pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or directory pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file or directory pkg: fstat() failed for(/usr/local/bin/mysqlaccess): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/big_endian.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/byte_order_generic.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/byte_order_generic_x86.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/byte_order_generic_x86_64.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/client_plugin.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/decimal.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/errmsg.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/handler_ername.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/handler_state.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/keycache.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/little_endian.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/m_ctype.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/ma_dyncol.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_alloc.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_attribute.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_byteorder.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_compiler.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_dbug.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_dir.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_getopt.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_list.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_net.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_pthread.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/my_xml.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/mysql_com.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/mysql_com_server.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/mysql_embed.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/mysql_time.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/mysqld_ername.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/mysqld_error.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/plugin_audit.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/plugin_auth_common.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/plugin_encryption.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/plugin_ftparser.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/plugin_password_validation.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_idle.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_socket.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_stage.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_statement.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_table.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_thread.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_debug_sync.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_encryption.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_encryption_scheme.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_kill_statement.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_md5.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_my_snprintf.h): No such file or directory pkg: fstat() failed for(/usr/local/include/mysql/service_sha1.h): No such file or direct
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 2017-Mar-30, at 7:51 PM, Mark Millard wrote:
> On 2017-Mar-30, at 1:22 PM, Mark Millard wrote:
>
>> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique
>> would not change the "WITNESS and INVARIANTS"-like part of the
>> issue. In fact if WITH_DEBUG= causes the cmake debug-style
>> llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not
>> make any difference: separate enforcing of lack of optimization.
>>
>> But just to see what results I've done "pkg delete llvm40"
>> and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
>> and its supporting code in place in addition to using WITH_DEBUG=
>> as the type of build fro FreeBSD's viewpoint.
>>
>> If you know that the test is a waste of machine cycles, you can
>> let me know if you want.
>
> The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG
> use made no difference for devel/llvm40 so devel/llvm40 itself
> has to change such as what Dimitry Andric reported separately
> as a working change to the Makefile .
>
> (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses
> for various other ports.)
I've now tried with both ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG and:
# svnlite diff /usr/ports/devel/llvm40/
Index: /usr/ports/devel/llvm40/Makefile
===
--- /usr/ports/devel/llvm40/Makefile(revision 436747)
+++ /usr/ports/devel/llvm40/Makefile(working copy)
@@ -236,6 +236,11 @@
.include
+.if defined(WITH_DEBUG)
+CMAKE_BUILD_TYPE= RelWithDebInfo
+STRIP=
+.endif
+
_CRTLIBDIR=
${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd
.if ${ARCH} == "amd64"
_COMPILER_RT_LIBS= \
pkg delete after the build reports:
Installed packages to be REMOVED:
llvm40-4.0.0
Number of packages to be removed: 1
The operation will free 42 GiB.
So down by 7 GiBytes from 49 GiBytes.
(I did not actually delete it.)
Also:
# du -sg /usr/obj/portswork/usr/ports/devel/llvm40
102 /usr/obj/portswork/usr/ports/devel/llvm40
which is down by 16 GiBytes from 118 GiBytes.
Reminder: These are from portmaster -DK so no
cleanup after the build, which is what leaves
the source code and such around in case of
needing to look at a problem.
(102+42) GiBytes == 146 GiBytes.
vs.
(118+49) GiBytes == 167 GiBytes.
So a difference of 21 GiBytes (or so).
But that is for everything in each case (and
WITH_DEBUG= in use):
# more /var/db/ports/devel_llvm40/options
# This file is auto-generated by 'make config'.
# Options for llvm40-4.0.0.r4
_OPTIONS_READ=llvm40-4.0.0.r4
_FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
OPTIONS_FILE_SET+=CLANG
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXTRAS
OPTIONS_FILE_SET+=LIT
OPTIONS_FILE_SET+=LLD
OPTIONS_FILE_SET+=LLDB
So avoiding WITH_DEBUG= and/or various build options
is still the major way of avoiding use of lots of space
if it is an issue.
Why no RAM+SWAP total report this time:
As far as I know FreeBSD does not track or report peak
swap-space usage since the last boot. And, unfortunately
I was not around to just sit and watch a top display this
time and I did not set up any periodic recording into a
file.
That is why I've not reported on the RAM+SWAP total
this time. It will have to be another experiment
some other time.
[I do wish FreeBSD had a way of reporting peak swap-space
usage.]
===
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"
