gcc5 not building on 11-0-RELEASE

[Fernando Herrero Carrón]

Hi everyone:

I am trying to build lang/gcc5 using Poudriere from ports tree just updated
a couple of hours ago.

The port fails to link with:

/usr/local/bin/ld:
/wrkdirs/usr/ports/lang/gcc5/work/.build/./gcc/liblto_plugin.so: error
loading plugin: Service unavailable

My port options are:

---Begin OPTIONS List---
===> The following configuration options are available for gcc5-5.4.0_2:
 BOOTSTRAP=off: Build using a full bootstrap
 GRAPHITE=on: Support for Graphite loop optimizations
 JAVA=off: Java platform support
===> Use 'make config' to modify these settings
---End OPTIONS List---




Some more info about my system:

>> Building lang/gcc5
build started at Tue May 30 17:59:55 CEST 2017
port directory: /usr/ports/lang/gcc5
building for: FreeBSD jaguar-default-job-01 11.0-RELEASE-p9 FreeBSD
11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
maintained by: ger...@freebsd.org
Makefile ident:  $FreeBSD: head/lang/gcc5/Makefile 441905 2017-05-28
09:31:40Z gerald $
Poudriere version: 3.1.14
Host OSVERSION: 1100122
Jail OSVERSION: 1100122

---Begin Environment---
SHELL=/bin/csh
STATUS=1
OPSYS=FreeBSD
ARCH=amd64
SAVED_TERM=rxvt
MASTERMNT=/usr/local/poudriere/data/.m/jaguar-default/ref
UID=0
FORCE_PACKAGE=yes
PATH=/usr/local/libexec/poudriere:.:/home/elferdo/local/bin:/usr/local/share/spark/bin:/home/elferdo/.cargo/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin
_JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=gcc5-5.4.0_2
OSREL=11.0
_OSRELEASE=11.0-RELEASE-p9
PYTHONBASE=/usr/local
OLDPWD=/
_SMP_CPUS=12
PWD=/usr/local/poudriere/data/.m/jaguar-default/ref/.p/pool
HAVE_COMPAT_IA32_KERN=YES
MASTERNAME=jaguar-default
SCRIPTPREFIX=/usr/local/share/poudriere
_JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.14
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
CONFIGURE_MAX_CMD_LEN=262144
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
_JAVA_OS_LIST_REGEXP=native\|linux
OSVERSION=1100122
---End Environment---



Thanks for your help.

Best,
Fernando
___
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: devel/cargo build failure

[Fernando Herrero Carrón]

El 24 ene. 2017 9:18 p. m., "Mathieu Arnold" <m...@freebsd.org> escribió:

Le 24/01/2017 à 20:27, Fernando Herrero Carrón a écrit :
>
>
> El 24 ene. 2017 6:57 p. m., "Mathieu Arnold" <m...@freebsd.org
> <mailto:m...@freebsd.org>> escribió:
>
> Le 24/01/2017 à 18:47, David Wolfskill a écrit :
> > On Tue, Jan 24, 2017 at 06:33:29PM +0100, Mathieu Arnold wrote:
> >> Le 24/01/2017 à 16:52, Bob Willcox a écrit :
> >>> When trying to build devel/cargo I get this error:
> >>>
> >>> /xports/Mk/Scripts/checksum.sh: cannot open
> 2016-11-02/cargo-nightly-x86_64-unknown-freebsd.tar.gz: No such
> file or directory
> >>> *** Error code 2
> >>>
> >>> Stop.
> >>> make: stopped in /xports/devel/cargo
> >>>
> >>> Anyone have any ideas why and what I can do to overcome it?
> >> Ok, so, the port changed the directory this file is fetched in,
> to fix
> >> the problem, you'll need to remove the
> >> cargo-nightly-x86_64-unknown-freebsd.tar.gz from
> /usr/ports/distfiles
> >> (or whereever your distfiles are)
> >> 
> > Thanks -- that worked for me.
>
> So, I opened PR #216442 to see if the code that made this problem was
> legacy or not, an exp-run will tell :-)
>
> --
> Mathieu Arnold
>
>
> Wow, cool to see more people doing rust on freebsd, count me in!


I have no idea what rust is, but sure.


http://www.freshports.org/devel/cargo:

Cargo is Rust's Package Manager. Cargo downloads your Rust project's
dependencies and compiles your project.
___
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: devel/cargo build failure

[Fernando Herrero Carrón]

El 24 ene. 2017 6:57 p. m., "Mathieu Arnold"  escribió:

Le 24/01/2017 à 18:47, David Wolfskill a écrit :
> On Tue, Jan 24, 2017 at 06:33:29PM +0100, Mathieu Arnold wrote:
>> Le 24/01/2017 à 16:52, Bob Willcox a écrit :
>>> When trying to build devel/cargo I get this error:
>>>
>>> /xports/Mk/Scripts/checksum.sh: cannot open
2016-11-02/cargo-nightly-x86_64-unknown-freebsd.tar.gz: No such file or
directory
>>> *** Error code 2
>>>
>>> Stop.
>>> make: stopped in /xports/devel/cargo
>>>
>>> Anyone have any ideas why and what I can do to overcome it?
>> Ok, so, the port changed the directory this file is fetched in, to fix
>> the problem, you'll need to remove the
>> cargo-nightly-x86_64-unknown-freebsd.tar.gz from /usr/ports/distfiles
>> (or whereever your distfiles are)
>> 
> Thanks -- that worked for me.

So, I opened PR #216442 to see if the code that made this problem was
legacy or not, an exp-run will tell :-)

--
Mathieu Arnold


Wow, cool to see more people doing rust on freebsd, count me in!

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

Ports with origin path different from port name

[Fernando Herrero Carrón]

Hi everyone,

I have lately come across at least two ports whose origin path is different
from the port name, which I found surprising.

One of them is mcmc-jags, which lives in math/jags, the other one is ccid,
which lives in devel/libccid.

Is there any reason for this mismatch?

Best,
Fernando
___
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: inkscape broken on 12-current amd64

[Fernando Herrero Carrón]

2017-01-14 19:00 GMT+01:00 Nilton Jose Rizzo :

>
>   My Box:
>
> root@valfenda:/usr/ports/graphics/inkscape # uname -a
> FreeBSD valfenda 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312006: Fri Jan 13
> 01:24:31 BRST 2017 root@valfenda:/usr/obj/usr/src/sys/VALFENDA  amd64
> root@valfenda:/usr/ports/graphics/inkscape # svnlite info /usr/ports
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: svn://svn.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 431401
> Node Kind: directory
> Schedule: normal
> Last Changed Author: feld
> Last Changed Rev: 431401
> Last Changed Date: 2017-01-13 14:49:59 -0200 (Fri, 13 Jan 2017)
>
>
>   On my box, the Inkscape was broken with this error:
>
>
> /usr/bin/ld/usr/bin/ld::  ccaannotnnot find -lomp
>  find -lomp
>

