Re: library porting question - optional python bindings
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 ___ 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?
Christoph Moench-Tegeder wrote: Some systems (e.g. cfengine) are using a pull model, where the "managed" machines connect to a central hub periodically, fetch the configuration and "do what needs to be done", while e.g. ansible follows a "push" model, where the "agent" is executed "somewhere" and connects to the managed node to do it's work. It should also be noted that one of the primary differences between ansible and the other configuration management / deployment options is that ansible is agent-less i.e., you don't run anything other than an sshd on the clients. This precludes a range of potential problems from version-skew to client security. That said you do also need to run python on the clients (an unfortunate design decision IMO). Most places I see these tools used inappropriately. If you're not spinning up new instances frequently or maintaining more than a few dozen hosts you're better off using simple shell scripts, or at least you are if you know a bit of shell programming (as in /bin/sh). Otherwise your time is better spent learning shell than the domain-specific languages of any of these tools. Even with hundreds of hosts to maintain most features of deployment tools appeal to those with less sysadmin experience than software development experience, unless perhaps you have to perform the same operation over several different operating systems. Even then using tool-specific methods limits your flexibility (which may well be a design goal). Roger ___ 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: mail/postfix and mail/postfix-current need upgrading
\mail\postfix-XXX Older versions of Postfix \mail\postfix-stableLatest stable version of Postfix \mail\postfix-current Experimental version of Postfix Based on the goal of user-friendliness and principle of least surprise I'd vote for changing -current to -experimental. It is a FreeBSD naming convention for -current to mean experimental (alpha, rc, ...) but for those who are not regularly involved with the FreeBSD release cycle this is not intuitive. Longer-term at least, there is user-friendliness to be gained by switching to a more descriptive name than -current to describe pre-released software. Note also that Wietse uses FreeBSD and usually follows BSD naming conventions but has chosen not to in this case. IMO, Roger As each "experimental" becomes stable, it is given a "postfix-stable" designation and the old stable release is given a "postfix-XXX" designation. The new postfix experimental release then assumes the "postfix-current" title. My only concern with changing the name "postfix-current" to "postfix-devel" or whatever is for historical purposes. I have always known it by the latter designations plus I am not sure if it would cause a problem in the ports system if it were to be renamed. In any case, the "postfix" ports were always kept up-to-date in virtual real time. Now they seem to lag behind. I am unsure as to what has happened. -- Carmel ___ 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: mail/postfix and mail/postfix-current need upgrading
Yay, great, thanks!!! mail/postfix-current at 3.2-20160224 mail/postfix at 3.1.0 mail/postfix211 at 2.11.7 Mark ___ 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?
## Chris Inacio (nacho...@gmail.com): > Happy if you would just reply with which one, if any, you use. I'm using cfengine for a mixed (several Linux, some FreeBSD) environment. But: without the "cfengine-masterfiles" (available as a port), using cfengine can be somewhat painful (as already remarked by some); and when using those masterfiles "as provided" by upstream integration between the cfengine port and the masterfiles is not really ideal. Caveat emptor: my cfengine setup did not start with the FreeBSD machines, some of the problems may be homegrown. Some items not immediatly relevant to the current question, but perhaps helpful to to consider when chosing any sort of configuration management; picked from experience and top of my head: - what environment do you expect? cfengine is C and "data", so there's little inital dependencies and you can bootstrap cfengine from a very minimalistic isntallation, while puppet/chef/salt/ansible require ruby/python/working ssh/... (that alone had been the tipping point in one setup I know of) OTOH cfengine/puppet/chef are probably "too large" for embedded/IoT stuff - those smallish systems would be fully loaded with the config management alone. - do you want "push" or "pull"? Some systems (e.g. cfengine) are using a pull model, where the "managed" machines connect to a central hub periodically, fetch the configuration and "do what needs to be done", while e.g. ansible follows a "push" model, where the "agent" is executed "somewhere" and connects to the managed node to do it's work. Considerations: network model, load. With the "pull" model, the agents are constantly executing, the aggregate load (CPU&IO) may be noticeable in virtualized/shared storage environments - and the central configuration hub requires enough "horse power" to handle the clients (I've heard of problems in that area, and some documentation hits that cascading setups should be used for huge setups). Consider having a centralized config hub and "change lag" because of periodic polling against "run anywhere" and "run anytime you need it". Regards, Christoph -- Spare Space ___ 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: [CFT] net-im/ejabberd to 16.01
On Mon, 29 Feb 2016 19:41:00 +0530 ash...@freebsd.org (Ashish SHUKLA) wrote: > https://people.freebsd.org/~ashish/diffs/ejabberd-16.01-02.diff > sha256 sum: > ec71fdd19c752b22271ce6e3f899b966b0017f05fa13532d1decf18478e41b6e Hi, Ashish, I'd be glad to test this, but the patch does not apply cleanly in my environment. I don't know if it is relevant, but my ports dir is a symlink: /usr/ports -> /usr/local/poudriere/ports/default When patch is applied in /usr/ports/net-im/ejabberd, first few sections apply OK, then it starts asking paths and applies diffs if correct path is entered, and finally it exits with: Patching file pkg-plist using Plan A... patch: malformed patch at line 1171: %PORTNAME%%-%%PORTVERSION%%/ebin/eldap_utils.beam Regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/ ___ 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
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
___
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
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"
