clang support for compiler:openmp
Hi, is there a specific reason, why we do not (yet) have openmp support for clang via compiler:openmp? With devel/openmp in the ports tree, I'd expect compiler:openmp to set LIB_DEPENDS+= libomp.so:devel/openmp for compiler=clang. CFLAGS and LIBS/LDFLAGS might be tweaked on a per-port level. Cheers Marcus signature.asc Description: PGP signature
Re: blender and cycles engine
On, Sun Jul 31, 2016, Stari Karp wrote: > Hi! > > The new Blender 2.77a is in the ports which has many improvement > related to the Cycles engine but on my system FreeBSD 10.3-RELEASE > (amd64) is still not possible to run Blender with Cycles option on. It > build but Blender doesn't start: > blender > Assertion failed: (findOption(Name) == Values.size() && "Option already > exists!"), function addLiteralOption, file > /construction/xports/devel/llvm37/work/llvm- > 3.7.1.src/include/llvm/Support/CommandLine.h, line 698. > Abort (core dumped) Do you have the CYCLESOSL option enabled? If so, can you disable that option and check, if the problem still occurs? Cheers Marcus signature.asc Description: PGP signature
Re: Multiple versions of Python packages (2.7 vs 3.4)
Quoting Miroslav Lachman <000.f...@quip.cz>: I checked that most files are installed in versioned subdirectory, for example python2.7/site-packages, some tools have versioned binaries like /usr/local/bin/pip-2.7 but they have also symlink /usr/local/bin/pip. Are there any way to create / install those packages without creating this symlink? If I didn't miss something the symlinks are the only common files for both versions so it will be overwritten by the later installation or upgrade. Or not? No, it won't. The symlink depends on the DEFAULT_VERSIONS entry in your /etc/make.conf or the ports default. Right now Python 2.7 is the default for the FreeBSD ports tree, so the symlinks are only created for Python 2.7. If you install Python 3.4 or another version, they won't be overridden. Cheers Marcus ___ 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: patch to bsd.ports.mk to support out-of-tree patches.
Julian Elischer jul...@freebsd.org:
[...]
esac | ${PATCH} ${PATCH_DIST_ARGS} `patch_dist_strip $$i` ; \
done )
.endif
+.if defined(EXTRA_PATCH_TREE)
[...]
+.endif
.if defined(EXTRA_PATCHES)
@set -e ; \
for i in ${EXTRA_PATCHES}; do \
Nice. I'd however change the patch behaviour to the following:
- patch-* from FreeBSD
- EXTRA_PATCHES from FreeBSD
- local patches
Your patch looks like it appleis the out-of-tree patches prior
to any EXTRA_PATCHES defined by the port itself. This should not be
the case, in my opinion. Locally managed patches should always come
last to ensure that all FreeBSD/maintainer-specific bits have been
applied and the local changes are just added on top of those.
Cheers
Marcus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unable to upgrade tex-xetex and tex-luatex: libpoppler.so.44 not found
On, Tue Nov 25, 2014, Dr. Peter Voigt wrote: I am currently unable to upgrade tex-xetex and tex-luatex on 10.1-RELEASE (amd64). [...] ' ... Shared object libpoppler.so.44 not found, required by xetex Error: `xetex -ini -jobname=xetex -progname=xetex -etex xetex.ini ' failed ### fmtutil: Error! Not all formats have been built successfully. Visit the log files in directory /usr/ports/print/tex-xetex/work/stage/usr/local/share/texmf-var/web2c for details. ### This is a summary of all `failed' messages: `xetex -ini -jobname=xetex -progname=xetex -etex xetex.ini ' failed *** Error code 1 The tex-xetex and tex-luatex ports use the first `xetex` or `luatex` that is found in your PATH environment, thus the build process uses the old (outdated) versions in /usr/local/bin. You can work around this by deinstalling both first, and then install them. Cheers Marcus pgpJbHJgyaPnU.pgp Description: PGP signature
Re: pysolfc broken?
Hans de Hartog hansdehar...@gmail.com: [root@myhost ~]# pkg install pysolfc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 3 packages will be affected (of 0 checked): New packages to be INSTALLED: pysolfc: 2.0_6 py27-tkinter: 2.7.8_5 py27-pillow: 2.6.0 [pysolfc/pillow complaining about missing TK support] py-pillow was updated a few days ago (version 2.6.0_1) to include the TKINTER option as default[1]. If you are retrieving your packages via an official repository, it should update itself soon. If you are building packages on your own, you may want to update the ports tree and rebuild py-pillow. [1] https://svnweb.freebsd.org/ports?view=revisionrevision=372903 Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: audio/openal-soft fails to install on FreeBSD 8.4-stable
On, Sat Oct 25, 2014, Torfinn Ingolfsen wrote: On Fri, Oct 24, 2014 at 10:32 PM, Henry Hu henry.hu...@gmail.com wrote: I just tried it on 8.4-RELEASE/amd64 and it failed with the same error. It seems like that the gcc on 8.4 is too old. One way to fix it is adding USE_GCC=yes to makefile. This will use gcc 4.8 by default and it builds successfully. But on later freebsd versions we can just use clang. Maintainer cc'ed. Interesting. I tried this: root@kg-core1# grep USES Makefile USES= tar:bzip2 cmake compiler:c11 I just committed that fix in r371503, thanks! Cheers Marcus pgpLwx2ngeTkv.pgp Description: PGP signature
Re: [BRAINSTORMING] simplifying maintainer's life
On, Thu Sep 04, 2014, Marcus von Appen wrote: Matthew Seaman matt...@freebsd.org: On 04/09/2014 07:00, Marcus von Appen wrote: - I often grep all plists to find which port could possibly provide such header or such library (among non-installed ports, of course). I do the same, but would argue that such a query service should belong to or offered by a pkg search (as sort of counterpart to pkg which). We've toyed with that idea -- allowing 'pkg search' or similar to search on any file in any package known in the repositories. The biggest problem is that including all that data in the package catalogues would bloat their size by a very large amount. Rather than bloating the catalogues for any use, there was a separate index of files. Not sure whether that's being routinely built on the FreeBSD pkg cluster at the moment -- probably not, as it was only ever experimental, and didn't have any generally available consumers. I did not mean it to be offline available, since it becomes outdated too fast. In many ways, I'd prefer to have this sort of functionality available as a web-app, thus saving users the necessity of downloading megabytes of data about ports / packages they would never use or care about. Needs someone to step up and write that application though. Not necessarily a web app, but a (web) service that's e.g. run somewhere on a pkg builder or proxy and which can be queried by tools as well as web services. I gave the pkg repo output a quick shot with about 370 random packages, which creates a filesite.yaml of roughly 4.5 MB. Reading the file and transforming it into a tree to get access to the file entries resulted in about 8 nodes (a compressed variant, where nodes with only a single child are merged, contains 78000 nodes). 370 packages are about 1 to 1.5 percent of the package amount, we currently have. Assuming linear growth, filesite.yaml would be around 450 MB in size, and a node tree for searching would contain around 8 million nodes. I doubt that a reasonably fast search service could be implemented on top of filesite.yaml alone. Storing everything in memory is not an option, since the index tree alone would consume far more than 300 MB (assuming an optimal word size of 20 bytes plus a bit of node and tree payload). Fragemented search over the file would cause heavy disk I/O and no matter, how many threads will perform the search, the disk I/O eventually will become the bottleneck. Searching the tree would be horribly slow, since the traversal would need either additional information in the structure (to avoid a complete BFS/DFS for file fragments) or keeping subtrees and helper structures in memory, which easily blows the minimum memory amount to use without a single query being executed. With this amount of information, Tries, DAWGs or generic DAGs would easily hit their limit and one would need to set up an incremental search based on seperate indices, which effectively leads to a document index and search implementation. My guess is that a webservice for searching the catalogue would be easier to be implemented based on a full text search engine, such as Solr or Lucene, since each particular entry within filesite.yaml is a specific and very small document. Cheers Marcus pgpWduVyDF31N.pgp Description: PGP signature
Re: py-imaging vs. py-pillow
On, Fri Oct 03, 2014, Stefan Ehmann wrote: According to freshports there are about 10 ports that depend on py-pilllow and 50 that depend on py-imaging. py-imaging conflicts with py-pilllow. E.g., calibre and xmbc cannot be installed at the same time. I noticed the problem because calibre switched to py-pilllow recently. There really should be a way that these packages can coexist. (py-imaging/py-pilllow maintainers CCed) I just pushed a patch to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193957, which updates pillow, makes it available for different python versions at the same time and addresses db@'s _imagingtk issue (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193958). This should allow us to migrate the ports to pillow. Cheers Marcus pgpadUj3VroDl.pgp Description: PGP signature
Re: [BRAINSTORMING] simplifying maintainer's life
On, Wed Sep 03, 2014, Thierry Thomas wrote:
Le mer 3 sep 14 à 21:12:56 +0200, Marcus von Appen m...@freebsd.org
écrivait :
On, Wed Sep 03, 2014, Bryan Drewery wrote:
[...]
I understand there is fear involved with not having a plist validate
everything. Consider that many other package systems do not require a
plist to start.
[...]
Seconded. In my opinion for 95% of all cases it sums up to: everything in
the
staging directory gets installed. We can use post-build or pre-install to
clean up the staging directory where necessary, or even revert the plist
meaning in the worst case, e.g. everything in ${EXCLUDE_INSTALL} is not to
be
installed, if necessary.
I disagree. I use plist for two things:
You belong to the +-5% ;-).
- when upgrading a port, I compare the previous plist with the newer
one, and if some important files are missing, I try to understand the
reason;
For those things a comparision mechanism in the qa scripts for a
porter/committer might come in handy:
- get stagedir contents
- get (current) package contents
- compare and show a list of changes for the QA
- I often grep all plists to find which port could possibly provide such
header or such library (among non-installed ports, of course).
I do the same, but would argue that such a query service should belong to or
offered by a pkg search (as sort of counterpart to pkg which).
Cheers
Marcus
pgp6T7gbmNik2.pgp
Description: PGP signature
Re: problem with devel/glib20
On, Thu Sep 04, 2014, Robert Huff wrote: [I have sent mail to the maintainer, but not heard back. The matter is somewhat pressing, so here I am ] [glib20 + python files installation issue] https://svnweb.freebsd.org/ports?view=revisionrevision=367216 A fix was committed yesterday (see above), most likely after you tried to build glib20. Can you update to your ports tree and try again? Cheers Marcus pgpgMGWkiUqTi.pgp Description: PGP signature
Re: [BRAINSTORMING] simplifying maintainer's life
Matthew Seaman matt...@freebsd.org: On 04/09/2014 07:00, Marcus von Appen wrote: - I often grep all plists to find which port could possibly provide such header or such library (among non-installed ports, of course). I do the same, but would argue that such a query service should belong to or offered by a pkg search (as sort of counterpart to pkg which). We've toyed with that idea -- allowing 'pkg search' or similar to search on any file in any package known in the repositories. The biggest problem is that including all that data in the package catalogues would bloat their size by a very large amount. Rather than bloating the catalogues for any use, there was a separate index of files. Not sure whether that's being routinely built on the FreeBSD pkg cluster at the moment -- probably not, as it was only ever experimental, and didn't have any generally available consumers. I did not mean it to be offline available, since it becomes outdated too fast. In many ways, I'd prefer to have this sort of functionality available as a web-app, thus saving users the necessity of downloading megabytes of data about ports / packages they would never use or care about. Needs someone to step up and write that application though. Not necessarily a web app, but a (web) service that's e.g. run somewhere on a pkg builder or proxy and which can be queried by tools as well as web services. If you tell me, how the index looks like, I can give it a quick (prototyping) shot. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [BRAINSTORMING] simplifying maintainer's life
On, Wed Sep 03, 2014, Bryan Drewery wrote:
[...]
I really dislike plists as they are today. The argument that having them
makes it easy to see what the port installs is bogus. Many don't have
pkg-plist because they have PLIST_* or INFO or are missing DOCS/EXAMPLES
due to usage of *. Many, such as rubygems and python, have autoplist
already. I would like to provide 1 approved way to do autoplist, rather
than having the dozens of different implementations that we have today
in ports.
[...]
I understand there is fear involved with not having a plist validate
everything. Consider that many other package systems do not require a
plist to start.
[...]
Seconded. In my opinion for 95% of all cases it sums up to: everything in the
staging directory gets installed. We can use post-build or pre-install to
clean up the staging directory where necessary, or even revert the plist
meaning in the worst case, e.g. everything in ${EXCLUDE_INSTALL} is not to be
installed, if necessary.
It'd greatly reduce the maintenance efforts and ugly hacks (look at python.mk
for an example) to work around the limitations of plist and upstream
solutions.
Cheers
Marcus
pgp9yJ1dqj0i6.pgp
Description: PGP signature
Re: [HEADSUP] pkg(8) is now the only package management tool
Alban Hertroys haram...@gmail.com: On 2 September 2014 11:08, Julian Elischer jul...@freebsd.org wrote: On 9/1/14, 8:03 PM, Andrew Berg wrote: On 2014.09.01 21:39, Julian Elischer wrote: sigh.. when are we as a project, all going to learn that reality in business is that you often need to install stuff that is old. Its not always your choice. The custommers require it.. You should try arguing with someone like Bank of Americas security and operations department some day about whether they want to suddenly upgrade 300 machines for no real reason (from their perspective). FreeBSD minor version upgrades are meant to be non-disruptive. However, I will admit that I have not performed any such upgrades in a critical environment, so if you think they are disruptive, please enlighten me with the details. Also, there are options out there for getting support for extended periods if you need it. Some companies are built around providing support for things that the original developers have long abandoned because some businesses need it. It's not how disruptive they are technically. it's how many months of shakedown testing you have to go through before they allow you to put new software on any production system. Just adding here, in commercial environments things don't change quickly or easily. Whether this applies to the current issue with pkg is not for me to say. For example, certain commercial upstream software vendors require to go through a certification process before they even consider supporting the new software you intend to use with theirs. Admittedly we haven't run into this issue in relation to FreeBSD, but we certainly have with Firefox. As an example, the last version of Firefox that Information Builders' WebFOCUS 7.7 supports is 3.6.7 (currently available versions are 31 or 32!) and for Internet Explorer that's 7 (currently at 11). If you run into any kind of problem, the standard answer is to use a browser that they support. Good luck with that! Firefox 3.6.7 was released on July 20, 2010; over 4 years ago. In such cases you're more or less required to keep an old system around that still has such old packages, if only to see if you can reproduce any issues you encounter (with modern versions of your software) on those old versions. With the deprecation of the old pkg_* tools you run into a conflict; You can either update packages that are _not_ under certification for such a vendor and get security updates and fixes using the new pkg, or you have to stick with the certified software and _not_ get any security updates or fixes. It gets more interesting if you have to deal with manufacturing processes (something we're looking to use FreeBSD for to replace our current OpenVMS systems before they go out of support), as often automatons write data to external databases and such software resides in PLC's. Manufacturing equipment tends to age and the kind of external databases they support is limited to what was available when they were new and the capabilities of the PLC involved. I can totally understand that at some point it starts to get impossible to maintain two separate packaging systems and I understand that you think 2 years is enough time to shake things out, but software vendors aren't that quick. For many, 2 years is a short time. It also should be noted that everyone had enough time to raise those issues in the time between tthe announcement and now. No one did. Now that it is gone, they are brought up, while they should have been long time ago instead. It can't work that way. My 2 cents in this discussion :-). Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] pkg(8) is now the only package management tool
Brandon Allbery allber...@gmail.com: On Tue, Sep 2, 2014 at 6:52 AM, Marcus von Appen m...@freebsd.org wrote: It also should be noted that everyone had enough time to raise those issues in the time between tthe announcement and now If this is an issue that needed to be brought up, then FreeBSD has apparently never before been used in an enterprise??? I'm tempted to ask, if the enterprise has SLAs to ensure continuity, even after the official support has ended? ;-) Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Parallel python package support with pkg
Dear all, the pkg team created something outstanding with pkg 1.3, which you might have missed. Since version 1.3, pkg supports the installation of packages, which share the same origin (location in the ports tree), but have different package names. In practice, this means that you can install e.g. a python module for two different Python versions at the same time with pkg now (a last fix for it was provided on August, the 8th, for the ports, so make sure to update your ports tree beforehand). To install a python module for different Python version, you just have to provide PYTHON_VERSION=pythonX.Y at the command line: # go to py-tkinter $ cd /usr/ports/x11-toolkits/py-tkinter # install it for the default python (2.7) $ make install clean # install it for python 3.3, too $ make PYTHON_VERSION=python3.3 install clean # check the installed packages $ pkg info \*tkinter py27-tkinter-2.7.8_5 py33-tkinter-3.3.5_5 Please note, that this will not work for all python ports yet. Those, which install conflicting files (most often applications or configuration files), will still create a conflict. If you need to offer that specific port for different python versions at the same time, you may want to follow up with the maintainer and our python team. If you are a maintainer and wish to enable your port for different python versions, but something blocks you, get in touch with our python team for assistance. You can find our contact details at https://wiki.freebsd.org/Python. Cheers Marcus on behalf of python@ pgpCc1GKY7OL5.pgp Description: PGP signature
Re: Why USE_PYTHON=yes doesn't rebuild default python meta-port?
On, Tue Aug 05, 2014, Yuri wrote: I am rebuilding the port hierarchy with the top port having USE_PYTHON=yes. This package runs python-config. But only python2 and python27 were actually built, and therefore only python2-config is available and my port breaks. Default meta-port python-2.7, that would have contained python-config, wasn't built. But USE_PYTHON=yes asks for the default python, doesn't it? So is this a bug in the make scripts, or else why default python version wasn't built? USE_PYTHON=yes asks for any python port, no matter which. lang/python is a consumer port that usually is not picked by ports within the ports infrastructure and you should avoid using 'python-config', 'python' and similar generic commands for building and installing ports, since a user can change the default version at any time. Having said this, pulling in 'only' python2 (lang/python2) is correct. The port, that breaks for you, needs to be fixed. Cheers Marcus pgpeO_85NfhDU.pgp Description: PGP signature
Re: py27-setuptools27-5.4.1
On, Thu Jul 31, 2014, jcv wrote: Hi- I am getting this error message and would like to know if there is an easy way to fix this??? pkg-static: py27-setuptools27-5.4.1 conflicts with py27-setuptools-5.4.1 (installs files into the same place). Problematic file: /usr/local/lib/python2.7/site-packages/easy-install.pth.dist *** Error code 70 I do not see anything in /ports/UPDATING regarding: py27-setuptools root@yeaguy:#cat /usr/ports/UPDATING | grep py27-setup root@yeaguy:# Try cat /usr/ports/UPDATING |grep py-setuptools It looks like you are bitten by the entry from 20140307 Cheers Marcus pgpt5tJKJOj11.pgp Description: PGP signature
[HEADS UP]: Conflict-free python packages for different python versions
On behalf of the FreeBSD python team, I'd like to announce the availability of
concurrent, conflict-free python package support in the ports tree.
Why?
FreeBSD supports different python versions and flavours to be installed at
the same time, such as e.g. Python 2.7 and Python 3.3. Ports installing
python modules however always assume that that they are installed
for only one python version.
To overcome the flaw in the ports tree that a single port, which is about to
be installed for different python versions at the same time, will install
conflicting files into the same directories, a change in how those ports are
built and installed was necessary.
What does that mean for port and pkg users?
If you are using the ports tree to build your own ports from scratch, it
won't have any impact as of now, since the underlying package installers, be
it pkg or the pkg_* tools, can't install multiple packages from the same
source port yet.
If you are using pkg or the pkg_* tools to install binary packages, it won't
have any impact as well, since they can't install multiple packages from the
same source port yet.
You should be aware of some directory and file name changes, though, that
eventually will occur on updates. A python module may use the python version
prefix for the doc and example directories and create scripts and binaries
with a python version suffix.
Right now, a port devel/py-foo might install
* documentation into/usr/local/share/doc/foo,
* examples into /usr/local/share/examples/foo,
* a script /usr/local/bin/foo
The announced change (along with an update to the port) will cause it to use
a python version prefix for the directories and a version suffix for the
scripts (and binaries). This means, that the port will install
* documentation into /usr/local/share/doc/py27-foo (for lang/python27)
* documentation into /usr/local/share/doc/py32-foo (for lang/python32)
* documentation into /usr/local/share/doc/py33-foo (for lang/python33)
...
* examples into /usr/local/share/examples/py27-foo (for lang/python27)
* examples into /usr/local/share/examples/py32-foo (for lang/python32)
* examples into /usr/local/share/examples/py33-foo (for lang/python33)
...
* a script /usr/local/bin/foo-2.7 (for lang/python27)
* a script /usr/local/bin/foo-3.2 (for lang/python32)
* a script /usr/local/bin/foo-3.3 (for lang/python33)
* a symlink /usr/local/bin/foo pointing to the script for the current
default python version (e.g. foo-2.7 or foo-3.3)
Please note that the current installation behaviour will not be changed
automatically. Ports that shall support conflict-free packages, must receive
an update first.
If you are not a port maintainer, committer or developer, you can stop
reading now.
What about maintainers and port developers?
Please read the CHANGES. The change makes use of USES=uniquefiles:dirs.
Thus, if you are maintaining a port, which shall become conflict-free,
set the new PYTHON_CONCURRENT_INSTALL knob to yes. The port must be
stage-safe to use the knob.
Please ensure that you do not set DATADIR, DOCSDIR, WWWDIR, EXAMPLESDIR or
ETCDIR explicitly in the port Makefile, since the uniquefiles USES will try
to prefix those. The change will also add a suffix to binaries and scripts
that will be installed into ${PREFIX}/bin, ${PREFIX}/sbin, ${PREFIX}/libexec
and create a symlink for the default python version on demand. If you are
using a manually maintained pkg-plist, you may need to adjust it using the
PYTHON_PKGNAMEPREFIX and PYTHON_VER variables to properly substitute
plist entries. If you are using PYDISTUTILS_AUTOPLIST, you usually do not
have take care of any plist modifications.
The rule of thumb is that most end-user applications, service daemons and
similar tools do not need to be installed concurrently for different python
versions. Python modules however will gain an immediate benefit, since they
can be provided for different python versions at the same time without
forcing the user to install them manually from another location.
We chose the knob to be an opt-in, rather than an opt-out solution, due to
various constraints, such as a full package rebuild, the requirement to
check all python-related ports prior to the commit and to keep the immediate
impact for users as small as possible.
If you have any specific questions about how to update your port, do not
hesitate to ask the FreeBSD python team.
Cheers
Marcus
pgpoVaVxZhjgR.pgp
Description: PGP signature
Re: What should be in scripts shebangs for python2?
Lev Serebryakov l...@freebsd.org:
Hello, Marcus.
You wrote 19 февраля 2014 г., 19:55:00:
MvA In short:
MvA * Use ${PYTHON_CMD} to replace the shebang lines or references of the
MvA python command
So, it is not possible to use static patch? It is pity :(
It should be avoided, if possible. Especially, when it is a shebang
line, since
we have a quite powerful mechanism to replace shebangs with minimal effort.
MvA * Use the proper supported python version (yes for any, 2 or 3 for a
MvA branch, X.Y for a release)
MvAfor USE_PYTHON_BUILD
I've hoped, that USE_PYTHON_BUILD=2 guarantee me, that here is
/usr/local/bin/python2 in system, but looks like it depends on something
else.
No, USE_PYTHON_BUILD=2 should provide lang/python2, which will install
/usr/local/bin/python2. This works for many ports, so I have no idea,
what's wrong
with your port. Do you mind to send me a shar of the port, so I can
have a look?
[...]
Cheers
Marcus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: What should be in scripts shebangs for python2?
On, Thu Feb 20, 2014, Lev Serebryakov wrote: Hello, Marcus. You wrote 20 февраля 2014 г., 12:06:46: MvA No, USE_PYTHON_BUILD=2 should provide lang/python2, which will install MvA /usr/local/bin/python2. This works for many ports, so I have no idea, MvA what's wrong It works locally, but pkg-fallout-buil...@freebsd.org sends me e-mails, where I see, that its software installs python27 but not python2 as dependency and it fails: http://beefy2.isc.freebsd.org/bulk/91amd64-default/2014-02-19_20h54m43s/logs/libopencm3-0.0.20140213.log I can't recreate this in a local poudriere environment, so I have no idea, what is going on on the build cluster. Excerpt from the local build: [...] === Returning to build of libopencm3-0.0.20140218 === libopencm3-0.0.20140218 depends on executable: python2 - not found ===Verifying install for python2 in /usr/ports/lang/python2 === Installing existing package /packages/All/python2-2_2.txz Installing python2-2_2... done === Returning to build of libopencm3-0.0.20140218 === libopencm3-0.0.20140218 depends on executable: gmake - [...] The port looks fine, make all-depends-list correctly lists lang/python2, stage builds work and all my poudriere installations handle it properly. My best guess is, that something on the build cluster (or that specific instance) goes wrong. Cheers Marcus pgpkhqo1RyBxj.pgp Description: PGP signature
Re: What should be in scripts shebangs for python2?
Lev Serebryakov l...@freebsd.org:
Hello, Freebsd-ports.
My port uses some pythons scripts to configure (it is not pythonn-related
by itself, only authors of this software use python scripts on build
stage).
How should I patch these scripts to work? It looks like
/usr/local/bin/python2 is installed by devel/python2 port, and
USE_PYTHON_BUILD=yes doesn't depends on this port, but on python27, which
USE_PYTHON_BUILD=yes indicates that the port supports any python
version, no matter,
if the user chooses python2.X or python3.x as the default for the system.
If your port is compatible with any python version and only uses
python for configuring
some bits, but does *not* need python at run-time, you should patch
the scripts to
use ${PYTHON_CMD}, via a ${REINPLACE_CMD} or the proper python_CMD=
${PYTHON_CMD} command
for the shebang USES.
If your port is only compatible for a specific branch (either 2.x OR
3.x), use the proper
major number for USE_PYTHON_BUILD, e.g. USE_PYTHON_BUILD=2. If the
port is only compatible
with a specific release (e.g. 3.2), use USE_PYTHON_BUILD=X.Y. For
those cases, you also can
rely on ${PYTHON_CMD}, which points to whatever is the most
appropriate version.
In short:
* Use ${PYTHON_CMD} to replace the shebang lines or references of the
python command
* Use the proper supported python version (yes for any, 2 or 3 for a
branch, X.Y for a release)
for USE_PYTHON_BUILD
could be changed in future or by users's request, so I don't want to
hardcode /usr/local/bin/python2.7, too...
Indeed, do not do this.
Cheers
Marcus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: USE_PYTHON version range no longer valid?
On, Wed Jan 15, 2014, Mike Brown wrote: A port I maintain (sorta) can only be built under Python 2.2.1 through 2.4.x. The app isn't being developed any longer, so patches to get it to build under 2.5+ aren't likely to be forthcoming. The port Makefile previously had USE_PYTHON= 2.2-2.4, but it was changed this week to simply USE_PYTHON=2, with this comment: Python cleanup: - USE_PYTHON* = 2.X - USE_PYTHON* = 2 - USE_PYTHON* = 2.X+ - USE_PYTHON* = yes Reviewed by:python (mva, rm) Approved by:portmgr-lurkers (mat) By removing 2.4 as the maximum version, there are inevitable build errors for this app. Reverting to USE_PYTHON= 2.2-2.4 results in 'make' failing with this: === py27-4suite-1.0.b1_1 needs an unsupported version of Python. I'm fine with that, although I'm unsure what the ramifications are of Python 2.4 being unsupported. Do people have the option of installing Python 2.4.6 and using it with this port, or do we need to decommission the port? Python 2.4 was removed from the tree ages ago and none of us noticed that this port would be affected by that. Sorry - it should have vanished with the removal of Python 2.4. I'll set a deprecation message along with the expiration date to the 1st of February. It will be removed from the tree after that date. Cheers Marcus pgprsiLUiDJpH.pgp Description: PGP signature
Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
Markiyan Kushnir markiyan.kush...@gmail.com: It sounds like a need for a more grained structure of the ports-related communication, just because the community is growing. Very often there is a need to discuss one's issue in a list prior to filing a PR. And yes, *discuss*, I agree with John, people should show they want to discuss their failed builds, whatever. I think automated failure reports (ports-qat) would easily be assigned to a separate list. I would suggest at least the following divisions: ports-questions@ would be for things like howtos, problems with managing ports, upgrading, versioning, etc. ports-devel@ for all sorts of ports build/install issues (port maintainers would be the primary responders), and ports-auto@ for automated repots like QAT. And the current ports@ would be aliased to ports-questions@. There's already ports-bugs@ for issues with ports (see the info on http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs). And this also would be the correct address for QAT reports, which are actually spamming the ports@ list (also imho). Personally, I do not think that we need yet another list :-). Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
John Marino freebsd.cont...@marino.st: Over the months I've seen several ports users copy a failure log and mail it to ports@, usually without even saying hello. I've tried to Do the QAT reports bug you on this list? If they do not, why is that so? I did not see you complain about those. discourage that behavior but other members of this mail list encourage this method of bypassing writing PRs. One user even proudly boasted In my opinion, writing a PR with all the required information (using send-pr or the web front-end) is still quite a hard task for many people, especially those coming freshly from another system. The front-end of GNATS and format of send-pr does not make that job easier or fun at all. Also, the PR will usually idle around for a couple of days and as a user you do not get instant feedback about your PR being actually received by the system (instead it takes a couple of hours). Work on a better reporting system is still ongoing, so let's see, how we could make life easier for users instead of babbling about leaving the list: - The ports tree *knows* in most cases that something went wrong. It reports this on the command line and leaves everything else up to the user. Instead of leaving it up to the user, who might be completely lost, further instructions and maybe automated hooks (send-pr'ish) can ease his daily life: - a port build fails at a stage that the Mk infrastructure can deal with: 1) Tell the user to reset certain environmental flags and where those might be found: Port cat/portname failed to build or install. Please make sure that your build environment did not have an impact on this by checking - that your ports tree is up to date (ports from DATE, today: DATE) - /etc/make.conf - make -VSTAGE_ENV - the output of `env` and checking relevant flags 2) let the user create a report with just a simple key press afterwards: If you verified that your environment is in a sane state, you might want to tell the maintainer (maintainermail) about it. Do not forget to copy the failure output from above! Do you want to create a report now? [y/N] 3) pressing 'y' above will create a PR with all relevant information, fire up an editor for the output to be pasted, hiding the most other, possibly confusing stuff. 4) Once the user pasted the content, saved and closed, the system will try to send the PR: The report has been created. Do you want to send it now? [Y/n/r]. where 'r' will allow the user to revise the whole send-pr content. Two key strokes, one copy operation and less confusing stuff to be set in the PR. One user even proudly boasted that sending email to ports@ is faster than writing a PR so of course he was going to do that instead. Which sums up to: the workflow for crating/handling PRs is not good enough, maintainers do not react fast enough on PRs, etc. If this kind of post is acceptable to the rest of the people here, and I'm alone in not only finding it very rude, but also making the volume of ports@ too high, then please tell me that the problem is with me. If nothing is going to change, I am going to unsubscribe from ports@ list. The gcc developers on g...@gcc.gnu.org always tell a poster when a post in appropriate for that list and as a result and as a result the I think, we forgot about ports-bugs@ to be the appropriate place and see it only as a list for GNATS reports. I agree with you insofar as that people should send specific things to the designated list. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[HEADS UP] lang/python removed as implicit port dependency
On behalf of the FreeBSD python team, I'd like to announce that the lang/python port has been removed as an implicit port dependency for ports using USE_PYTHON, USE_PYTHON_BUILD and USE_PYTHON_RUN in revision 336850. Why? The removal is necessary to bring us a step closer to building and installing ports for multiple python versions at the same time. What does that mean for port users? If you are using the ports tree to build your own ports from scratch, propably not much. Chances are high that lang/python was installed earlier, either as dependency or directly by you. In that case, it is very unlikely that you will run into any trouble with the change and hence you should not need to do anything in special. What does that mean for pkg users? If you are using pkg or are running your own pkg build server (e.g. via poudriere), it might happen that the one or other port breaks, since it cannot find the 'python' command or something else, which is installed by lang/python. We tried our best to keep the breakage as low as possible, but with more than 24000 ports to test and endless OPTION combinations, this is an impossible task. Please accept our apologies for your inconvenience and let us know about that misbehaviour by submitting a PR. If you are not a port maintainer, committer or developer, you can stop reading now. What about maintainers and port developers? Please read the CHANGES. Keep the direct usage of lang/python within BUILD_ and RUN_DEPENDS as low as possible. Using lang/python as dependency will complicate package building for different python versions (due to the PACKAGE_DEPENDS_ONLY knob). Ports should refer to a specific python version, version range or a version meta port (lang/python2 or lang/python3) instead. USE_PYTHON=yes and friends will only pull in the default python version now (e.g. lang/python27 or whatever is configured via DEFAULT_VERSIONS), so test your port thoroughly for (a possibly) incorrect usage of the 'python' command. Cheers Marcus pgpmOsFNOfHP5.pgp Description: PGP signature
Re: Proposal for Authors / Vendors in ports
Jason Helfman j...@freebsd.org: On Wed, Nov 13, 2013 at 11:30 PM, Erwin Lansing er...@freebsd.org wrote: On Wed, Nov 13, 2013 at 04:47:20PM -0500, Eitan Adler wrote: On Wed, Nov 13, 2013 at 3:27 PM, Melvyn Sopacua mel...@magemana.nl wrote: On Wed, 13 Nov 2013, Kris Moore wrote: Wanted to run this by the ports community, see your thoughts. We build our PBIs from the ports system, and are able to parse most of the information out for display graphically, like descriptions, maintainers, website, License, etc. However we currently don't have a way to pull the actual name of the upstream vendor / author. I.E. for Firefox the vendor would be Mozilla. WWW: [Mozilla](http://www.mozilla.org/) So, markdown format in pkg-descr. Seems the least amount of work? This adds a lot of work to the parser. IMHO we should have VENDOR_WWW and possibly VENDOR_NAME in the port's Makefile. It should not be hard to automate this for VENDOR_WWW since we already have the WWW: lines in pkg-descr. That sounds like an excellent idea. I'm just a bit worried about spreading the information over too many places, and would rather split content from logic and add these to pkg-descr as well next to the current WWW. I know we're not consistent already with things like COMMENT and LICENSE already in the Makefile, so won't ojbect too much to where these end up. Erwin With good ideas usually bloat is not too far behind. I think this is a great idea, however I think it would be worth considering a potential new file for this, that can be parsed without causing too much new data in existing files. Perhaps, a file named pkg-vendor. In this file, all sorts of information can be places, and parsed or used by our package infrastructure. I like that idea, but how about carrying it on a bit to enable more metadata, such as Trove categorization, generic descriptions, links to relevant sites of interest for the port, etc.pp. Instead of pkg-vendor, I'd name it pkg-meta or so and something like the following comes into mind: VENDOR: ' NAME : Vendor WWW : UrlOfVendor ' UPSTREAM: ' CONTACT : UpstreamDeveloperContact BUGS : LinkToUpstreamBugTrackerOrWhatever CHANGELOG: LinkToUpstreamChangeLog ' CLASSIFICATION: ' trove classifiers here ' LINKS: ' DOC : LinkToOnlineReference DOC : OtherLinkToOnlineReference RELATED : LinkToRelatedProjectOfRelevance COMMERCIAL : LinkToCommercialSite/Support/whatever YOURIDEAHERE : .. ' Personally, I would not want to see that being parsed by some make-compatible implementation, but would rather see some supplementary script in Tools/ or something else to deal with this. Especially to avoid keeping the format limited to cope with the limitation of make and sh. Since the meta information are not necessary by the ports infrastructure (as pointed out earlier), supplementary third-party tools and projects can and should deal with it. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Installing ports for different versions of Python
On, Sat Oct 05, 2013, Daamn M wrote: Hi, Sorry if I'm asking a question that have been asked many times but I couldn't find an answer using google. I need to install few version of Python (at least 2.6, 2.7 and 3.3). I really appreciate that FreeBSD let me have many versions the same time. But I have a problem when I need some third party library. It turns out that I can have only one instance. For example: I have installed python 2.7 and then port py-someport. Then I installed python 3.3 and set PYTHON_DEFAULT_VERSION to point python 3.3. If I try to install port py-someport again I wll get an error message saying that an older version is already installed. This is a limitation in package handling at the moment. The FreeBSD ports tree unfortunately uses the origin (e.g. devel/py-someport) to check, if a port was already installed, instead of e.g. the package name (e.g. py33-someport, py27-someport, etc.). This is something being out of scope of the FreeBSD python team, but we hope for a change of that behaviour in the near future. The way a port is registered in the database suggest that there could be more than one version. I mean: port py-someport is registered as py27-someport when installed for python 2.7. Now I copy ports adding versio prefix. For example to install py-someport for version 3.3 I copy the port as py33-someport. I works pretty well but I don't find it a clean way. Could you help? Your best chance at the moment would be to use virtualenv, if possible. Most python packages feature pip support, so that you could 1) change to your specific virtualenv 2) pip install python package (or easy_install python package) 3) work in your virtualenv Cheers Marcus pgpg5j5Q8ZPKh.pgp Description: PGP signature
Re: [HEADSUP] Staging, packaging and more
On, Thu Oct 03, 2013, Fernando Apesteguía wrote: El 03/10/2013 22:41, Marcus von Appen m...@freebsd.org escribió: On, Thu Oct 03, 2013, Nathan Whitehorn wrote: On 10/03/13 07:17, Andriy Gapon wrote: on 03/10/2013 11:48 Baptiste Daroussin said the following: This also allows lots of new features to come: - Allow to create sub-packages - Allow to create debuginfo packages. I'd like to mention a few other possibilities along the same lines: - doc packages - examples packages - devel packages (headers, tools and other files required for compiling dependent software, but not generally needed for an end user) Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. Cheers Marcus pgp28gw4TyxxO.pgp Description: PGP signature
Re: [HEADSUP] Staging, packaging and more
On, Thu Oct 03, 2013, Nathan Whitehorn wrote: On 10/03/13 07:17, Andriy Gapon wrote: on 03/10/2013 11:48 Baptiste Daroussin said the following: This also allows lots of new features to come: - Allow to create sub-packages - Allow to create debuginfo packages. I'd like to mention a few other possibilities along the same lines: - doc packages - examples packages - devel packages (headers, tools and other files required for compiling dependent software, but not generally needed for an end user) Please no devel packages. Seconded. Cheers Marcus pgpMsSPQ2iAq5.pgp Description: PGP signature
Re: [RFC] Stage support for easy_install
On, Sat Sep 28, 2013, Olivier Duchateau wrote: 2013/9/26 William Grzybowski w...@freebsd.org: Hi, I made an attempt to support stage for easy-install, you can find the patch here http://people.freebsd.org/~wg/easyinstall-stage.txt Aprrently it works :), let me know what you think. Thanks, it works fine. I made new diff after recent change in Mk/bsd.python.mk https://people.freebsd.org/~olivierd/patches/bsd.python.mk.diff Unfortunately it does not. easy_install has the tendency to create .pth and site.py* files in the stagedir, causing leftovers that we are currently unable to handle. From the recent discussion with some of the distutils people and according to some bug reports to distribute and setuptools, there is currently no guaranteed way not to break things, if we work around that issue (there is a -m switch to easy_install, but that forces eggs to explicitly add a requirement into their import lines). I'm afraid to say that this might take some more time to sort out. Cheers Marcus pgpGEot3Pk3O5.pgp Description: PGP signature
Re: [HEADS UP] Improved python package support ahead
On, Sat Sep 21, 2013, Marcus von Appen wrote:
Two new port Makefile knobs are to be committed to the ports tree in a
couple of days or few weeks.
PYDISTUTILS_AUTOPLIST
This knob will enable the creation of an automatic package list similar
to the linux rpm ports and rubygems. It will work for the majority
packages that do not install files outside of the site-packages and
include directories for python. Ports installing e.g. binaries
might need some additional care, since there is a small regression for
directories within BSD.local.dist.
The regression should be fixed within the latest update of
http://people.freebsd.org/~mva/python_mod_plist.diff.
The local tree under ${PREFIX} should be respected for most of the
cases. Since the conversion to PYDISTUTILS_AUTOPLIST has to be done
individually on a per-port basis, issues with certain ports can be fixed
on demand later on.
If there are no concerns, both knobs will be committed tomorrow or the
day after.
Cheers
Marcus
pgpdaPdYCTJ0a.pgp
Description: PGP signature
[HEADS UP] Improved python package support ahead
Two new port Makefile knobs are to be committed to the ports tree in a couple of days or few weeks. PYDISTUTILS_AUTOPLIST This knob will enable the creation of an automatic package list similar to the linux rpm ports and rubygems. It will work for the majority packages that do not install files outside of the site-packages and include directories for python. Ports installing e.g. binaries might need some additional care, since there is a small regression for directories within BSD.local.dist. The knob supports the traditional distutils as well as easy_install on all currently supported python versions. You can mix contents of an existing pkg-plist (e.g. if the port installs additional documentation) with the automatic results. PYTHON_PY3K_PLIST_HACK Several ports currently install python scripts without using the typical python way of doing things (e.g. devel/glib20), but which are byte-compiled. To enable proper support for python 3.2+ within the package lists, this knob will replace the contents of the existing pkg-plist (e.g. share/port/foo.pyc, share/port/foo.pyo) with the proper values. It's based on the plist include hack existing in devel/py-virtualenv, which is currently used by various ports. Both knobs will improve the situation for python packages to be built for Python 3.x as default version. This will not solve all problems at an instant, but reduces the wrong plist entries being created, if you use python3.x as DEFAULT_PYTHON_VERSION. The patch itself can be retrieved from http://people.freebsd.org/~mva/python_mod_plist.diff Cheers Marcus pgpdhrAQxsdVq.pgp Description: PGP signature
Re: FreeBSD Port: sdl-1.2.15_2,2 build error
Hi David, On, Sat Sep 07, 2013, David Lichti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I encountered an error while building the sdl12 port for FreeBSD 9.1: In file included from ./src/video/x11/SDL_x11dyn.c:96: ./src/video/x11/SDL_x11sym.h:168: error: conflicting types for '_XData32' /usr/local/include/X11/Xlibint.h:650: error: previous declaration of '_XData32' was here gmake: *** [build/SDL_x11dyn.lo] Error 1 === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 I can't recreate that issue. Can you tell me, which version of the xlib package is installed on your system? What does pkg_info libX11* | head -n1 say? Cheers Marcus pgp3KAb6OsrTD.pgp Description: PGP signature
Re: poudriere three pythons
On, Tue Aug 20, 2013, Marko Cupać wrote: On Tue, 20 Aug 2013 17:27:27 +0200 Marko Cupać marko.cu...@mimar.rs wrote: I am trying to set up local pkg repository, and am building packages with poudriere. As a dependency for net/samba36 it builds python - not only lang/python27 (like when built locally with portmaster), but: python-2.7.2-txz python2-2.txz python27-2.7.5_2.txz How to make it build just one python? I did the second test, clearing all packages first and then putting lang/python to the list of packages to be built. This way total of 6 packages are built (of which three pythons): gettext-0.18.3.txz libiconv-1.14_1.txz pkg-1.1.4_1.txz python-2.7.2.txz python2-2.txz python27-2.7.5_2.txz python-2.7.2* and python2-2* are meta-ports providing the symlinks to bin/python and bin/python2. Once all ports can correctly rely on a specific python version at build-time (which is not the case for many ports at the moment), the meta-ports will be removed as required dependency. Cheers Marcus pgpokeVFzW19O.pgp Description: PGP signature
Re: devel/git fails, no /usr/local/bin/python
On, Sun Aug 18, 2013, Poul-Henning Kamp wrote: I just tried to compile a 9-stable with ports r324867 using sysbuild.sh. Along the way the devel/git port fails, for the lack of python: gmake[1]: /usr/local/bin/python: Command not found test $(cat GIT-PYTHON-VERSION 2/dev/null) = || \ flags=--force; \ /usr/local/bin/python setup.py build $flags /usr/local/bin/python: not found I'm not quite sure what /usr/local/bin/python should be or point at, nor who/what/where it should have been created, but I have these: [...] Besides the answer already given, devel/git was updated (along with several other ports so far) some hours ago to catch up with the latest change and should pull in the correct python dependencies automatically now. Cheers Marcus pgpVpGiWZAldw.pgp Description: PGP signature
Re: python 2 and 3 modules
David Demelier demelier.da...@gmail.com:
2013/7/28 Daniel Braniss da...@cs.huji.ac.il:
Hi,
I need to be able to have both (2.7 and 3.2) modules.
setting PYTHON_VERSION=3.2 in /etc/make.conf compiles properly,
but make install, insists that that the 2.7 version is installed!
after deinstalling, it will install the 3.2 version in the correct
directory:
/usr/local/lib/python3.2/site-path
but now I lost the 2.7 version.
the same happens if I try to install the 2.7 version, it will complain
that the 3,2 version is installed.
BTW, the comments in ports/Mk/bsd.python.mk are very confusing and
some are wrong:
# PYTHON_VERSION- Version of the python binary in your
${PATH}, in the
# format python2.0. Set
this in your
makefile in case you
# want to build extensions with an
older binary.
# default: depends on the version of
your python binary
setting it to python3.2 produces errors in the make, while 3.2 is ok
is there any fix?
thanks,
danny
For the moment its pretty difficult to install python 2.7 and 3.3 at
the same time. However, if you plan to install python 3.3, you need to
set PYTHON_DEFAULT_VERSION to python3.3 and not PYTHON_VERSION.
No, it is not.
cd /usr/ports/lang/python27 make install clean
cd /usr/ports/lang/python32 make install clean
cd /usr/ports/lang/python33 make install clean
works like a charm. If you however want to use Python modules, it might become
more difficult. It was discussed some time ago on the freebsd-python
mailing list
without an applicable result.
If you need to have the same Python module for different versions
around, I would
recommend to use virtualenv in favour of the ports infrastructure, since
make -DPYTHON_DEFAULT_VERSION=xxx python-module- or -
make -DPYTHON_VERSION=xxx python-module - or -
make -DPYTHON3_DEFAULT_VERSION=xxx python-module
might mess up previous installations for a different python version.
Cheers
Marcus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: python 2 and 3 modules
David Demelier demelier.da...@gmail.com:
2013/7/29 Marcus von Appen m...@freebsd.org:
David Demelier demelier.da...@gmail.com:
2013/7/28 Daniel Braniss da...@cs.huji.ac.il:
Hi,
I need to be able to have both (2.7 and 3.2) modules.
setting PYTHON_VERSION=3.2 in /etc/make.conf compiles properly,
but make install, insists that that the 2.7 version is installed!
after deinstalling, it will install the 3.2 version in the correct
directory:
/usr/local/lib/python3.2/site-path
but now I lost the 2.7 version.
the same happens if I try to install the 2.7 version, it will complain
that the 3,2 version is installed.
BTW, the comments in ports/Mk/bsd.python.mk are very confusing and
some are wrong:
# PYTHON_VERSION- Version of the python binary in your ${PATH},
in the
# format python2.0. Set this in
your
makefile in case you
# want to build extensions with
an
older binary.
# default: depends on the version
of
your python binary
setting it to python3.2 produces errors in the make, while 3.2 is ok
is there any fix?
thanks,
danny
For the moment its pretty difficult to install python 2.7 and 3.3 at
the same time. However, if you plan to install python 3.3, you need to
set PYTHON_DEFAULT_VERSION to python3.3 and not PYTHON_VERSION.
No, it is not.
cd /usr/ports/lang/python27 make install clean
cd /usr/ports/lang/python32 make install clean
cd /usr/ports/lang/python33 make install clean
works like a charm. If you however want to use Python modules, it might
become
more difficult. It was discussed some time ago on the freebsd-python mailing
list
without an applicable result.
If you need to have the same Python module for different versions around, I
would
recommend to use virtualenv in favour of the ports infrastructure, since
make -DPYTHON_DEFAULT_VERSION=xxx python-module- or -
make -DPYTHON_VERSION=xxx python-module - or -
make -DPYTHON3_DEFAULT_VERSION=xxx python-module
might mess up previous installations for a different python version.
Cheers
Marcus
Of course from ports it will work. I've told about binary packages.
When you bulk build a package for python 2.7 and python 3.3 the
/usr/local/bin/python will be included in both versions. Because bulk
building python 3 modules will requires to set PYTHON_DEFAULT_VERSION
and PYTHON3_DEFAULT_VERSION to the python 3.3 interpreter.
Then the poudriere bulk will generate python 2.7 and python 3.3
pkg-plist including for both /usr/local/bin/python and all of the
non-versioned files I've already told above.
You may now think who cares? it build from ports. I would say no,
binary packages will be used more and more in the future.
I would not, either. This however is a problem with the package builder
and ports infrastructure, which would need some install hooks to allow
a check at installation time.
Cheers
Marcus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: python 2 and 3 modules
Baptiste Daroussin b...@freebsd.org:
On Mon, Jul 29, 2013 at 12:26:24PM +0200, Marcus von Appen wrote:
David Demelier demelier.da...@gmail.com:
2013/7/29 Marcus von Appen m...@freebsd.org:
David Demelier demelier.da...@gmail.com:
2013/7/28 Daniel Braniss da...@cs.huji.ac.il:
Hi,
I need to be able to have both (2.7 and 3.2) modules.
setting PYTHON_VERSION=3.2 in /etc/make.conf compiles properly,
but make install, insists that that the 2.7 version is installed!
after deinstalling, it will install the 3.2 version in the correct
directory:
/usr/local/lib/python3.2/site-path
but now I lost the 2.7 version.
the same happens if I try to install the 2.7 version, it will complain
that the 3,2 version is installed.
BTW, the comments in ports/Mk/bsd.python.mk are very confusing and
some are wrong:
# PYTHON_VERSION- Version of the python binary in your ${PATH},
in the
# format python2.0.
Set this in
your
makefile in case you
# want to build extensions with
an
older binary.
# default: depends on
the version
of
your python binary
setting it to python3.2 produces errors in the make, while 3.2 is ok
is there any fix?
thanks,
danny
For the moment its pretty difficult to install python 2.7 and 3.3 at
the same time. However, if you plan to install python 3.3, you need to
set PYTHON_DEFAULT_VERSION to python3.3 and not PYTHON_VERSION.
No, it is not.
cd /usr/ports/lang/python27 make install clean
cd /usr/ports/lang/python32 make install clean
cd /usr/ports/lang/python33 make install clean
works like a charm. If you however want to use Python modules, it might
become
more difficult. It was discussed some time ago on the
freebsd-python mailing
list
without an applicable result.
If you need to have the same Python module for different
versions around, I
would
recommend to use virtualenv in favour of the ports infrastructure, since
make -DPYTHON_DEFAULT_VERSION=xxx python-module- or -
make -DPYTHON_VERSION=xxx python-module - or -
make -DPYTHON3_DEFAULT_VERSION=xxx python-module
might mess up previous installations for a different python version.
Cheers
Marcus
Of course from ports it will work. I've told about binary packages.
When you bulk build a package for python 2.7 and python 3.3 the
/usr/local/bin/python will be included in both versions. Because bulk
building python 3 modules will requires to set PYTHON_DEFAULT_VERSION
and PYTHON3_DEFAULT_VERSION to the python 3.3 interpreter.
Then the poudriere bulk will generate python 2.7 and python 3.3
pkg-plist including for both /usr/local/bin/python and all of the
non-versioned files I've already told above.
You may now think who cares? it build from ports. I would say no,
binary packages will be used more and more in the future.
I would not, either. This however is a problem with the package builder
and ports infrastructure, which would need some install hooks to allow
a check at installation time.
That is totally wrong, that is a python bug (python is not the only
one in that
case).
It is not wrong. You just misunderstood me.
The ports have only be design for source installation, problem is
when you are
buidling packages properly each packages are being done in a cleanroom aka a
jail without anything installed in it that makes python 3.3 port think it is
becoming the default because no other python are installed at that time.
This result in all python port defining bin/python, and thus they
_do_ conflict
with each other. While this was/is silent with pkg_install, pkgng
yell about it.
On the port level, yes, with the IF_DEFAULT conditional.
We have lang/python, which acts as wrapper; what conditional in
the package builder triggers either port of lang/pythonXX to install itself
as default (except for the current default version defined in bsd.python.mk,
which uses _PYTHON_PORTBRANCH for that)? If I closely follow the port logic,
only lang/python27 should be picked as default, if no specific flags are
provided. Or I'm missing something obvious in the bsd.python.mk logic.
A fun thing you can do with pkg_install (in binary mode only no
compilation from
sources and with packages built in a cleanroom)
# pkg_add -r python27
default is now python27
# pkg_add -r python33
default is now python33
# pkg_delete python27
hey I have no default python anymore.
If that is really the case (I can only confirm that for lang/python27),
let's get it fixed on the bsd.python.mk and lang/pythonXX level and let
lang/python do the magic, which it is supposed to do.
Java is solving the problem by using a javawrapper. There is 3
possible way to
solve the situation with python, move the symlink dancing into a post install
script. Have a javawrapper like thing.
The post-install script is what I was talking about above. So we
Re: Change design of py-* ruby-* ports
On, Thu Apr 25, 2013, David Demelier wrote:
Hello,
Currently the ports tree has unified ports for python and ruby modules with
origin like databases/py-sqlalchemy. When someone wants to bulk the
ports tree to create packages the databases/py-sqlalchemy will only
be built against the current python version set in Mk/bsd.python.mk
(or overriden in make.conf).
Or at the command-line for indiviual ports.
This is a very bad design and we should fix that as soon as possible,
we are a lot of people and some portmgr folks included that is not the
best way to manage python / ruby modules.
Let say I want to install a package, unfortunately this one requires some
python modules that are only working for python 2.7 but me as a developer I
want to develop with python 3, then we are stuck.
Correct. This is the general limitation of depending on a package
infrastructure for your specific operating system - or the developer's
fault, since he did not yet port the module to your specific version -
or the maintainer's, since he could not ensure that the port is stabe
enough for your favourite version.
What we need to do now, is to move *all* py-* and ruby-* to their respective
versions i.e py27-* and ruby19 (or 18?).
Then we will need to copy all of these and set them to the newer version so
py33 and ruby20.
And initiate a hell of repocopying and testing on each minor
release. And cause maintainers to have a lot of additional maintenance
efforts. And, and, and, ... No, thanks.
Also this will remove the breakage of OPTIONS, all of these ports needs the
dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
This will blow out the ports tree by adding a lot of ports, but it's the best
way to cover the both version and future bulk generation for users.
No, it is not. It is the best way you thought of so far.
Your problem description is too unspecific or too easy to solve. Right
now it reads as
* one shall be able to install py27-, py32-, ... ports (or ruby) in
parallel - fair enough, then we need to fix the following issue along
with some other minor side effects:
/usr/ports/devel/py-logilab-common # make PYTHON_DEFAULT_VERSION=python3.2
PYTHON3_DEFAULT_VERSION=python3.2 install
=== Installing for py32-logilab-common-0.59.0
=== py32-logilab-common-0.59.0 depends on file: /usr/local/bin/python3.2 -
found
=== Generating temporary packing list
=== Checking if devel/py-logilab-common already installed
=== An older version of devel/py-logilab-common is already installed
(py27-logilab-common-0.59.0)
Cheers
Marcus
pgpTUqYCnUwo0.pgp
Description: PGP signature
Re: Change design of py-* ruby-* ports
On, Thu Apr 25, 2013, David Demelier wrote:
[...]
And if a port requires a py- module but for a specific version, how is it
possible to share PYTHON_VERSION= through dependencies?
This is done at the moment by using
# Propagate the chosen python version to submakes.
.MAKEFLAGS: PYTHON_VERSION=python${_PYTHON_VERSION}
within bsd.python.mk, which opens a different can of worms (see
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167368 for details)
Cheers
Marcus
pgp6WMie1ERUw.pgp
Description: PGP signature
Re: graphics/opencv ISSUE with gcc 4.6.3
On, Wed Jan 16, 2013, awarecons wrote: [...] Can you please use send-pr(1) or the web interface[1] instead of those mails or at least provide enough information about your system environment to allow one to actually investigate on the issues, you mention? send-pr or [1] also have the advantage that your reports do not get lost. [1] http://www.freebsd.org/send-pr.html Thanks Marcus pgpfQJcsLQIRL.pgp Description: PGP signature
Re: lang/perl5.14 GNU PThread mult. ISSUEs
On, Mon Jan 07, 2013, awarecons wrote:
uname: FreeBSD 9.0-RELEASE
How to reproduce:
compile, guess any 5.[12-16], perl with GNU PThread support and try,
for e.g., portmaster x11/kde4 or x11/gnome2 with maximum ports
involved/chosen (to enlarge test coverage). Try to use clang, gcc 4.2
(default) and 4.6.3 (gcc 4.74.8 seem to be excessively errorneous),
some of the error-bunch:
[bunch of error examples]
When perl5.14 is compiled without GNU PThread - no such errors, is it
normal to GNU PThread, just wonder??..
Thank you in advance and luck.
This sounds to me as if lang/perl is hit by some issue similar to what
happened for the lang/python ports, when compiled with PTH enabled.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/146644
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/156425
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/172190
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/170754
A quick and dirty fix for a user might be to add
${LOCALBASE}/include/pth as permanent include directory to the
environment's CFLAGS/CPPFLAGS (at least for building ports), though I
would not recommend it.
Cheers
Marcus
pgpq4YEsiiEKF.pgp
Description: PGP signature
Re: graphics/opencv apparently broken, also out of date: update
On, Sun Dec 23, 2012, Thomas Mueller wrote:
I originally sent this early last November, but nothing happened, and
now the ports freeze is over.
I had great difficulty using send-pr when submitting the problem with
graphics/gnash, couldn't set MAIL_AGENT to what I use (msmtp) with sendmail
not set up: just got error messages. Try again?
I am snagged in graphics/opencv in my massive upgrade of ports, and see error
messages in the log file indicating errors in the C code. I also see there is
a newer version of openCV out. But I was able to pigeonhole graphics/opencv
and four other ports that depend on opencv and complete the rest of the
massive
upgrade of ports.
I think, I sent you some instructions on how to fix it, in case it is a
Python-related issue that I struggled into as well.
[...]
Scanning dependencies of target opencv_python
[ 63%] Building CXX object
modules/python/CMakeFiles/opencv_python.dir/src2/cv2.o
[...]
Yes, it is Python, which causes it. Find a patch attached, which should
fix the issue. Please apply it as follows:
# cd /usr/ports/graphics/opencv
# patch -p0 /path/to/the/opencv.patch
# rm Makefile.orig files/extra-patch-opencv_nopython.orig
After you have patched it, you can try to build and install graphics/opencv
again. Let me know, if this solves the issue for you.
Cheers
Marcus
Index: Makefile
===
--- Makefile (revision 309416)
+++ Makefile (working copy)
@@ -30,7 +30,8 @@
PLIST_SUB+= VERSION=${DISTVERSION}
.if !defined(_BUILDING_OPENCV_CORE) !defined(_BUILDING_OPENCV_PYTHON)
-EXTRA_PATCHES+= ${FILESDIR}/extra-patch-opencv
+EXTRA_PATCHES+= ${FILESDIR}/extra-patch-opencv \
+ ${FILESDIR}/extra-patch-opencv_nopython
LIB_DEPENDS+= opencv_core.2:${PORTSDIR}/graphics/opencv-core
LDFLAGS+= -L${LOCALBASE}/lib
Index: files/extra-patch-opencv_nopython
===
--- files/extra-patch-opencv_nopython (revision 0)
+++ files/extra-patch-opencv_nopython (working copy)
@@ -0,0 +1,13 @@
+--- CMakeLists.txt.orig 2012-12-21 08:53:28.0 +0100
CMakeLists.txt 2012-12-21 08:53:54.0 +0100
+@@ -646,8 +646,8 @@
+
+ # Always try to find python
+ # ===
+-find_host_package(PythonInterp)
+-find_host_package(PythonLibs)
++#find_host_package(PythonInterp)
++#find_host_package(PythonLibs)
+
+ # cmake 2.4 (at least on Ubuntu 8.04 (hardy)) don't define PYTHONLIBS_FOUND
+ if(NOT PYTHONLIBS_FOUND AND PYTHON_INCLUDE_PATH)
pgp2L6IKB9sVQ.pgp
Description: PGP signature
Re: graphics/opencv apparently broken, also out of date: any hope of update?
On, Fri Dec 21, 2012, Thomas Mueller wrote: Any hope of updating graphics/opencv, now at version 2.4.3 . I just checked again. I complained about this port being broken last October, and no action on updating even though the ports freeze is past. I do not see any PR from you, so I guess you only complained here. Do you mind to give some more details about how and what fails for you when building graphics/opencv? Ideally (but not necessarily) as a PR, so we do not lose the information and someone can take care of it? Please keep in mind that the mailing list is not a bug tracker, so that information and reports get lost, if noone picks them up. Cheers Marcus pgpksGLWZsTF0.pgp Description: PGP signature
Re: net/liveMedia
On, Wed Dec 12, 2012, Австин Ким wrote: 1212 Wednesday, 12 December 2012 (EST) [15686] Build error encountered during build of multimedia/vlc: In file included from live555.cpp:61:0: /usr/local/live/liveMedia/include/liveMedia.hh:114:38: fatal error: ProxyServerMediaSession.hh: No such file or directory compilation terminated. Suggested patch: In the file: /usr/local/live/liveMedia/include/liveMedia.hh Suggest replacing the following line: #include ProxyServerMediaSession.hh With the following two lines: #include MediaSession.hh #include ServerMediaSession.hh net/liveMedia has been fixed already and all dependent ports should build fine again. Please update your ports tree. Thanks for reporting! Cheers Marcus pgpvtZQz6MknX.pgp Description: PGP signature
Re: Is PR database updated?
Mark Linimon lini...@lonesome.com: On Fri, Nov 16, 2012 at 08:13:47AM +0100, Fernando Apesteguía wrote: Is there some problem with the PR database? The web part of the database is not updating. We are working on it. Wouldn't it make sense to add that information temporarily to the GNATS-Webpage(s), so we avoid further confusion and requests? Or is the problem fixed in the next few hours? :-) Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Is PR database updated?
On, Fri Nov 16, 2012, Miroslav Lachman wrote: Eitan Adler wrote: [...] Wouldn't it make sense to add that information temporarily to the GNATS-Webpage(s), so we avoid further confusion and requests? Or is the problem fixed in the next few hours? :-) see freebsd.org right under learn more. Well hidden important message. Not really hidden, but not an eye-catcher either. I've mistaken that block for the content belonging to Based on BSD UNIX. This really, really should be fixed/changed, so such information is easier to find. Cheers Marcus pgpjT9zDfEmtR.pgp Description: PGP signature
Re: General usefulness of option descriptions
On, Sun Oct 07, 2012, Michael Gmelin wrote: Hi, This probably has been discussed before, but I think in many cases using the default descriptions of OptionsNG is more harm than good. That's not entirely true. They can provide a fallback, if the port maintainer forgot to add a meaningful description. I converted security/libpreludedb to OptionsNG yesterday and left in most of the descriptions and therefore overrode them. I did that for a good reason, since I believe that the description of the option should be more than just repeating the option name. Unfortunately the portmgr in charge disagreed and removed all description overrides, figuring that I must have forgotten to remove them. That's why I raise this topic on the list - I feel like we're using a lot of information if we converting ports like this. In this specific example this means: Before: PERL=off: Include Perl bindings PYTHON=off: Include Python bindings MYSQL=on: Use MySQL backend PGSQL=off: Use PostgreSQL backend SQLITE=off: Use SQLite backend Afterwards: DOCS=on: Build and/or install documentation MYSQL=on: MySQL database PERL=off: Perl scripting language PGSQL=off: PostgreSQL database PYTHON=off: Python bindings SQLITE=off: SQLite database This might not seem dramatic at a first glance, but something bad just happened here. We moved from describing what the option actually means to the user in the context of the port (Include Perl binding, Use MySQL backend) to what it means to the ports tree (Perl scripting language, MySQL database). The purpose of using the option in context of the port is not visible anymore and at this point showing the user MYSQL PERL PGSQL PYTHON SQLITE as options without any descriptions would provide just as much information. The descriptions are defaults, not mandatory. You always can provide your own PERL_DESC - bsd.options.desc.mk just assigns default values, if the port does not provide them already. Thus, if you need a context-specific description, which does not match with the default provided by bsd.options.desc.mk, you can provide your own. [...] 3. Global option descriptions seem inconsistent as well (all kinds exist like support/backend/bindings etc., probably depending on the first port that used them) and to make matters worse, they're actually changing, e.g. bsd.options.desc.mk from 2012/08/31 said: MYSQL_DESC?= MySQL backend While the one from 2012/10/07 says: MYSQL_DESC?= MySQL database So even if using the default was contextually correct at some point, it could just be changed without the maintainer noticing it. This indeed is problematic and I stumble over this from time to time myself. Since bsd.options.desc.mk can be changed by every committer and is still fairly young, this is unavoidable, especially since there are no real rules yet. Guidelines for the naming might be good, such as: If X provides a audio codec, the description has to be X audio codec support If X provides a video codec, the description has to be X video codec support If X provides a database binding, the description has to be X database support ... Mabye we can flesh that out based on what we have in bsd.options.mk already and add it to the docs and comment section of the file. Cheers Marcus pgpPjywtAQdTS.pgp Description: PGP signature
Re: maintainer timeout for FreeBSD commiters
Radim Kolar h...@filez.com: We *are* making progress in cutting through the backlog though. ports have about 900 open PR. Why it does not have more port commiters? Its difficult to recruit new person? More committers does not mean that the backlog will be processed faster, just as more developers on a project does not mean that the project is done faster. ;-) Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port system problems
Baptiste Daroussin b...@freebsd.org: On Tue, Jun 26, 2012 at 12:22:28AM +0200, Florent Peterschmitt wrote: Hello, I'm not a developer and I know how it's difficult to make a port (or some ports, for example VirtualBox) but I think the port system has many problems: 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). 2. Option system is not really well documented What kind of documentation do you need?, please report what you are expected so that we can improve it 3. Some dependencies are totally useless Please report PR 4. So slow... What is slow do you mean compiling is slow? Let me give some examples: 1. games/wesnoth should be splitted in games/wesnoth-bin and games/wesnoth-datas. Why rebuild everything when just binaries needs ? This is coming, it takes lot of time, and some things have to be done first, in the infrastructure that the user do not see much. I do not see any necessity for infrastructure changes here - we did that in the past for several ports (e.g. alephone, alienarena, ...). 2. Why do we have to put WITH_NEW_XORG in /etc/make.conf to get it ? Why not put this var in a port configuration file which will be read by all ports needing this var ? Because this is not that easy, do you have a technical way to propose? I think noone is really happy with the WITH_NEW_XORG, but this is the less worse :) way we found, if you have a better way to propose, please step up and propose. /etc/make.conf (or whatever to be included in /etc/make.conf) can be seen as port configuration file that is evaluated by the ports. And each port picks those things, it needs. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port system problems
Matthew Seaman m.sea...@infracaninophile.co.uk: On 26/06/2012 08:26, Marcus von Appen wrote: 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). Actually, yes -- that's pretty much exactly what we're talking about here. Why do you feel subpackages would be a bad thing? Because it makes installing ports more complex, causes maintainers to rip upstream installation routines apart, and burdens users with additional tasks to perform for what particular benefit (except saving some disk space)? If I want to do some development the Debian way, I would need to do the following: - install foo-bin (if it ships with binaries) - install foo-lib (libraries, etc.) - install foo-dev (headers, etc.) - install foo-doc (API docs) With the ports I am currently doing: - install foo What are the requirements, use cases and benefits for splitting up packages in such a way? How would it work with the ports infrastructure without making things more complex for port maintainers and the different port installation scenarios, we have? Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port system problems
Baptiste Daroussin b...@freebsd.org: On Tue, Jun 26, 2012 at 10:34:00AM +0200, Marcus von Appen wrote: Matthew Seaman m.sea...@infracaninophile.co.uk: On 26/06/2012 08:26, Marcus von Appen wrote: 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). Actually, yes -- that's pretty much exactly what we're talking about here. Why do you feel subpackages would be a bad thing? Because it makes installing ports more complex, causes maintainers to rip upstream installation routines apart, and burdens users with additional tasks to perform for what particular benefit (except saving some disk space)? If I want to do some development the Debian way, I would need to do the following: - install foo-bin (if it ships with binaries) - install foo-lib (libraries, etc.) - install foo-dev (headers, etc.) - install foo-doc (API docs) With the ports I am currently doing: - install foo yes but you do not allow to install 2 packages one depending on mysql51 and one depending on mysql55, there will be conflicts on dependency just because of developpement files, the runtime can be made not to conflict. But I can't install mysql51-dev and mysql55-dev. Resolving those conflicts by e.g. introducing unique prefixes would be much better. Shouldn't we rather find a solid concept for avoiding CONFLICT entries by using e.g. improved prefixes, instead of starting to split packages, which does not add any noticeable benefit (at least I can't see one yet). I trust maintainers to no abuse package splitting and do it when it make sense. In the case you give I would probably split the package that way: foo (everything needed in runtime: bin + libraries) If the libs of e.g. mysql51 and mysql55 are named similar, we still have the same problem as mentioned above and end up with additionaly hackery, which better would be placed elsewhere. foo-dev (everything needed for developper: headers, static libraries, pkg-config stuff, libtool stuff, API docs) foo-docs (all user documentation about the runtime) For which version? 51, 55? Again, we need some prefix hackery to keep that clean and allow a side-by-side installation. Although I refer to your example, it is not limited to it. The same applies to other ports, which install multiple versions. I doubt, that splitting ports is the right way to go here, since it does not solve the initial problem. As long as there are CONFLICTs, splitting just tries to circumvent them. Instead we should handle them right from the start. We did it with some success (and still existing regressions) for e.g. lang/python. So we surely can take our time to edge out some guidelines and best practices for avoiding CONFLICTs. Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port system problems
Matthew Seaman m.sea...@infracaninophile.co.uk: On 26/06/2012 10:31, Andrea Venturoli wrote: On 06/26/12 11:03, Matthew Seaman wrote: Yes, it will multiply the number of ports. By three is about right, given that most ports will only have port-docs and port-examples sub-ports. However, first of all, you are assuming that the effort required to install each of those sub-ports is the same as it is to install a single port now. That is simply not the case. Not exactly. I still didn't get the details, so I might speak nonsense, however... The effort will be 3x processing time for portupgrade (or whatever) to update the package database 3 times as much as before. I remember the big X.org split up: going from a few ports to tens of them slowed down an installation/upgrade process by an order of magnitude (or even more). The X.org split up is an extreme case -- it went from three or four ports to several hundred ports as I recall. Yes, that made a big difference, because they were all individual ports and all of the processing steps required to install a port had to be repeated for each of them. Sub-ports should be much more efficient, as there's a lot of the work involved in installing which is a one-time thing when installing port plus some collection of sub-ports. How does that look like in detail? Are there any concepts on about how it is supposed to work, what the implications are, and so forth? Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port system problems
Matthew Seaman m.sea...@infracaninophile.co.uk: On 26/06/2012 12:07, Marcus von Appen wrote: Sub-ports should be much more efficient, as there's a lot of the work involved in installing which is a one-time thing when installing port plus some collection of sub-ports. How does that look like in detail? Are there any concepts on about how it is supposed to work, what the implications are, and so forth? Please understand that a lot of this stuff exists only in various people's heads and is subject to arbitrary change as ideas evolve. Other parts are more-or-less documented; some is already under development and may or may not require various degrees of revision in the light of experience. I understand that quite well, but I fear that we miss to document it in the long-term. When I started fiddling around with bsd.port.mk in my early days, it sometimes was a pain to figure out, why code XYZ is in there and at which point of time it is triggered for exactly what purpose. Yes, I could have bugged those, who know, but I'd rather see that written down somewhere, so others can start faster with less nagging (which includes me, too, as someone to get started with writing things down :-). Hence I would love to see some docs on the bigger things that are on the doorstep, so that learning and understanding the overall system is less time consuming. Plus, a documentation (draft) in e.g. the Wiki allows a broader feedback and sharing of ideas without moving back and forth in the mailing list history. [long exaplanation of how the system is supposed to work] From what I understand, the whole magic happens in step 7-9. The port builds as usual, installs itself in a fake root (stagedir) and packages are created based on the relative paths, PORTEXAMPLES/DOCS, ... entries or plist placeholders or whatever. The maintainers are - if I got that right - completely off the hook with modifying their ports to split them in some way or another, correct? Do you mind to put your explanation into the Wiki (maybe using the StageDir page, since this would better explain what the purpose of StageDir is)? Cheers Marcus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port system problems
On, Tue Jun 26, 2012, Mark Felder wrote: On Tue, 26 Jun 2012 04:31:40 -0500, Andrea Venturoli m...@netfence.it wrote: The effort will be 3x processing time for portupgrade (or whatever) to update the package database 3 times as much as before. pkgng uses sqlite. Please provide proof that it is as slow or slower than our current package database is. If I am trying to convince a customer of some solution X, I usually do not tell him to provide proof that the offered solution is worse than the current one when negotiating. Instead I try to convince him that the offered solution is better, more robust, future-proof, easier to maintain and saves tons of money. Please do not validate a system as good, just because noone yet provided some figures that outline that the existing system is in fact worse. That said, I might assume that the sqlite solution is faster, but noone can see that yet. Cheers Marcus pgpppmwwlATqu.pgp Description: PGP signature
Re: Port system problems
On, Tue Jun 26, 2012, Florent Peterschmitt wrote:
On 26.06.2012 11:03, Matthew Seaman wrote:
On 26/06/2012 09:17, Andrea Venturoli wrote:
On 06/26/12 09:58, Matthew Seaman wrote:
On 26/06/2012 08:26, Marcus von Appen wrote:
1. Ports are not modular
What do you mean by modular? if you are speaking about subpackages it
is coming,
but it takes time
I hope, we are not talking about some Debian-like approach here
(foo-bin,
foo-dev, foo-doc, ).
Actually, yes -- that's pretty much exactly what we're talking about
here. Why do you feel subpackages would be a bad thing?
Can I share my 2c?
Because it will just multiply be three the number of ports each of us
has to install/maintain/upgrade/etc...
Yes, it will multiply the number of ports. By three is about right,
given that most ports will only have port-docs and port-examples
sub-ports. However, first of all, you are assuming that the effort
required to install each of those sub-ports is the same as it is to
install a single port now. That is simply not the case.
If you want to install the foo/bar port, then (as now) you'ld
essentially[+] --
# cd ${PORTSDIR}/foo/bar
# make
# make install
but you'ld end up with bar-0.99, bar-doc-0.99 and bar-examples-0.99
installed. Unless you have a setting like NOPORTDOCS or NOPORTEXAMPLES
(probably controlled by a dialogue menu like any other options) which
means you don't get the associated -docs or -examples sub-ports.
That's no real change in terms of what you'ld have to do compared to now.
The difference is that if you install from packages, you now have the
opportunity not to install docs or examples.
Secondly, that's just one example of how sub-ports should work, and
docs/examples will be special-cased given their ubiquity. Most
sub-ports would be controlled by port OPTIONS dialogues.
A typical example would involve client-server apps -- so mysqlNN-server
becomes a sub-port of mysqlNN-client. You get to check a box saying
'install the server as well as the client' when you go to install
mysqlNN. Similarly all those php5-XYZ modules become sub-ports of
lang/php5. The big difference being that the port and all its sub-ports
are compiled in one step, and just packaged separately. Which is
probably less work overall that the current situation with ports and
slave-ports.
Cheers,
Matthew
[+] Or more likely you'ld use portupgrade or portmaster or similar to
run these steps for you.
Hello,
It's exactly what I wanted to say. I think so that port system should
adapt to this way of building ports. I mean that is instead of having
vala, we have vala-bin, vala-doc, vala-lib and vala-examples, and port
system don't untar vala archive for each port, but once and pick up
files into this unique directory. Then no waste of time because untar is
what takes most time for big ports.
We should still have a vala port, which is used to configure what we
want (other subports -examples, -lib and -doc).
But where it can be very useful, it's when we have a big port made of
many libraries, like Mono. We should be able to split it, because I
don't want to build everything.
I can't see that from the rough outline given earlier. What I understood
is that some stagedir is used to build mono, then packages (-lib, -doc,
-whatever) are created and installed.
If you do not use downloaded packages, but install them yourself, you'd
need to rebuild the complete mono port on an update.
Happy to be corrected here
Marcus
pgps2HkoVeLBo.pgp
Description: PGP signature
Re: Port system problems
On, Tue Jun 26, 2012, Jeremy Messenger wrote: On Tue, Jun 26, 2012 at 3:44 AM, Baptiste Daroussin b...@freebsd.org wrote: On Tue, Jun 26, 2012 at 10:34:00AM +0200, Marcus von Appen wrote: Matthew Seaman m.sea...@infracaninophile.co.uk: On 26/06/2012 08:26, Marcus von Appen wrote: 1. Ports are not modular What do you mean by modular? if you are speaking about subpackages it is coming, but it takes time I hope, we are not talking about some Debian-like approach here (foo-bin, foo-dev, foo-doc, ). Actually, yes -- that's pretty much exactly what we're talking about here. Why do you feel subpackages would be a bad thing? Because it makes installing ports more complex, causes maintainers to rip upstream installation routines apart, and burdens users with additional tasks to perform for what particular benefit (except saving some disk space)? If I want to do some development the Debian way, I would need to do the following: - install foo-bin (if it ships with binaries) - install foo-lib (libraries, etc.) - install foo-dev (headers, etc.) - install foo-doc (API docs) With the ports I am currently doing: - install foo I agree. yes but you do not allow to install 2 packages one depending on mysql51 and one depending on mysql55, there will be conflicts on dependency just because of developpement files, the runtime can be made not to conflict. I trust maintainers to no abuse package splitting and do it when it make sense. In the case you give I would probably split the package that way: foo (everything needed in runtime: bin + libraries) foo-dev (everything needed for developper: headers, static libraries, pkg-config stuff, libtool stuff, API docs) foo-docs (all user documentation about the runtime) of course there will be no rule on how to split packages, just common sense. Disagree. We shouldn't split for that. Have you seen how many Linux users report when they can't compile one of application, just because they didn't install the *-dev? A LOT (thousands and thousands)! When it's A LOT then it means that it's flawed. If the upstream provide the split tarballs then I do not have any problem with it. Seconded. For newcomers, such a package system is as complex as an Ubuntu or Debian (under the hood), if they just want to do X. Archlinux does provide complete packages, which makes perfect sense for me. I still do not see any reason or argument on why we would need sub-packages. Cheers Marcus pgpygwkrUSsvY.pgp Description: PGP signature
Re: Port system problems
On, Tue Jun 26, 2012, Baptiste Daroussin wrote: [...] 2. Option system is not really well documented What kind of documentation do you need?, please report what you are expected so that we can improve it 3. Some dependencies are totally useless Please report PR 4. So slow... What is slow do you mean compiling is slow? Let me give some examples: 1. games/wesnoth should be splitted in games/wesnoth-bin and games/wesnoth-datas. Why rebuild everything when just binaries needs ? This is coming, it takes lot of time, and some things have to be done first, in the infrastructure that the user do not see much. I do not see any necessity for infrastructure changes here - we did that in the past for several ports (e.g. alephone, alienarena, ...). No be able to have sub packages and flavours (aka N packages from one port) there are changes needed Being able to and having the need to do something are two different things. Do we need this or do we make things more complex by taking sub-packages into consideration (for both or either one, the ports Makefile infrastructure and package tool(s))? Cheers Marcus pgp1DZHSh2HJA.pgp Description: PGP signature
Re: Port system problems
On, Tue Jun 26, 2012, Mark Felder wrote: On Tue, 26 Jun 2012 13:50:48 -0500, Marcus von Appen m...@freebsd.org wrote: I still do not see any reason or argument on why we would need sub-packages. I want up to date packages for all my servers. My servers all have different requirements -- I want Apache with LDAP here, and definitely Apache without LDAP there. Designing a package-building and deployment system for a non-homogenous server farm is an exercise in futility. Having proper sub-packages fixes this issue in a cleanly supportable fashion. That sound good to me and something I'd vote for, since it does not split ports on a technical, but functional level into packages. Cheers Marcus pgp7HNvIgfmrY.pgp Description: PGP signature
Re: Port system problems
On, Tue Jun 26, 2012, Mark Felder wrote: On Tue, 26 Jun 2012 13:42:54 -0500, Marcus von Appen m...@freebsd.org wrote: That said, I might assume that the sqlite solution is faster, but noone can see that yet. The new system will be much, much better overall and people just need to stop making conclusions without knowing all the facts. Then please provide facts. Do not get me wrong - I neither want to be nit-picking (well, just a bit ;-) nor I want to fight that idea by any means, but there was just a sub-packages with StageDir will improve everything rant without any arguments. It's going to be a heavily revamped system so people should stop comparing it to our current architecture. It's only similar on the surface. Why should we stop to compare it? It aims to replace an architecture and hence performs similar tasks and tries to fulfill certain needs. That should qualify it for comparision in one or another way. Once more: I do not oppose the idea, but right now I do not see any sustainable concept nor anything else. I do not want all those working on it to run into a situation in which more people are unhappy with the solution provided. I also do not want to work with a system that burdens me with tasks that I do not _want_ to fulfill. This is why I ask about all those things, so I can throw in my to cents to make the system appealing for me. And thus I want to understand at least the big picture, concept and workflows. Cheers Marcus pgpLph6IJ1VT9.pgp Description: PGP signature
Re: Port system problems
On, Tue Jun 26, 2012, Matthew Seaman wrote: On 26/06/2012 19:46, Marcus von Appen wrote: I can't see that from the rough outline given earlier. What I understood is that some stagedir is used to build mono, then packages (-lib, -doc, -whatever) are created and installed. If you do not use downloaded packages, but install them yourself, you'd need to rebuild the complete mono port on an update. Happy to be corrected here I don't know anything about the particulars of the mono port, but if it makes sense to divide it into several slave ports, then that will still be possible. Use of sub-ports is not going to be mandatory. Well, possibly with the exception of docs and/or examples, but that shouldn't be a huge burden for anyone. Right - we should be careful about how to split ports, however. And some -dev/-bin/-lib/-doc approach is nothing I would consider benefitial. A port with sub-packages based on functionality, which can be installed according to the use case provided by Mark makes more sense here. Remember what the big win is here: a binary package system that is fit for purpose and that preserves as much of the functionality and flexibility of the ports as possible. Yes, compiling from source yourself is the gold standard, but we think it would be pretty great if there was a binary package management system that was good enough that you don't actually /have/ to do that if you don't want to. Exactly. Also, you need to consider the maintainers. It must be ensured, that they do not have to fiddle with nth of sub-package adjustments just to support those properly. Cheers Marcus pgpurm120WTtX.pgp Description: PGP signature
Re: openal-soft
Shane Ambler free...@shaneware.biz:
On 22/04/2012 08:20, ajtiM wrote:
Update to openal-soft fron 1.13 to 1.14 doesn't works on my FreeBSD 9.0
release:
Linking C executable alstream
/usr/bin/ld: cannot find -lavcodec
*** Error code 1
Stop in /usr/ports/audio/openal-soft/work/openal-soft-1.14.
*** Error code 1
Personally I added the following to my /etc/make.conf for a temporary fix
.if ${.CURDIR:M*/audio/openal-soft*}
LDFLAGS+= -L/usr/local/lib
.endif
The linking issue with ffmpeg has been fixed yesterday, so you should
be able to
build and update openal-soft without any problems now.
Cheers
Marcus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
USE_PYTHON usage shadows dependency requirements and creates conflicts
Hi,
I stumbled upon an interesting issue today, which might have been
discussed at length earlier, but I was unable to find any reference so
far.
Using USE_PYTHON=x.y in a port A, which has a dependency on another port
B, which also defines USE_PYTHON=q.w will cause a IGNORE to be raised
from bsd.python.mk, since _PYTHON_VERSION_NONSUPPORTED gets set to
whatever the USE_PYTHON value from port A was.
Test case:
Create 2 directories, /usr/ports/devel/fake1 and /usr/ports/devel/fake2
Add the Makefiles (diffs below) to both:
diff -Nur /nonexistent/Makefile fake1/Makefile
--- /nonexistent/Makefile 1970-01-01 01:00:00.0 +0100
+++ fake1/Makefile 2012-04-21 11:55:05.0 +0200
@@ -0,0 +1,9 @@
+PORTNAME= fake1
+PORTVERSION= 1
+CATEGORIES=devel
+
+LIB_DEPENDS= fake2.0:${PORTSDIR}/devel/fake2
+
+USE_PYTHON=3.2
+
+.include bsd.port.mk
diff -Nur /nonexistent/Makefile fake2/Makefile
--- /nonexistent/Makefile 1970-01-01 01:00:00.0 +0100
+++ fake2/Makefile 2012-04-21 11:55:13.0 +0200
@@ -0,0 +1,6 @@
+PORTNAME= fake2
+PORTVERSION= 1
+
+USE_PYTHON=2.5-3.1
+
+.include bsd.port.mk
Execute make depends in /usr/ports/devel/fake1.
/usr/ports/devel/fake1 # make depends
=== fake1-1 depends on shared library: fake2.0 - not found
===Verifying install for fake2.0 in /usr/ports/devel/fake2
=== fake2-1 needs Python 3.1 at most. But you specified 3.2.
*** Error code 1
Stop in /usr/ports/devel/fake2.
*** Error code 1
Stop in /usr/ports/devel/fake1.
Installing fake2 before fake1 will circumvent the problem, which however
does not help the typical ports tree user.
It looks to me like we have an isolation issue for environment/make
variables here. Could other parts be affected, too or can we assume that
this issue solely affects bsd.python.mk at the moment?
Regards
Marcus
pgpGo6LauNrPM.pgp
Description: PGP signature
Re: FreeBSD port: blender_2.49b_5
Hi Bruno, On, Sat Aug 14, 2010, Bruno d'Arcangeli wrote: Hi, Do you plan to port blender 2.53? Yes, as soon as it will be released as a stable version. I know that it is a beta version but it is really stable. The ongoing changes within the blender SVN, which scares me to update graphics/blender to some beta version. Maybe a graphics/blender-devel port with the beta might be sufficient for you? Note that this however might change (in)frequently, depending on the blender (alpha/beta) releases. Regards Marcus pgpGAzMrvBLvY.pgp Description: PGP signature
Re: ports/148223: [PATCH] editors/hte ability to install as hte instead of ht
On, Tue Jul 13, 2010, Aldis Berjoza wrote: On 13/07/2010 22:41, m...@freebsd.org wrote: Synopsis: [PATCH] editors/hte ability to install as hte instead of ht State-Changed-From-To: open-feedback State-Changed-By: mva State-Changed-When: Tue Jul 13 19:41:11 UTC 2010 State-Changed-Why: In my opinion it does not make much sense to add a CONFLICTS in case someone uses the default options for editors/hte, if it could be avoided by simply renaming the ht binary of the upcoming texlive-core port to something else and add a pkg-message entry for it. This causes less work for users of both ports. Is there some important reason, why texlive-core's ht binary should not be renamed for the port? http://www.freebsd.org/cgi/query-pr.cgi?pr=148223 hte is only 1 binary, while texlive is HUGE (+-5229 distfiles) It my opinion it's much easier to rename hte and add CONFLICTS line, then risk breaking HUGE system such as texlive. Even more, I'd personally prefer hte to install hte binary instead of ht. I remember back in days, when I just started using FreeBSD and was a noob, it took me quite some time to figure out, that editors/hte port install ht binary So I also propose to install editors/hte as hte instead of ht (however, that probably breaks some licensing terms or something like that. Correct me if I'm wrong) Also note that texlive 2010 will have FreeBSD binaries as well, and I'm very happy about it, but I doubt, that tug.org will rename ht (of texlive-core) just because 1 port install package with same name In the end user will probably rewrote one with another (just like me) Sorry if this is quite long, I just wanted to stress-out how texlive is important (at least for me) I see your point and agree with it. I do not know about the complexity of texlive (in terms of tools using and calling each other) nor about its range of use (in terms of active user base), which might be an important point to consider, too. Back to the original issue: I then would favour to rename the editors/hte binary completely and permanenty to 'hte' and add an UPDATING entry about that incompatible binary naming change instead of adding an (in my opinion more confusing) CONFLICTS entry. Although this might be contrary to POLA, it would cause less confusion and annoyance for users. (ports@ CC'd for comments on a best practive here). Regards Marcus pgpo7q3PTfTAI.pgp Description: PGP signature
Re: pylint entry in UPDATING?
Hi Vladimir, On, Mon May 17, 2010, chukha...@mail.ru wrote: Hi, It seems than the new version of devel/pylint port is not compatible with the old config files in user's home. [...] Everything work since renaming ~/.pylintrc and ~/.pylint.d. I think this is good to mention in ports/UPDATING. personally, I do not think that (incompatibly) changed user options or configuration settings for this port are 'worth' an entry in UPDATING, thus I skipped it. Regards Marcus pgpAAtA1DLs3d.pgp Description: PGP signature
Re: audio/sdl_mixer does not pull libmikmod as dependency
On, Tue Apr 20, 2010, Demelier David wrote: Hi, I was checking why supertux fails, and I noticed that libmikmod wasn't installed. I checked the sdl_mixer options and MIKMOD is activated. Why does make (missing|deinstall|install) does not pull libmikmod, flac, smpeg as sdl_mixer dependencies ? Because I missed a '+=' in the LIB_DEPENDS for mikmod and flac, which caused them to be ignored under various circumstances. It has been fixed now, thanks for noticing :-). Regards Marcus pgpHvjSFILDeG.pgp Description: PGP signature
Re: [SDL-1.2.14] Build fails on the libvlg checking
On, Sun Jan 31, 2010, David Marec wrote: Hello, Trying to update SDL1.2 librairies, the build failed on the following errors: /usr/bin/ld: skipping incompatible /usr/lib/libvgl.so when searching for -lvgl /usr/bin/ld: skipping incompatible /usr/lib/libvgl.a when searching for -lvgl /usr/bin/ld: skipping incompatible /usr/lib/libvgl.so when searching for -lvgl /usr/bin/ld: skipping incompatible /usr/lib/libvgl.a when searching for -lvgl /usr/bin/ld: skipping incompatible /usr/lib/libvgl.so when searching for -lvgl /usr/bin/ld: skipping incompatible /usr/lib/libvgl.a when searching for -lvgl /usr/bin/ld: cannot find -lvgl Running: david:~uname -p -r 8.0-STABLE amd64 Any idea to get rid of this ? /usr/lib/libvgl.* should not be available on RELENG_8, amd64 - instead it should reside in /usr/lib32 only. Did you upgrade from i386 to amd64 or did you manually link the libvgl.* to /usr/lib? If so, please remove them or run make config and disable the VGL knob (or add 'WITHOUT_VGL=true' to the make invocation). Regards Marcus pgpNLtvscBKL9.pgp Description: PGP signature
Re: [SDL-1.2.14] Build fails on the libvlg checking
On, Sun Jan 31, 2010, David Marec wrote: Le dimanche 31 janvier 2010 14:27:19, Marcus von Appen a écrit : /usr/lib/libvgl.* should not be available on RELENG_8, amd64 - instead it should reside in /usr/lib32 only. Did you upgrade from i386 to amd64 or did you manually link the libvgl.* to /usr/lib? Neither of them. The system is amd64 from the begining. If so, please remove them or run make config and disable the VGL knob (or add 'WITHOUT_VGL=true' to the make invocation). That s what i did. And it still does not work for you? But, if, for example, svgalib is tagged i386 only, svgl is not. If I manually link libvgl.* from /usr/lib32 to /usr/lib and rebuild SDL with VGL enabled, anything links properly. I am not sure, what's wrong on your side. If it still fails for you after disabling the VGL knob, could you please send me the config.log from /usr/ports/devel/sdl12/work/SDL-1.2.14 as well as the tee'd output from your make invocation: make | tee sdlbuild.log btw, should i remove these libs ? I do not recommend to do that manually. Which shared library versions of libvgl are installed (output of find /usr/lib -name *vgl*) on your side? Did you ever run make delete-old or make delete-old-libs after updating the system? Regards Marcus pgpyErOFU2TUJ.pgp Description: PGP signature
Re: Unable to build graphics/gd
On, Sun Jul 19, 2009, Jerry wrote: I am unable to build the 'graphics/gd' port on FreeBSD-7.2 although I have updated the posts tree, etc. The build simply stops during the 'make' phase. A complete copy of the build log is available at this URL: http://pastebin.ca/1499985 Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Regards Marcus pgpiJRGxQvGkH.pgp Description: PGP signature
Re: Unable to build graphics/gd
On, Sun Jul 19, 2009, Jerry wrote: On Sun, 19 Jul 2009 13:00:30 +0200 Marcus von Appen m...@freebsd.org wrote: [snip] Looks like it tries to link against the older version that's still installed. Try to deinstall gd first, then build and install it again. Thanks, that fixed it. Strange, but I have not had that problem before. Just for informational purposes: It is a problem with how the FreeBSD upgrade tools work and how a port (read: application, library, whatever) manages its own build. Usually a port, in case it links to one of its own components, should do that by using the just built component in its build directory. Some of them however do not do that but use the complete system environment, thus it can happen that they link to e.g. an older version of themselves or so, causing anything to fail as you just noticed. Regards Marcus pgp0JLNPOmsgo.pgp Description: PGP signature
Re: The mistake of blender-2.49
On, Tue Jun 16, 2009, Wayne Huang wrote: I update my ports in Jun. [...] but, when I download the blender-2.49.tar.gz I found the distinfo is fault. (my url of blender is http://download.blender.org/source/blender-2.49.tar.gz) the md5 code,sha256 code and size of the source file is all fault. I don't know where can I report this,so I send the letter for you. Sorry for the delayed response. 2.49a is out and currently tested by me. So the port will be updated within the next few days. Thanks for the patience. Regards Marcus pgpL81W0OIF9b.pgp Description: PGP signature
Re: Question about ports....
On, Thu Mar 19, 2009, Wesley Shields wrote: On Thu, Mar 19, 2009 at 09:38:52AM +0200, Mika Veijonsuo wrote: On Thu, 19 Mar 2009 07:05:33 +0100 Leslie Jensen les...@eskk.nu wrote: PySolFC-1.1! Comparison failed wine-1.1.16,1 needs updating (index has 1.1.17,1) My first question is: What is wrong when Comparison fails? It seems that the port was renamed from games/PySolFC to games/pysolfc recently, so there is no games/PySolFC in the ports for pkg_version to compare to. It appears the port was renamed to games/pysolfc on 2009/03/14, but that there was no entry in MOVED. I've CC'ed the committer which made the change. Hopefully Marcus can clean it up (I'd do it myself but I'm traveling for business until tomorrow evening). Fixed a minute ago. Thanks for reporting and sorry for the inconvenience. Regards Marcus pgpvcFnC3CHx5.pgp Description: PGP signature
Re: Testers for graphics/blender with OPTION knobs
On, Fri Mar 13, 2009, Christian Walther wrote:
[...]
make config looks really promising. I configured graphics/blender with
the following options:
[X] DDS DDS file format support
[X] FFMPEGAudio and video support using ffmpeg
[X] FREETYPE Improved font rendering support
[ ] ICONV Iconv support for localisation (only with NLS)
[ ] KETSJIBuild GameEngine and BlenderPlayer
[ ] NLS Native language support
[X] OCFLAGS Optimized Cflags
[ ] OPENAL3D sound support using OpenAL
[X] OPENEXR High dynamic-range (HDR) support using OpenEXR
[ ] OPENMPParallel processing support
[ ] VERSE Shared networking support using Verse
The install fails with the following error message:
=== Generating temporary packing list
=== Checking if graphics/blender already installed
install:
/usr/ports/graphics/blender/work/blender-2.48a/obj/freebsd-7.1-i386/bin/blenderplayer:
No such file or directory
*** Error code 71
Stop in /usr/ports/graphics/blender.
*** Error code 1
Stop in /usr/ports/graphics/blender.
Looks as if the make install doesn't handle the new config properly.
blenderplayer is not build, if the KETSJI option is disabled. This is
fixed in the attached patch. To fix it manually without reapplying the
whole patch, surround the installation of blenderplayer (line 215 in the
Makefile) with an .if ... .endif:
.if !defined(WITHOUT_KETSJI)
@${INSTALL_PROGRAM}
${WRKSRC}/obj/freebsd-${OSREL}-${ARCH}/bin/blenderplayer
${PREFIX}/bin/blenderplayer
.endif
Note that the indentation requires a tab character, so do not directly
copy and paste the above snippet.
Thanks for noticing.
Regards
Marcus
Index: graphics/blender/Makefile
===
RCS file: /home/pcvs/ports/graphics/blender/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- graphics/blender/Makefile 23 Feb 2009 21:43:16 - 1.30
+++ graphics/blender/Makefile 14 Mar 2009 08:50:48 -
@@ -16,14 +16,10 @@
BUILD_DEPENDS= ${LOCALBASE}/lib/libode.a:${PORTSDIR}/devel/ode
LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg \
- freetype.9:${PORTSDIR}/print/freetype2 \
png.5:${PORTSDIR}/graphics/png \
tiff.4:${PORTSDIR}/graphics/tiff \
- IlmImf.6:${PORTSDIR}/graphics/OpenEXR \
- alut.1:${PORTSDIR}/audio/freealut\
- openal.0:${PORTSDIR}/audio/openal \
- avutil.1:${PORTSDIR}/multimedia/ffmpeg \
- GLEW.1:${PORTSDIR}/graphics/glew
+ GLEW.1:${PORTSDIR}/graphics/glew \
+ IlmThread.6:${PORTSDIR}/graphics/ilmbase
USE_XORG= x11 xext xmu xi
USE_PYTHON= 2.5+
@@ -43,33 +39,96 @@
LANG= ar bg ca cs de el es fi fr hr hr_HR it ja ko nl pl pt_BR ro \
ru sr s...@latn sv uk zh_CN
-OPTIONS= OCFLAGS Enable optimized CFLAGS off \
- NLS Native language support on
+OPTIONS= DDS DDS file format support on \
+ FFMPEG Audio and video support using ffmpeg on \
+ FREETYPE Improved font rendering support on \
+ ICONV Iconv support for localisation (only with NLS) off \
+ KETSJI Build GameEngine and BlenderPlayer on \
+ NLS Native language support on \
+ OCFLAGS Optimized Cflags off \
+ OPENAL 3D sound support using OpenAL on \
+ OPENEXR High dynamic-range (HDR) support using OpenEXR on \
+ OPENMP Parallel processing support off \
+ VERSE Shared networking support using Verse on
.include bsd.port.pre.mk
-MAKE_ENV+= NAN_CPPFLAGS=-I${LOCALBASE}/include/freetype2 \
- -I${LOCALBASE}/include \
- -I${LOCALBASE}/include/OpenEXR \
- -I${PYTHON_INCLUDEDIR}/
-MAKE_ENV+= NAN_FREETYPE=${LOCALBASE}/
-MAKE_ENV+= NAN_OPENEXR=${LOCALBASE}/
-MAKE_ENV+= NAN_OPENAL=${LOCALBASE}/
+MAKE_ENV+= NAN_FMOD=${LOCALBASE}/
MAKE_ENV+= NAN_PYTHON=${LOCALBASE}/
MAKE_ENV+= NAN_PYTHON_VERSION=${PYTHON_VER}
-MAKE_ENV+= NAN_FMOD=${LOCALBASE}/
MAKE_ENV+= NAN_JPEG=${LOCALBASE}/
MAKE_ENV+= NAN_PNG=${LOCALBASE}/
MAKE_ENV+= NAN_ZLIB=${LOCALBASE}/
MAKE_ENV+= NAN_ODE=${LOCALBASE}/
MAKE_ENV+= NAN_GLEW=${LOCALBASE}/
+MAKE_ENV+= NAN_JUST_BLENDERDYNAMIC=true
+MAKE_ENV+= WITH_BF_DYNAMICOPENGL=true
+
CFLAGS+= -I${LOCALBASE}/include
+NANCPPFLAGS=
+
+.if !defined(WITHOUT_DDS)
+MAKE_ENV+= WITH_DDS=true
+.else
+MAKE_ENV+= WITH_DDS=false
+.endif
+
+.if defined(WITHOUT_FFMPEG)
+MAKE_ENV+= WITH_FFMPEG=false
+.else
+MAKE_ENV+= WITH_FFMPEG=true
+MAKE_ENV+= NAN_USE_FFMPEG_CONFIG=true
+MAKE_ENV+= NAN_FFMPEG=${LOCALBASE}/
+LIB_DEPENDS+= avutil.1:${PORTSDIR}/multimedia/ffmpeg
+.endif
+
+.if defined(WITHOUT_FREETYPE)
+MAKE_ENV+= WITH_FREETYPE2=false
+.else
+MAKE_ENV+= WITH_FREETYPE2=true
+MAKE_ENV+= NAN_FREETYPE=${LOCALBASE}/
+MAKE_ENV+= NAN_FTGL=${LOCALBASE}/
+NANCPPFLAGS+= -I${LOCALBASE}/include/freetype2
+LIB_DEPENDS+= freetype.9:${PORTSDIR}/print/freetype2
+LIB_DEPENDS+= ftgl.2:${PORTSDIR}/graphics/ftgl
+.endif
+
+.if defined(WITHOUT_KETSJI)
+MAKE_ENV+= NAN_NO_KETSJI=true
+MAKE_ENV+= WITH_BF_BLENDERGAMEENGINE=false
+MAKE_ENV+= WITH_BF_BLENDERPLAYER=false
+PLIST_SUB+= KETSJI=@comment
+.else
+MAKE_ENV+= NAN_NO_KETSJI=false
+MAKE_ENV+=
Testers for graphics/blender with OPTION knobs
Hi,
it took some time, but finally graphics/blender got a lot of options to
configure. Those enable users to tweak it to their personal needs and
hopefully will allow graphics/blender to run on more platforms.
Especially users of non-i386 platforms are invited to test the different
options as some of the earlier dependencies, which had and have certain
requirements, can be disabled now.
A patch is attached and feedback highly welcome.
Regards
Marcus
Index: graphics/blender/Makefile
===
RCS file: /home/pcvs/ports/graphics/blender/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- graphics/blender/Makefile 23 Feb 2009 21:43:16 - 1.30
+++ graphics/blender/Makefile 13 Mar 2009 20:02:27 -
@@ -16,14 +16,10 @@
BUILD_DEPENDS= ${LOCALBASE}/lib/libode.a:${PORTSDIR}/devel/ode
LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg \
- freetype.9:${PORTSDIR}/print/freetype2 \
png.5:${PORTSDIR}/graphics/png \
tiff.4:${PORTSDIR}/graphics/tiff \
- IlmImf.6:${PORTSDIR}/graphics/OpenEXR \
- alut.1:${PORTSDIR}/audio/freealut\
- openal.0:${PORTSDIR}/audio/openal \
- avutil.1:${PORTSDIR}/multimedia/ffmpeg \
- GLEW.1:${PORTSDIR}/graphics/glew
+ GLEW.1:${PORTSDIR}/graphics/glew \
+ IlmThread.6:${PORTSDIR}/graphics/ilmbase
USE_XORG= x11 xext xmu xi
USE_PYTHON= 2.5+
@@ -43,33 +39,96 @@
LANG= ar bg ca cs de el es fi fr hr hr_HR it ja ko nl pl pt_BR ro \
ru sr s...@latn sv uk zh_CN
-OPTIONS= OCFLAGS Enable optimized CFLAGS off \
- NLS Native language support on
+OPTIONS= DDS DDS file format support on \
+ FFMPEG Audio and video support using ffmpeg on \
+ FREETYPE Improved font rendering support on \
+ ICONV Iconv support for localisation (only with NLS) off \
+ KETSJI Build GameEngine and BlenderPlayer on \
+ NLS Native language support on \
+ OCFLAGS Optimized Cflags off \
+ OPENAL 3D sound support using OpenAL on \
+ OPENEXR High dynamic-range (HDR) support using OpenEXR on \
+ OPENMP Parallel processing support off \
+ VERSE Shared networking support using Verse on
.include bsd.port.pre.mk
-MAKE_ENV+= NAN_CPPFLAGS=-I${LOCALBASE}/include/freetype2 \
- -I${LOCALBASE}/include \
- -I${LOCALBASE}/include/OpenEXR \
- -I${PYTHON_INCLUDEDIR}/
-MAKE_ENV+= NAN_FREETYPE=${LOCALBASE}/
-MAKE_ENV+= NAN_OPENEXR=${LOCALBASE}/
-MAKE_ENV+= NAN_OPENAL=${LOCALBASE}/
+MAKE_ENV+= NAN_FMOD=${LOCALBASE}/
MAKE_ENV+= NAN_PYTHON=${LOCALBASE}/
MAKE_ENV+= NAN_PYTHON_VERSION=${PYTHON_VER}
-MAKE_ENV+= NAN_FMOD=${LOCALBASE}/
MAKE_ENV+= NAN_JPEG=${LOCALBASE}/
MAKE_ENV+= NAN_PNG=${LOCALBASE}/
MAKE_ENV+= NAN_ZLIB=${LOCALBASE}/
MAKE_ENV+= NAN_ODE=${LOCALBASE}/
MAKE_ENV+= NAN_GLEW=${LOCALBASE}/
+MAKE_ENV+= NAN_JUST_BLENDERDYNAMIC=true
+MAKE_ENV+= WITH_BF_DYNAMICOPENGL=true
+
CFLAGS+= -I${LOCALBASE}/include
+NANCPPFLAGS=
+
+.if !defined(WITHOUT_DDS)
+MAKE_ENV+= WITH_DDS=true
+.else
+MAKE_ENV+= WITH_DDS=false
+.endif
+
+.if defined(WITHOUT_FFMPEG)
+MAKE_ENV+= WITH_FFMPEG=false
+.else
+MAKE_ENV+= WITH_FFMPEG=true
+MAKE_ENV+= NAN_USE_FFMPEG_CONFIG=true
+MAKE_ENV+= NAN_FFMPEG=${LOCALBASE}/
+LIB_DEPENDS+= avutil.1:${PORTSDIR}/multimedia/ffmpeg
+.endif
+
+.if defined(WITHOUT_FREETYPE)
+MAKE_ENV+= WITH_FREETYPE2=false
+.else
+MAKE_ENV+= WITH_FREETYPE2=true
+MAKE_ENV+= NAN_FREETYPE=${LOCALBASE}/
+MAKE_ENV+= NAN_FTGL=${LOCALBASE}/
+NANCPPFLAGS+= -I${LOCALBASE}/include/freetype2
+LIB_DEPENDS+= freetype.9:${PORTSDIR}/print/freetype2
+LIB_DEPENDS+= ftgl.2:${PORTSDIR}/graphics/ftgl
+.endif
+
+.if defined(WITHOUT_KETSJI)
+MAKE_ENV+= NAN_NO_KETSJI=true
+MAKE_ENV+= WITH_BF_BLENDERGAMEENGINE=false
+MAKE_ENV+= WITH_BF_BLENDERPLAYER=false
+PLIST_SUB+= KETSJI=@comment
+.else
+MAKE_ENV+= NAN_NO_KETSJI=false
+MAKE_ENV+= NAN_USE_BULLET=true
+MAKE_ENV+= WITH_BF_BLENDERGAMEENGINE=true
+MAKE_ENV+= WITH_BF_BLENDERPLAYER=true
+PLIST_SUB+= KETSJI=
+.endif
.if !defined(WITHOUT_NLS)
USE_GETTEXT= yes
MAKE_ENV+= INTERNATIONAL=true
+
+# Iconv support?
+.if defined(WITH_ICONV)
+USE_ICONV= yes
+MAKE_ENV+= WITH_ICONV=true
+.else
+MAKE_ENV+= WITH_ICONV=false
+.endif
+
+.if defined(WITHOUT_FREETYPE)
+# Implies Freetype2 - ignore the without knob.
+MAKE_ENV+= WITH_FREETYPE2=true
+MAKE_ENV+= NAN_FREETYPE=${LOCALBASE}/
+LIB_DEPENDS+= freetype.9:${PORTSDIR}/print/freetype2
+LIB_DEPENDS+= ftgl.2:${PORTSDIR}/graphics/ftgl
+.endif
+
PLIST_SUB+= NLS=
.else
+MAKE_ENV+= WITH_ICONV=false
PLIST_SUB+= NLS=@comment
.endif
@@ -77,16 +136,45 @@
CFLAGS+= -O3 -ffast-math
.endif
-.if ${ARCH} == amd64
-MAKE_ENV+= NAN_NO_KETSJI=true
-MAKE_ENV+= WITH_BF_BLENDERGAMEENGINE=false
-MAKE_ENV+= WITH_BF_BLENDERPLAYER=false
+.if defined(WITHOUT_OPENAL)
+MAKE_ENV+= NAN_NO_OPENAL=true
.else
-MAKE_ENV+= WITH_BF_BLENDERGAMEENGINE=true
-MAKE_ENV+= WITH_BF_OPENAL=true
-MAKE_ENV+= WITH_BF_BLENDERPLAYER=true
+MAKE_ENV+= NAN_NO_OPENAL=false
+MAKE_ENV+= NAN_OPENAL=${LOCALBASE}/
+LIB_DEPENDS+= openal.0:${PORTSDIR}/audio/openal \
+ alut.1:${PORTSDIR}/audio/freealut
.endif
+.if
Re: SDL / Pulseaudio
On, Fri Mar 06, 2009, Andre Heider wrote: [More pulseaudio related patches] Thanks. I'll look into that and fix it as appropriate. Regards Marcus pgpqVAeQsHDYv.pgp Description: PGP signature
Re: SDL / Pulseaudio
On, Tue Mar 03, 2009, Andre Heider wrote: Hi list, devel/sdl12 doesn't pick up pulseaudio, no matter if I select it in make config or not. I didn't find the time to dig further, but I noticed 2 bits: - the dependency to libpulse-simple.so.0 isn't set in the Makefile I missed that one, sorry. It will be fixed soon. - if I run ./configure without args, it correctly finds the lib and compiles the SDL audio driver for it Is this a known issue or am I missing some other port? For some weird reason the --enable-pulseaudio switch will disable PulseAudio support in 1.2.13. That'll be fixed as well. Thanks for noticing and notifying :-). Regards Marcus pgp3fNfQy0HCW.pgp Description: PGP signature
Re: graphics/blender: Make use of OpenAL configurable
On, Mon Feb 23, 2009, Christian Walther wrote: Hi, I have a suggestion for the graphics/blender port, because blenders Makefile states that OpenAL can be disabled: # To build without openAL, uncomment the following line, or set it as # an environment variable, or put it uncommented in user-def.mk: # export NAN_NO_OPENAL=true Not every blender user requires OpenAL I guess, so it would be great to have OpenAL as an option selectable during make config, or having NAN_NO_OPENAL exported so that it can be defined in /etc/make.conf. This would reduce the binary size, probably even the amount of installed ports, and exploit one major benefit of the ports system. Maybe it would even make sense to integrate BLENDERGAMEENGINE and BLENDERPLAYER user selectable. Personally, I don't think that I'll need any of the two. Those things are currently being worked on and I hope to have a bunch of configuration and build options ready soon. Regards Marcus pgpCfX6kMVS0z.pgp Description: PGP signature
Re: Blender 2.48 fails to build
On, Sun Feb 01, 2009, Philipp Ost wrote: Hi Marcus, graphics/blender fails to build: [...] /usr/local//lib/libopenal.a(libopenal_la-x86_cpu_caps_prk.o)(.text+0x4e): In function `_alDetectCPUCaps': : undefined reference to `_alDetectx86CPUCaps' /usr/local//lib/libopenal.a(libopenal_la-mixaudio16_mmx_prk.o)(.text+0xf24e): In function `MixAudio16_MMX_1': : undefined reference to `_alMMXmemcpy' gmake[1]: *** This looks like your audio/openal library installation is broken and blender's failing due to some missing symbols within the openal library. Did you activate some OPTION knobs on installing audio/openal and if so, which were that? If some were enabled, try to reinstall audio/openal with all OPTION knobs disabled and then rebuild graphics/blender. Regards Marcus pgp6S7KzmzCZG.pgp Description: PGP signature
Re: ports/118213: games/HeroesOfMightAndMagic - heroesOfMightAndMagic's doesn't work correctly
After some more investigation it turns out to be some side effect of the sound changes made on 2006-11-26. The game works fine using a kernel before that change, later ones (but before the linuxulator mmap changes between 2007-02-15 and 2007-02-16) cause a hard reboot. The responsible parties, emulation@ and ariff@ are informed and I'm waiting for a possible solution. Regards Marcus pgp1xSeeksh5z.pgp Description: PGP signature
devel/linux-js does not work on recent RELENG_7
Hi, although installing devel/linux-js works fine, the module cannot be loaded on RELENG_7 after installation. The affected joystick is USB powered and clearly recognized by native ports. uhid is compiled in as device. Right after trying to load it, dmesg spits out a link_elf: symbol FILEDESC_UNLOCK undefined message. # kldload linux_js kldload: can't load linux_js: No such file or directory # ls /boot/modules/linux* /boot/modules/linux_js.ko # tail /etc/rc.conf [...] linux_js_enable=YES jscal_enable=YES # dmesg |grep uhid uhid0: Mega World USB 2-Axis 8-Button Gamepad, class 0/0, rev 1.10/1.01, addr 3 on uhub5 # uname -a FreeBSD medusa.sysfault.org 7.0-BETA4 FreeBSD 7.0-BETA4 #3: Sat Dec 15 19:50:53 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MEDUSA i386 Can someone verify this behaviour or is this a problem on my system only? Regards Marcus pgpD8pYQYYS4N.pgp Description: PGP signature
Re: Please left freeze for: cups-base-1.3.3_2 issues--
On, Thu Nov 15, 2007, David Southwell wrote: On Wednesday 14 November 2007 14:19:39 Erwin Lansing wrote: On Wed, Nov 14, 2007 at 02:05:46PM -0600, Andrew Daugherity wrote: cups-base was patched for this vulnerability (with version 1.3.3_2), but the change to the vulnerabilities file erroneously has it marked as cups-base 1.3.3_2, instead of cups-base 1.3.3_2: http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/vuxml/vuln.xml?r1=1. 148 1 Committed. Thanks for noticing! -erwin Thanks v. much. Unfortunately it seems the freeze is preventing the commit from being effective. I have just cvsupped and portupgrade -a and still getting the same problem. I wonder if this commit could be implemented despite the freeze. I am getting 98 port upgrades fail that depend upon cups-base Did you do a portaudit -F to fetch the latest portaudit database that's used for checking? I did a few minutes ago and anything's fine on my side, portaudit -a does not report cups-base to be vulnerable any longer. Regards Marcus pgpBvf3Lccw5e.pgp Description: PGP signature
[Bug]: recent graphics/libfpx update breaks build
Submitter-Id: current-users Originator:Marcus von Appen Organization: Confidential: no Synopsis: [Bug]: recent graphics/libfpx update breaks build Severity: serious Priority: high Category: ports Class: sw-bug Release: FreeBSD 6.3-PRERELEASE i386 Environment: System: FreeBSD medusa.sysfault.org 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Sun Oct 28 11:05:41 CET 2007 Description: The recent graphics/libfpx mega-patch update causes the build to break on RELENG_6. How-To-Repeat: The following is an excerpt, the full log is available at http://sysfault.org/freebsd/libfpx.log. cd /usr/ports/graphics/libfpx make leads to === Extracting for libfpx-1.2.0.12_1 = MD5 Checksum OK for libfpx-1.2.0.12.tar.bz2. = SHA256 Checksum OK for libfpx-1.2.0.12.tar.bz2. = MD5 Checksum OK for fpx.mega-patch.2007-11-01.bz2. = SHA256 Checksum OK for fpx.mega-patch.2007-11-01.bz2. === Patching for libfpx-1.2.0.12_1 === Applying distribution patches for libfpx-1.2.0.12_1 /bin/rm /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ri_image/wchar.c /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/fpx/fpxlib.h === Configuring for libfpx-1.2.0.12_1 === Building for libfpx-1.2.0.12_1 Warning: Object directory not changed from original /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12 c++ -O2 -pipe -march=pentium4 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/jpeg -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/basics -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ri_image -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/fpx -I/usr/local/include -D_UNIX -c /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp c++ -fpic -DPIC -O2 -pipe -march=pentium4 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/jpeg -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/basics -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ri_image -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless -I/usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/fpx -I/usr/local/include -D_UNIX -c /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp -o olestorg.So In file included from /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/exphead.cxx:21, from /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olecomm.h:49, from /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp:26: /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h/ref.hxx:73: error: redeclaration of C++ built-in type `char' /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h/ref.hxx:81: error: expected initializer before unsigned /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h/ref.hxx:116: error: `DWORD' does not name a type /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h/ref.hxx:117: error: `DWORD' does not name a type /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h/ref.hxx:122: error: `DWORD' does not name a type /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/oless/h/ref.hxx:133: error: expected `,' or `...' before '' token [... snip tons of following errors ...] /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp: In member function `virtual Boolean OLEStorage::OpenHeaderStream(const XGUID, const char*, OLEHeaderStream**, int)': /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp:682: error: no matching function for call to `OLEHeaderStream::OLEHeaderStream(const _XGUID, OLEStorage* const, IStream*)' /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olehstrm.h:52: note: candidates are: OLEHeaderStream::OLEHeaderStream(const OLEHeaderStream) /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olehstrm.h:57: note: OLEHeaderStream::OLEHeaderStream(int) /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp: At global scope: /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp:697: error: `DWORD' has not been declared /usr/ports/graphics/libfpx/work/libfpx-1.2.0.12/ole/olestorg.cpp:698: error: ISO C++ forbids declaration of `mode' with no type /usr/ports/graphics
Re: ImageMagick
On, Thu Sep 27, 2007, Johan Hendriks wrote: I can not update Image Magick on all of my machines. This is on 6.2 and 6.1 it errors out with the following error: [Test broken] Deactivate the IMAGEMAGICK_TESTS knob. This circumvents the test issue and ImageMagick will be installed without any problems. The failed tests however indicate, that someone should look into it :-). Regards Marcus pgpZBsexbSrKF.pgp Description: PGP signature
Re: Request for tester for pcc port
On, Tue Sep 18, 2007, Gea-Suan Lin wrote: Hello everyone, I made a port for pcc (Portable C Compiler), but it seems have problem in do-build occasionally. [...] It's already in the ports: /usr/ports/lang/pcc. It suffers from the same issues however (maintainer was informed some hours ago). Regards Marcus pgp6ib0qDTtEo.pgp Description: PGP signature
Re: HEADS UP: ncurses wide character support in 7.x
On, Fri Mar 09, 2007, Rong-en Fan wrote: FYI, we have ncurses wide character support in 7.x now. [...] Great work, thanks a lot. Will it be backported to RELENG_6? Regards Marcus pgpqN55PfGFQF.pgp Description: PGP signature
Re: editors/hte IA64/AMD64 compliance test
On, Fri Mar 02, 2007, Rong-en Fan wrote:
On 3/2/07, Marcus von Appen [EMAIL PROTECTED] wrote:
Hi,
the authors of editors/hte made up a new release, v2.0, and announced
64-bit compliance.
It would be great if someone with a IA64 and/or AMD64 arch could test the
port. The diff for editors/hte can be found at:
http://sysfault.org/data/hte-patch.diff
Simply apply it to your local port and try to build and run it.
It runs on my amd64 6.x. BTW, the distinfo seems incorrect, I got
Thanks. I'll make up a PR then and wait for the tinderboxes to complain
:).
MD5 (ht-2.0.tar.bz2) = 3fb6d9a736bfbb7f4b6f46ee752201e5
SHA256 (ht-2.0.tar.bz2) =
1d0025030fb9bb22b8b14043611fff5003e8cbc3a9689977b79c14eba0c6829f
SIZE (ht-2.0.tar.bz2) = 854003
They exchanged the upstream package, no big deal.
A minor issue, you may want to remove
.if ${OSVERSION} 40
LIB_DEPENDS+= ncurses.5:${PORTSDIR}/devel/ncurses
.endif
There is no need to keep pre 4.x support.
Okay, I'll do so. Thanks for testing.
Regards
Marcus
pgpXFoqaAec9B.pgp
Description: PGP signature
editors/hte IA64/AMD64 compliance test
Hi, the authors of editors/hte made up a new release, v2.0, and announced 64-bit compliance. It would be great if someone with a IA64 and/or AMD64 arch could test the port. The diff for editors/hte can be found at: http://sysfault.org/data/hte-patch.diff Simply apply it to your local port and try to build and run it. Thanks and regards Marcus pgphpnpM2mEYt.pgp Description: PGP signature
docbook breaks sysutils/hal
Hi, sysutils/hal fails on install on my system whenever I have the docbook related ports already installed. Removing all of them and letting them install as dependency of hal works fine, but breaks hal upgrades, when they are already installed. gmake[3]: Entering directory `/usr/ports/sysutils/hal/work/hal-0.5.8.20060917/doc/spec' /usr/local/bin/docbook2html --nochunks hal-spec.xml -o . Using catalogs: /usr/local/share/sgml/catalog, /usr/local/share/sgml/docbook/dsssl/modular/print/catalog, /usr/local/share/sgml/docbook/dsssl/modular/html/catalog, /usr/local/share/sgml/docbook/dsssl/modular/dtds/html/catalog, /usr/local/share/sgml/docbook/dsssl/modular/common/catalog, /usr/local/share/sgml/docbook/dsssl/modular/catalog, /usr/local/share/sgml/docbook/4.1/catalog, /usr/local/share/sgml/docbook/3.1/catalog, /usr/local/share/sgml/docbook/2.4.1/catalog, /usr/local/share/sgml/docbook/4.0/catalog, /usr/local/share/sgml/docbook/3.0/catalog, /usr/local/share/sgml/docbook/catalog, /usr/local/share/sgml/html/catalog, /usr/local/share/sgml/iso8879/catalog, /usr/local/share/sgml/linuxdoc/catalog, /usr/local/share/sgml/jade/catalog Using stylesheet: /usr/local/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/ports/sysutils/hal/work/hal-0.5.8.20060917/doc/spec/hal-spec.xml jade:E: cannot open /usr/local/share/sgml/xml.dcl (No such file or directory) jade:/usr/ports/sysutils/hal/work/hal-0.5.8.20060917/doc/spec/hal-spec.xml:3:119:E: URL not supported by this version jade:/usr/ports/sysutils/hal/work/hal-0.5.8.20060917/doc/spec/hal-spec.xml:3:119:E: DTD did not contain element declaration for document type name jade:/usr/ports/sysutils/hal/work/hal-0.5.8.20060917/doc/spec/hal-spec.xml:7:9:E: there is no attribute ID [...more attribute and tag errors (basically for all tags and attributes as it seems...] Stop in /usr/ports/sysutils/hal. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.36502.0 env PORT_UPGRADE=yes make ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! sysutils/hal (hal-0.5.8.20060917_1) (unknown build error) --- Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed Output of `pkg_info | grep book` docbook-1.3 docbook-241_2 docbook-3.0_2 docbook-3.1_2 docbook-4.0_2 docbook-4.1_2 docbook-sk-4.1.2_3 docbook-to-man-1.0 docbook-utils-0.6.14 docbook-xml-4.2_1 docbook-xml-4.3 docbook-xml-4.4 docbook-xsl-1.70.1 dsssl-docbook-modular-1.79,1 sdocbook-xml-4.1.2.5_2 Any advices on how to fix that issue without reinstalling all the packages anytime hal is updated? Regards Marcus pgpRWOxFjww5L.pgp Description: PGP signature
Dropping X11BASE in favour for LOCALBASE
Hi, according to the status report sent around today, X11BASE should be dropped in favour for LOCALBASE. Is there an actual schedule until when this should happen and how should we deal with our current ports now? Just remove the USE_X_PREFIX macro when we submit new PRs for (our) existing ports or anything besides that? A further explanation why that move shall happen would be great, too :-). Regards Marcus pgpzx7IqNOnKb.pgp Description: PGP signature
Re: Dropping X11BASE in favour for LOCALBASE
On, Thu Oct 19, 2006, Kris Kennaway wrote: On Thu, Oct 19, 2006 at 06:01:42PM +0200, Marcus von Appen wrote: Hi, according to the status report sent around today, X11BASE should be dropped in favour for LOCALBASE. Is there an actual schedule until when this should happen and how should we deal with our current ports now? Just remove the USE_X_PREFIX macro when we submit new PRs for (our) existing ports or anything besides that? A further explanation why that move shall happen would be great, too :-). It can only possibly happen after a team of interested people have put in the work to fix the several thousand ports that have hard-coded knowledge of /usr/X11R6 (i.e. which do not respect X11BASE anyway). So what was the announcement about then? Was the X11BASE vs. LOCALBASE section within it just a generalization of the GNOME changes and X11BASE will be kept? Or should we maintainers switch to LOCALBASE whenever possible from now on? Regards Marcus pgpydgR2m9elW.pgp Description: PGP signature
Python 2.5 egg-info files break pkg-plists
Hi,
Python 2.5 seems to install automatically generated egg-info files for
each package. This causes each port, which installs files into
the site-packages directory to leave files around:
For devel/pygame this would be pygame-1.7.1release-py2.5.egg-info.
For x11-toolkits/py-tkinter this would be Tkinter-0.0.0-py2.5.egg-info
...
This is a more or less serious issue which should be fixed soon, either
by updating all ports, which place files into site-packages or by
turning that option off in the distutils package.
The line, which should do that would be line 604 in
Python-2.5/Lib/distutils/command/install.py:
-('install_egg_info', lambda self:True),
+('install_egg_info', lambda self:False),
Although the egg support was planned for 2.6, some of its code went
already into the 2.5 distutils distribution :-}.
As python eggs rely upon .egg-info files to track down dependencies,
this becomes a funny issue to deal with.
Regards
Marcus
pgpApHXzNBvoj.pgp
Description: PGP signature
Re: devel/guichan update and dependant ports
On, Fri Sep 22, 2006, Dmitry Marakasov wrote: * Marcus von Appen ([EMAIL PROTECTED]) wrote: Personally I would break games/diameter and keep it as broken until a compatible version of it will be released (or remove it in a year or so if nothing happens). I agree. To fork guichan for only one port is not a solution. I would be grateful if you wait a week or so before updating guichan. Of course. If you need the updated guichan port for testing, tell me and I'll send you a diff with the changes I made. I've just mailed diameter's author, and I hope we'll come with some solution shortly, most likely patch for current version of diameter. I'll keep you informed. Okay, great. Regards Marcus pgp7aGyMqeCGN.pgp Description: PGP signature
