Re: graphics/openimageio fails to build
On 14/1/21 8:16 am, Torfinn Ingolfsen wrote: > like so: > FAILED: > src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/jpeg2000.imageio/jpeg2000input.cpp.o > Stop. > make: stopped in /usr/ports/graphics/openimageio The update to 2.2.10.1 has been committed which has a patch to fix the build with openjeg. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: graphics/openimageio fails to build
On 14/1/21 8:16 am, Torfinn Ingolfsen wrote: > like so: > FAILED: > src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/jpeg2000.imageio/jpeg2000input.cpp.o ... > fatal error: too many errors emitted, stopping now [-ferror-limit=] > 20 errors generated. ... > ports tree updated today. This on > root@kg-core2# uname -a > FreeBSD kg-core2.kg4.no 11.4-RELEASE-p5 FreeBSD 11.4-RELEASE-p5 #0: > Tue Dec 1 11:46:55 UTC 2020 > r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > Any more info I can provide? > I haven't run test builds for a while, I will look into it. Do you need openjpeg support? Normal jpeg support is always on, the option for OPENJPEG is a separate library for jpeg2000 support. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Updating devel/tbb - Introducing devel/onetbb
On 10/1/21 4:29 am, Ganael Laplanche wrote: > 1) Move devel/tbb to a dedicated subdir and install devel/onetbb to its > default location. Here, we just anticipate what is written above. As you say, > as having devel/onetbb-only is the target, that would be the best solution > *BUT* it has the major disadvantage of having to patch all the current > dependent ports. This is error-prone and will require extra work I won't have > time to do. As I already wrote, I would prefer each porter to patch each port > himself (because he is the one who knows his port better that anyone). That's > why I suggested the second option. You don't have to do it all yourself, you create the bug reports to change tbb and to create onetbb, one report can depend on the other so they get committed together. My experience is being told to submit one report for each port, not one patch to change multiple ports. Then you create a report to say blender fails to build with your new port and add the report number to the Blocks list in your report. That leaves me to submit a patch to update blender to work with your change before your update can be committed. I would then add reports to update other dependencies that block my update. At most you submit 20 reports to say xx/yy port needs updating. There is devel/pybugz and ports-mgmt/freebsd-bugzilla-cli that could automate that but I haven't used them so can't recommend either. Then all the depends and blocks get updated together or some ports can get marked as broken if they fail to update in a suitable time. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Updating devel/tbb - Introducing devel/onetbb
On 8/1/21 9:51 pm, Ganael Laplanche wrote: > - leave devel/tbb in place and introduce a new port: devel/onetbb While I would generally support moving the old libs to a new portname, the fact that the project has renamed itself makes this acceptable. > - design devel/onetbb to install files in dedicated subdirs so that it will > not CONFLICT with current devel/tbb (needed during migration phase) > - provide a pkgconf file that will be used by dependencies to locate those > files and include/link options easily The expected result is to have onetbb as the only option in the future, you should leave the new port to use a standard install and only if there is a need for it, alter the old port to co-install, you could get lucky and not have anyone that wants both versions installed. Use bugs.freebsd to manage the update, start with submitting onetbb, and add conflicts with tbb. If dependent ports don't update and people want both installed, submit changes to allow tbb to co-install and have depends on bugs for each port that breaks so they get updated when the tbb changes get committed. The blender port uses seven of the other ports (with options on), with three others being slaves of one, so I expect that means a third of the ports will need to be updated together, as I doubt they will work together if they link to different tbb libs. > - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify > description to indicate the 'legacy' status of the port I don't see a need to make these changes to the existing port. Maybe adding a note in the pkg-descr could make people aware of the new port. > - [let maintainers migrate their ports to that new version] > - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE and > do the same for remaining (non-updated) deps As long as the existing tbb library compiles, it can stay as it is. Once maintaining the old port to build with new compilers/systems becomes a chore, then mark tbb and deps as deprecated and give them six months to update or be deleted. If all the deps get updated before then, the old tbb port can just be deleted. If a port or two wants to stay with the old tbb, then let them maintain the tbb port. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/libarcus fails to install
On 31/12/20 7:49 am, Diane Bruce wrote:
> On Wed, Dec 30, 2020 at 11:01:05AM +1030, Shane Ambler wrote:
>> On 28/12/20 4:40 am, Torfinn Ingolfsen wrote:
>>> On Sun, Dec 27, 2020 at 2:41 PM Torfinn Ingolfsen wrote:
>>>>
>>>> net/libarcus builds, but fails to install:
>>
>>> FWIW, devel/libsavitar has the same "problem"; with python38 installed
>>> it fails to install because it builds for 3.8 instead of 3.7.
>>
>> The issue is in cmake - I have just reported it as a bug
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252277
>
> Thanks for tracking this down! This bug of course fails to show
> up on poudriere.
poudriere builds ports in a clean environment, there is usually just one
python version available when it builds a port.
>>
>> For a workaround try adding the following to the end of the libarcus
>> Makefile (above the last .include line) indents are tabs not spaces
>> The same addition should also work for libsavitar
>>
>> post-patch:
>> ${REINPLACE_CMD} -e 's|VERSION_LESS 3.12|VERSION_LESS 4.12|g' \
>> ${WRKSRC}/CMakeLists.txt \
>> ${WRKSRC}/cmake/FindSIP.cmake
>>
>
> Should we do this for now? Or wait for CMake to be fixed?
> I can certainly add this snippet to the port for now.
You can use that yourself to allow you to build your own ports until
cmake gets an update relating to this.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/libarcus fails to install
On 28/12/20 4:40 am, Torfinn Ingolfsen wrote:
> On Sun, Dec 27, 2020 at 2:41 PM Torfinn Ingolfsen wrote:
>>
>> net/libarcus builds, but fails to install:
> FWIW, devel/libsavitar has the same "problem"; with python38 installed
> it fails to install because it builds for 3.8 instead of 3.7.
The issue is in cmake - I have just reported it as a bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252277
For a workaround try adding the following to the end of the libarcus
Makefile (above the last .include line) indents are tabs not spaces
The same addition should also work for libsavitar
post-patch:
${REINPLACE_CMD} -e 's|VERSION_LESS 3.12|VERSION_LESS 4.12|g' \
${WRKSRC}/CMakeLists.txt \
${WRKSRC}/cmake/FindSIP.cmake
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: BLENDER 2.79
On 19/4/20 10:12 pm, Adam Weinberger wrote: > On Sat, Apr 18, 2020 at 10:45 PM Shane Ambler wrote: >> >> On 19/4/20 6:15 am, Adam Weinberger wrote: >>> On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO wrote: >>>> >>>> Hello world :-) >>>> >>>> I have been using Blender-2.79 from Shane's Red Ports repository on >>>> GitHub because Blender since version 2.80 (current port is 2.82) >>>> unfortunately removed the Blender Game Engine (BGE) which I am using >>>> for work. >> >> Also note that 2.79 uses python 3.5 which is EOL 9/2020 - ~5 months >> https://devguide.python.org/#status-of-python-branches >> > Shane, if you are able to provide and support a 2.79 port, I'd be > thrilled to see it in the tree. >> >>> back unsupported and unmaintained older versions of software isn't a >>> path we go down very often. If Blender were a trivial build, it'd be >>> more feasible, but the complexity of the maintenance burden is >>> difficult to overcome. >> >> I personally maintain several blender versions, mostly to allow testing. >> Usually there is little effort, I stop updating older versions as >> dependent ports get dropped and patching gets too much, now at 2.77+. >> I make these publicly available on github not as official ports. >> >> The main concern with having a second blender port for 2.79 is the >> python35 EOL in five months. > > Is py35 a hard dep for 2.79 or can that be adjusted to 3.5+? Each blender version is only tested with and officially only supports one python version. There are no conditionals to build with what's available. I have updated my redports copy of blender279 to use python 3.6. The change is only making it find the new version, this builds and passes limited testing. I will rely on you testing it to suit your needs to see if I need to make any other patches for py36. The question now is whether we want to submit blender279/oiio18 as official ports for some time or whether you keep it as a private port. -- Tomasz, Have you looked at devel/godot-tools? The GDScript it uses internally is very similar to python, so is a quick learning curve. There is also a visual node-based scripting. While there is C# support, I don't have that working in FreeBSD yet, the mono port update in bugs.freebsd comes close. It is common for godot developers to use blender for 3d assets. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: BLENDER 2.79
On 19/4/20 6:15 am, Adam Weinberger wrote: > On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO wrote: >> >> Hello world :-) >> >> I have been using Blender-2.79 from Shane's Red Ports repository on >> GitHub because Blender since version 2.80 (current port is 2.82) >> unfortunately removed the Blender Game Engine (BGE) which I am using >> for work. >> >> The only solution so far is to use older Blender2.79 that still has >> the BGE. Blender developers just removed something with no alternative >> and no plan for alternative. Luckily I found Shane's repository that >> provides port for older version. >> >> Another solution is to have UPBGE Blender 2.80 fork with experimental >> and refreshed BGE included, unfortunately the BGE API has changed and >> it is not backward-compatible. >> >> My question is can we include both Blender-2.79 and UPBGE in the >> official ports tree next to official Blender release? All dependencies >> are provided, Actually you also need the older openimageio18 port. Also note that 2.79 uses python 3.5 which is EOL 9/2020 - ~5 months https://devguide.python.org/#status-of-python-branches >> all of them works fine next to each other. It would be >> really handy to have at least Blender-2.79 from PKG. >> >> https://github.com/sambler/sambler-redports/tree/master/graphics/blender279 >> https://github.com/sambler/sambler-redports/tree/master/graphics/upbge > > BGE is gone and done, and in most cases FreeBSD does not keep old > versions of ports around, and that's especially true for massive and > complex projects like Blender. The need to support an older blender version only relies on the use of the game engine, having started a project using the 2.79 BGE it is not nice to have to start from scratch. This would be the reason to support 2.79 in ports. Unfortunately only one person has shown interest in the nine months since 2.80 was released. If you are planning to release your project, you also need to consider support for 2.79 on other systems as well. > When UPBGE matures it'd be great to have it in the tree, but bringing I have submitted a port for upbge, following the blender 2.8x branch, while it is considered pre-release, it is only the game engine that is under development, the remainder should match the relevant blender release. The master branch is still based on 2.79 and would need the older openimageio as well. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244535 > back unsupported and unmaintained older versions of software isn't a > path we go down very often. If Blender were a trivial build, it'd be > more feasible, but the complexity of the maintenance burden is > difficult to overcome. I personally maintain several blender versions, mostly to allow testing. Usually there is little effort, I stop updating older versions as dependent ports get dropped and patching gets too much, now at 2.77+. I make these publicly available on github not as official ports. The main concern with having a second blender port for 2.79 is the python35 EOL in five months. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Request commiter to look at some lingering updates
Hi guys, I have several port updates that are getting close to a year old, it would be appreciated if these could be committed. 225939 - graphics/ptex 225940 - graphics/opensubdiv 225941 - graphics/opencolorio 224382 - graphics/openimageio 225942 - graphics/openshadinglanguage and graphics/blender These are dependencies (optional or indirect) for blender that can be built and tested as one lot. The blender update also includes a fix to build against the newest opencollada version which was just reported in bug 233859 I have built these with 11.2 amd64/i386 as well as 12-beta amd64/i386 Thanks -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Again, flavors or options?
On 21/12/2017 16:35, Freddie Cash wrote:
> On Dec 20, 2017 6:16 PM, "Yuri" <y...@rawbw.com> wrote:
>
> I have the port for the digital currency. It has 3 parts that install
> non-intersecting file sets: daemon, cli, qt-ui. The commonality: same
> repository, same build options, same license, mostly same port options.
>
> I am attracted to the idea to use flavors to let users choose which part do
> they want: FLAVORS=default daemon qt cli
As I said in my first answer, flavours changes the dependencies not the
options of the port, eg a flavour using py27 another using py36
I don't think there is a way to have different options enabled for
different flavours, each flavour will use the same options.
Until we have the ability to break a single port into multiple packages
that can be installed separately, you either have options for each item
or a different port for each. So you could make the daemon and cli
enabled as default, which will be available in the standard repos, then
the qt-gui as an option the user needs to enable and build themselves.
To simplify maintaining multiple related ports, you can use the same
Makefile for each by setting up the others as slave ports, see 5.10 of
the porters handbook. By setting a variable in the slave, you can use
logic tests to control what varies for each port in the one Makefile.
> "default" will install all of them, others will install individual parts.
> Option list will be slightly different for each flavor.
>
> One alternative: only have port options. Then some options can't be
> conditional on which parts are built.
You have several options to logically control what options are enabled.
You can find several possibilities in 5.13 of the porters handbook.
from 5.13.3.7 -
OPT1_IMPLIES= OPT2
# this means when you enable OPT1, OPT2 will automatically be turned on
from 5.13.3.8 -
OPT1_PREVENTS= OPT2
# this prevents enabling OPT1 and OPT2 at the same time
You can use the standard logic available in any Makefile -
.if ${PORT_OPTIONS:MOPT1} && ${PORT_OPTIONS:MOPT2}
# make adjustments for both options being on
.endif
You also get custom build targets based on options (5.13.3.12) -
post-patch-OPT1-on:
${REINPLACE_CMD} -e 's|opt2=True|opt2=False|' ${WRKSRC}/configure
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Option vs. flavor?
On 17/12/2017 08:32, Yuri wrote:
> On 12/16/17 13:39, Franco Fichtner wrote:
>> Why not use a separate data package as optional dependency? Solves the
>> conditional fetch.
>
>
> But with the port option fetch is also conditional. There is no need to
> create an extra-package.
Flavours aren't for option variations, they are for the same code being
linked against multiple versions of other ports, each with different
dependencies - eg python 2.7/3.6 or ruby 2.2/ruby2.4
You could either make a separate port for the data files or add it as an
option to the main port.
Using an option for the data files, you either make it a default option
so that the data is installed by anyone that installs the pkg or have it
off so that anyone who wants the data files needs to build the port
themselves. Having 4.5GB of optional data, I wouldn't suggest having it
as an option that is on, this way the package repos don't need to add
4.5GB of data for each arch that pkgs are built for.
Add a second port for data files - see games/alephone and alephone-data
for an example. To prevent the pkg being added to pkg repos, add
NO_PACKAGE= Data files too big, user to download manually
Using a second data port means the user can download and install the
data without having to compile the program.
Add info about this to pkg-message for the user to read, even if it is
about building the data port to get the extra data.
As for adding it as an option -
OPTIONS_DEFINE= EXTRADATA
EXTRADATA_DISTFILES= extra_data_files.tgz
post-install-EXTRADATA-on:
${COPYTREE_SHARE} ${WRKDIR}/extra_data_files ${STAGEDIR}/${DATADIR}
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: building blender 2.79 fails because of python dependencies
On 30/11/2017 21:05, blubee blubeeme wrote: > On Wed, Nov 29, 2017 at 9:25 PM, blubee blubeeme <gurenc...@gmail.com> > wrote: > >> Here's a build log: >> >> running install_scripts ... >> ===> blender-2.79_2 depends on shared library: libOpenColorIO.so - not >> found >> ===> opencolorio-1.0.9_3 needs Python 2.7 at most, but 3.5 was specified. >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/ports/graphics/opencolorio >> *** Error code 1 >> >> Stop. >> >> > I solved this problem by deselecting the opencolorio, openimageio and > cycles options. > > But this error does bring up an error that I'm currently dealing with > somewhere else. > > A project that uses multiple versions of python often fail to build with an > error similar to this one above: > ===> opencolorio-1.0.9_3 needs Python 2.7 at most, but 3.5 was specified. > *** Error code 1 > > How do you porters work with projects that needs multiple versions of > python to build? blender should build with cycles openimageio and opencolorio enabled. Can you build and install openimageio and then build blender? A recent change added python flavors, we can now use make FLAVOR=py35 to build a python module for python 3.5 instead of the default 2.7 https://wiki.freebsd.org/Ports/FlavorsTools My guess is it is related to the python flavors change, either it is a glitch that has since been fixed or a config you have is effecting it as I can't find a way to get the error. Check your make.conf Do you have PYTHON_VERSION set? it shouldn't be used any more Do you have DEFAULT_VERSIONS= python=3.5 -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RTTI support in devel/llvm40 (and maybe other llvm ports)
On 10/11/2017 17:37, Alexey Dokuchaev wrote: > Hi Brooks, > > I've just found out that our `devel/llvm40' port comes without > -DLLVM_ENABLE_RTTI=ON on the CMAKE_ARGS. This is a regression > from e.g. 3.4 times when it was enabled by default. > > The problem is that RTTI support is required by some consumers, > e.g. `graphics/openshadinglanguage' and `graphics/appleseed' > (cf. https://github.com/appleseedhq/appleseed/issues/1625), > but I cannot enable RTTI in those ports unless I enable it in > LLVM port(s) first. > It is probably more a case of llvm sets rtti off by default even though the llvm ports < v3.8 have enabled it. Previous versions of osl had rtti enabled to match the llvm setting. I disabled rtti in osl when switching to llvm40 only to get it to work. No changes to graphics/blender were needed. While I know appleseed fails when rtti is disabled directly in CXXFLAGS, maybe cmake can detect the use of rtti in llvm (or offer an option) and adjust to suit, or just add -fno-rtti only for the osl files. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Extra Clang Tools
On 16/09/2017 23:22, blubee blubeeme wrote: Howdy I made a few changes to the devel/llvm40/Makefile and added pp-trace as the last line of EXTRA_COMMANDS Then I rebuilt llvm40, then I noticed that the pp-trace executable is built, here's a output of the work directory grepping for pp-trace: So it now gets built but not installed; is it possible to have the port updated to move these files to the proper after they are built? Create a new report at https://bugs.freebsd.org with a patch for the Makefile and pkg-plist. While the pp-trace binary has not been included, the docs for it are already in the existing packages, the makefile is done in a way that adding it to the command list adds it to the package. To make the following patch you would use diff -udp Makefile.orig Makefile diff -udp pkg-plist.orig pkg-plist --- Makefile.orig 2017-09-17 13:02:06.907563000 +0930 +++ Makefile2017-09-17 13:02:16.043096000 +0930 @@ -164,7 +164,8 @@ EXTRAS_COMMANDS+= \ clang-reorder-fields \ clang-tidy \ find-all-symbols \ - modularize + modularize \ + pp-trace EXTRAS_LIBS= libclangApplyReplacements \ libclangChangeNamespace \ libclangIncludeFixer \ --- pkg-plist.orig 2017-05-26 17:46:41.237943000 +0930 +++ pkg-plist 2017-09-17 12:46:44.526703000 +0930 @@ -58,6 +58,7 @@ bin/sancov%%LLVM_SUFFIX%% %%EXTRAS%%bin/clang-tidy%%LLVM_SUFFIX%% %%EXTRAS%%bin/find-all-symbols%%LLVM_SUFFIX%% %%EXTRAS%%bin/modularize%%LLVM_SUFFIX%% +%%EXTRAS%%bin/pp-trace%%LLVM_SUFFIX%% %%LLD%%bin/lld%%LLVM_SUFFIX%% %%LLD%%bin/lld-link%%LLVM_SUFFIX%% %%LIT%%bin/lit%%LLVM_SUFFIX%% -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Extra Clang Tools
On 16/09/2017 11:59, blubee blubeeme wrote: FreeBSD switched to clang as it's compiler some time ago; was clang extra tools: http://clang.llvm.org/extra/index.html ever ported over? If yes, where is it located? You will find them included in the llvm ports with EXTRAS enabled clang-tidy is in llvm 3.8+ clang-include-fixer is in llvm 3.9+ modularize is in llvm 3.8+ pp-trace doesn't appear to exist clang-rename is in llvm 3.8+ clangd is in llvm-devel (5.0) Note that llvm ports append the version to the app name - they can be found in /usr/local/bin and /usr/local/llvm-/bin/ Building base WITH_CLANG_EXTRAS offers a different set of extras which are also in the llvm ports. As listed in 11-STABLE from /usr/src/usr.bin/clang/Makefile bugpoint clang-format llc lli llvm-ar llvm-as llvm-bcanalyzer llvm-cov llvm-cxxdump llvm-cxxfilt llvm-diff llvm-dis llvm-dwarfdump llvm-extract llvm-link llvm-lto llvm-lto2 llvm-mc llvm-modextract llvm-nm llvm-pdbdump llvm-profdata llvm-rtdyld llvm-symbolizer llvm-xray opt -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Issues between openmp and llvm
On 13/09/2017 20:51, Jan Beich wrote: Shane Ambler <free...@shaneware.biz> writes: ... libomp.so - found (/usr/local/llvm-devel/lib/libomp.so) The issue is that the build then fails because cc/ld is looking for openmp files in /usr/local where they should be installed. Try using SOVERSION to ignore devel/llvm* copy e.g., LIB_DEPENDS += libomp.so.0:devel/openmp Yes that works, now. As other libs from llvm are versioned what are the chances that it will always to work? -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Issues between openmp and llvm
I am testing an update to graphics/blender and seeing if I can use devel/openmp as a dependency to prevent forcing the choice of compiler. This works fine when openmp is pre-installed but fails if llvm[40|devel] is installed before checking if libomp exists. As the copy of libomp.so installed by llvm is found, devel/openmp does not get installed. > ... libomp.so - found (/usr/local/llvm-devel/lib/libomp.so) The issue is that the build then fails because cc/ld is looking for openmp files in /usr/local where they should be installed. This can fail on the host system as well as in poudriere. In poudriere it only fails if blenders CYCLESOSL option is enabled which now installs llvm40 before checking for libomp.so. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Some github projects aren't fetchable using commit hash
On 02/09/2017 11:31, Kyle Evans wrote: On Sep 1, 2017 20:03, "Shane Ambler" <free...@shaneware.biz> wrote: Respond to github support that an abbreviated hash with multiple matches will fail. Under that condition, it may be desirable to respond with the newest of the matches rather than a not found error. To be honest, the failing seems like a little better behavior than suddenly swapping out the package I thought I was downloading with a newer version. It'd at least be a little more obvious and theoretically detectable if they respond properly. For a port the distinfo will detect a hash and size difference of the tarball and fail. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Some github projects aren't fetchable using commit hash
On 02/09/2017 02:29, Yuri wrote: On 09/01/17 09:53, Tobias Kortkamp wrote: In libretro/picodrive there are two objects which have the same abbreviated hash. Probably best to use the full hash. Since another object with the same abbreviated hash can be committed into the project any time, any port using such hash (which is a lot) can break any time. I thought the porters handbook specified using a 10 digit hash... at the minimum you need a hash long enough that it is unique in that repo. If a later commit breaks the uniqueness then a longer hash will be needed. Respond to github support that an abbreviated hash with multiple matches will fail. Under that condition, it may be desirable to respond with the newest of the matches rather than a not found error. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trying to get poudriere to start
On 28/07/2017 16:51, Shane Ambler wrote: On 27/07/2017 09:30, Willem Jan Withagen wrote: On 27-7-2017 01:43, mokhi wrote: Aha, Okay... Good if it works :) It is a gross hack, but it gets me going for the time being. Also needed to fight with ninja. Turns out that somebody changed my old port to include noninja, without telling me... :( That change would be related to r444324 http://leader/viewvc/viewvc.cgi/FreeBSD-ports?view=revision=444324 Sorry, ignore that link, it should be https://svnweb.freebsd.org/ports/head/Mk/Uses/cmake.mk?revision=444324=markup Your port uses cmake, which previously would use make to build your port. The options to use ninja instead of make was an option but is now the default as speed improvements on larger projects were found. The addition of USES= cmake:noninja means your port failed using ninja during the tests of that change, which means it was left to build the same way it was before the change. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trying to get poudriere to start
On 27/07/2017 09:30, Willem Jan Withagen wrote: On 27-7-2017 01:43, mokhi wrote: Aha, Okay... Good if it works :) It is a gross hack, but it gets me going for the time being. Also needed to fight with ninja. Turns out that somebody changed my old port to include noninja, without telling me... :( That change would be related to r444324 http://leader/viewvc/viewvc.cgi/FreeBSD-ports?view=revision=444324 Your port uses cmake, which previously would use make to build your port. The options to use ninja instead of make was an option but is now the default as speed improvements on larger projects were found. The addition of USES= cmake:noninja means your port failed using ninja during the tests of that change, which means it was left to build the same way it was before the change. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of synth following expulsion of John Marino?
On 16/02/2017 14:20, Thomas Mueller wrote: For every build - /usr/local/etc/poudriere.d/make.conf OPTIONS_SET= OPTIMIZED_CFLAGS SIMD PGSQL IPV6 editors_vim_SET= CSCOPE X11 GTK3 PYTHON You can also get more specific by using - /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/---make.conf Shane Ambler Is there any way to do this options preconfiguring not using poudriere? One good thing about NetBSD pkgsrc, also Gentoo portage, is being able to set options by package or for all packages in /etc/make.conf or mk.conf . Is there a good way to do this in FreeBSD prior to running synth? Any options you setup for poudriere work just the same when placed in /etc/make.conf - poudriere copies the above files into /etc/make.conf in the build environment. You can define BATCH in your make.conf to stop config dialogs - poudriere adds BATCH=yes to the make.conf of each build jail. synth also has it's own files in /usr/local/etc/synth that it will use. See man synth -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of synth following expulsion of John Marino?
On 16/02/2017 05:28, Adam Weinberger wrote: On 15 Feb, 2017, at 11:47, abi <a...@abinet.ru> wrote: On 15.02.2017 18:00, Adam Weinberger wrote: On 15 Feb, 2017, at 2:26, Thomas Mueller <mueller6...@twc.com> wrote: Expulsion of John Marino was a shocker to me, caught me by surprise. Now my question is what is the status of synth? Should I switch from portmaster to synth? If synth is deprecated or dropped, after I switch from portmaster to synth, then I have to switch back, and this would be a monster mess of extra work. Not to be inflammatory here, just want to know where I/we stand and don't want to go too far off course updating my ports. I don't recommend portmaster for anybody. It's unmaintained, it already causes headaches on upgrades, and even though it works now, it is unlikely to keep working as the ports tree evolves. This is FUD. Yes, portmaster can be less maintained, but it works without observable issues, at least I don't see any problems with it on my systems. synth and poudriere lacks the ability to set and maintain port options recursively, eliminating any practical (from user perspective, not developer) use of such software stand alone. Sure it does. poudriere options -j jailname editors/vim Sets options recursively. Not seeing any problems with it right now isn't the point of my message. The point is that portmaster WILL break when new features (currently in progress) are added to the ports build system, and being unmaintained, there's no guarantees that it will ever unbreak. I used to do that sort thing in tinderbox, with poudriere and the new options framework I prefer to set my options in make.conf. For every build - /usr/local/etc/poudriere.d/make.conf OPTIONS_SET= OPTIMIZED_CFLAGS SIMD PGSQL IPV6 editors_vim_SET= CSCOPE X11 GTK3 PYTHON You can also get more specific by using - /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/-make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/---make.conf -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
On 12/12/2016 23:14, scratch65...@att.net wrote:
[Default] On Mon, 12 Dec 2016 17:01:33 +1030, Shane Ambler
<free...@shaneware.biz> wrote:
The quarterly ports has been setup for a couple of years but doesn't
seem to be documented well, or it just isn't obvious to find. You can
use svn to checkout a stable branch by specifying a branch name, such as
ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
use the quarterly ports by changing the pkg repo URL from
pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly
That's interesting. The ones that break on me are the ones I get
from portsnap. Does portsnap tap quarterly or something else?
Pretty sure portsnap gets snapshots from HEAD. Don't see a way to set
quarterly for it, so svn would be needed to get a quarterly ports tree.
It would mostly be a matter of timing, a snapshot is made for portsnap
and a pkg build is started. By the time the pkg repo is built (a day?
two?) a new snapshot would be in use by portsnap so it would never be in
sync with the pkg repo.
It might be worth changing defaults to use quarterly for both portsnap
and pkg. An average user shouldn't have issues to only getting new
versions every three months, for those that want to stay on the cutting
edge a few settings can be changed to use HEAD and/or latest.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
On 13/12/2016 06:01, Julian H. Stacey wrote: I would say this rarely happens with the default setup, the more port options you change the more likely it is something will break. Yes, I now start: cd /var/db/ports; mv * MV/* ; setenv NO_DIALOG=YES Before: cd /usr/ports; make BERKLIX_CLIENT=YES # Uses ports/*/Makefile.local (still innumerable breaks of course on 1200 ports inc deps.) I can re-enable options for a 2nd pass rebuild for the very few ports need it (maybe some better way?). That's what I like about poudriere, one port can fail and builds still continue until as much is built as possible. I also know that everything is built before changing anything that is installed. poudriere's `-f' is nice to accept a list. But I havent found a way to build my list yet from my Makefile.local eg cd /usr/ports; make BERKLIX_CLIENT=YES echo_my_category_and_port I'll probably hack bsd.port.mk & bsd.port.subdir.mk make all-depends-list also - make build-depends-list make run-depends-list make package-depends-list make test-depends-list To create a list of ports I have installed I just use pkg info -aqo | sort > myports.list For setting options, I created /usr/local/etc/poudriere.d/mypkg-make.conf and filled it with lines like DEFAULT_VERSIONS= apache=2.4 perl5=5.20 pgsql=9.5 OPTIONS_SET= OPTIMIZED_CFLAGS CPU_OPTS SIMD MMX SSE SSE2 SSSE3 x11-servers_xorg-server_SET= DEVD SUID x11-servers_xorg-server_UNSET= HAL then I use poudriere bulk -j 10stableamd64 -p myports -z mypkg -f myports.list that way these settings are only used when building my pkg repo and not when I test build any ports (use poudriere.d/make.conf for settings to be used in all poudriere builds). My /etc/make.conf only contains - .include "/usr/local/etc/poudriere.d/mypkg-make.conf" so the same setting are used for any manual port builds as well as my poudriere created pkg repo. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
On 12/12/2016 13:12, Janky Jay, III wrote:
Hello scratch,
On 12/11/2016 03:35 PM, scratch65...@att.net wrote:
I have to admit that I avoid ports if at all possible because
I've hardly ever been able to do a build that ran to completion.
There's always some piece of code that's missing and can't be
found, or is the wrong version, et lengthy cetera. I've never
done release engineering, but I honestly can't imagine how some
of the stuff that makes its way into the ports tree ever got past
QA. It would get someone sacked if it happened in industry.
If the dev schedule would SLOW DOWN and the commitment switched
to quality from the current emphasis on frequency, with separate
trees for alpha-, beta-, and real release-quality, fully-vetted
code, the ports system might become usable again.
Note that there are over 26000 ports, over 1600 port maintainers and
hundreds of third party projects get updated every day. While the port
maintainers spend a good portion of their spare time trying to keep it
building there will be times that some ports fail to build.
The HEAD of the ports svn repo is for the cutting edge development, a
quarterly branch is created every three months and is only updated to
receive security and build or runtime fixes during that time.
The quarterly ports has been setup for a couple of years but doesn't
seem to be documented well, or it just isn't obvious to find. You can
use svn to checkout a stable branch by specifying a branch name, such as
ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
use the quarterly ports by changing the pkg repo URL from
pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly
This very, VERY rarely happens to me and I use ports *ONLY* in
production environments. If you could please provide examples and report
the issues to the port maintainer of the ports with issues, that would
greatly help this situation. (Please don't take this as an insult or
anything other than trying to be helpful...) Simply complaining about it
without providing any additional information is certainly not going to
improve anything.
I would say this rarely happens with the default setup, the more port
options you change the more likely it is something will break.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Is there possible run a MacOS X binary
On 08/12/2016 09:15, Nilton Jose Rizzo wrote: Thankx for all comments. I know and understood all difficult. I'll have to spend my money on the purchase a Machintosh machine. Now that bhyve has gui support can OSX be started as a bhyve guest? Has anyone tried to get an openfirmware loader running? Do current macs still use openfirmware? For info regarding a compat layer for anyone wanting to work on that - cocotron.org is an mit licensed project similar to GNUStep - it has mostly focused on windows compatibility with Foundation usable on *nix flavours. There is apparently X11 support in AppKit but it needs a lot of work. -- FreeBSD - the place to B...Sharing Devices Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: running make makesum for multiple github repos
On 27/11/2016 23:27, Willem Jan Withagen wrote:
On 27-11-2016 13:34, Mathieu Arnold wrote:
Le 27/11/2016 à 12:57, Willem Jan Withagen a écrit :
On 26-11-2016 21:10, Mathieu Arnold wrote:
Le 25/11/2016 à 12:46, Willem Jan Withagen a écrit :
Hi,
I'm try in to make a port for Ceph, but it depens on a lot of github
modules.
In the fourth field the group is required, and subdir is optional.
The GH_TUPLE format is a bit strange, I agree, but the subdirectory
could not be put in another place because the third field (commit or
tag) can contain a / (there are a few examples in the tree), and the
path can contain a : (I stumbled upon one).
Also, GH_SUBDIR is optional, and it was a bad idea to put an optional
part in the middle of the string.
(And I'm not talking about the fact that GH_SUBDIR is newer than
GH_TUPLE, and that backward compatibility needed to be kept.)
GH_TUPLE is also not very often used in the ports. So there are not that
many examples to find. And I appreciate backwards compatibility, and
starting to escape chars will not make it more ledgible.
It now looks like:
GH_TUPLE+= ceph:xxHash:v0.5.1-2-g1f40c65:xxHash/src/xxHash
GH_TUPLE+= ceph:isa-l:v2.16.0:isal/src/isa-l
GH_TUPLE+= ceph:lua:lua-5.3-ceph:lua/src/lua
GH_TUPLE+= ceph:Beast:999e2fa:Beast/src/Beast
GH_TUPLE+= boostorg:boost:boost-1.61.0-275-g1790aff:boost/src/boost
GH_TUPLE+= ceph:dpdk:a38e5ec:dpd/src/dpd
1:
https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github
That is where i got my info...
The trouble I had using multiple github repos when it was first setup
(before GH_TUPLE) was that you *MUST* use the default group - that is
one tuple with no group name or using the group name of DEFAULT and no
subdir, the default repo is set as WRKSRC and is the base dir that the
other subdirs are relative to.
That would be the point that makes the manual mis-leading as the
examples use a group name for both repos. In example 5.4 under the
sample makefile it reads "This will fetch three distribution files from
github. The default one comes from foo/foo and is version 1.0.2." that
means the not-so-obvious default repo is using an automatically
generated tuple from ${PORTNAME}:${PORTNAME}:${PORTVERSION}
So I get makesum to work by using a default tuple -
GH_TUPLE= wjwithagen:ceph:64bcf92
GH_TUPLE+= facebook:rocksdb:6370c43:rocksdb/src/rocksdb
GH_TUPLE+=
ceph:ceph-erasure-code-corpus:b5c8634:cepherasure/ceph-erasure-code-corpus
GH_TUPLE+= ceph:ceph-object-corpus:bb3cee6:cephobject/ceph-object-corpus
GH_TUPLE+= ceph:civetweb:v1.5:civetweb/src/civetweb
GH_TUPLE+=
ceph:jerasure:v2-ceph:jerasure/src/erasure-code/jerasure/jerasure
GH_TUPLE+=
ceph:gf-complete:v3-ceph:gfcomplete/src/erasure-code/jerasure/gf-complete
GH_TUPLE+= ceph:googletest:ceph-release-1.7.x:googletest/src/googletest
GH_TUPLE+= ceph:spdk:v1.2.0:spdk/src/spdk
GH_TUPLE+= ceph:xxHash:v0.5.1:xxhash/src/xxHash
GH_TUPLE+= ceph:isa-l:v2.16.0:isa/src/isa-l
GH_TUPLE+= ceph:lua:lua-5.3-ceph:lua/src/lua
GH_TUPLE+= ceph:Beast:999e2fa:beast/src/Beast
GH_TUPLE+= boostorg:boost:boost-1.61.0:boost/src/boost
GH_TUPLE+= ceph:dpdk:a38e5ec:dpdk/src/dpdk
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Alternatives to rsync
On 14/10/2016 08:56, Greg 'groggy' Lehey wrote: On Thursday, 13 October 2016 at 18:13:39 +1030, Shane Ambler wrote: On 13/10/2016 15:09, reko.turja--- via freebsd-ports wrote: One of my users is needing rsync like functionality to transfer changed contents of some directories between couple of machines. As rsync 3 isn't open source, but GPL3 it's out of question in order to keep the system untainted. The software should be relatively lightweight - no fullblown mirroring/backup is needed. Also hints how to achieve similar ends using maybe tar/ssh might do. sysutils/cpdup provides similar functionality to rsync and is bsd licensed. Does anybody have information on how efficient it is in comparison with rsync? Apart from that, I agree with the other comments. But if Reko wants a non-GPL3 package, for whatever reason, what's wrong with an older version of rsync? A new port could be created to build an older version - unless there is a wider interest in maintaining the older version, the drawback will be that it will use an old unsupported code base that will need to be maintained by the one person using it and will likely only get limited testing within the scope of their use case. There is a chance that others want to stay away from gplv3 so a fork of rsync 2.6.9 could be the start of a new rsync alternative project - not just a port to build an old version. -- FreeBSD - the place to B...Saving Data Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Alternatives to rsync
On 13/10/2016 15:09, reko.turja--- via freebsd-ports wrote: One of my users is needing rsync like functionality to transfer changed contents of some directories between couple of machines. As rsync 3 isn't open source, but GPL3 it's out of question in order to keep the system untainted. The software should be relatively lightweight - no fullblown mirroring/backup is needed. Also hints how to achieve similar ends using maybe tar/ssh might do. -Reko sysutils/cpdup provides similar functionality to rsync and is bsd licensed. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Can a commiter look at devel/godot
After several changes over the last few months it would be nice if the update to devel/godot and the new devel/godot-tools could get committed. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209742 Thanks -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On 20/08/2016 21:30, Diane Bruce wrote: On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote: On 19/08/2016 10:13, Steven G. Kargl wrote: ... You should find that all newer copies of libgcc_s contain compatibility support for binaries that were linked to earlier versions. Indeed. And the version masquerading as a GNU libgcc_s in base does the same thing. Two problems: our base libgcc_s only covers version up to GCC_4.2.0 and there is a name conflict on the library name with libgcc_s from the gnu compiler. Hence if a program links against base libgcc_s first then requires libgfortran which itself requires support for above GCC_4.2.0, the program fails. OR Whenever a program requires support that is missing on the platform it is running on from our libgcc_s, it will fail. There are numerous PR's on this which all have the common problem of linking with a libgcc_s that does not support > GCC_4.2.0 Actually the problem is going the other way. A port gets compiled and linked against the newer libs but at run time it finds the base system lib first and loads that which doesn't support the binary that is being run. If the gcc6 libgcc_s was always installed and found first then we wouldn't have this problem. I first found this issue trying to import numpy into blender. As blender had started and was using the base libgcc_s, when I tried to import numpy that needed the newer libgcc_s for it's fortran code it failed. I discovered that setting LD_LIBRARY_PATH in the environment when starting blender got it to load the newer libgcc_s which then worked when importing numpy, so I've been happy doing that for a couple of years. I have seen the same thing were a python module has brought in the base libgcc_s before numpy which needed the newer one. The dynamic loading of python modules seems to be the only time I have seen this. Either changing the import order or LD_LIBRARY_PATH to get the newer lib loaded the first time has solved the issue. So one solution could be to copy the newer libgcc_s into /lib but the newer library won't get added to base as it contains GPLv3 code. Maybe remove /lib/libgcc_s.so to force the search for a newer version. While bug reports have lead to other things, I think the solution might be to configure/patch ld to get it searching paths to find the newer version first. libgcc_s would be such a common case that we could have a permanent ld setting in base to always find a newer libgcc_s before the base version. I haven't been bitten enough to have looked at this. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: graphics/gd marked as broken?
On 21/08/2016 04:46, Grzegorz Junka wrote: On 20/08/2016 19:11, Grzegorz Junka wrote: On 20/08/2016 16:23, Walter Schwarzenfeld wrote: The port is not broken, it compiles in port and with poudriere. Only if option WEBP is set to on it is broken. look with poudriere options -C -jhailname graphics/gd how is it set, and change it if is to on. So, poudriere lies then, it says it's broken: [00:01:21] >> [04][00:00:00] Starting build of graphics/gd [00:01:21] >> [04][00:00:00] Finished build of graphics/gd: Ignored: is marked as broken: circular dependencies Greg Sorry, I should have been clearer. I know the port isn't broken, I just don't understand why poudriere says it's marked as broken if, according to you, it's a circular dependency and the port isn't marked in any way? Greg Actually it isn't poudriere - the port itself says it's broken when the WEBP option is enabled. WEBP_BROKEN=circular dependencies So the new version of gd added support for webp, the maintainer added the option to enable it, then marked the option as broken. gd doesn't have WEBP enabled by default so you have settings somewhere to enable it. If you aren't specifically enabling the WEBP option for gd then check that you aren't enabling it globally in OPTIONS_SET In the make.conf for your build add - graphics_gd_UNSET= WEBP If that doesn't work some others to try. graphics_gd_UNSET_FORCE= WEBP OPTIONS_UNSET=WEBP OPTIONS_UNSET_FORCE=WEBP -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On 19/08/2016 10:13, Steven G. Kargl wrote: On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric <d...@freebsd.org> wrote: how would you solve the problem of having multiple, possibly incompatible versions of the same library in different directories? For example, on one of my systems, I now have these: /usr/local/lib/gcc47/libgcc_s.so.1 /usr/local/lib/gcc48/libgcc_s.so.1 /usr/local/lib/gcc49/libgcc_s.so.1 /usr/local/lib/gcc5/libgcc_s.so.1 /usr/local/lib/gcc6/libgcc_s.so.1 /usr/local/lib/gcc7/libgcc_s.so.1 So which one are you going to put at the front of the path? The gcc7 version? If you are lucky that one is backwards compatible with all the previous ones, You should find that all newer copies of libgcc_s contain compatibility support for binaries that were linked to earlier versions. For the gcc policy on library ABI compatibility read - http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html You can find the ABI versions contained in each library - % strings /usr/lib/libgcc_s.so | grep 'GCC_[0-9]' | sort -u GCC_3.0 GCC_3.3 GCC_3.3.1 GCC_3.4 GCC_3.4.2 GCC_3.4.4 GCC_4.0.0 GCC_4.2.0 GCC_4.3.0 % strings /usr/local/lib/gcc48/libgcc_s.so.1 | grep 'GCC_[0-9]' | sort -u GCC_3.0 GCC_3.3 GCC_3.3.1 GCC_3.4 GCC_3.4.2 GCC_3.4.4 GCC_4.0.0 GCC_4.2.0 GCC_4.3.0 GCC_4.6.0 GCC_4.7.0 GCC_4.8.0 -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: blender and cycles engine
On 31/07/2016 09:12, 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) What do you have installed that uses llvm37? When blender is built using CYCLESOSL it uses llvm34 which could be the reason for the conflict. If you are building with CYCLES and not CYCLESOSL then it shouldn't need llvm34 but you may have two ports that blender depends on that have been built using different llvm versions. What ports are listed with - pkg info -rx 'llvm3[47]' -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: what to do when base openssl isn't suitable
On 02/07/2016 04:29, Don Lewis wrote: I've got a port that does not work with base openssl because it looks for libssl.pc. Other than that, I don't think it is picky about what flavor of ports ssl is installed. If it is looking for libssl.pc then it is using pkg-config to get the CFLAGS/CXXFLAGS/LDFLAGS to use for openssl. Search the Makefiles for pkg-config openssl --cflags --libs or the variable substituted equivalent, then patch it to suit. If you want to use the system openssl then manually adding -lssl -lcrypto where it adds the result from pkg-config should work. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Reorganization of the py-sqlalchemy ports
On 19/05/2016 16:55, Matthew Seaman wrote: On 18/05/2016 23:04, Olivier Duchateau wrote: I'm proposing the following: py-sqlalchemy06 0.6.9 ni...@freebsd.org (Deprecate 2016-08-20) py-sqlalchemy07 0.7.10 ni...@freebsd.org (Deprecate 2016-08-20) py-sqlalchemy08 0.8.7 ni...@freebsd.org py-sqlalchemy09 0.9.10 m.tsatse...@gmail.com py-sqlalchemy10 1.0.13 m.tsatse...@gmail.com I wonder, why to create as many SQLAlchemy ports as releases (it's just an ORM after all). The easiest way, imho is focusing on 1.0.x releases, and having only one port databases/py-sqlalchemy. This is the conservative approach. It may well be the case that everything that depends on sqlalchemy can perfectly well just use the latest version, in which case the number of ports can be reduced. However we don't know how compatible the different versions are yet, and it will take some time and experimentation to work it out. In the mean time, having this many ports will provide some assurance of compatibility. Personally I am just starting to look at sqlalchemy so can't comment on the compatibility between versions. Having a look at bsdstats.org they show port install numbers of py27-sqlalchemy9 py27-sqlalchemy06 147 py27-sqlalchemy08 1 It may be worth considering keeping 0.6 for compatibility and drop 0.7, 0.8, 0.9 As we currently have 0.6, 0.7, and 0.8 I would skip adding 0.9 and just add 1.0 -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Need some help with c++/qt5 code
On 15/04/2016 21:45, Raphael Kubo da Costa wrote:
Dimitry Andric <d...@freebsd.org> writes:
On 14 Apr 2016, at 13:58, Shane Ambler <free...@shaneware.biz> wrote:
Hi there, while I am comfortable with c and python, I only know a little
c++ and could use some help.
...
class TPanelFactory
{
QString m_panelType;
static QMap<QString, TPanelFactory *> m_table;
public:
TPanelFactory(QString panelType);
~TPanelFactory();
QString getPanelType() const { return m_panelType; }
virtual void initialize(TPanel *panel) = 0;
virtual TPanel *createPanel(QWidget *parent);
static TPanel *createPanel(QWidget *parent, QString panelType);
};
m_table is then in the source file as
QMap<QString, TPanelFactory *> TPanelFactory::m_table;
The segfault happens in the constructor -
TPanelFactory::TPanelFactory(QString panelType)
: m_panelType(panelType)
{
assert(m_table.count(panelType) == 0);
m_table[m_panelType] = this;
}
the last line causes the segfault, if I comment it out then main() is
entered, but I expect removing that line will bite back soon enough.
How can I get this working?
Why would this fail on FreeBSD but not OSX or windows?
Most likely the program depends on the initialization order of global
constructors. This is bad practice, and should be avoided.
I agree. Maybe using Q_GLOBAL_STATIC helps?
- Remove m_table from TPanelFactory.
- In pane.cpp, you do something like this:
typedef QMap<QString, TPanelFactory *> PanelMapType;
Q_GLOBAL_STATIC(PanelMapType, s_panelMap);
you then need to replace uses of m_table with s_panelMap and use
s_panelMap->operation() instead of m_table.operation().
Thanks that does the trick.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Need some help with c++/qt5 code
On 15/04/2016 08:02, Dimitry Andric wrote:
On 14 Apr 2016, at 13:58, Shane Ambler <free...@shaneware.biz> wrote:
Hi there, while I am comfortable with c and python, I only know a little
c++ and could use some help.
...
class TPanelFactory
{
QString m_panelType;
static QMap<QString, TPanelFactory *> m_table;
public:
TPanelFactory(QString panelType);
~TPanelFactory();
QString getPanelType() const { return m_panelType; }
virtual void initialize(TPanel *panel) = 0;
virtual TPanel *createPanel(QWidget *parent);
static TPanel *createPanel(QWidget *parent, QString panelType);
};
m_table is then in the source file as
QMap<QString, TPanelFactory *> TPanelFactory::m_table;
The segfault happens in the constructor -
TPanelFactory::TPanelFactory(QString panelType)
: m_panelType(panelType)
{
assert(m_table.count(panelType) == 0);
m_table[m_panelType] = this;
}
the last line causes the segfault, if I comment it out then main() is
entered, but I expect removing that line will bite back soon enough.
How can I get this working?
Why would this fail on FreeBSD but not OSX or windows?
Most likely the program depends on the initialization order of global
constructors. This is bad practice, and should be avoided.
So what's the value of m_table at this point? It looks a lot like it
is still uninitialized.
Yes uninitialised sounds right - what is the right way to fix this?
I get non-zero values for the address of each variable there, but while
they may be allocated I don't think they are initialised as a call to
m_table.count() will cause a segfault.
TPanelFactory::TPanelFactory(QString panelType)
: m_panelType(panelType)
{
assert(m_table.count(panelType) == 0);
std::cout << "m_table.count is " << m_table.count(panelType) <<
std::endl;
std::cout << "TPanelFactory::m_table is at " <<
::m_table << std::endl;
std::cout << "this is at " << this << std::endl;
std::cout << "panelType is at " << << std::endl;
std::cout << "m_panelType is at " << _panelType << std::endl;
m_table[m_panelType] = this;
}
The output with m_table.count() prevents the other output lines
running, without the m_table.count() line, the others can output
before the segfault.
Without the m_table.count() line -
% ./opentoonz
TPanelFactory::m_table is at 0xc39568
this is at 0xc3a628
panelType is at 0x7fffd408
m_panelType is at 0xc3a630
Segmentation fault
With the m_table.count() line -
% lldb opentoonz
Current executable set to 'opentoonz' (x86_64).
(lldb) run
Process 56499 launching
Process 56499 stopped
(lldb) Process 56499 launched:
'/home/shane/Projects/opentoonz/test_install/bin/opentoonz' (x86_64)
Process 56499 stopped
* (lldb) thread #1: tid = 101441, 0x004f2d7f
opentoonz`QMapData<QString, TPanelFactory*>::nodeRange(QString const&,
QMapNode<QString, TPanelFactory*>**, QMapNode<QString,
TPanelFactory*>**) + 31, stop reason = invalid address (fault address: 0x10)
frame #0: 0x004f2d7f opentoonz`QMapData<QString,
TPanelFactory*>::nodeRange(QString const&, QMapNode<QString,
TPanelFactory*>**, QMapNode<QString, TPanelFactory*>**) + 31
opentoonz`QMapData<QString, TPanelFactory*>::nodeRange(QString const&,
QMapNode<QString, TPanelFactory*>**, QMapNode<QString,
TPanelFactory*>**) + 31:
-> 0x4f2d7f: movq 0x10(%r14), %r15
0x4f2d83: addq $0x8, %r14
0x4f2d87: testq %r15, %r15
0x4f2d8a: je 0x4f2e6a ; QMapData<QString,
TPanelFactory*>::nodeRange(QString const&, QMapNode<QString,
TPanelFactory*>**, QMapNode<QString, TPanelFactory*>**) + 266
(lldb) bt
* thread #1: tid = 101441, 0x004f2d7f
opentoonz`QMapData<QString, TPanelFactory*>::nodeRange(QString const&,
QMapNode<QString, TPanelFactory*>**, QMapNode<QString,
TPanelFactory*>**) + 31, stop reason = invalid address (fault address: 0x10)
* frame #0: 0x004f2d7f opentoonz`QMapData<QString,
TPanelFactory*>::nodeRange(QString const&, QMapNode<QString,
TPanelFactory*>**, QMapNode<QString, TPanelFactory*>**) + 31
frame #1: 0x004f20d8
opentoonz`TPanelFactory::TPanelFactory(QString) + 120
frame #2: 0x0057118d
opentoonz`XsheetViewerFactory::XsheetViewerFactory() + 45
frame #3: 0x005701d7 opentoonz`_GLOBAL__I_a + 1687
frame #4: 0x0080a1b2 opentoonz`__do_global_ctors_aux + 34
frame #5: 0x0048551e opentoonz`_init + 14
frame #6: 0x000800c03c9f
frame #7: 0x000800c0328e
(lldb) quit
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Need some help with c++/qt5 code
Hi there, while I am comfortable with c and python, I only know a little
c++ and could use some help.
I am in the process of getting a QT5 based app running on FreeBSD and
have an issue that I'm not sure how to resolve. The project is opentoonz
which is a commercial project that was recently open sourced. The code
base has been previously built only on OSX and windows
By using work others have done to build on linux I have got to the point
of compiling and linking on FreeBSD but get a segfault on startup. The
failing code is part of the variable initialising run before the first
line of main()
I am using clang 3.4.1 on 10-STABLE-amd64, (gcc build needs more work)
the binary is linked to gcc48/libgcc_s.so which is needed for the
superlu/blas libraries that are used.
The class definition is -
class TPanelFactory
{
QString m_panelType;
static QMap<QString, TPanelFactory *> m_table;
public:
TPanelFactory(QString panelType);
~TPanelFactory();
QString getPanelType() const { return m_panelType; }
virtual void initialize(TPanel *panel) = 0;
virtual TPanel *createPanel(QWidget *parent);
static TPanel *createPanel(QWidget *parent, QString panelType);
};
m_table is then in the source file as
QMap<QString, TPanelFactory *> TPanelFactory::m_table;
The segfault happens in the constructor -
TPanelFactory::TPanelFactory(QString panelType)
: m_panelType(panelType)
{
assert(m_table.count(panelType) == 0);
m_table[m_panelType] = this;
}
the last line causes the segfault, if I comment it out then main() is
entered, but I expect removing that line will bite back soon enough.
How can I get this working?
Why would this fail on FreeBSD but not OSX or windows?
The backtrace I get from lldb and gdb -
% lldb opentoonz
Current executable set to 'opentoonz' (x86_64).
(lldb) run
Process 80086 launching
Process 80086 stopped
(lldb) Process 80086 launched:
'/home/shane/Projects/opentoonz/test_install/bin/opentoonz' (x86_64)
Process 80086 stopped
* (lldb) thread #1: tid = 101033, 0x004f2026
opentoonz`TPanelFactory::TPanelFactory(QString) + 70, stop reason =
invalid address (fault address: 0x0)
frame #0: 0x004f2026
opentoonz`TPanelFactory::TPanelFactory(QString) + 70
opentoonz`TPanelFactory::TPanelFactory(QString) + 70:
-> 0x4f2026: cmpl $0x2, (%rax)
0x4f2029: jb 0x4f203d ;
TPanelFactory::TPanelFactory(QString) + 93
0x4f202b: movq 0x73eb5e(%rip), %r15 ; opentoonz..got + 6728
0x4f2032: movq %r15, %rdi
(lldb) bt
* thread #1: tid = 101033, 0x004f2026
opentoonz`TPanelFactory::TPanelFactory(QString) + 70, stop reason =
invalid address (fault address: 0x0)
* frame #0: 0x004f2026
opentoonz`TPanelFactory::TPanelFactory(QString) + 70
frame #1: 0x00570cfd
opentoonz`XsheetViewerFactory::XsheetViewerFactory() + 45
frame #2: 0x0056fd47 opentoonz`_GLOBAL__I_a + 1687
frame #3: 0x00809d22 opentoonz`__do_global_ctors_aux + 34
frame #4: 0x004854ae opentoonz`_init + 14
frame #5: 0x000800c02c9f
frame #6: 0x000800c0228e
(lldb) quit
% gdb opentoonz
...
(gdb) run
Starting program: /home/shane/Projects/opentoonz/test_install/bin/opentoonz
Program received signal SIGSEGV, Segmentation fault.
0x004f2026 in TPanelFactory::TPanelFactory(QString) ()
(gdb) bt
#0 0x004f2026 in TPanelFactory::TPanelFactory(QString) ()
#1 0x00570cfd in XsheetViewerFactory::XsheetViewerFactory() ()
#2 0x0056fd47 in global constructors keyed to a ()
#3 0x00809d22 in __do_global_ctors_aux ()
#4 0x004854ae in _init ()
#5 0x7fffda20 in ?? ()
#6 0x000800c02c9f in objlist_call_init () from /libexec/ld-elf.so.1
#7 0x000800c0228e in _rtld () from /libexec/ld-elf.so.1
#8 0x000800c00449 in .rtld_start () from /libexec/ld-elf.so.1
#9 0x in ?? ()
(gdb) quit
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Multiple ffmpeg versions in ports
On 31/03/2016 10:29, Kevin Oberman wrote: On Wed, Mar 30, 2016 at 2:39 PM, Ben Woods <woods...@gmail.com> wrote: On 30 March 2016 at 23:28, Ben Woods <woods...@gmail.com> wrote: What do you think about having numerous versions of ffmpeg in ports, similar to lang/python? I guess the obvious question is how could it be possible for multiple ffmpeg versions to be installed at the same time? Is it possible to ensure the files do not overlap, and that each package is linking against the correct installed version? -- From: Benjamin Woods woods...@gmail.com Probably speaking out of turn, but we do have ffmpeg0 and ffmpeg in ports now. For quite some time we had ffmpeg1, as well, but I think all ports have now moved on, so ffmpeg1 was removed. It would be up to someone to write he support for a separate ffmpeg3/ ffmpeg, ffmpeg0 and ffmpeg1 when it existed, can all be installed simultaneously. If you look through the ffmep0 Makefile you will find it adds a 0 suffix to the binaries, libraries and dirs installed to prevent conflicts. The ffmpeg configure step supports specifying the dirs to install into as well as the suffix to add. It may be time ffmpeg is updated to 3.x and the current ffmepg could be moved to ffmpeg2. It is only a matter of someone making and maintaining the port/s for each version, probably more to the point is how many other ports would need a version other than what is in ffmpeg. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Multiple versions of Python packages (2.7 vs 3.4)
On 16/03/2016 23:39, Miroslav Lachman wrote:
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?
This is an automated step to allow the python ports to be installed for
more than one python version at the same time. The scripts in
/usr/local/bin being one of the places that a conflict can happen. Docs
and licenses are other paths that can conflict, these other dir names
are altered to match the python version. eg share/licenses/py-pip will
get changed to share/licenses/py27-pip
In the Makefile of the port USE_PYTHON=concurrent enables this feature,
if a port conflicts with multiple python versions then concurrent needs
to be added (or sometimes other adjustments). If you remove concurrent
then the symlinks in bin won't be made.
I don't think there is a way to control this with environment variables
so you would have to alter the ports Makefile and build yourself if you
want it to work differently.
The reason for the symlink is to allow the expected pip script to exist
in bin while preventing multiple python versions conflicting, the pkg
installed for the default version of python will own the bin/pip which
will symlink to it's install of bin/pip-${PYTHON_VER} - pkgs installed
for other versions of python will only install bin/pip-${PYTHON_VER}
So if python 2.7 is the default version, py27-pip will install bin/pip
and bin/pip-2.7 while py34-pip will only install bin/pip-3.4
If you run pip you will get the default py27 version but if you want to
run it for py34 then you need to specifically run pip-3.4
You can alter the default python version by adding to /etc/make.conf
DEFAULT_VERSIONS= python=2.7 python2=2.7 python3=3.4
And if your wondering how to build multiple versions -
cd /usr/ports/devel/py-pip
make PYTHON_VERSION=3.4 install clean
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: library porting question - optional python bindings
On 03/03/2016 03:03, Chris Inacio wrote: On Tue, Mar 1, 2016 at 3:04 AM, Shane Ambler <free...@shaneware.biz> wrote: On 01/03/2016 13:08, Chris Inacio wrote: All, I'm trying to build a port definition for a library/application that can optionally include Python bindings. The library/application generally depends on other C libraries to exist (ZMQ v3, Protobufs-C) and if you enable Python support, then you need a Python interpreter plus Python-protobufs & python zmq. For a normal python module I would suggest making it as a separate port that just installs the python module. This makes it easier to install multiple versions for each python version. The py-module port can be a slave of the main port so you don't have to maintain the same code twice. The library is generally a C library with 3 "targets" a library (.so), header files (.h), and daemon that can be used as well. If you enable the optional Python support, then there is an entire python build area with the full "python setup.py ..." that gets run *from the C Makefile* when the Python dependencies are available. So yes, I can see that it makes sense to have this has 2 separate ports from a port maintenance point of view, but this is distributed as a single distribution. So you're suggesting 2 ports, from one source download, and 1 of those ports dependent on the other port? Yes you only need the one src tarball and distinfo between both ports. You can also use the same pkg-descr and maybe the same pkg-plist. If the contents of the python port Makefile is kept to a minimum you will only have to change the master port to update both, the changes to the master port will apply to both ports. You can use conditionals to get variations between building each port. The python module port only needs to depend on the master port if it uses the libraries installed by it, which I'm expecting it would. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: library porting question - optional python bindings
On 01/03/2016 13:08, Chris Inacio wrote:
All,
I'm trying to build a port definition for a library/application that can
optionally include Python bindings. The library/application generally
depends on other C libraries to exist (ZMQ v3, Protobufs-C) and if you
enable Python support, then you need a Python interpreter plus
Python-protobufs & python zmq.
Putting an OPTION of Python in the port file is easy. Including the
optional Python dependencies (and presumably targets - but I'm not that far
yet) seems to be a lot more complicated. I haven't found anything that
would tell me how I'm supposed to do that. I have found that I'm supposed
to add pyXX prefixes to the python targets.
Python bindings as in a module that can be imported in python? or
python bindings that help the lib linking to it to be exposed to python?
The difference is a python module will be installed into
pythonx.y/site-packages while the other will install lib/libxxx.so
devel/boost-python-libs is an example of the later.
For a normal python module I would suggest making it as a separate port
that just installs the python module. This makes it easier to install
multiple versions for each python version. The py-module port can be a
slave of the main port so you don't have to maintain the same code
twice.
A port with PORTNAME=nose and PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}
can then end up with multiple installs to support each python version.
pkg info -ox nose
py27-nose-1.3.7devel/py-nose
py34-nose-1.3.7devel/py-nose
py35-nose-1.3.7devel/py-nose
Does anyone know of a similar application/library that I can go look at?
Is there any documentation on how to solve this?
I have graphics/openimageio and py-openimageio as well as
graphics/opencolorio that has opencolorio-tools and py-opencolorio as
slaves.
openimageio uses SLAVE_PORT as defined by the ports infrastructure
while opencolorio defines it's own OCIO_SLAVE to distinguish between
the two slaves
Using VARIABLE?=xxx in the master Makefile allows the slave port to
override that variable.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Poudriere and python framework of ports
On 09/01/2016 13:21, Yasuhiro KIMURA wrote:
But on poudriere with 10.2-R jail the result is different as
following:
* "poudriere testport -j 102release -o mail/postfix-policyd-spf-python"
fails at check-sanity phase.
* Some dependents (such as mail/py-authres or mail/py-pyspf) are build
as python 2 packages (py27-authres-0.800, py27-pyspf-2.0.12_3, and
etc.)
Then what is the cause of failure on poudriere? Is there something
wrong with my patch, or is this bug of either poudriere or python
framework of ports? Would someone please let me know?
In poudriere each port is built independently, that is they don't
inherit the specified python version from the port triggering the build
as a dependency. It is possible that poudriere could be adjusted to
compensate for this. It would require considering PYTHON_VERSION and
using pkg names when dealing with dependencies instead of just the port
origin. So, yes to a poudriere bug.
For now - to get ports to build in poudriere with python3 you need to
create a make.conf for the poudriere jail -
/usr/local/etc/poudriere.d/jailname-make.conf
To get all ports built with python3 as the default version add
DEFAULT_VERSIONS= python=3.5
To get python3 ports that install into a system that has py2.7 as
default you need to have
DEFAULT_VERSIONS= python=2.7 python3=3.5
PYTHON_VERSION= python3.5
As the default python is still 2.7 I believe the port will need to
define IGNORE. Something like -
.if defined(PACKAGE_BUILDING) && ${PYTHON_DEFAULT} == 2.7
IGNORE= requires python3 dependencies and must be built manually
.endif
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: USES=fortran can't mix with the libraries requiring /lib/libgcc_s.so.1 from the base
On 24/12/2015 01:04, Diane Bruce wrote: On Wed, Dec 23, 2015 at 04:35:29AM -0800, Yuri wrote: What is the general solution for this problem? Is there a non-gcc version of fortran? No there is currently no clang version of Fortran. 'flang' was a SOC project to bring in clang support for fortran but it is moribund. The clang guys are the ones you should bug. In any case, the Fortran spec now requires quad math support so that would have to be provided as well. One thing is when gcc is required because clang can't compile something, and another things is when fortran language requires it. The latter is here to stay. Can there be the separate fortran from gcc that is build with clang? Or can we switch /usr/ports/lang/gccNN to be always built with the base clang? I know this is certainly possible. No. The core problem is due to our version of libgcc not having quadmath support. Maybe the quadmath files could be taken out to make a standalone library. Another possibility might be DragonEgg, though it doesn't appear to have been updated for a while. http://dragonegg.llvm.org/ "DragonEgg is a gcc plugin that replaces GCC's optimizers and code generators with those from the LLVM project. It works with gcc-4.5 or newer, can target the x86-32/x86-64 and ARM processor families, and has been successfully used on the Darwin, FreeBSD, KFreeBSD, Linux and OpenBSD platforms. It fully supports Ada, C, C++ and Fortran. It has partial support for Go, Java, Obj-C and Obj-C++." -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: llvm37 python3 problem
On 09/10/2015 02:33, Walter Schwarzenfeld wrote:
I think this should work:
in /etc/make.conf:
either
DEFAULT_VERSIONS=python=2.7 python2=2.7 python3=3.4
or
.if ${.CURDIR:M*/ports/devel/llvm*}
USE_PYTHON=2.7
.endif
should work.
We know it works with the old python2.7. The point is that it fails if
you only want to use something recent like python3.4
python 2.7 was released 5 years ago. Even python3.4 was release over a
years and a half ago. If I had trouble with FreeBSD 7.3 you would tell
me to upgrade, so why do we have to keep using such an old version of
python? Not everyone wants to keep using old software.
The point of original the email was to get llvm/clang 3.7 working on a
machine that has python 3.4 installed as default and not 2.7
Which leads to wanting to place in make.conf -
DEFAULT_VERSIONS=python=3.4 python2=2.7 python3=3.4
And Loic - just so you know, while python 2.7 was going to be supported
until 2015, it was extended again for yet another 5 years - see
http://legacy.python.org/dev/peps/pep-0373/
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Does OpenMP (iomp5) work for clang-devel?
On 21/07/2015 18:06, Shane Ambler wrote:
On 21/07/2015 10:59, Dennis Glatting wrote:
On Tue, 2015-07-21 at 01:07 +, Brooks Davis wrote:
On Mon, Jul 20, 2015 at 05:48:58PM -0700, Dennis Glatting wrote:
I can't seem to get this working and it appears not to emit code. I
have
libiomp5 installed and I compile specifying:
clang++-devel -fopenmp=libiomp5 ...
And the compiler says:
clang: warning: argument unused during compilation:
'-fopenmp=libiomp5'
That should be just -fopenmp
From http://blog.llvm.org/2015/05/openmp-support_22.html
To enable OpenMP, just add ‘-fopenmp’ to the command line and provide
paths to OpenMP headers and library with ‘-I path to omp.h -L LLVM
OpenMP library path’.
Having just installed devel/llvm37 and done a few tests, this doesn't
appear to happen, for a single file test I also need to add -lomp
clang37 -fopenmp -I/usr/local/llvm37/include -L/usr/local/llvm37/lib
-lomp omp.c -o omp-test
One issue is that lldb breaks qtcreator. Sounds odd but I get -
[leader:~] shane% qtcreator
QProcess: Destroyed while process (/usr/local/bin/lldb-mi-devel) is
still running.
QProcess: Destroyed while process (/usr/local/bin/lldb-mi37) is still
running.
Broken pipe
[leader:~] shane%
If I rename the two binaries reported qtcreator runs fine.
qtcreator-3.4.0 - rebuilt while llvm37 was installed without change.
My main interest in openmp is for compiling graphics/blender.
This breaks llvm37 -
I am running 10-stable -
FreeBSD leader.local 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #16
r285937: Tue Jul 28 20:58:13 ACST 2015
root@leader.local:/usr/obj/usr/src/sys/GENERIC amd64
% pkg info -ox llvm37
llvm37-3.7.0.r1devel/llvm37
Adding to make.conf -
.if ${.CURDIR:M*/graphics/blender*}
CC=clang37
CXX=clang++37
CPP=clang-cpp37
.endif
The build ends with -
[ 42%] Building C object
source/blender/editors/datafiles/CMakeFiles/bf_editor_datafiles.dir/__/__/__/__/release/datafiles/matcaps/mc04.jpg.c.o
Assertion failed: (!DMEntry Decl already exists in localdeclmap!),
function EmitAutoVarAlloca, file
/wrkdirs/usr/ports/devel/llvm37/work/llvm-3.7.0rc1.src/tools/clang/lib/CodeGen/CGDecl.cpp,
line 1016.
[ 42%] Building C object
source/blender/bmesh/CMakeFiles/bf_bmesh.dir/operators/bmo_create.c.o
clang-3.7: error: unable to execute command: Abort trap
clang-3.7: error: clang frontend command failed due to signal (use -v to
see invocation)
clang version 3.7.0 (tags/RELEASE_370/rc1)
Target: x86_64-unknown-freebsd10.2
Thread model: posix
clang-3.7: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed
source, and associated run script.
clang-3.7: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.7: note: diagnostic msg: /tmp/BLI_kdopbvh-8090d7.c
clang-3.7: note: diagnostic msg: /tmp/BLI_kdopbvh-8090d7.sh
clang-3.7: note: diagnostic msg:
Full build log and debug files are available at
http://shaneware.biz/freebsddebugdata/clang37/
Brooks, I haven't submitted this upstream but can if you want.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: Does OpenMP (iomp5) work for clang-devel?
On 21/07/2015 10:59, Dennis Glatting wrote: On Tue, 2015-07-21 at 01:07 +, Brooks Davis wrote: On Mon, Jul 20, 2015 at 05:48:58PM -0700, Dennis Glatting wrote: I can't seem to get this working and it appears not to emit code. I have libiomp5 installed and I compile specifying: clang++-devel -fopenmp=libiomp5 ... And the compiler says: clang: warning: argument unused during compilation: '-fopenmp=libiomp5' That should be just -fopenmp From http://blog.llvm.org/2015/05/openmp-support_22.html To enable OpenMP, just add ‘-fopenmp’ to the command line and provide paths to OpenMP headers and library with ‘-I path to omp.h -L LLVM OpenMP library path’. The most recent clang-devel port doesn't include the bits to make iomp support automatic (it came not long after the update). I'm working on a update, but the ability to build clang and llvm separately appears to have been broken quite badly so it's taking a while and the only port to install will be devel/llvm-devel. That will be great, been waiting for this. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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: Proposal to fix postgresql package maintainance nightmare
On 21/07/2015 19:16, Baptiste Daroussin wrote: Hi, We do manage a bunch of postgresql servers on FreeBSD, and I really find the current model of packages postgresql is a nightmare on FreeBSD. Let's first start with the current issues. - Impossible to have tools from both old and new version at the same time (which is necessary to upgrade db and prepare upgrades of db) - Impossible to chose the version we want to run in production without having to rebuild the packages and the whole ports tree with a specific default. - Nightmare each time a new default version is set in the ports tree. Sounds like a good plan, I am not a heavy postgresql user but I have set the default pg version in make.conf to prevent unexpected new versions going in during port updates when I didn't think of doing upgrade steps. Here is my proposal to fix that. Having one single postgresql-client package always on the latest stable version (backward compability being very good) providing the client cli tools and the libraries (those libraries will be used for everything in the ports tree needing to talk to postgresql) Have one full postgresql package per supported version upstream self installing itself into let's say: /usr/local/postgresql94 and symlinks all the client tools to /usr/local/bin suffixed by the version psql94 pg_bla94 etc. Don't want to start a debate but thought I would mention as food for thought -- I'm not sure of any strong need to have more than one pg client version available. The newer client can connect to any older server and I don't know of any issues when an old client connects to a newer server. That way everything talk to pgsql will only depend on one postgresql-client packages that will smoothly be upgraded to newer versions. All database administrators will have the ability to chose the production version they do want without having to worry about a default version. They can install multiple version in parallel and deal with upgrade the way they want having access to both versions of the tools of the same time. Any opinion on that change? Any idea one how to make the upgrade path as transparent as possible for current setup? (beside of course adding an UPDATING entry) I think allowing multiple pg server versions is a good idea, this can prevent old binary versions being removed before the data update process. A new upgrade command could be added so we can do `service postgresql upgrade` which tests for existing paths, defines old and new dirs and runs pg_upgrade. The rc script could either add a version postfix to the data dir path or test PG_VERSION content to decide if data gets moved to data-old so new versions being started won't see older version data. Lack of up to date data dirs can lead to You need to perform an upgrade first. Different disk usage (filecount?) for old and new data dir can lead to Have you upgraded your old data? I don't think an upgrade step could be added during a port build, it would have to be at server start in the rc script. I wouldn't add an automatic upgrade step unless it was enabled by the user. -- FreeBSD - the place to B...Serving Data Shane Ambler ___ 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: poudriere with custom packages
On 16/07/2015 13:19, Aristedes Maniatis wrote:
I have a custom built package which I'm building outside the FreeBSD
ports system (using pkg-create commands). How can I add that package
to a poudriere managed repository so that it appears in the package
index and can be easily installed like any other package?
Thanks for any help
Cheers Ari
Create a port for it and include it in the list of ports you tell
poudriere to build. Poudriere will compile any port that exists in the
ports tree it uses whether it is an official port or not.
As long as the name you use for the port is unique, steps like portsnap
or svn update should not remove it. I would still keep a copy elsewhere.
Then you add the folder that poudriere stores pkgs in to be included in
the available repos list.
I use a couple of poudriere commands to build my ports. I have one
using a make.conf that sets various options that I want to use. In
another setup I use a make.conf that also sets python version to 3.4
which builds various modules to use with py34.
For example -
poudriere bulk -j 10stableamd64cc -p myports -z mypkg math/py-numpy
poudriere bulk -j 10stableamd64cc -p myports -z mypkgpy34 math/py-numpy
The first will use etc/poudriere.d/mypkg-make.conf
while the second will use etc/poudriere.d/mypkgpy34-make.conf
to be copied into etc/make.conf during the ports build.
In /usr/local/etc/pkg/repos/homerepo.conf I have
HomeRepoPoudrierePy34: {
url:
file:///usr/local/poudriere/data/packages/10stableamd64cc-myports-mypkgpy34,
mirror_type: none,
pubkey: /usr/local/etc/ssl/certs/pkg.cert,
enabled: yes
}
HomeRepoPoudriere: {
url:
file:///usr/local/poudriere/data/packages/10stableamd64cc-myports-mypkg,
mirror_type: none,
pubkey: /usr/local/etc/ssl/certs/pkg.cert,
enabled: yes
}
When I run pkg install it gets an updated list from each repo and
chooses which to install. For ports that are in both repos but with a
different pkg name (as in python prefix) I get both installed, I think
that installing both might only happen first when using the -f flag.
Once both are installed it gets updates from each repo to match.
I recall hearing a plan to add a weight to repos to choose which is
used first. I have found so far that the last repo entry (they are all
listed in one config file) is used over others if the same port is in
multiple repos.
While I have disabled the normal freebsd repo it should be included if
enabled, allowing your own repo to be the source for ports to install
that only exist in your poudriere builds and others to come from the
official repo.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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_GITHUB and submodules
Jonathan Anderson mailto:jonathan.robert.ander...@gmail.com
May 20, 2015 at 11:00 AM
Thanks everybody for the input! With a security hat on, I definitely concur
with the policy of no fetching outside of fetch and of requiring
reproducibility/verifiability (e.g., commit hashes). With my
getting-this-darn-port-updated hat, however... :)
I think that I'll try to go with Shane's solution, if others concur that it's
a good idea. I don't want to create a rust-llvm port, since Rust's customized
version of LLVM isn't much good outside of Rust, it doesn't expose any
external libraries and it's intended to eventually go away. So, until GitHub
implements the give me a tarball with all of the submodules feature, I might
try hacking up MASTER_SITES as Shane suggests.
In case you missed it this was changed shortly after the last email, see
http://leader/viewvc/viewvc.cgi/FreeBSD-ports?view=revisionrevision=387742
If you follow the link in the comments to review.freebsd.org you can
find some examples of ports updated to this change.
One catch that may either change or become documented is that one item
must be in the DEFAULT group, which can be implied by not giving it a
group name.
Using this also gives you multiple WRKSRC_* definitions eg using the
group name addons will let you use ${WRKSRC_addons} in custom steps.
This leads to
USE_GITHUB= yes
GH_ACCOUNT= sambler \
sambler:addons \
sambler:contrib \
sambler:trans
GH_PROJECT= myblender \
myblenderaddons:addons \
myblendercontrib:contrib \
myblendertranslations:trans
GH_TAGNAME= sambler-${PORTVERSION}.${PORTREVISION} \
addons-${PORTVERSION}.${PORTREVISION}:addons \
contrib-${PORTVERSION}.${PORTREVISION}:contrib \
translate-${PORTVERSION}.${PORTREVISION}:trans
and further down -
post-extract:
@${MV} ${WRKSRC_trans}/* ${WRKSRC}/release/datafiles/locale/
@${MV} ${WRKSRC_addons}/* ${WRKSRC}/release/scripts/addons/
@${MV} ${WRKSRC_contrib}/* ${WRKSRC}/release/scripts/contrib/
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: New port with USES=gmake will not stage
On 11/06/2015 15:03, Euan Thoms wrote:
On Thursday, June 11, 2015 13:18 SGT, Chris H bsd-li...@bsdforge.com wrote:
On Thu, 11 Jun 2015 11:33:03 +0800 Euan Thoms e...@potensol.com wrote
I'm making a port for OpenSIPS. It builds successfully, but the even with
just make it installs files to the system instead of to stage (i.e. to
/usr/local/... instead of /usr/ports/net/opensips/work/stage/usr/local/...).
I am using gmake and gcc since that's what's required for OpenSIPS.
I've done a similar port before and the FreeBSD ports macros do the staging
for me. However, even when I tell gmake the DESTDIR=${STAGEDIR} in do-build
and do-install, a make just installs the files to /usr/local/... .
MAKE_ARGS+= PREFIX=${LOCALBASE}
MAKE_ARGS+= exclude_modules=${EXCLUDE_MODULES}
include_modules=${INCLUDE_MODULES}
While MAKE_ARGS should send options to gmake, what about backing up a
step to configure?
Try setting PREFIX in CONFIGURE_ENV or maybe MAKE_ENV to specify
environment variables instead of arguments.
cd ${WRKSRC} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} ${ALL_TARGET}
Do you need USE_AUTOTOOLS=autoconf or to add a custom do-configure: ?
#do-build:
# cd ${WRKSRC} ${GMAKE} ${MAKE_ARGS} ${ALL_TARGET}
#
#do-install:
# cd ${WRKSRC} ${GMAKE} ${MAKE_ARGS} ${INSTALL_TARGET}
.include bsd.port.mk
EOF
I can't find the make files for stage to drill down and see what's going wrong. Any
pointers to the script that make stage uses?
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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_GITHUB and submodules
On 20/05/2015 04:14, Jonathan Anderson wrote:
Hi all,
Is there a mechanism for using the USE_GITHUB variable in a port that
depends on submodules? For instance, the Rust port requires an embedded
(and modified) version of LLVM, which it includes as a submodule. Right
now I'm attempting to add the following to a `post-extract` rule:
While you can setup multiple files to be downloaded for a port this
doesn't work with USE_GITHUB, see my 3 year old report -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172964
This isn't an official port, but the workaround I came up with was to
setup multiple files by setting MASTER_SITES using --
MASTER_SITES= https://github.com/sambler/myblender/tarball/:base \
https://github.com/sambler/myblendertranslations/tarball/:trans \
https://github.com/sambler/myblenderaddons/tarball/:addons \
https://github.com/sambler/myblendercontrib/tarball/:contrib
DISTFILES= sambler-${PORTVERSION}.${PORTREVISION}:base \
translate-${PORTVERSION}.${PORTREVISION}:trans \
addons-${PORTVERSION}.${PORTREVISION}:addons \
contrib-${PORTVERSION}.${PORTREVISION}:contrib
DIST_SUBDIR= ${PORTNAME}
The DISTFILES names are setup to match my tag format.
This gives you multiple archives for the port, each will be extracted
into the work dir, I then use post-extract to move them into place
within the main source tree and don't depend on git for the port--
post-extract:
# tanslations
@${MV} ${WRKDIR}/sambler-myblendertranslations-*/*
${WRKSRC}/release/datafiles/locale/
# addons
@${MV} ${WRKDIR}/sambler-myblenderaddons-*/*
${WRKSRC}/release/scripts/addons/
# contrib
@${MV} ${WRKDIR}/sambler-myblendercontrib-*/*
${WRKSRC}/release/scripts/addons_contrib/
post-extract:
cd ${WRKSRC} \
git init \
git remote add origin https://github.com/${GH_ACCOUNT}/${PORTNAME} \
git fetch \
git reset --hard ${PORTVERSION} \
git submodule init \
git submodule update --recursive
But this seems quite hackish! It would be great if submodules Just
Worked... but alternatively, is there a USE_GITHUB_URL or somesuch that
would check things out via Git instead of tarball to save me the `git
init` through `git reset` steps?
Cheers,
Jon
--
jonat...@freebsd.org
___
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
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: Blender 2.74 cannot compile on FreeBSD 10.1
On 05/04/2015 18:08, Ben Woods wrote: The graphics/libraw package installs /usr/local/lib/libraw_r.so.10, not libraw_r.so.9 so it will not be detected. See the pkg-plist for graphics/libraw here: https://svnweb.freebsd.org/ports/head/graphics/libraw/pkg-plist?revision=379518view=markup The interesting thing is that whilst graphics/blender depends on the graphics/openimageio library, neither depend on the graphics/libraw library. It might be worth asking the port maintainers for graphics/blender and graphics/openimageio if they have come across this before. I have added m...@freebsd.org and free...@shaneware.biz to the recipients of this email to check with them. Yes that's my fault, if openimageio finds libraw it will use it but doesn't seem to find the current libraw. I should add that as an option and patch it to find the current version. Looks like I should also do the same for libgif. thanks On Sun, Apr 5, 2015 at 9:33 AM Robert Backhaus rob...@robbak.com wrote: To get the simple things out of the road - you have reinstalled libraw, and checked that libraw_r.so.9 is in /usr/local/lib? This error tells me that your install of libOpenImageIO.so.1.4 is faulty, so you should also rebuild the port that includes that (pkg which `locate \*libOpenImageIO.so.1.4`) On 5 April 2015 at 02:36, pipolandi pipola...@gmail.com wrote: I forgot to say that libraw is installed. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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: blender 2.74
On 04/04/2015 09:01, ajtiM wrote: Hi! I did install Blender 2.74 on my FreeBSD 10.1 (amd64) without a problem but it doesn't want to start. When I run from terminal I got: blender Two passes with the same argument (-alloca-hoisting) attempted to be registered! Writing: /tmp/blender.crash.txt Segmentation fault (core dumped) In /tmp/blender.crash.txt is just: # Blender 2.74 (sub 0), Unknown revision # backtrace 2.74 hasn't been added to ports yet, are you compiling yourself? The error looks familiar, I think it was from different llvm versions being used. blender needs to use the same llvm/clang version as osl. -3.4 Check your LLVM_* settings in cmake. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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 it possibly to detect which OpenSSL is used for a port?
On 21/03/2015 04:32, Naram Qashat wrote:
This isn't quite what I'm looking for. I want to be able to tell within a
port's Makefile if the user wanted the base or ports OpenSSL to be used.
I've been trying to port TDE to FreeBSD, and tdelibs uses pkg-config to
check for OpenSSL. This would work if the only form of OpenSSL was in
ports, but the base OpenSSL doesn't have a pkg-config file to use, so I
need to know which is going to be used so I can determine when this
pkg-config check can be removed.
I created a new port devel/godot not long ago, it used pkg-config to
find openssl so I set it to use openssl port as it was a quick easy fix
till I got around to finding a better solution.
I was then offered a patch to fix this, which removed a test whether
pkg config openssl failed and changed 'pkg-config openssl --cflags
--libs' to 'echo -lssl -lcrypto'
https://svnweb.freebsd.org/ports/head/devel/godot/files/patch-platform_x11_detect.py?r1=377975r2=380508
Having USE_OPENSSL=yes in your Makefile leads to LDFLAGS getting -rpath
set to the location of the ssl libs. Therefore adding -lssl -lcrypto
instead of the pkg-config response leads to finding the ssl libs based
on the ssl option set at build time.
Worst case you may need to re-order the LDFLAGS so that other -L/path
entries are placed after the ssl search paths.
If you still need tests then try testing ${OPENSSLBASE} == '/usr'
# The makefile sets this variables:
# OPENSSLBASE - /usr or ${LOCALBASE}
# OPENSSLDIR- path to openssl
# OPENSSLLIB- path to the libs
# OPENSSLINC- path to the matching includes
# OPENSSLRPATH - rpath for dynamic linker
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: WITH_OPENSSL_PORT documentation
On 09/03/2015 05:54, Adam Weinberger wrote: Can somebody please write something---anything, even 2 sentences---for the PHB about how to use WITH_OPENSSL_PORT? What users should set it to to get LibreSSL for example, and what porters are supposed to put in the Makefile to support it? The text at the top of bsd.openssl.mk just shows WITH_OPENSSL_PORT=yes. A few sentences would be a big help, and I'm sure the doc people would be happy to take care of all the markup and formatting for you. # Adam I looked at it a few of days ago and didn't think there was an issue. bsd.openssl.mk has - # Use of 'USE_OPENSSL=yes' includes this Makefile after bsd.ports.pre.mk # # the user/port can now set this options in the makefiles. # # WITH_OPENSSL_BASE=yes - Use the version in the base system. # WITH_OPENSSL_PORT=yes - Use the OpenSSL port, even if base is up to date # # USE_OPENSSL_RPATH=yes - Pass RFLAGS options in CFLAGS, # needed for ports who don't use LDFLAGS # # Overrideable defaults: # # OPENSSL_SHLIBVER= 8 # OPENSSL_PORT= security/openssl If you specifically want to use the base or port ssl you set either WITH_OPENSSL_BASE=yes or WITH_OPENSSL_PORT=yes. If you want a specific ssl variation you can set OPENSSL_PORT to the port you want to use. The default is security/openssl So if you want to use libressl then you set WITH_OPENSSL_PORT=yes and OPENSSL_PORT=security/libressl Porters should put USE_OPENSSL=yes in their Makefile, other settings should only be added if necessary, leave the other options to the user. -- FreeBSD - the place to B...Securing Domains Shane Ambler ___ 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: Dependent ports use different c++ compilers
On 06/02/2015 21:29, m...@reifenberger.com wrote: Hi, kicad-devel depends at least on two c++ libraries: boost-lib and webkit-gtk2. kicad-devel and boost uses: USES+= compiler:c++11-lang This leads at least under FreeBSD 9.3 and 10.* to the usage of clang++ webkit-gtk2 uses: USES += compiler:c++11-lib This leads at least under FreeBSD 9.3 to the usage of GNU g++ (FreeBSD 10+ is using clang++) and this leads to missing symbols when linking kicad-devel. How can this dilemma be resolved? Greetings --- Mike (mr@) The newc++stack wiki page has some tips on using both libc++ and libstdc++ https://wiki.freebsd.org/NewC++Stack -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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: testing the value of ${CXX} in ports Makefile
On 30/01/2015 14:13, Don Lewis wrote:
I need to test the value of ${CXX} in the Makefile for a port and am
getting unexpected results. Here is a simplified version of the
Makefile:
PORTNAME= junk
PORTVERSION=0.0.0
CATEGORIES= devel
DISTFILES=
MAINTAINER= truck...@freebsd.org
COMMENT=junk
USE_GCC=4.9+
.include bsd.port.pre.mk
post-patch:
echo CXX=${CXX}
.if ${CXX} == g++49
echo detected g++49
.else
echo did not detect g++49
.endif
.include bsd.port.post.mk
If I run make patch, this is what I get:
# make patch
=== junk-0.0.0 depends on file: /usr/local/sbin/pkg - found
=== Fetching all distfiles required by junk-0.0.0 for building
=== Extracting for junk-0.0.0
=== Patching for junk-0.0.0
echo CXX=g++49
CXX=g++49
echo did not detect g++49
did not detect g++49
You want to use @${ECHO} in the port makefile for that to print right
If I run make -dA patch and look at the debug output, I observe
bsd.gcc.mk getting processed after the .if is evaluated. When the .if
is processed, the value of ${CXX} is still c++. It sort of looks like
bsd.gcc.mk isn't getting included until bsd.port.post.mk and we are
relying on lazy expansion to get the correct value of ${CXX} for the
actions.
Maybe more to the point is that CXX used to build might only be defined
as part of MAKE_ENV to be passed as the environment for the make
command when it is run.
It sort of looks like I'll have to do something like:
post-patch:
[ ${CXX} = g++49 ] echo detected g++49
but that just seems goofy.
I believe the correct way to what you want is -
USES= compiler
.include bsd.port.pre.mk
.if ${CHOSEN_COMPILER_TYPE} == gcc and ${COMPILER_VERSION} == 49
EXTRA_PATCHES= ${FILESDIR}/extra-patch-srcfile.c
.endif
See
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/uses.html
and/or comments in /usr/ports/Mk/Uses/compiler.mk
You may also want to consider patching with -
#if (__GNUC__ == 4) (__GNUC_MINOR__ == 9)
// 4.9 specific changes
#endif
Of note is that clang identifies itself as gcc 4.2 so you may also want
to test for __clang__ if you want to use with __GNUC_MINOR__
You can also define more control over gcc version - USE_GCC=4.8 will
require gcc 4.8 while USE_GCC=4.8+ says you can use 4.8 or higher.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: testing the value of ${CXX} in ports Makefile
On 31/01/2015 15:30, Jan Beich wrote:
Also, the following wouldn't work
.if ${CHOSEN_COMPILER_TYPE} == gcc ${COMPILER_VERSION} == 49
because COMPILER_VERSION or COMPILER_FEATURES are evaluated against
COMPILER_TYPE, not CHOSEN_COMPILER_TYPE.
That is a good point, it appears we currently only get the chosen
compiler type and not it's version or features.
So COMPILER_FEATURES and COMPILER_VERSION should be set against
CHOSEN_COMPILER_TYPE as that is the one to be used to build the current
port, which would be the one we want to know about when making build
decisions.
Or at least there should be CHOSEN_COMPILER_FEATURES and
CHOSEN_COMPILER_VERSION
I have chosen to submit this as a bug report -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197219
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: testing the value of ${CXX} in ports Makefile
On 31/01/2015 10:55, Don Lewis wrote:
On 31 Jan, Shane Ambler wrote:
On 30/01/2015 14:13, Don Lewis wrote:
post-patch:
@echo CXX=${CXX}
@echo GCC_DEFAULT=${GCC_DEFAULT}
.if ${CHOSEN_COMPILER_TYPE} == gcc and ${COMPILER_VERSION} == 49
@echo g++49 was detected
.else
@echo g++49 was not detected
.endif
# make patch
make: /usr/ports/editors/junk/Makefile line 17: Malformed conditional
(${CHOSEN_COMPILER_TYPE} == gcc and ${COMPILER_VERSION} == 49)
make: Fatal errors encountered -- cannot continue
yeah my bad - don't know why I typed `and` instead of ``
You may also want to consider patching with -
#if (__GNUC__ == 4) (__GNUC_MINOR__ == 9)
// 4.9 specific changes
#endif
That would work if I was patching C or C++ code, but I'm actually patching
a file that is used to set the the -O value for CFLAGS. The build stuff
in the port is pretty strange and uses different optimization levels for
for different parts of the build and one of choices that it makes
triggers a code generation bug in gcc 4.9.
What is the build system used?
Can the build files do something like
COMPVERS=`${CXX} --version | grep -e gcc -e 4.9`
if [ ! -z $COMPVERS ]
${CXX} -O2
else
${CXX} -Os
fi
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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 3 doc?
On 28/12/2014 11:15, George Mitchell wrote: I have both python 2.7.8 and python 3.3.5 installed on my machine. When I build lang/python-doc-html, I end up with python-doc-html-2.7.8. Is it possible to also get python-doc-html-3.3.5 generated and installed somehow? -- George There are two settings that determine the version of python being used - DEFAULT_VERSIONS can be set in /etc/make.conf and will effect the python version used for every port you build. This can also be used to define other default versions, see /usr/ports/Mk/bsd.default-versions.mk DEFAULT_VERSIONS= python=3.3 You can also set PYTHON_VERSION in your environment before building to only effect the one port. For csh/tcsh setenv PYTHON_VERSION python3.3 for sh/bash PYTHON_VERSION=python3.3;export PYTHON_VERSION -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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: building legacy packages with poudriere ?
On 05/12/2014 12:35, Mike Tancsa wrote: On 12/4/2014 7:51 PM, Bryan Drewery wrote: Poudriere (as of latest 3.1) still supports pkg_install packages. It is *ports* that does not. You will need to use an older ports tree. You can use the /branches/pkg_install/ branch, but it is stuck at 2014 Sep. Excellent! Sept 2014 is fine for what I need to build from. Next question, how do I fetch that branch ? # poudriere ports -B pkg_install -c default method is portsnap - pkg_install is an svn branch name poudriere ports -m svn+https -B pkg_install -c If that fails you could manually checkout with svn and use poudriere ports -c -p pkg_install -F -f none -M /path/to -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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
Need help compiling use of std::vector
I am trying to compile the new version of a port I maintain and have
trouble related to std::vector. The code producing the error can be
boiled down to the following test case, which compiles as 64bit but
fails as 32bit.
#include stdlib.h
#include vector
int main(int argc, char *argv[])
{
int num_layers = 3;
std::vectorconst char * layers (num_layers, NULL);
exit(0);
}
So that should create a vector containing 3 items initially set to NULL.
10.0 compiles ok - both 32 and 64 bit. (libc++)
8.4, 9.2 and 9.3 compiles 64bit but fails on 32bit. (libstdc++)
Using the above code
clang++ -m32 test.cpp
fails with
/usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to
'const char *' from incompatible type 'const int'
I often get the following with the test case - not the real code.
error: 'operator new' takes type size_t ('unsigned int') as first parameter
I have tried changing num_layers to unsigned int, size_t, std::size_t
How do I fix this to work on 32 and 64 bit?
The original code is located on line 758 at
https://github.com/imageworks/OpenShadingLanguage/blob/master/src/testshade/testshade.cpp
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: Need help compiling use of std::vector
On 25/09/2014 04:27, Matthias Andree wrote: Am 24.09.2014 um 17:04 schrieb Shane Ambler: Using the above code clang++ -m32 test.cpp fails with /usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to 'const char *' from incompatible type 'const int' I don't think -m32 compilation has ever worked properly for C++ on the older FreeBSD releases, where older includes 9.3. You're probably better off trying to build with 32-bit chroots or jails on your 64-bit host, like poudriere or Tinderbox are doing (but I'm not sure if they support setting up 32-bit jails on 64-bit computers). See here https://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051855.html so it's a long-standing thing, and for recent developments: https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042378.html -so that would have been for 10-CURRENT at the time, and hints that the headers weren't pure enough for -m32 and similar tricks. I am not aware that this effort was ever MFH'd. I am Cc'ing Konstantin Belousov in case he wants to shed more light on this issue. My poudriere setup is where I encountered the error. The -m32 was just a test compile of the simplified test code, that produced the same error as within a 32 bit jail. While using -m32 does produce the same error, it appears to always produce the error with all the changes I tried. Compiling the variations I tried within a 32 bit jail gives a favourable result that I can test further. I assumed that compiling a small test code would tell me if the change worked. I should have thought about doing it all in a 32bit jail. Thanks. ___ 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: tinderbox seems broken after recent commits (python-related?)
On 19/08/2014 13:26, Alexey Dokuchaev wrote: hi there, tinderbox is unable to build more-or-less complex ports for couple of days now; both for 8.4/pkg_tools and 9.3/pkgng: it quietly exits with no package produced and no logs generated, except build/build-name/make.0 that looks always like this (modulo list of dependent packages, can be longer): `python27-2.7.8_3.txz' is up to date. `gettext-0.18.3.1_1.txz' is up to date. `libiconv-1.14_3.txz' is up to date. `indexinfo-0.2.txz' is up to date. make: Graph cycles through `py27-pylib-1.4.20.txz' make: Graph cycles through `py27-setuptools27-5.5.1.txz' `pkgconf-0.9.6_1.txz' is up to date. `pkg-1.3.6.txz' is up to date. On stable/8, make(1) falls into endless loop, repeating these lines all over again untill it dies via sig11. Can it be related to the recent Python framework overhaul? Any ideas how to remedy the situation? Thanks, ./danfe This was mentioned earlier on the tinderbox list --- Original Message Subject: Re: Graph cycles through in devel/p5-CPAN-Meta-Requirements Date: Wed, 13 Aug 2014 20:47:26 +0930 From: Shane Ambler free...@shaneware.biz To: Tomoyuki Sakurai tomoyu...@reallyenglish.com, tinderbox-l...@marcuscom.com tinderbox-l...@marcuscom.com On 13/08/2014 16:41, Tomoyuki Sakurai wrote: hi, just fyi, tinderbox users. devel/p5-CPAN-Meta-Requirements has a circular dependency on p5-CPAN-Meta. any port depending on p5-CPAN-Meta, munin-node in my case, cannot be built on tinderbox. the build silently fails as if there was no error. this will hit you hard if you build your packages and assume no error means no problem. a work around is commenting out TEST_DEPENDS line in devel/p5-CPAN-Meta-Requirements/Makefile. I'm getting circular dependencies with python ports too. Comment out the TEST_DEPENDS in devel/py-setuptools/Makefile to stop it for now. I think this started with changing USE_PYTHON to USES=python possibly same for perl. Maybe mixing the two is the issue. ___ 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: Ports that don't actually support Python 3.x
On 07/07/2014 09:13, Kubilay Kocak wrote: On 7/07/2014 8:41 AM, Melvyn Sopacua wrote: Hi Kubilay! On Mon, 7 Jul 2014, Kubilay Kocak wrote: On 7/07/2014 7:52 AM, Melvyn Sopacua wrote: Submit an issue with patch, I'll add maintainer_approval flag cc'ing maintainer if you cant, just let me know the issue ID :) Thought I submitted more already, but they're still in the queue and django-redis was comitted. Will submit tomorrow. No such thing as too many issue reports, plus that way the maintainer will get to see it :) I've also been looking to support py3.4, I should start sending in some patches. py-openid only supports 2.x there is a fork that supports 3.x - this looks as though it will remain as two separate ports https://github.com/necaris/python3-openid I have a new port created but I'm not looking to maintain it, if your interested - https://github.com/sambler/sambler-redports/tree/master/security/py3-openid ___ 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 install catch 22
On 04/04/2014 22:42, Willem Jan Withagen wrote: Hi, I've tried to upgrade my python 2.7 which did not work. Then I deinstalled all python stuff and tried to install python3 (aka 3.3) You can install both versions of python (2.7 3.3) at the same time, but currently you can only install a module to one of the versions at a time. So far there are still many modules that don't work with 3.x so you may want to use 2.7 if you want python with more than the default modules. The default python is still 2.7, if you want to use 3.3 then you might want to add DEFAULT_VERSIONS=PYTHON=3.3 PYTHON3=3.3 to your /etc/make.conf The system everytime refuses to install because of missing a database: pkg-static: lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so): No such file or directory *** [fake-pkg] Error code 74 [ replace python33 by python27 te get the similar error for 2.7 ] This would indicate that the dbm module wasn't built. It should be built and is a module that gives access to others that may be installed from the list below. The db modules below don't need to be installed first for _dbm.so to be built. This is an error compiling not related to the other modules. If your using a gui then scrollback in the terminal to see the error - increase scrollback limit if needed, from cli maybe use script to keep a log of the build to look through. gettext libiconv and gmake are the only things that need to be installed before python to build. Maybe there is an issue with you not building from /usr/ports ? And then hints: Note that some of the standard modules are provided as separate ports since they require extra dependencies: gdbmdatabases/py-gdbm sqlite3 databases/py-sqlite3 tkinter x11-toolkits/py-tkinter Install them as needed. Which is nasty catch22, because one needs a recent/working python to actually be able to do this. How do other cope with this? Could using pkg to install a prebuilt binary package be an option? What FreeBSD version are you using? ___ 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: WARNING: devel/icu: recent update redners openldap-server and other ports unusable!
On 08/02/2014 08:24, O. Hartmann wrote:
Today a couple of updates has been introduced, one of them was an
update of port devel/icu.
I the good manner/tradition of updating UPDATING, I expect a
warning/hint/advice a couple of days from now - when everybody has
already stepped into the mess.
On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports
including devel/icu renders many ports unusable due to a library
version bump in libicu.
After updating ports relying on devel/icu via
portmaster -r devel/icu
and the updating of port
net/openldap24-server
(which is openldap-sasl-server in my case), OpenLDAP doesn't start
anymore on all boxes affected by the update of devel/icu!
I always get the error
52f5551f hdb_db_init: Initializing HDB database
52f5551f olcDbDirectory: value #0: invalid path: Permission denied
52f5551f config error processing olcDatabase={1}hdb,cn=config:
olcDbDirectory: value #0: invalid path: Permission denied 52f5551f
send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing
system resources. 52f5551f syncinfo_free: rid=001
52f5551f slapd stopped.
52f5551f connections_destroy: nothing to destroy.
/usr/local/etc/rc.d/slapd: WARNING: failed to start slapd
This obscure
olcDbDirectory: value #0: invalid path: Permission denied
is not obvious to me. The server ran minutes ago BEFORE the update, the
directories containing the DB5 databases have all the correct ownership
(ldap:ldap, I suspected first a misconfiguration as this error seems
typical for a misconfiguration of the ownership).
Does anyone see the same problem? And maybe please would put out some
notes in UPDATING within a considerable narrow timeframe regarding
devel/icu! It seems, FreeBSD's ports systems get more and more messy.
oh
Not the same problem but I did see building postgresql server break -
I changed databases/postgresql92-server/makefile with the following.
Ideally the test for *_52 should be added to configure.in rather than
replacing the oldest.
--- a/databases/postgresql92-server/Makefile
+++ b/databases/postgresql92-server/Makefile
@@ -355,6 +355,8 @@ post-patch:
. if defined(SERVER_ONLY) ${PORT_OPTIONS:MICU}
@${REINPLACE_CMD} -E -e \
s|^(m4_if.*)2.6[0-9](.*Autoconf version
)2.6[0-9]|\1${AUTOCONF_VERSION}\2${AUTOCONF_VERSION}|g \
+ -e s|ucol_open_43|ucol_open_52|g \
+ -e s|ucnv_fromUChars_43|ucnv_fromUChars_52|g \
${WRKSRC}/configure.in
. endif
___
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: poudirere behave-alike for
On 25/11/2013 11:45, Christopher J. Ruwe wrote: I think my question is slightly off-topic, but I think freebsd-ports@ may be the best of many not so good fits: I need to build packages for Solaris and SmartOS. My first choice would be ports, which unfortunately are not very well suited to cross-building. Instead I use, as many people, pkgsrc. I would like to leverage pkgsrc with something like poudriere, especially as I have ZFS and zones in Solaris/SmartOS. I found in a message on the DragonFlyBSD list http://leaf.dragonflybsd.org/mailarchive/users/2013-01/msg8.html a mention of poudriere being used on DragonFly/pkgsrc. Does anybody know of the state of this piece of software? The git repos I can find on google are stale links. As etoilebsd is referenced in the mail from DragonFly, I chose to ask here first. The freebsd ports tree at http://svnweb.freebsd.org/ports/head/ports-mgmt/poudriere/ shows poudriere source is downloaded from http://fossil.etoilebsd.net/poudriere/tarball/ I think the best place to start would be the DPorts as it mentions they needed to patch it to work on Dragonfly - those patches will highlight the changes you need to make so should be the best start. ___ 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: Determining file size of port source
On 15/11/2013 13:15, Joe Nosay wrote: On Wed, Nov 13, 2013 at 11:14 PM, Shane Ambler free...@shaneware.bizwrote: You can use make makesum to create the distinfo for you - once you get the download links right. Thanks. I'm still patching/rewriting files. One of my problems was not re-creating the folder properly and then archiving it. Another helpful command to use is make makepatch. While working on the port, remember to make a copy of each file you adjust with a .orig suffix, then you can use make makepatch to generate the patches for you. ___ 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: Determining file size of port source
On 14/11/2013 09:53, Joe Nosay wrote: root@conhecer:/traverso/work # cd .. root@conhecer:/traverso # make === Found saved configuration for traverso-0.49.2 === traverso-0.49.2 depends on file: /usr/local/sbin/pkg - found = traverso-0.49.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://downloads.sourceforge.net/project/traversofreebsdport/work/traverso-0.49.2-revision_2.tar.gztraverso-0.49.2.tar.gz fetch: http://downloads.sourceforge.net/project/traversofreebsdport/work/traverso-0.49.2-revision_2.tar.gztraverso-0.49.2.tar.gz: Not Found = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/traverso-0.49.2.tar.gz fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/traverso-0.49.2.tar.gz: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop. make[1]: stopped in /traverso *** Error code 1 Stop. make: stopped in /traverso root@conhecer:/traverso # ls /usr/ports/distfiles|grep trav traverso-0.49.2-revision_2.tar.gz root@conhecer:/traverso # I do not need the 0.49.2 to be added to the download path. I only need what is listed in /usr/ports/distfiles and nothing more. If your asking about the sourceforge download link, we'd need to see your Makefile to see how it is calculated to get it correct. Using SF for MASTER_SITES includes auto link calculations, it sounds like you are adding to the link creation when you don't need to. On Wed, Nov 13, 2013 at 6:15 PM, Joe Nosay superbisq...@gmail.com wrote: ls -lh -D Byte does not give me the exact byte size of the archive. What is the correct command? Thanks You can use make makesum to create the distinfo for you - once you get the download links right. ___ 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: Build C++ based packages using C++11
On 01/11/2013 02:59, Michael Gmelin wrote: On Tue, 29 Oct 2013 13:34:24 +0100 Michael Gmelin free...@grem.de wrote: I was thinking more of building the entire stack using C++11 (libc++ requires it anyway). To give you an example I know personally, the port devel/ice provides a bigger feature set if C++11 is available. If it's used, it's advised to also build dependencies (e.g. databases/db5) using C++11 as well, to make sure symbols and exception handling works properly. The way I would approach this is to set up poudriere to build the entire tree using clang++ -std=c++11 -stdlib=libc++ and then start dealing with the fallout, fixing smaller problems immediately (or make the maintainers fix them) and mark ports that are to hard to fix as NEEDS_CPP98 or something like this. So, how could I get that started? I'm willing to put effort into this myself, but I would need pointers on how to do this in a way that makes sure it leads to some productive result. Basically it would be some project to make as much of the ports tree as possible work with libc++ and C++1x, starting with devel/*. Not sure if there is anybody interested in this besides me right now - given the feedback so far I doubt it. I actually think fixing builds for 10.0 is achieving this, at least with clang and libc++ as the older libstdc++ has been removed with gcc. 10.0 also appears to be stricter on things like math.h, eg. isnan(int) produces an error in 10.0 but not 9.2. The only issue I would think you'll find working on this is that every port maintainer has ports that need updating and most are working on fixing their own ports. So there is a high chance that you will fix a port the same time as the maintainer is doing it. So if you start, I would suggest building against 10.0 (with or without -std=c++11) and try starting with unmaintained ports. I believe that would be with MAINTAINER=po...@freebsd.org. If you submit fixes for these then you should probably update for staging as well. If you start doing this I would suggest keeping examples of what you fix and creating a changes table. eg if you get error: then try replacing this with this or this. ___ 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: CLANG and gcc testing
On 26/10/2013 23:52, Muhammad Moinur Rahman wrote: Hi, Do I need to test for gcc and CLANG any more in STABLE/9 and STABLE/10 anymore for any ports or should it be CLANG only? By default 10.0 only has clang installed in base. 9.2 has both but the user needs to specifically configure to use clang to compile. I see that to mean we must test with gcc on 9.x and clang on 10.x while clang on 9.x is optional but preferred. ___ 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: Need some help debugging c++ code for 10.0
On 18/10/2013 20:52, Tijl Coosemans wrote: Have you managed to get this working? I just noticed opencolorio is a dependency of Calligra (KDE office suite) which would be nice to have in FreeBSD 10.0. The patch for opencolorio in pr/182220 allows it to build and install on 10.0. I just sent another update to include staging fixes. While I know it compiles and installs, the issue with openimageio stops me verifying that it runs ok. Calligra does build and run (depending on options - I had to disable postgresql, I also made a small patch to replace std::abs with abs in an msword filter file), not sure where to go to make it use opencolorio. ___ 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
Need some help debugging c++ code for 10.0
Hi there, I am the port maintainer for opencolorio, openimageio and openshadinglanguage. These build and run on 9.2 with clang 3.3 but I have an issue on 10.0. I don't have much programming experience and even less with c++ which all 3 use. After ocio and oiio are installed building osl generates oslc (the osl script compiler) and then runs it to pre-compile the included scripts. This step fails on 10.0 I am fairly sure that the issue is within the ustring class - full code can be viewed at github.com/OpenImageIO/oiio with src/include/ustring.h having some info about the class. The following is from src/libutil/ustring.cpp for ustrings constructor #if defined(__GNUC__) // We don't want the internal 'string str' to redundantly store the // chars, along with our own allocation. So we use our knowledge of // the internal structure of gcc strings to make it point to our chars! // Note that we've carefully structured the TableRep fields so they // mimic a GCC basic_string::_Rep. // // It turns out that the first field of a gcc std::string is a // pointer to the characters within the basic_string::_Rep. We // merely redirect that pointer, though for std::string to function // properly, the chars must be preceeded immediately in memory by // the rest of basic_string::_Rep, consisting of length, capacity // and refcount fields. And we have designed our TableRep to do // just that! So now we redirect the std::string's pointer to our // own characters and its mocked-up _Rep. // // See /usr/include/c++/VERSION/bits/basic_string.h for the details // of gcc's std::string implementation. *(const char **)str = c_str(); DASSERT (str.c_str() == c_str()); #else // Not gcc -- just assign the internal string. This will result in // double allocation for the chars. If you care about that, do // something special for your platform, much like we did for gcc // above. (Windows users, I'm talking to you.) str = s; #endif When the osl build starts to precompile the bundled osl scripts oslc triggers the DASSERT (which is line 137) shown above. If I adjust the #if (and the matching destructor) so the non-gcc fallback is used, osl still fails just without the assert message. Running the osl compile step in gdb I get the following backtrace -- /usr/ports/graphics/openimageio/work/OpenImageIO-oiio-f9d8f1b/src/libutil/ustring.cpp:137: failed assertion 'str.c_str() == c_str()' Program received signal SIGABRT, Aborted. [Switching to Thread 819406400 (LWP 100230/oslc)] 0x00080344998a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x00080344998a in thr_kill () from /lib/libc.so.7 #1 0x000803518259 in abort () from /lib/libc.so.7 #2 0x00080196d120 in TableRep (this=0x81943c3d0, s=0x801bb50b8 resolution, len=10) at /usr/ports/graphics/openimageio/work/OpenImageIO-oiio-f9d8f1b/src/libutil/ustring.cpp:137 #3 0x00080196d607 in OpenImageIO::v1_2::ustring::make_unique (str=0x801bb50b8 resolution) at /usr/ports/graphics/openimageio/work/OpenImageIO-oiio-f9d8f1b/src/libutil/ustring.cpp:196 #4 0x00080110118f in ustring (this=0x801f21e20, str=0x801bb50b8 resolution) at ustring.h:166 #5 0x00080110114d in ustring (this=0x801f21e20, str=0x801bb50b8 resolution) at ustring.h:167 #6 0x0008019ae35b in __cxx_global_var_init16 () at /usr/ports/graphics/openimageio/work/OpenImageIO-oiio-f9d8f1b/src/libtexture/imagecache.cpp:80 #7 0x0008019c8a39 in global constructors keyed to a () at /usr/ports/graphics/openimageio/work/OpenImageIO-oiio-f9d8f1b/src/libtexture/imagecache.cpp:229 #8 0x000801ba83b2 in __do_global_ctors_aux () from /usr/local/lib/libOpenImageIO.so.1.2 #9 0x0008015a7d0e in _init () from /usr/local/lib/libOpenImageIO.so.1.2 #10 0x7fffccc0 in ?? () #11 0x000800616701 in objlist_call_init () from /libexec/ld-elf.so.1 #12 0x000800615c97 in _rtld () from /libexec/ld-elf.so.1 #13 0x000800614089 in .text () from /libexec/ld-elf.so.1 #14 0x in ?? () (gdb) ___ 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 06/10/2013 21:13, Marcus von Appen wrote: On, Sat Oct 05, 2013, Daamn M wrote: 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.). Personally I went and created my own variations, easy if you want one or two, probably a hassle if you want a lot that constantly get updated. eg to get py-numpy for python3.3 I duplicated py-numpy to py-numpy33 and changed PORTNAME to numpy33 and USE_PYTHON to 3.3 I made a few other adjustments like renaming f2py to f2py33 and a quick replace in the pkg-plist for __PYCACHE__ and 3.3 added to names. So I end up with py27-numpy and py33-numpy33 installed ___ 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: libc++ differences between 9.2 and 10.0
On 20/09/2013 17:50, Michael Gmelin wrote: On Fri, 20 Sep 2013 15:01:58 +0930 Shane Ambler free...@shaneware.biz wrote: I'm Starting to look at fixing my ports to build on 10.0 and there appears to be a difference between 9.2 and 10.0 when it comes to using libc++ The first port I am looking at is graphics/opencolorio. a patch was submitted (ports/182220) that works fine on 10.0 but it breaks 9.2 build when using clang with - error: no type named 'shared_ptr' in namespace 'std' The patch is simple, just adding - #elif __cplusplus = 199711 #include memory #define OCIO_SHARED_PTR std::shared_ptr #define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast As far as I can see both 10.0 and 9.2 use the same contrib/libc++ contents but I don't see why 9.2 isn't finding std::shared_ptr The other thing is I don't think testing __cplusplus is the right way to go but don't see an alternative. __cplusplus is defined in clang irrespective of the library used so isn't really a reliable test. Are there any defines to easily test for std::shared_ptr or is that a test I need to create for configure or cmake - has already been done? Hi Shane, I looks like you're using libstdc++ on 9.2 (the version that comes with gcc 4.2). To build with libc++ you need to use CXXFLAGS+= -std=c++11 -stdlib=libc++. I tried adding that to the Makefile as well as LDFLAGS+= -stdlib=libc++ Just realised that I put them in a test for OSVERSION between 901000 and 10 - missed a zero for 10 so it wasn't used ;-) my fault Checking for _cplusplus isn't enough, since this only checks for the language standard, but not for standard c++ library used. First you should check for a C++11 enabled compiled (you're checking for C++98, which didn't standardize std::shared_ptr) #elif __cplusplus = 201103 Then you should also check which standard library is used (in the end you can mix clang C++11 and an old C++ standard library): #elif _cplusplus = 201103 defined(_LIBCPP_VERSION) This checks if libc++ is used. Since all relevant version of libc++ support C++11 features like shared_ptr this should be good enough. That sounds like a reasonable option. If you want to stay compatible with newer versions of gcc and libstdc++ you'll have to figure out how to check for this as well (unfortunately I can't tell the exact checks to use from the top of my head). This expands tests for OCIO_USE_BOOST_PTR (windows) and __GNUC__ choosing between boost::shared_ptr and std::tr1:;shareed_ptr ___ 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
libc++ differences between 9.2 and 10.0
I'm Starting to look at fixing my ports to build on 10.0 and there appears to be a difference between 9.2 and 10.0 when it comes to using libc++ The first port I am looking at is graphics/opencolorio. a patch was submitted (ports/182220) that works fine on 10.0 but it breaks 9.2 build when using clang with - error: no type named 'shared_ptr' in namespace 'std' The patch is simple, just adding - #elif __cplusplus = 199711 #include memory #define OCIO_SHARED_PTR std::shared_ptr #define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast As far as I can see both 10.0 and 9.2 use the same contrib/libc++ contents but I don't see why 9.2 isn't finding std::shared_ptr The other thing is I don't think testing __cplusplus is the right way to go but don't see an alternative. __cplusplus is defined in clang irrespective of the library used so isn't really a reliable test. Are there any defines to easily test for std::shared_ptr or is that a test I need to create for configure or cmake - has already been done? ___ 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: Freeocl build but doesn't work
On 28/07/2013 03:21, lbartoletti wrote: Le Thu, 25 Jul 2013 11:36:23 +0200, So try to compile your test with gcc46 -Wl,-rpath=/usr/local/lib/gcc46. Hello, It doesn't work. I tried it with FreeBSD amd64 9.1 and 10.0 and FreeOCL / OpenCL require GLIBCXX_3.4.11 into libstdc++... I have seen a similar thing trying to compile lmms with gcc46. From what I can tell the linker has brought in a gcc42 version with another lib which prevents the newer gcc46 version coming in. I haven't got around to working it out but thought of looking through external libs used to find the one that brings in the older version and building that with gcc46. I also wonder if a static linked c++ lib may be preventing the newer version being brought in. ___ 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: graphics/openshadinglagugae: Fails to compile with CLANG 3.3 (now also on FreeBSD 9.2 as well as 10.0-CURRENT)
On 19/07/2013 15:49, O. Hartmann wrote: Please CC me if some hints or solutions are available. I have just submitted a patch to update osl to 1.3.3 - pr/180650 The release notes say Changes to support LLVM 3.3 but I haven't confirmed that it fixes the 10 compile yet. ___ 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 of sysutils/pacman in FreeBSD?
On 13/07/2013 20:36, Sam Fourman Jr. wrote: This is a bit off topic, but would you happen to know if there is a place we can keep up on the coming linuxulator work? is there maybe a github repo setup to test a new linuxulator? Possibly start at https://wiki.freebsd.org/linux-kernel ___ 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: help with making a port
On 08/07/2013 05:32, Aryeh Friedman wrote: On Sun, Jul 7, 2013 at 3:51 PM, Jason Helfman j...@freebsd.org wrote: pkg which /path/to/file or pkg_info -W /path/to/file aryeh@dev:/home/aryeh% pkg_info -W /usr/local/share/foo/foo.jar pkg_info: You appear to be using the newer pkg(1) tool on this system Of the two examples 'pkg_info -W' is the old way and 'pkg which' is the new way. The error from pkg_info -W indicates you have the new package system setup and need to use the pkg which command. Is this your first attempt at making the port? Maybe you have an old attempt still in place. Did you move the port to a new category folder? As foo-0.1 isn't the real name of the port, are you certain that the name you are using is a new unique name? ___ 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: [CFH] FreeBSD 10 and ports
On 11/06/2013 16:20, Martin Wilke wrote: As we all know FreeBSD 10 brings a new compiler along, and for that we need to get ports on the right track. I have done several exp-runs on the current src and we still have a lot of fallouts. We would like to ask you to have a look [1] at the failed ports and help to fix them. We will start this week an i386 exp-run to see how the status is. For those of us running 9.1 what is the best way to test? I previously had little luck compiling in a 10-current tinderbox. I see that one of my ports is failing with 10 and clang 3.3. I know it compiles with clang 3.1 on 9.1. Is using 3.4 from clang-devel a useful test compiler? ___ 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
Change when using gcc48
As the port maintainer of graphics/openimageio I have come across a change when building with gcc48. The current version of openimageio compiles fine with clang gcc and gcc46, but when compiled with gcc48 the unlink function is not defined. The simple solution is to add #include unistd.h to the source file but why is this only needed for gcc48? Is this an intended change? ___ 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: Any way to keep two versions of Xorg?
On 29/04/2013 02:43, per...@pluto.rain.com wrote: Thomas Mueller muelle...@insightbb.com wrote: Is there any way to keep two versions of Xorg-server, using no more than one at a time? Reason is the newer but unstable version with KMS, permitting full use of the newer Intel graphics chips. Provided you are OK with having the new KMS code in the kernel while running the older Xorg (so you don't need different kernels -- thus different base -- in addition to different Xorg userland), and if you don't mind having two entire ports/packages sets each including its own Xorg, this thread may help: I would say set PREFIX to install the port in a non-default location. With Xorg every gui app wants to use the X libs so I think setting LD_LIBRARY_PATH could get around that, but I would keep the old version in /usr/local and install the new version elsewhere until you get it running. See chapter 9.4 PREFIX and DESTDIR of porters handbook for more info. ___ 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
Can a ports commiter add this to their todo list
I believe we are still under a ports freeze so expect this request to be added to a todo list to be done after the freeze. Currently the port audio/hydrogen is marked as broken and has an expiration date of 2013-03-05 so I am hoping to get it fixed before it is deleted. I have submitted a patch to fix this and am willing to adopt the obviously neglected port. See pr/177806 Thanks. ___ 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: starnge ports tree error: perl5.16 non-existent -- dependency list incomplete
On 15/03/2013 00:34, Beeblebrox wrote: Can someone tell me what's going on here? Perl gets installed twice then fails because it is not there? I have tested with enabling only one of below at-a-time in build-jail's make.conf, but no use. PERL_VERSION= 5.16 \ #PERL_DEFAULT_VERSION= 5.16 \ #PERL_PORT= perl5.16 PERL_PORT uses a two digit version - 5.16 PERL_VERSION should be a three digit version - 5.16.2 My guess is that your entry for PERL_VERSION is not getting updated by the perl install as it isn't a grep match. ___ 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: I need help with git
On 06/02/2013 00:27, Wesley Shields wrote:
I don't know if we have a way to express this in the ports framework but
you absolutely can grab a tarball of a repo at any specific commit on
github even if it is not tagged.
This is the URL to grab ironbee/libhtp at
234fd5bab1225e483ea263a5a15faebed0bd61b9:
https://github.com/ironbee/libhtp/archive/234fd5bab1225e483ea263a5a15faebed0bd61b9.tar.gz
/usr/ports/Mk/bsd.sites.mk contains --
# GitHub files can also be obtained, without the commit hashes, by doing:
#
# MASTER_SITES=
http://github.com/accountname/${PORTNAME}/archive/${PORTVERSION}.tar.gz?dummy=/
# FETCH_ARGS= -Fpr
Where PORTVERSION would be expected to equal the tag name. I think that
would mean not defining USE_GITHUB.
I haven't tested this yet - but it looks like PORTVERSION can be swapped
for the long commit hash.
So you could probably use --
MASTER_SITES=
http://github.com/${GH_ACCOUNT}/${GH_PROJECT}/archive/${GH_COMMIT}.tar.gz?dummy=/
DISTFILES=${GH_PROJECT}-${GH_COMMIT}.tar.gz
FETCH_ARGS= -Fpr
GH_ACCOUNT= ironbee
GH_PROJECT= libhtp
GH_COMMIT= 234fd5bab1225e483ea263a5a15faebed0bd61b9
Without USE_GITHUB you may need to add WRKSRC=
${WRKDIR}/${GH_ACCOUNT}-${GH_COMMIT}
That could be the workaround for getting an untagged commit.
___
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: I need help with git
GH_COMMIT= 4dfdc80 Probably not needed if you specify a tag other than master. If I pull master, I get commit f57e464. That's not what I want. Why doesn't this thing pull the commit I'm telling it to pull? I think the thing most people miss here is that GH_COMMIT doesn't effect what gets downloaded, it's not used like an svn rev number - it is only used to define WRKSRC When a github tarball gets extracted GH_COMMIT is part of the dir name. Which is why it is mandatory and needs to match the tag. It is just needed to work with the way github creates tarballs. It is inconvenient but github is only setup to let you download tarballs of specific tags not specific commits. If the main devs don't tag the specific points you want the only option is to fork and create your own tags. ___ 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: Problems with GITHUB pulls
On 30/01/2013 07:54, Paul Schmehl wrote: I maintain the security/barnyard2 port. It pulls the software from git, which is the only place where it's available. The problem is, master's commit tag and md5 sum and size have changed. I *could* update the port by changing the commit tag and the distino file, but that's seems rather kludgy to me. The version hasn't changed. The developers simply fixed some problems in the software and then bumped master to the newer commit. Is that really the correct way to handle software at git? If so, am I going to be forced to update the port every time the developers make minor changes to a version? Is there a way for me to work around this problem so that the port version remains at the stable commit until the version actually gets bumped? GH_COMMIT is mandatory, so I can't leave that out. Yet the git tagname has changed. What's the best way to handle this? Following the head of a branch is always dynamic. The way to get a consistent download from github is to use tags. Try the tag v2-1.11 If you want to keep closer to the head of a branch then either get the devs to tag some stable points along the way or fork your own version and add tags as you want and use your repo for the port. ___ 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: FreeBSD 9.1 Postgresql
On 23/01/2013 05:30, Owen O' Shaughnessy wrote: Hi Guys, Wondering if anybody else has tried installing Postgres from packages? I have used pkg_add -r to install postgresql-server and postgresql-client, both installed sucessfully, I've got server and client binaries and libraries but no configuration files for the server. Does the package assume it is an upgrade, or is there another package that you install to get the configuration files and initscripts? I was expecting to find: /usr/local/etc/rc.d/postgresql I was expecting a binary somewhere on the system called initdb What you are after should be installed as part of the server package. Sure you didn't get the client only? initdb should be in /usr/local/bin with postgres and postmaster. The postgresql.conf file will be inside the data dir after initdb is run. /usr/local/etc/rc.d/postgresql should exist and contain info on adding settings to /etc/rc.conf Of course if you happen to have $PREFIX set to something other than /usr/local things may have ended up elsewhere. (not sure if that effects packages or just port builds) ___ 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: devel/boost-libs looks hardwired for gcc/g++
On 09/01/2013 18:26, Baptiste Daroussin wrote: FYI I'm working on an update to 1.52.0 version, which will not be hard wired anymore http://people.freebsd.org/~bapt/boost-1.52.0.diff I just had a quick look over the patch - with 1.48 boost-python-libs generates libboost_python and libboost_python3 when built against python 3.x - does 1.52 still do this or has it been merged? ___ 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: devel/boost-libs looks hardwired for gcc/g++
On 09/01/2013 09:53, Jakub Lach wrote: There is no gcc/++ on this system, however there is cc (clang) and gcc47 from ports, which should be used in ports if respecting CC= yes it is poorly hard-coded to use gcc there is a fix waiting in pr/173865 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/173865 ___ 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: FreeBSD ports you maintain which are out of date
On 28/11/2012 09:45, Kevin Oberman wrote: On Tue, Nov 27, 2012 at 8:12 AM, Radim Kolar h...@filez.com wrote: can be this daily spam turned off? i emailed there portsc...@portscout.freebsd.org but message was not delivered It's not spam, but a very useful service. I you don't work on any ports, you should be able to filter it very easily with procmail or your mail reader. Probably more to the point is that it shouldn't get sent to the ports mailing list - just to port maintainers. Maybe once a month a list can be sent to the mailing list that would be unmaintained ports that need updating? ___ 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
The state of redports
I haven't got a response from redports servers for a while now. Has redports closed it's doors? Having hardware issues? ___ 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: Github problems
On 09/11/2012 07:35, Paul Schmehl wrote: I'm working on a new port, and I'm having problems with Github. = snorby-2.5.3.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch https://nodeload.github.com/Snorby/snorby/tarball/master?dummy=/snorby-2.5.3.tar.gz That relates to changes at github - a fix was committed 2 days ago, so - portsnap fetch update should fix that ___ 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: Possible regression in i386 build with gcc 4.6
On 07/10/2012 03:24, Tijl Coosemans wrote: The __sync built-ins exist in both base and ports gcc, but __sync_fetch_and_add_8 needs at least -march=i586. OK I get the bit that I missed here - the tests for gcc atomics was outdated and I need to change that as well as set the arch :-) But that does leave the tbb alternative built with gcc42 runs but not the gcc46 version. That should fall to the gcc maintainer? ___ 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: Possible regression in i386 build with gcc 4.6
On 08/10/2012 08:40, Tijl Coosemans wrote:
inline long long
atomic_exchange_and_add (volatile long long *at, long long x)
{
#ifdef USE_GCC_ATOMICS
return __sync_fetch_and_add (at, x);
#elif USE_TBB
atomiclong long *a = (atomiclong long *)at;
This cast is dangerous. It looks like atomiclong long has 8 byte
alignment, but long long on i386 only has 4 byte alignment.
Could that be the cause of the seg fault?
gcc42 just happens to generate it into a place that equals 8 byte align
where gcc46 doesn't?
___
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