Hi,

This has been discussed recently for 11 as well:
https://lists.freebsd.org/pipermail/freebsd-ports/2016-December/106313.html

I haven't looked at the issue myself yet, but you might find Kevin's link
helpful.

Cheers,
Fernando
___
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: graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

2016-12-18 21:44 GMT+01:00 Kevin Oberman <rkober...@gmail.com>:

> On Sun, Dec 18, 2016 at 12:22 PM, Fernando Herrero Carrón <
> elfe...@gmail.com> wrote:
>
>> 2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón <elfe...@gmail.com>:
>>
>> >
>> > It looks like inkscape unconditionally asks for compiler:openmp in its
>> > Makefile.
>> >
>>
>> Sorry, I just rechecked and this is not true. Still, it fails in both
>> cases.
>
>
> I reported this issue a long time ago, but it is a problem with incorrect
> linkage when ImageMagick is installed with OpenMP. for an explanation and
> workaround, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194760
> See comment 18 for my analysis and confirmed work around.
>
> Oh, sorry, I must have skipped it. Thanks for the pointer, will read it
carefully.
___
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: graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

2016-12-18 21:22 GMT+01:00 Fernando Herrero Carrón <elfe...@gmail.com>:

>
>
> 2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón <elfe...@gmail.com>:
>
>>
>> It looks like inkscape unconditionally asks for compiler:openmp in its
>> Makefile.
>>
>
> Sorry, I just rechecked and this is not true. Still, it fails in both
> cases.
>
>
I made it build by explicitly adding llvm37/lib to LDFLAGS, and then
stumbled upon this other issue with GraphicsMagick [and openmp] (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194760). This is getting
tough :-(
___
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: graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón <elfe...@gmail.com>:

>
> It looks like inkscape unconditionally asks for compiler:openmp in its
> Makefile.
>

Sorry, I just rechecked and this is not true. Still, it fails in both cases.
___
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"

graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

Hi everyone,

graphics/inkscape is failing to build with openmp otion set, but unchecking
it yields exactly the same result. There is an open PR about this (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208883) but hasn't
receive much attention.

It looks like inkscape unconditionally asks for compiler:openmp in its
Makefile. I know the openmp issue has been brought up several times but, is
there a way to make inkscape compile with it? Otherwise I would remove
openmp support for the time being and at least get it to build.

Cheers,
Fernando
___
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: math/R slave ports and shared library

[Fernando Herrero Carrón]

2016-10-04 4:59 GMT+02:00 Joseph Mingrone :

> After some surgery, math/R is in more manageable shape.  But, the surgery
> broke two slave ports, math/libR and math/libRmath.  They have each been
> marked broken since June or July and I posted to ports@ about deleting
> them, but didn't get a response.
>
>
This is great work indeed. The huge Makefile was a pain to work with,
mainly because of the slave ports, so this is greatly appreciated.


> math/libRmath
> I'm not sure how widely used math/libRmath is today, but it's still
> described in R's main installation document (https://cran.r-project.org/
> doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library).  It
> *should* be straightforward to just incorporate math/libRmath's four files
> into math/R and then delete math/libRmath.  The directory for libRmath is
> under WRKSRC, but it's not included in the main Makefile, so I'd have to
> either patch the main Makefile or do something with post-build and
> post-install.  Is this palatable?
>
> ---
> post-build:
> ${SETENV} ${MAKE_ENV} ${MAKE_CMD} -C ${WRKSRC}/src/nmath/standalone
>
> post-install
> .for f in libRmath.a libRmath.so libRmath.so.${RMATH_SOVERSION}
> ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f}
> ${STAGEDIR}/lib/
> .endfor
> ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h
> ${STAGEDIR}/include/
> ---
>
>
I would be very surprised (though it cannot be excluded) to see C programs
using libRmath. There are some questions on StackOverflow about developing
and distributing libRmath, so this cannot be 100% excluded [2]. The de
facto standard for R/C++ interoperability is Rcpp [1]. I am not sure
whether Rcpp can be built standalone, but it being an R package, I suspect
it needs a full R installation. Its main use is for R to include C++ code,
no the other way around.

All in all, I don't see much use for a standalone libRmath, but it cannot
be excluded. The truth being told, I would expect newer scientific software
coming from python+scipy+numpy rather than from R embedded in C/C++.

math/libR
> Right now, unlike upstream, math/R's shared library option is turned on by
> default.  This was done only in late June because a dependency,
> math/rkward-kde4, required it.  Upstream turns it off, for the reasons
> described in [1].  I'm inclined to remove the libR option from math/R's
> OPTIONS_DEFAULT and resurrect math/libR (or maybe math/R-libR by using
> PKGNAMESUFFIX) as a very simple slave port that just installs math/R with
> that option on.  math/rkward-kde4 could then depend on math/libR.  One
> issue is that, I believe, R's installed packages (packages installed from
> within R) and many of R's dependencies would have to be rebuilt after
> turning off the libR option.
>
>
I have done some little benchmarking myself with and without dynamic libR
and have not seen any noticeable differences in performance (though I have
left it off to be safe), but don't take this as conclusive, more testing
should be done. Packages certainly do need to be rebuilt after switching
from dynamic libR to static. I can't tell what happens the other way
around. Ports-installed packages could be automatically recompiled, but
recompiling user-installed packages is a different story.

I think having two separate installations, whose packages would be mutually
exclusive is too dangerous and too easy for the user to mess up. I can
perform some more extensive benchmarks and see if having it enabled by
default really hurts.

In my opinion, performancewise I would only leave LTO and OPENMP as default
options. Even long double is not guaranteed to provide better precision
than double and it is very possible (per theory and per experience) that it
hinders performance [3].

Kind regards,
Fernando

[1] http://gallery.rcpp.org/articles/r-function-from-c++/
[2]
http://stackoverflow.com/questions/5393257/including-r-standalone-library-in-a-c-source-tree
[3] http://www.cplusplus.com/forum/beginner/34088/#msg183895
___
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: BLAS/LAPACK options in ports

[Fernando Herrero Carrón]

2016-09-29 5:25 GMT+02:00 Maho NAKATA <maho.nak...@gmail.com>:

> Hi Fernando
>
> +1
>
> > I think we should add it. Is a PR necessary?
> Please send me a patch.
>
>
There you go. Thanks!


