Re: library porting question - optional python bindings

[Shane Ambler]

On 03/03/2016 03:03, Chris Inacio wrote:

On Tue, Mar 1, 2016 at 3:04 AM, Shane Ambler  wrote:


On 01/03/2016 13:08, Chris Inacio wrote:


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.





For a normal python module I would suggest making it as a separate port
that just installs the python module. This makes it easier to install
multiple versions for each python version. The py-module port can be a
slave of the main port so you don't have to maintain the same code
twice.






The library is generally a C library with 3 "targets" a library (.so),
header files (.h), and daemon that can be used as well.

If you enable the optional Python support, then there is an entire python
build area with the full "python setup.py ..." that gets run *from the C
Makefile* when the Python dependencies are available.

So yes, I can see that it makes sense to have this has 2 separate ports
from a port maintenance point of view, but this is distributed as a single
distribution.

So you're suggesting 2 ports, from one source download, and 1 of those
ports dependent on the other port?


Yes you only need the one src tarball and distinfo between both ports.
You can also use the same pkg-descr and maybe the same pkg-plist.

If the contents of the python port Makefile is kept to a minimum you
will only have to change the master port to update both, the changes to
the master port will apply to both ports. You can use conditionals to
get variations between building each port.

The python module port only needs to depend on the master port if it
uses the libraries installed by it, which I'm expecting it would.


--
FreeBSD - the place to B...Software Developing

Shane Ambler

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

FreeBSD Port: netatalk3-3.1.8,1

[Dutchman01]

Hi Marcus,

 

Can you please rename the patch
 patch-etc_apfd_Makefile.in correctly

 

into
 patch-etc_afpd_Makefile.in

 

It looks so stupid.

 

Thanks,

Dutchman

___
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 TV anti-blue & glare protector

[lcdaccessory]

Dear ports  MD,

New LCD/LED TV defender blocker for year 2016.
huge profits reserve for first distributor there, a lots request from end-users
New and hottest model refer to  http://www.lcdaccessory.com 

inquire email to Eric from eMetal Technology
i...@emetal.tw 




























































___
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

[Chris Inacio]

On Tue, Mar 1, 2016 at 8:57 PM, Kubilay Kocak  wrote:

> On 1/03/2016 1:38 PM, Chris Inacio wrote:
> > 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?
>
> Package it separately if it:
>
> * Is listed on PyPI (.python.org)
> * Has value separate from the 'parent software' (on its own)
> * Users might want it without the parent software
> * Is pure python, OR
> * Doesn't otherwise explicitly require depend on the parent software
>
> From the description above, given the dependencies of each of the
> software components are different (main software, python package), I'd
> go for separate packaging unless there's a good reason not to.
>
> > thanks,
> > Chris Inacio
>
>

I don't believe you can build the Python package without the availability
of the C library.
___
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

[Chris Inacio]

On Tue, Mar 1, 2016 at 3:04 AM, Shane Ambler  wrote:

> On 01/03/2016 13:08, Chris Inacio wrote:
>
>> 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.
>>
>
> Python bindings as in a module that can be imported in python? or
> python bindings that help the lib linking to it to be exposed to python?
>
> The difference is a python module will be installed into
> pythonx.y/site-packages while the other will install lib/libxxx.so
>
> devel/boost-python-libs is an example of the later.
>
> For a normal python module I would suggest making it as a separate port
> that just installs the python module. This makes it easier to install
> multiple versions for each python version. The py-module port can be a
> slave of the main port so you don't have to maintain the same code
> twice.
>
> A port with PORTNAME=nose and PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}
> can then end up with multiple installs to support each python version.
>
> pkg info -ox nose
> py27-nose-1.3.7devel/py-nose
> py34-nose-1.3.7devel/py-nose
> py35-nose-1.3.7devel/py-nose
>
> Does anyone know of a similar application/library that I can go look at?
>> Is there any documentation on how to solve this?
>>
>
> I have graphics/openimageio and py-openimageio as well as
> graphics/opencolorio that has opencolorio-tools and py-opencolorio as
> slaves.
>
> openimageio uses SLAVE_PORT as defined by the ports infrastructure
> while opencolorio defines it's own OCIO_SLAVE to distinguish between
> the two slaves
>
> Using VARIABLE?=xxx in the master Makefile allows the slave port to
> override that variable.
>
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
>
The library is generally a C library with 3 "targets" a library (.so),
header files (.h), and daemon that can be used as well.