> Best,
>  Nakata Maho
>
> 2016-09-29 6:47 GMT+09:00 Fernando Herrero Carrón <elfe...@gmail.com>:
>
>> Hi everyone,
>>
>> There are many scientific packages in ports with depend on libraries
>> providing BLAS/LAPACK functionality. There are several implementations
>> available, which mainly exploit multicore CPUs, and the ports
>> infrastructure helps ports handle these dependencies.
>>
>> I would like to suggest a couple of improvements:
>>
>> * Mk/Uses/blaslapack.mk currently offers support for: atlas, gotoblas,
>> netlib and openblas. Mk/bsd.options.desc.mk offers descriptions for all
>> except gotoblas, I think we should add it. Is a PR necessary?
>>
>> * There is a vanilla/single-core implementation: math/blas and
>> math/lapack.
>> I don't know if they are useful any more, but I think blaslapack.mk
>> should
>> also offer these options, for completeness.
>>
>> Comments on this?
>>
>> Best regards,
>> Fernando
>> ___
>> 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"
>>
>
>
>
> --
> -- Nakata Maho http://accc.riken.jp/maho/ , JA OOO
> http://ja.openoffice.org/
> http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/
> maho.pgp.txt
>
--- bsd.options.desc.mk	2016-03-21 13:04:40.0 +0100
+++ bsd.options.desc.mk.new	2016-09-29 16:52:53.003903339 +0200
@@ -127,6 +127,7 @@
 GNUPLOT_DESC?=		Plotting support via gnuplot
 GNUTLS_DESC?=		SSL/TLS support via GnuTLS
 GOPHER_DESC?=		Gopher protocol support
+GOTOBLAS_DESC?=		GotoBLAS2 blas implementation
 GPERFTOOLS_DESC?=	Google gperftools support
 GPHOTO_DESC?=		Digital cameras support via libgphoto2
 GRAPHMAGICK_DESC?=	GraphicsMagick image processing support
___
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"

BLAS/LAPACK options in ports

[Fernando Herrero Carrón]

Hi everyone,

There are many scientific packages in ports with depend on libraries
providing BLAS/LAPACK functionality. There are several implementations
available, which mainly exploit multicore CPUs, and the ports
infrastructure helps ports handle these dependencies.

I would like to suggest a couple of improvements:

* Mk/Uses/blaslapack.mk currently offers support for: atlas, gotoblas,
netlib and openblas. Mk/bsd.options.desc.mk offers descriptions for all
except gotoblas, I think we should add it. Is a PR necessary?

* There is a vanilla/single-core implementation: math/blas and math/lapack.
I don't know if they are useful any more, but I think blaslapack.mk should
also offer these options, for completeness.

Comments on this?

Best regards,
Fernando
___
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: multimedia/mplayer2 ignored on poudriere

[Fernando Herrero Carrón]

2016-09-24 20:15 GMT+02:00 Mathieu Arnold <m...@freebsd.org>:

> Le 24/09/2016 à 16:25, Fernando Herrero Carrón a écrit :
> > Ok, I have finally installed multimedia/mplayer. Let's hope poudriere
> gets
> > this solved soon.
>
> If you remove the "PYTHON_VERSION=3.4" it will work. It is what it was
> telling you. If it was a PR, I would close it as "Works as intended".
>
>
Who was telling me what? I didn't even have PYTHON_VERSION defined in the
first place! Let me quote (
https://lists.freebsd.org/pipermail/freebsd-ports/2016-January/101573.html):

To get python3 ports that install into a system that has py2.7 as
default you need to have

DEFAULT_VERSIONS= python=2.7 python3=3.5
PYTHON_VERSION= python3.5

Notice the "you need to have". I just copied that into my machine-make.conf
(and replaced 3.5 for 3.4) and no, it is not working for me. If it were a
PR, I would appreciate more help and less condescendence.

I will try again without PYTHON_VERSION, I may have skipped some
combination of variables.

Thanks all for helping!

Fernando


> 2016-09-24 13:20 GMT+02:00 Fernando Herrero Carrón <elfe...@gmail.com>:
> >
> >>
> >> 2016-09-23 20:56 GMT+02:00 Fernando Herrero Carrón <elfe...@gmail.com>:
> >>
> >>>
> >>> 2016-09-23 19:55 GMT+02:00 Carlos J. Puga Medina <c...@freebsd.org>:
> >>>
> >>>> Hi Fernando,
> >>>>
> >>>> mplayer2 fails to build on the package builders due to ports
> >>>> infrastructure problems, so an ugly conditional was added in the
> >>>> Makefile to ignore it ATM.
> >>>>
> >>>> ===>   mplayer2-2.0.20130428_22 depends on package:
> /packages/All/py34-
> >>>> docutils-0.12.txz - not found
> >>>>
> >>>> So yes, you'll be able to build mplayer2 via poudriere if you set
> >>>> python3 as
> >>>> DEFAULT_VERSIONS [1]
> >>>>
> >>>> [1] https://wiki.freebsd.org/DEFAULT_VERSIONS
> >>>> [2] https://lists.freebsd.org/pipermail/freebsd-ports/2016-Janua
> >>>> ry/101573.html
> >>>>
> >>>> Kind regards,
> >>>> --
> >>>> Carlos Jacobo Puga Medina <c...@freebsd.org>
> >>>> PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
> >>>>
> >>> Hi Carlos Jacobo,
> >>>
> >>> Thanks for your reply.
> >>>
> >>> So the workaround is to define both DEFAULT_VERSIONS and
> PYTHON_VERSION?
> >>> I will give it a try and see.
> >>>
> >>> Thanks a lot for the links!
> >>>
> >>> Best regards,
> >>> Fernando
> >>>
> >> I changed my poudriere.d/machine-make.conf to:
> >>
> >> DEFAULT_VERSIONS+=ssl=openssl python=2.7 python3=3.4
> >> PYTHON_VERSION=python3.4
> >>
> >> Poudriere has now rebuilt some python packages because of dependency
> >> changes, and lang/llvm37 is refusing to build, with the end result that
> >> mplayer2 is not built either:
> >>
> >> [00:01:17] >> [01][00:00:01] Finished build of devel/llvm37:
> Ignored:
> >> is marked as broken: LLDB does not build with Python 3
> >> [00:01:17] >> [01][00:00:01] Skipping build of net/avahi-app:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of graphics/cairo:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of sysutils/consolekit:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of
> >> devel/gobject-introspection: Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of print/harfbuzz:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of graphics/libEGL:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of multimedia/libass:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of multimedia/mplayer2:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of sysutils/polkit:
> >> Dependent port devel/llvm37 ignored
> >> [00:01:17] >> [01][00:00:01] Skipping build of audio/pulseaudio:
> >> Dependent port devel/llvm37 ignored
> >>
> >> I guess I will have to compile mplayer in my home directory.
> >>
> > ___
> > 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"
>
>
> --
> Mathieu Arnold
>
>
>
___
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: multimedia/mplayer2 ignored on poudriere

[Fernando Herrero Carrón]

Ok, I have finally installed multimedia/mplayer. Let's hope poudriere gets
this solved soon.

2016-09-24 13:20 GMT+02:00 Fernando Herrero Carrón <elfe...@gmail.com>:

>
>
> 2016-09-23 20:56 GMT+02:00 Fernando Herrero Carrón <elfe...@gmail.com>:
>
>>
>>
>> 2016-09-23 19:55 GMT+02:00 Carlos J. Puga Medina <c...@freebsd.org>:
>>
>>> Hi Fernando,
>>>
>>> mplayer2 fails to build on the package builders due to ports
>>> infrastructure problems, so an ugly conditional was added in the
>>> Makefile to ignore it ATM.
>>>
>>> ===>   mplayer2-2.0.20130428_22 depends on package: /packages/All/py34-
>>> docutils-0.12.txz - not found
>>>
>>> So yes, you'll be able to build mplayer2 via poudriere if you set
>>> python3 as
>>> DEFAULT_VERSIONS [1]
>>>
>>> [1] https://wiki.freebsd.org/DEFAULT_VERSIONS
>>> [2] https://lists.freebsd.org/pipermail/freebsd-ports/2016-Janua
>>> ry/101573.html
>>>
>>> Kind regards,
>>> --
>>> Carlos Jacobo Puga Medina <c...@freebsd.org>
>>> PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
>>>
>>
>> Hi Carlos Jacobo,
>>
>> Thanks for your reply.
>>
>> So the workaround is to define both DEFAULT_VERSIONS and PYTHON_VERSION?
>> I will give it a try and see.
>>
>> Thanks a lot for the links!
>>
>> Best regards,
>> Fernando
>>
>
> I changed my poudriere.d/machine-make.conf to:
>
> DEFAULT_VERSIONS+=ssl=openssl python=2.7 python3=3.4
> PYTHON_VERSION=python3.4
>
> Poudriere has now rebuilt some python packages because of dependency
> changes, and lang/llvm37 is refusing to build, with the end result that
> mplayer2 is not built either:
>
> [00:01:17] >> [01][00:00:01] Finished build of devel/llvm37: Ignored:
> is marked as broken: LLDB does not build with Python 3
> [00:01:17] >> [01][00:00:01] Skipping build of net/avahi-app:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of graphics/cairo:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of sysutils/consolekit:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of
> devel/gobject-introspection: Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of print/harfbuzz:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of graphics/libEGL:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of multimedia/libass:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of multimedia/mplayer2:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of sysutils/polkit:
> Dependent port devel/llvm37 ignored
> [00:01:17] >> [01][00:00:01] Skipping build of audio/pulseaudio:
> Dependent port devel/llvm37 ignored
>
> I guess I will have to compile mplayer in my home directory.
>
___
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: multimedia/mplayer2 ignored on poudriere

[Fernando Herrero Carrón]

2016-09-23 20:56 GMT+02:00 Fernando Herrero Carrón <elfe...@gmail.com>:

>
>
> 2016-09-23 19:55 GMT+02:00 Carlos J. Puga Medina <c...@freebsd.org>:
>
>> Hi Fernando,
>>
>> mplayer2 fails to build on the package builders due to ports
>> infrastructure problems, so an ugly conditional was added in the
>> Makefile to ignore it ATM.
>>
>> ===>   mplayer2-2.0.20130428_22 depends on package: /packages/All/py34-
>> docutils-0.12.txz - not found
>>
>> So yes, you'll be able to build mplayer2 via poudriere if you set python3
>> as
>> DEFAULT_VERSIONS [1]
>>
>> [1] https://wiki.freebsd.org/DEFAULT_VERSIONS
>> [2] https://lists.freebsd.org/pipermail/freebsd-ports/2016-Janua
>> ry/101573.html
>>
>> Kind regards,
>> --
>> Carlos Jacobo Puga Medina <c...@freebsd.org>
>> PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
>>
>
> Hi Carlos Jacobo,
>
> Thanks for your reply.
>
> So the workaround is to define both DEFAULT_VERSIONS and PYTHON_VERSION? I
> will give it a try and see.
>
> Thanks a lot for the links!
>
> Best regards,
> Fernando
>

I changed my poudriere.d/machine-make.conf to:

DEFAULT_VERSIONS+=ssl=openssl python=2.7 python3=3.4
PYTHON_VERSION=python3.4

Poudriere has now rebuilt some python packages because of dependency
changes, and lang/llvm37 is refusing to build, with the end result that
mplayer2 is not built either:

[00:01:17] >> [01][00:00:01] Finished build of devel/llvm37: Ignored:
is marked as broken: LLDB does not build with Python 3
[00:01:17] >> [01][00:00:01] Skipping build of net/avahi-app: Dependent
port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of graphics/cairo:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of sysutils/consolekit:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of
devel/gobject-introspection: Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of print/harfbuzz:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of graphics/libEGL:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of multimedia/libass:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of multimedia/mplayer2:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of sysutils/polkit:
Dependent port devel/llvm37 ignored
[00:01:17] >> [01][00:00:01] Skipping build of audio/pulseaudio:
Dependent port devel/llvm37 ignored

I guess I will have to compile mplayer in my home directory.
___
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: multimedia/mplayer2 ignored on poudriere

[Fernando Herrero Carrón]

2016-09-23 19:55 GMT+02:00 Carlos J. Puga Medina :

> Hi Fernando,
>
> mplayer2 fails to build on the package builders due to ports
> infrastructure problems, so an ugly conditional was added in the
> Makefile to ignore it ATM.
>
> ===>   mplayer2-2.0.20130428_22 depends on package: /packages/All/py34-
> docutils-0.12.txz - not found
>
> So yes, you'll be able to build mplayer2 via poudriere if you set python3
> as
> DEFAULT_VERSIONS [1]
>
> [1] https://wiki.freebsd.org/DEFAULT_VERSIONS
> [2] https://lists.freebsd.org/pipermail/freebsd-ports/2016-
> January/101573.html
>
> Kind regards,
> --
> Carlos Jacobo Puga Medina 
> PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
>

Hi Carlos Jacobo,

Thanks for your reply.

So the workaround is to define both DEFAULT_VERSIONS and PYTHON_VERSION? I
will give it a try and see.

Thanks a lot for the links!

Best regards,
Fernando
___
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"

multimedia/mplayer2 ignored on poudriere

[Fernando Herrero Carrón]

Hi everyone,

I am updating my packages using poudriere and multimedia/mplayer2 is being
ignored because my default python version is 2. The port explicitly lists
lang/python3 as a build depend, why do I need to set my default version to
3 then? If I do so, other ports (llvm37 I think it was) won't compile
either.

Thanks.

Best regards,
Fernando
___
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: Firefox 49.0_5,1 crash on startup

[Fernando Herrero Carrón]

2016-09-21 11:41 GMT+02:00 Otacílio de Araújo Ramos Neto <
otacilio.n...@bsd.com.br>:

> Em qua, 21 de set de 2016 05:16, João Neves  escreveu:
>
> > Hi,
> >
> > Upgraded to Firefox 49.0_5,1 from ports on my 10.3 x86_64 installation
> > running on VirtualBox, where a previous version was running OK recently
> and
> > now Firefox immediately fails to start up, no core dump or any other
> > information.
> >
> > I enabled the DEBUG config option to try and get some sort of output,
> but I
> > only get:
> >
> > nsStringStats
> >  => mAllocCount:  8
> >  => mReallocCount:1
> >  => mFreeCount:   1  --  LEAKED 7 !!!
> >  => mShareCount:  4
> >  => mAdoptCount:  0
> >  => mAdoptFreeCount:  0
> >  => Process ID: 10931, Thread ID: 34403848192
> >
> > The only non-standard option I am currently using is DBUS=off.
> >
> > My make.conf is as follows:
> >
> > DEFAULT_VERSIONS+=ssl=libressl
> > DEFAULT_VERSIONS+=linux=c6_64
> >
> > Cheers.
> >
> > --
> > João Neves
> >
>
>
> Hello João
>
> This problem happens with me also. The fix was rebuild
> virtualbox-ose-addtions with OpenGL support enabled. And enable this
> support to OpenGL 3D acceleration in virtual machine configuration also. To
> confirm you can try run glxgears. If it crash the problem is exactly the
> same that I have faced.
>
> []'s
> -Otacilio
>
> >
>

Hi there,

I experienced the same with firefox and darktable. The only obvious
connection between the two is gtk3. Other applications using Tcl/Tk work
fine. I was hoping to investigate it further, but good that someone
mentioned it :-)
___
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: Firefox with no sound