If you enable the optional Python support, then there is an entire python
build area with the full "python setup.py ..." that gets run *from the C
Makefile* when the Python dependencies are available.

So yes, I can see that it makes sense to have this has 2 separate ports
from a port maintenance point of view, but this is distributed as a single
distribution.

So you're suggesting 2 ports, from one source download, and 1 of those
ports dependent on the other 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: Maintainer for multimedia/zoneminder

[Jan Bramkamp]

On 02/03/16 16:15, Kristian Kræmmer Nielsen wrote:

Hi,

This mail-address is written in "MAINTAINER" for multimedia/zoneminder -
does that actually mean the port has no maintainer?


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

Maintainer for multimedia/zoneminder

[Kristian Kræmmer Nielsen]

Hi,

This mail-address is written in "MAINTAINER" for multimedia/zoneminder -  
does that actually mean the port has no maintainer?


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

security/py-cryptography build failure with OpenSSL 1.0.2g

[Jim Ohlstein]

Hello,

Build failure since update of OpenSSL to 1.0.2g. FreeBSD 10.3-BETA2 
amd64, Poudriere version 3.1.12.


Build log at http://bit.ly/1UyofSH

Thanks,

--
Jim Ohlstein


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

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

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
graphics/cadubi | 1.3 | v1.3.1
+-+
graphics/djview4-qt4| 4.10.3  | 4.10.6
+-+
lang/sbcl   | 1.3.1   | 1.3.3
+-+
math/yacas  | 1.3.6   | 1.4.0
+-+
net/py-iplib| 1.1 | 1.1bsd
+-+
net-mgmt/weathermap | 1.1.1   | 26.0.0
+-+
www/py-django-classy-tags   | 0.7.1   | 0.7.2
+-+


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

[Kurt Jaeger]

Hi!

> I wonder if anybody is using Rex? We have been using Rex
> (https://www.rexify.org) with much satisfaction. It is similar in
> concept to Ansible, ie push, not pull.

I'm planing to look at it as soon as I find time.

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

[Priyadarshan]

I wonder if anybody is using Rex? We have been using Rex
(https://www.rexify.org) with much satisfaction. It is similar in
concept to Ansible, ie push, not pull.

Configuration instructions are via so-called Rexfiles. They are written
in a small DSL but can also contain arbitrary Perl, and that where it
shines, perhaps because we use Perl a lot.

(A short intro:
http://www.slideshare.net/AndyBeverley/an-introduction-to-rex-floss-uk-devops-york-2015)

Priyadarshan
___
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?

[Dave Cottlehuber]

Currently just ansible. In the past I've used: 

cfengine
puppet
chef
ansible

cfengine & puppet have large communities with significant amounts of
re-usable code, ansible is still a way behind due to being much newer. I
am not really impressed with DSLs, they seem to hide not quite enough of
the complexity for me.

All the tools have had various bits broken during the time I used them,
you can expect to end up digging inside eventually no matter what tool
you pick, so bear this in mind if you're comfortable doing that or not.

Of the three I now only use ansible by choice (albeit in a somewhat
smaller environment than when I started) because ansible is a very easy
step from replacing custom shell scripts to using it as an orchestator,
and many of my customers & colleagues can extend or add it without
dealing with a complex system or unfamiliar DSL. In the end this was the
deciding factor: is the organisation large enough to require & support
dedicated/trained ops people or not?

Finally,  https://www.youtube.com/watch?v=GVhpPF0j-iE&html5=1 &
https://ttboj.wordpress.com/2016/01/18/next-generation-configuration-mgmt/
looks very interesting, albeit a way off complete.

A+
Dave

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