[Fernando Herrero Carrón]

2016-09-17 14:36 GMT+02:00 Elton Luis Grandolpho :

> Hi,
>
> I am using Firefox and Chromium in my computer.
>
> Sound works fine using Chromium(last version), but does not work with
> Firefox(last version) using youtube , for example.
>
> uname -a
> FreeBSD FX6100ASUS 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar
> 25 02:10:02 UTC 2016 
> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> $ ident /usr/ports/www/firefox/Makefile
> /usr/ports/www/firefox/Makefile:
>  $FreeBSD: tags/RELEASE_10_3_0/www/firefox/Makefile 410638 2016-03-08
> 18:19:56Z jbeich $
>
> Could you check, please?
>
> If you have any questions, please let me know
>
> Best regards
>
> Elton Luis Grandolpho
>
>
>
Hi Elton Luis,

If you have compiled firefox with Pulseaudio support you may want to check
PA's settings. From the command line, you can reroute audio with something
like "pactl move-sink-input 3 oss_output.dsp0".  You can inspect clients
using PA with "pactl list". I'm pretty sure there are some graphical
options like gnome-audio-settings or something like that, but I haven't got
them installed.

Otherwise there is a sysctl variable, hw.snd.default_unit, which you may
also want to check. Set it to your desired output before launching firefox
(if you don't have PA support compiled in).

Hope that helps,
Fernando
___
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: Run Dependencies to llvm (for e.g. graphics/libEGL)

[Fernando Herrero Carrón]

It probably makes sense, yes: http://www.mesa3d.org/llvmpipe.html

LLVM is being used in more and more projects to optimize dynamically
generated code, in this case software 3D rendering.

2016-08-31 12:01 GMT+02:00 Matthias Fechner :

> Dear all,
>
>
> I just saw that I have for some installed packages llvm as run
> dependency (e.g. graphics/libEGL) that it has a run dependency to llvm36:
>
> cd /usr/ports
>
> make search name=libEGL
>
> R-deps: damageproto-1.2.1 ... llvm37-3.7.1_3 ...
>
>
> Does this really makes sense or is this a bug in one of the dependencies?
>
>
> Thanks
> Matthias
>
> --
>
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
>
>
> ___
> 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: Considering removal of math/libR and math/libRmath

[Fernando Herrero Carrón]

El 16/7/2016 16:34, "Joseph Mingrone"  escribió:
>
> Hello,
>
> Neither of these ports are depended on by other ports and the option to
include
> libR with math/R is already there (with an option).  Is anyone using
either of
> these ports?  Do you foresee any problems if they are swallowed by math/R?
>
> Joseph

From math/R's perspective it would be nice to see them go away. The
Makefile handling of both is somewhat cumbersome as it stands.

I myself have never felt the need to embed libR in C or C++ and if had to,
I would probably turn to Rcpp.

Upstream R can also be built without base packages, just the basic
environment. Adding such an option to math/R might be a good replacement
for both libR* ports.

Cheers,
Fernando
___
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)

[Fernando Herrero Carrón]

El 9 jul. 2016 3:13 p. m., "Guido Falsi" <m...@madpilot.net> escribió:
>
> On 07/09/16 14:36, Fernando Herrero Carrón wrote:
> > El 9 jul. 2016 10:33 a. m., "Wojciech Puchar" <woj...@puchar.net>
escribió:
> >>
> >>
> >>
> >> On Fri, 8 Jul 2016, 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".
> >>>
> >> Why openssl is a part of base system at all?
> >>
> >
> > Maybe we can also ask: why is pkg not?
>
> This has been answered various times. I can't speak for the maintainers
> of pkg, but an answer to this question was already posted in this same
> thread:
>
> https://lists.freebsd.org/pipermail/freebsd-ports/2016-July/103886.html
>
> (second bullet in the list)
>
> If you look in the mailing list archives you will find more replies on
> the same tome.

Oh, sorry, I just wrote at first thought without googling much. Thanks for
the pointers, though, I will have a look at them.

Best,
Fernando
___
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)

[Fernando Herrero Carrón]

El 9 jul. 2016 10:33 a. m., "Wojciech Puchar"  escribió:
>
>
>
> On Fri, 8 Jul 2016, 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".
>>
> Why openssl is a part of base system at all?
>

Maybe we can also ask: why is pkg not?
___
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: Any way to add USES clause depending on two options without including bsd.port.options.mk?

[Fernando Herrero Carrón]

El 24 jun. 2016 9:36 p. m., "Yuri" <y...@rawbw.com> escribió:
>
> On 06/23/2016 14:54, Fernando Herrero Carrón wrote:
>>
>> Could you please elaborate on the reasons why you want to do that? I
don't
>> see how that particular combination of options would introduce a
dependence
>> that neither of them alone would.
>
>
> In this particular case, as I figured, this isn't actually necessary. But
it could be necessary in general, when, say, only in GUI there are some
messages to translate, or only GUI needs python.
>
>
>> And then, why not include port.options.mk? Then you could explicitly
check
>> for both options being set.
>
>
>
> You are right. But without including port.options.mk Makefile looks so
much more elegant. Several times I received e-mails asking to remove
port.options.mk inclusion to highten the degree of elegance this way. -)

Fair enough! I am not one to argue against elegance ;-) but as Mathieu
said: magic only goes so far!

Good luck!

>
>
> Yuri
>

Fernando
___
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: QA script error (libc++)

[Fernando Herrero Carrón]

El 24 jun. 2016 4:23 p. m., "Fernando Apesteguía" <
fernando.apesteg...@gmail.com> escribió:
>
> On Fri, Jun 24, 2016 at 10:25 AM, Fernando Herrero Carrón
> <elfe...@gmail.com> wrote:
> >
> > El 24 jun. 2016 8:16 a. m., "Fernando Apesteguía"
> > <fernando.apesteg...@gmail.com> escribió:
> >>
> >> One of my ports is written in C++. It links agains libc++ that is in
> >> base (/usr/src/contrib/libc++). The port still builds fine and works
> >> but the QA scripts show an error complaining about the executable
> >> being linked to libc++ without the library being listed as an actual
> >> dependency and it suggests to add the following line to the Makefile:
> >>
> >> LIB_DEPENDS+=libc++.so:devel/libc++
> >>
> >> Is this strictly necessary? Would something like this be acceptable?:
> >>
> >> .if !exists(/usr/lib/libc++.so)
> >> ...
> >> LIB_DEPENDS+=libc++.so:devel/libc++
> >> ...
> >> .endif
> >>
> >> Note: the port does not compile on FreeBSD < 10.x
> >>
> >> Thanks in advance.
> >
> > Dear Fernando,
> >
> > I would say adding a dependency on libc++ from ports is not necessary.
On a
> > standard system you can pass the compiler an option like -stdlib=libc++
and
> > it works.
> >
> > This library is usually linked against when compiling with c++11 or
newer.
> > Maybe adding the appropriate compiler option [1] would be a better
choice?
>
> I forgot to mention I'm already using this:
>
> USES= compiler:gcc-c++11-lib
>
> But the QA script still complains.
>

I myself program in c++, have plenty of c++ ports installed and don't have
devel/libc++ on my system.

Could it be that a previous port does install devel/libc++ for you, and
this one links against it by chance? Do you already have devel/libc++
installed when compiling this port?
___
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: QA script error (libc++)

[Fernando Herrero Carrón]

El 24 jun. 2016 8:16 a. m., "Fernando Apesteguía" <
fernando.apesteg...@gmail.com> escribió:
>
> One of my ports is written in C++. It links agains libc++ that is in
> base (/usr/src/contrib/libc++). The port still builds fine and works
> but the QA scripts show an error complaining about the executable
> being linked to libc++ without the library being listed as an actual
> dependency and it suggests to add the following line to the Makefile:
>
> LIB_DEPENDS+=libc++.so:devel/libc++
>
> Is this strictly necessary? Would something like this be acceptable?:
>
> .if !exists(/usr/lib/libc++.so)
> ...
> LIB_DEPENDS+=libc++.so:devel/libc++
> ...
> .endif
>
> Note: the port does not compile on FreeBSD < 10.x
>
> Thanks in advance.

Dear Fernando,

I would say adding a dependency on libc++ from ports is not necessary. On a
standard system you can pass the compiler an option like -stdlib=libc++ and
it works.

This library is usually linked against when compiling with c++11 or newer.
Maybe adding the appropriate compiler option [1] would be a better choice?

Cheers,
Fernando

[1] https://www.freebsd.org/doc/en/books/porters-handbook/uses-compiler.html
___
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: Any way to add USES clause depending on two options without including bsd.port.options.mk?

[Fernando Herrero Carrón]

El 23 jun. 2016 11:26 p. m., "Yuri"  escribió:
>
> I have two port options: GUI NLS.
>
> I would like to have USES=gettext only when both GUI and NLS are "on".
>
> If it was only one option, say NLS, NLS_USES=gettext would work.
>
> But what about the two options case? Is there any magic to do this
without .include  ?
>
>
> Yuri
>

Hi Yuri,

Could you please elaborate on the reasons why you want to do that? I don't
see how that particular combination of options would introduce a dependence
that neither of them alone would.

And then, why not include port.options.mk? Then you could explicitly check
for both options being set.

Cheers,
Fernando
___
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: x11/rxvt-unicode && 256 colors

[Fernando Herrero Carrón]

2016-06-13 20:44 GMT+02:00 Thierry Thomas :

> Le lun 13 jui 16 à 20:00:57 +0200, Matthias Apitz 
>  écrivait :
>
> > El día Monday, June 13, 2016 a las 07:49:46PM +0200, Thierry Thomas
> escribió:
> >
> > > Le lun 13 jui 16 à 13:56:41 +0200, Matthias Apitz 
> > >  écrivait :
> > >
> > > Could you please try:
> > > $ TERM=rxvt-unicode-256color /usr/local/bin/tput colors
> >
> > $ env | fgrep TERM
> > TERM=rxvt-unicode-256color
> > $ /usr/local/bin/tput colors
> > 256
> > $ tput colors
> > 100
>
> The port x11/rxvt-unicode installs its terminfo under $PREFIX/share/misc
> and /usr/bin/tput does not read it, but tput installed from ports
> (devel/ncurses) does.
>
>
Nice explanation, Thomas. I wonder now what's the use of having rxvt
terminfo in /etc/termcap if it is neither relevant nor acurate.

Cheers,
Fernando
___
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: x11/rxvt-unicode && 256 colors

[Fernando Herrero Carrón]

Hmmm, is that 100 decimal or hexadecimal? 256 == 0x100...

2016-06-13 13:56 GMT+02:00 Matthias Apitz :

>
> Hello,
>
> I'm using x11/rxvt-unicode from head (PORTVERSION 9.21). I can not
> convince urxvt to use (for example in vim) 256 colors; it only says it
> has 100 colors:
>
> $ TERM=rxvt-unicode-256color tput colors
> 100
>
> This wrong info comes perhaps from /etc/termcap or some other place in
> the system. The terminfo file the port installs is not used at all (I
> checked this with truss), not even when the TERINFO env var points to
> it; The terminal itself is able to use 256 colors (there are some perl
> script in the net to check this, and they print fine the full palette).
>
> Any idea how I could fix this?
>
> Thanks
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎
> +49-176-38902045
> "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer
> Gesellschaft bzw.
> sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns.
> ..." (jW 19.05.2016)
> ___
> 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: math/R maintenance

[Fernando Herrero Carrón]

Hi,

I submitted a new patch for math/R 3.3.0 (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207425). Could someone
please take look at it?

Thanks a lot!

2016-05-22 22:31 GMT+02:00 Fernando Herrero Carrón <elfe...@gmail.com>:

>
> El 22 may. 2016 11:59 a. m., "Kurt Jaeger" <li...@opsec.eu> escribió:
> >
> > Hi!
> >
> > > > Ignore that, it was a simple ${PORTSDIR} removal. I'm testing right
> now.
> >
> > > Thanks a lot, Kurt. I am rechecking in any case to see if it still
> works.
> >
> > Turns out, there are quite a few other sleeper PRs for R,
> > for example the one to update to 3.3.0.
> >
> > Can you provide a patch that's working with the state after
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209315
> >
> > Thanks!
> >
>
> I see the port has been updated today, I'll try to get a new patch this
> week.
>
> 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"

math/openblas + poudriere + manual building

[Fernando Herrero Carrón]

Hi everyone,

I am using poudriere for the first time to test some patches to math/R. One
new feature will be the ability to link against math/openblas. My portstree
was updated yesterday (28/05).

math/openblas is one of the de-facto, open source, high performance basic
linear algebra packages (including paralellism, architecture specific code
and so on).

For my purposes right now I only want to build math/openblas (0.2.18,1) for
my computer, so I uncheck the DYNAMIC_ARCH option, which I suppose will
generate code for many architectures. I see there is a closed PR [1]
suggesting that the port would automatically set this option as default if
bulk building. However, since I have manually unset it, poudriere bails out
suggesting that I build the package manually because the port optimizes for
the build machine

Finished build of math/openblas: Ignored: has to be built manually:
Optimizes for the local machine

Here come two questions:

* After searching a bit, I have not found how to *manually* build a package
in poudriere. Does that mean: build the port in your ports tree outside
poudriere? Should that message be reworded? Is there something missing in
the documentation? Am I missing something?

* I see some people are manually editing the Makefile of math/atlas to tune
to their machines [2]. My solution with math/openblas has been to finally
enable DYNAMIC_ARCH, which probably compiles more code than I need to. I am
fairly comfortable with the package optimizing for the build machine. Isn't
there any easy way to force poudriere to go on? Setting NO_IGNORE in the
environment or something like that (which, surprisingly, allows building of
forbidden, but not ignored ports)?

Cheers,
Fernando

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209190
[2]
https://lists.freebsd.org/pipermail/freebsd-ports/2014-December/097102.html
___
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: math/R maintenance

[Fernando Herrero Carrón]

El 22 may. 2016 11:59 a. m., "Kurt Jaeger"  escribió:
>
> Hi!
>
> > > Ignore that, it was a simple ${PORTSDIR} removal. I'm testing right
now.
>
> > Thanks a lot, Kurt. I am rechecking in any case to see if it still
works.
>
> Turns out, there are quite a few other sleeper PRs for R,
> for example the one to update to 3.3.0.
>
> Can you provide a patch that's working with the state after
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209315
>
> Thanks!
>

I see the port has been updated today, I'll try to get a new patch this
week.

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: math/R maintenance

[Fernando Herrero Carrón]

Hi,


2016-05-22 11:40 GMT+02:00 Kurt Jaeger :

> Hi!
>
> > I've tested the patch, it does no longer apply cleanly. Can you
> > update the patch and add it to
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207425
> >
> > Then I can test and commit it, with maintainer timeout 8-}
>
> Ignore that, it was a simple ${PORTSDIR} removal. I'm testing right now.
>
>
Thanks a lot, Kurt. I am rechecking in any case to see if it still works.
___
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"

math/R maintenance

[Fernando Herrero Carrón]

Hi everyone,

Some time ago I submitted a patch [1] to add some optimization related
options to math/R (choose with BLAS library to link against and add LTO,
basically). The PR has not received much attention since then, and the
maintainer hasn't replied to my emails either.

The Makefile of the port seems somewhat outdated as well and could use some
improvements. If the port needs a new maintainer I would volunteer, even
though I have no previous experience. At the very least I could certainly
help putting it into shape and testing it.

Best wishes,
Fernando

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207425
___
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"

editors/emacs-nox11 not compiling with LTO enabled

[Fernando Herrero Carrón]

Hi everyone,

I just upgraded my ports tree with portsnap and am upgrading my
packages. When compiling emacs-nox11-24.5_3,3 with Link Time Optimization
disabled, everything compiles and works fine. If I enable LTO, though, I
get the following error:

*gcc48* -std=gnu99 -Demacs  -I. -I. -I../lib -I./../lib
-I/usr/local/include/libxml2   -MMD -MF *deps/.d* -MP
-I/usr/local/include -I/usr/local/include/p11-kit-1
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
-I/usr/local/include -pthread -O2 -pipe -O2 -fno-strict-aliasing -pipe
-march=core2  -isystem /usr/local/include -fstack-protector
-Wl,-rpath=/usr/local/lib/gcc48 -flto -ffat-lto-objects  -Wl,-znocombreloc
-ltinfo -L/usr/local/lib -Wl,-rpath=/usr/local/lib -fstack-protector
-Wl,-rpath=/usr/local/lib/gcc48 -L/usr/local/lib/gcc48 \
  -o temacs  vm-limit.o dispnew.o frame.o scroll.o xdisp.o menu.o  window.o
charset.o coding.o category.o ccl.o character.o chartab.o bidi.o cm.o
term.o terminal.o xfaces.oemacs.o keyboard.o macros.o keymap.o sysdep.o
buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o cmds.o
casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o
doc.o editfns.o callint.o eval.o floatfns.o fns.o font.o print.o lread.o
syntax.o unexelf.o bytecode.o process.o gnutls.o callproc.o region-cache.o
sound.o atimer.o doprnt.o intervals.o textprop.o composite.o xml.o
gfilenotify.o profiler.o decompress.oxgselect.o  terminfo.o
lastfile.o gmalloc.o ../lib/libgnu.a-lrt  -lexecinfo
-L/usr/local/lib -lxml2 -lutil -lncurses-L/usr/local/lib
-lgnutls   -lpthread  -L/usr/local/lib -lgio-2.0 -lgobject-2.0 -lglib-2.0
-lintl   -lm -lz

*gcc48: error: deps/.d: No such file or directorylto-wrapper:
/usr/local/bin/gcc48 returned 1 exit status*
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:664: recipe for target 'temacs' failed
gmake[3]: *** [temacs] Error 1
gmake[3]: Leaving directory
'/usr/ports/editors/emacs-nox11/work/emacs-24.5/src'
Makefile:387: recipe for target 'src' failed

The directory src/deps exists however:

ports/editors/emacs-nox11% ls work/emacs-24.5/src/deps
alloc.dcasetab.d  coding.d   editfns.d  frame.d
keymap.d   process.d  sysdep.d   window.d
atimer.d   category.d composite.demacs.dgfilenotify.d
lastfile.d profiler.d term.d xdisp.d
bidi.d ccl.d  data.d eval.d gmalloc.d
lread.dregex.dterminal.d xfaces.d
buffer.d   character.ddecompress.d   fileio.d   gnutls.d
macros.d   region-cache.d terminfo.d xgselect.d
bytecode.d charset.d  dired.dfilelock.d indent.d
marker.d   scroll.d   textprop.d xml.d
callint.d  chartab.d  dispnew.d  floatfns.d insdel.d
menu.d search.d   undo.d
callproc.d cm.d   doc.d  fns.d  intervals.d
minibuf.d  sound.dunexelf.d
casefiddle.d   cmds.d doprnt.d   font.d keyboard.d
print.dsyntax.d   vm-limit.d

Any help with this will be greatly appreciated.

Cheers,
Fernando
___
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"

Anyone working on audio/mixxx

[Fernando Herrero Carrón]

Hi,

audio/mixxx (http://www.mixxx.org) has no maintainer. The project has been
frozen on version 1.11 for a long time, but now 2.0.0 is out (actually
december last year). Is anyone working on this port? I would like to help
with upgrading it.

Cheers,
Fernando
___
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: library porting question - optional python bindings

[Fernando Herrero Carrón]

El 1 mar. 2016 3:38 a. m., "Chris Inacio"  escribió:
>
> All,
>
> I'm trying to build a port definition for a library/application that can
> optionally include Python bindings.  The library/application generally
> depends on other C libraries to exist (ZMQ v3, Protobufs-C) and if you
> enable Python support, then you need a Python interpreter plus
> Python-protobufs & python zmq.
>
> Putting an OPTION of Python in the port file is easy.  Including the
> optional Python dependencies (and presumably targets - but I'm not that
far
> yet) seems to be a lot more complicated.  I haven't found anything that
> would tell me how I'm supposed to do that.  I have found that I'm supposed
> to add pyXX prefixes to the python targets.
>
> Does anyone know of a similar application/library that I can go look at?
> Is there any documentation on how to solve this?
>
> thanks,
> Chris Inacio
> ___
> 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"

multimedia/ffmpeg will optionally include ports providing libraries. There
does not seem any implemented in an interpreted language, though I vaguely
remember one option pulling in ruby (probably by transition).

The idea is that you can depend on a specific file and the port that
provides it with the syntax: file_to_depend_on:providing_port.

I hope that helps.

Cheers,
Fernando
___
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: Completely unscientific poll: cfengine, puppet, other?

[Fernando Herrero Carrón]

El 28 feb. 2016 8:11 p. m., "Chris Inacio"  escribió:
>
> Hello all,
>
> I was considering adding some more support into some tooling/ports for
> FreeBSD and I thought it would probably be good to get configuration
> management support some thought.  So I can understand under certain Linux
> flavors (e.g. RedHat) that puppet is the de facto choice - since the
> distribution packager has chosen one.
>
> Is there a dominant one for FreeBSD?
>
> Happy if you would just reply with which one, if any, you use.  If you
want
> to add more to the conversation, that's fine.  I understand the mailing
> list I posted this to and the likely audience - as I said I started think
> about this from adding more support into some ports.
>
> Thanks
> chris inacio
> ___
> 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"

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

Introduction of a new member

[Fernando Herrero Carrón]

Hi everyone,

I have been a FreeBSD user for a long time and decided it is time to give
back. I hope I can start contributing soon.

Thanks for all the great work!

Cheers,
Fernando
___
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"

math/R and slave ports guidelines

[Fernando Herrero Carrón]

Hi all,

I am working on some upgrades to the Makefile of math/R and I have found
that there are two slave ports depending on it: math/libR and
math/libRmath. Now I have some questions about how slave ports should be
handled.

As it stands, the master port will only set some options *if* it is the
master port itself being built and not one of the slaves. For example
(math/R/Makefile:145):

*.if !defined(LIBRMATH_SLAVEPORT)*
.if ${PORT_OPTIONS:MATLAS}
LIB_DEPENDS+=   libatlas.so:${PORTSDIR}/math/atlas
BLAS?=  ${LIBM} -lf77blas
LAPACK?=${LIBM} -lalapack -lcblas
.else
BLAS?=  no
LAPACK?=no
.endif
CONFIGURE_ARGS+=--with-blas="${BLAS}" --with-lapack="${LAPACK}"
.if ${BLAS} == "no" || ${LAPACK} == "no"
PLIST_SUB+= LAPACK=""
.else
PLIST_SUB+= LAPACK="@comment "
.endif
[...]

this fragment will only try compiling against ATLAS if it is not the
math/libRmath port the one being compiled.

In my opinion having the choice to link against
ATLAS/openBLAS/netlib/none_of_them is interesting to any maths ports. Is
there any reason why this specific slave port rejects it? Are there any
general guidelines as to how options from master ports should be handled in
slave ports? I haven't found any specific hints in the porter's handbook.

Having a look at editors/emacs-nox11/Makefile (emacs-nox11 is a slave to
emacs) I see the possibility of specifying OPTIONS_EXCLUDE, which seems a
more reasonable place to handle such cases.

Any help with this will be highly appreciated.

Best,
Fernando
___
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: math/R and slave ports guidelines

[Fernando Herrero Carrón]

My proposal would be that the master port offers the options to link
against: none/ATLAS/openBLAS/netlib and that slave ports follow suit. Does
that sound reasonable?

2016-02-13 14:40 GMT+01:00 Fernando Herrero Carrón <elfe...@gmail.com>:

> Hi all,
>
> I am working on some upgrades to the Makefile of math/R and I have found
> that there are two slave ports depending on it: math/libR and
> math/libRmath. Now I have some questions about how slave ports should be
> handled.
>
> As it stands, the master port will only set some options *if* it is the
> master port itself being built and not one of the slaves. For example
> (math/R/Makefile:145):
>
> *.if !defined(LIBRMATH_SLAVEPORT)*
> .if ${PORT_OPTIONS:MATLAS}
> LIB_DEPENDS+=   libatlas.so:${PORTSDIR}/math/atlas
> BLAS?=  ${LIBM} -lf77blas
> LAPACK?=${LIBM} -lalapack -lcblas
> .else
> BLAS?=  no
> LAPACK?=no
> .endif
> CONFIGURE_ARGS+=--with-blas="${BLAS}" --with-lapack="${LAPACK}"
> .if ${BLAS} == "no" || ${LAPACK} == "no"
> PLIST_SUB+= LAPACK=""
> .else
> PLIST_SUB+= LAPACK="@comment "
> .endif
> [...]
>
> this fragment will only try compiling against ATLAS if it is not the
> math/libRmath port the one being compiled.
>
> In my opinion having the choice to link against
> ATLAS/openBLAS/netlib/none_of_them is interesting to any maths ports. Is
> there any reason why this specific slave port rejects it? Are there any
> general guidelines as to how options from master ports should be handled in
> slave ports? I haven't found any specific hints in the porter's handbook.
>
> Having a look at editors/emacs-nox11/Makefile (emacs-nox11 is a slave to
> emacs) I see the possibility of specifying OPTIONS_EXCLUDE, which seems a
> more reasonable place to handle such cases.
>
> Any help with this will be highly appreciated.
>
> Best,
> Fernando
>
>
>
___
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"