Re: Large builds with poudriere
On Thu, May 20, 2021 at 03:09:32PM -0700, Mark Millard wrote:
> Kevin Oberman rkoberman at gmail.com wrote on
> Thu May 20 21:37:28 UTC 2021 :
>
> > On Thu, May 20, 2021 at 12:48 PM Mark Millard wrote:
> >
> > > Kevin Oberman rkoberman at gmail.com wrote on
> > > Thu May 20 19:21:24 UTC 2021 :
> > >
> > > > You can greatly reduce the build-time for devel/llvm* by changing the
> > > > config to BE_NATIVE to avoid building backends for all FreeBSD supported
> > > > platforms. Obviously this is not acceptable for many cases, but if you
> > > > never cross-compile for other platforms, it's a really big win.
> > >
> > >
> > > Unfortunately, using something like (llvm10 is just one example,
> > > llvm11 showed the same sort of problem at the time):
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
> > > CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD
> > > BE_NATIVE
> > > BE_STANDARD
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
> > >
> > > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD
> > >
> > > does not work for all platforms/targets. On a Cortex-A57
> > > this lead to:
> > >
> > > Registered Targets:
> > > amdgcn - AMD GCN GPUs
> > > r600 - AMD GPUs HD2XXX-HD6XXX
> > >
> > > In other words, aarch64 was missing. I had to pick
> > > BE_STANDARD or BE_FREEBSD to get something that
> > > would target aarch64 on aarch64.
> > >
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > > ( dsl-only.net went
> > > away in early 2018-Mar)
> > >
> > Looks like the Makefile might need some work. I see stuff for handling
> > aach64/arm64, so it SHOULD work, but there are things I don't understand
> > about AARCH64 to figure it all out. Still, it should be detected.
> >
> > Out of curiosity, if you do a "make -C /usr/ports/devel/llvm10 config",
> > the line for BE_NATIVE should show the architecture you are running on. If
> > it's missing/something else, maybe you should ask brooks@ about it.
>
>
> On two types of Cortex-A72 context
> # make -C /usr/ports/devel/llvm10 config
>
> produced:
>
> BE_NATIVE Backend(s) for this architecture ()
>
> The same for each of:
>
> # make -C /usr/ports/devel/llvm80 config
> # make -C /usr/ports/devel/llvm90 config
> # make -C /usr/ports/devel/llvm11 config
> # make -C /usr/ports/devel/llvm12 config
>
> But this turns out to be because:
>
> # make -C /usr/ports/devel/llvm10 -V ARCH
> aarch64
>
> yet the Makefiles have a test for arm64 instead:
>
> .elif ${ARCH} == arm64
> _NATIVE_BACKENDS= AAarch64
Ah, that's the key point. I've fixed the ARCH value and fixed the
spelling of AArch64 in older ports where it was wrong.
-- Brooks
signature.asc
Description: PGP signature
Re: Any plan to fix ports git main history compatibility with old GitHub master?
On Mon, Apr 05, 2021 at 05:33:08PM -0300, Eric Turgeon wrote: > Today when trying to sync the GhostBSD ports tree with the FreeBSD ports > tree, I found out the main branch history is not compatible with the old > GitHub master. > > Any plan to migrate to main with hold git history as we had with > freebsd-src? The main branch will contain a commit which is identical to the last commit of the old master branch (except for the hash). If the GhostBSD repo is merged up to that point, you can then merge the matching commit from main and proceed with using main as the source for future merges. If you have outstanding WIPs the process of updating them to the new history should be about the same as the one for source: https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/articles/committers-guide/_index.adoc#562-migrating-from-github-fork -- Brooks signature.asc Description: PGP signature
Re: devel/llvm11 failed to build
On Wed, Dec 02, 2020 at 09:20:00AM +0900, KIRIYAMA Kazuhiko wrote:
> Hi, all
>
> I've changed Makefile so as to include *mmintrin.h as
> follows:
>
> --- /home/kiri/work/ports/head/devel/llvm11/Makefile 2020-11-09
> 12:30:07.0 +0900
> +++ llvm11/Makefile 2020-11-29 17:12:58.544495000 +0900
> @@ -59,8 +59,8 @@
>
> # Disable assertions. They should be disabled by cmake, but USES=cmake
> # overrides -DCMAKE_*_FLAGS_RELEASE.
> -CFLAGS+= -DNDEBUG
> -CXXFLAGS+= -DNDEBUG
> +CFLAGS+= -DNDEBUG -DNO_WARN_X86_INTRINSICS
> -I${WRKSRC}/tools/clang/lib/Headers/ppc_wrappers
> +CXXFLAGS+= -DNDEBUG -DNO_WARN_X86_INTRINSICS
> -I${WRKSRC}/tools/clang/lib/Headers/ppc_wrappers
>
> OPTIONS_DEFINE= BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLD_LINK LLDB
> PYCLANG
> OPTIONS_DEFINE_aarch64= OPENMP
>
> and `make install' devel/llvm11, but failed to build:
...
> May circumstances are as follows:
>
> root@jdtpkxb:~ # uname -a
> FreeBSD jdtpkxb 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r367712M: Tue Nov 17
> 01:35:26 JST 2020 root@msrvkxb:/usr/obj/usr/src/amd64.amd64/sys/XIJ amd64
> root@jdtpkxb:~ # svnlite info /usr/ports
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: http://svn.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: http://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 555444
> Node Kind: directory
> Schedule: normal
> Last Changed Author: lwhsu
> Last Changed Rev: 555444
> Last Changed Date: 2020-11-16 11:44:38 +0900 (Mon, 16 Nov 2020)
>
> root@jdtpkxb:~ #
>
> What should I do ?
I can't understand what you think this patch will do. You're causing
PowerPC intrinsic headers to be included while building for amd64. I
don't see how that could work.
-- Brooks
signature.asc
Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, Aug 07, 2020 at 11:48:34AM -0400, Greg Veldman wrote: > On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote: > > The real question is: Will we design things in a way that we expect ports > > tree users to always install git and its dependencies on their system or > > not (long term)? > > > > For developers it???s a no-brainer (obviously yes), but ports tree users > > aren???t developers. > > Or alternatively, will there be a git/gitlite or similar utility > included in base that can be used to bootstrap one's ports tree? We'd love to have something, but we aren't going to hold up progress indefinitely waiting for one to be implemented in an acceptable language with an acceptable license. -- Brooks signature.asc Description: PGP signature
Re: Fwd: AFFECTS: users of devel/kuya
Thanks for the report, I make that typo all the time. Thanks also to bapt@ for fixing. -- Brooks On Thu, Apr 23, 2020 at 08:16:59AM +0200, Andrea Venturoli wrote: > Hello. > > Should that be devel/kyua? > > Not to be nitpicking, but someone might try grep on UPDATING :) > > bye > av. > > > Forwarded Message > Subject: AFFECTS: users of devel/kuya > Date: Wed, 22 Apr 2020 00:00:00 GMT > From: Alexander Kojevnikov > > > > AFFECTS: users of devel/kuya > > 20200422: > AFFECTS: users of devel/kuya > AUTHOR: bro...@freebsd.org > > A tests group has been added and the tests user should be a member > of it by default rather than nobody. You should update your password > database to match (change the group from 65534 to 977 after updating). > > ___ > 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" > signature.asc Description: PGP signature
Re: Poudriere make.conf documentation question
On Fri, Apr 17, 2020 at 09:42:51AM -0700, Jose Quinteiro wrote: > Hello, > > The Handbook says: > "The system make.conf and this new file are combined at build time to > create the make.conf used by the build jail." > https://www.freebsd.org/doc/handbook/ports-poudriere.html > > The poudriere man page and Porter's Handbook do not mention > /etc/make.conf as a file that will get used. > > My simple test did not work with /etc/make.conf, but I also suspect I > screwed something else up. > > Does /etc/make.conf get "combined" into the effective make.conf for > Poudriere? I think that documentation is confusing as is the manpage. I think that the webpage is refering to the first one in the list below not /etc/make.conf, but I could be wrong. Here's the relevent bit of the manpage: Create optional make.conf You can also specify a global make.conf which will be used for all the jails. Any of the following are allowed and will all be used in the order shown: /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 /usr/local/etc/poudriere.d/--make.conf /usr/local/etc/poudriere.d/---make.conf /usr/local/etc/poudriere.d/hooks/plugins//make.conf -- Brooks signature.asc Description: PGP signature
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > I'm testing modifications of ports I maintain in > a jail. I have nothing in make.conf(5) except > DEVELOPER=true > But I get messages regarding python versions like: > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > But I make no demands on versions. > What causes this, and how can I stop it. :) Is your set of packages fully up to date? IIRC other have had issues when they tried to install LLVM with out of date dependencies. -- Brooks signature.asc Description: PGP signature
Re: amd64->{armv7,aarc64} cross builds of devel/llvm10 (via poudriere-devel): failed in package stage for missing libarcher* files
Fixed in r526532. Thanks for the hint that it was in OPENMP. -- Brooks On Mon, Feb 17, 2020 at 08:19:26PM -0800, Mark Millard wrote: > On 2020-Feb-17, at 09:56, Mark Millard wrote: > > > On 2020-Feb-17, at 09:53, Mark Millard wrote: > > > >> [The native arm64 build worked fine. But the cross builds > >> got . . .] > >> > >> The builds failed with: > >> > >> > Compressing man pages (compress-man) > >> ===> Installing ldconfig configuration file > >> === > >> === > >> ===> Building package for llvm10-10.0.0.r1_1 > >> pkg-static: Unable to access file > >> /wrkdirs/usr/ports/devel/llvm10/work/stageusr/local/llvm10/lib/libarcher.so:No > >> such file or directory > >> pkg-static: Unable to access file > >> /wrkdirs/usr/ports/devel/llvm10/work/stageusr/local/llvm10/lib/libarcher_static.a:No > >> such file or directory > >> *** Error code 1 > >> > >> Stop. > >> make: stopped in /usr/ports/devel/llvm10 > >> =>> Cleaning up wrkdir > >> ===> Cleaning for llvm10-10.0.0.r1_1 > >> > >> > >> head -r3577979 based system source; head -r536339 based ports tree. > >> > > > > I forgot to list: > > > > ===> The following configuration options are available for > > llvm10-10.0.0.r1_1: > > BE_AMDGPU=on: AMD GPU backend (required by mesa) > > CLANG=on: Build clang > > DOCS=on: Build and/or install documentation > > EXTRAS=on: Extra clang tools > > LIT=on: Install lit and FileCheck test tools > > LLD=on: Install lld, the LLVM linker > > LLDB=on: Install lldb, the LLVM debugger > > LLD_LINK=on: Link ld.lld as ld to clang uses it > > PYCLANG=off: Install python bindings to libclang > > > Options available for the single BACKENDS: you have to select exactly > > one of them > > BE_FREEBSD=off: Backends for FreeBSD architectures > > BE_NATIVE=on: Backend(s) for this architecture (ARM) > > BE_STANDARD=off: All non-experimental backends > > > > > llvm10-10.0.0.r2 gets the same. > > I was curious what the libarcher* files would be tied to > and found that libarcher is a tool library for an llvm > openmp tool. > > But openmp does not seem to be available for armv7 or > aarch64 so the file is not expected to be present for > installation, much like libgomp.so , liniomp5.so , > libomp.so , and libomptarget.so . Looks like a > %%OPENMP%% prefix is needed in llvm10/pkg-plist for > each of the two libarcher lines. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > signature.asc Description: PGP signature
Re: devel/llvm80 port on 12.1
On Thu, Dec 12, 2019 at 04:42:07PM +0100, Lars Engels wrote: > I'm trying reduce the size of the NomadBSD image and the biggest > installed package is devel/llvm80 with 848 MiB. > llvm80 is a dependency of graphics/mesa-dri which is needed for > x11-servers/xorg-server. > > Looking at the llvm version of 12.1-RELEASE in base I see that it is the > same version like the installed port: > > $ /usr/bin/clang --version > FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM > 8.0.1) > Target: x86_64-unknown-freebsd12.1 > Thread model: posix > InstalledDir: /usr/bin > > $ /usr/local/llvm80/bin/clang --version > clang version 8.0.1 (tags/RELEASE_801/final) > Target: x86_64-portbld-freebsd12.0 > Thread model: posix > InstalledDir: /usr/local/llvm80/bin > > So it looks like on 12.1 the mesa-dri port can use the base llvm instead > of the one from ports and save all people running Xorg almost 1 GB of > disk space? Nope. Mesa uses LLVM library ABIs which provide NO stability guarantees so we can not publish them as part of the release without locking the branch to a single LLVM version for the 5-year life (we effectively tried that with 10.x, it was terrible with many ports requiring workarounds for the increasingly obsolete base compiler). If you want to save space here, help out on the subpackage work so you only need to depend on the libraries. https://reviews.freebsd.org/D16457 -- Brooks signature.asc Description: PGP signature
Re: Checking you the maintainer of a port?
On Wed, Nov 27, 2019 at 02:05:56PM -0700, Janky Jay, III wrote: > Hello, > > On 11/27/19 2:03 PM, @lbutlr wrote: > > I thought that the maintainer of a port was listed somewhere in the files > > at user/ports//portbase/ but evidently not. What is the easiest way > > to find out, sitting in console on a server without a GUI, to find out who > > the maintainer is? (On my desktop I can just google and launch a browser, > > but that is not possible on most of the servers which do not have web > > clients installed. > > > > (Right now I am looking for the maintainer of roundcube, but this is a > > general question.) > > > > Please see the "MAINTAINER=" line in the port's "Makefile". A slightly more general answer is: cd /usr/ports//; make -V MAINTAINER -- Brooks signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 12:56, Brooks Davis wrote:
>
> > On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
> >>
> >>
> >> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
> >>
> >>> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> >>>> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> >>>>> [I found something known to be missing in the
> >>>>> in at least some versions of
> >>>>> llvm/cmake/modules/CrossCompile.cmake that messes
> >>>>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >>>>>
> >>>>> On 2019-Aug-6, at 20:23, Mark Millard wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >>>>>>
> >>>>>>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>>>>>>>
> >>>>>>>>> I'd prefer to disable this dependency. There's a knob that worked
> >>>>>>>>> in
> >>>>>>>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> >>>>>>>>> present and I've failed to find a knob to disable it. For now, the
> >>>>>>>>> easy
> >>>>>>>>> workaround is probably to disable options LIT. We could make that
> >>>>>>>>> the
> >>>>>>>>> default on non-LLVM platforms is that makes sense.
> >>>>>>>>>
> >>>>>>>>> -- Brooks
> >>>>>>>>
> >>>>>>>> Okay.
> >>>>>>>>
> >>>>>>>> poudriere-devel automatically built math/z3 because
> >>>>>>>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>>>>>>> previously built: I've never had other use of it. So
> >>>>>>>> my context was not one of an implicit autodetect.
> >>>>>>>
> >>>>>>> The dependency is there because if z3 is installed then the package
> >>>>>>> that is built depends on z3. Thus I had not choice but to add a z3
> >>>>>>> dependency until I find a way to turn it off. You can either help
> >>>>>>> find
> >>>>>>> a way to disable z3 detection in the cmake infrastructure or turn off
> >>>>>>> LIT. I don't have any use for reports on the effects of commenting
> >>>>>>> out
> >>>>>>> the DEPENDS line. I know what that does.
> >>>>>>
> >>>>>>
> >>>>>> I hope this helps. (I'm not a cmake expert.)
> >>>>>>
> >>>>>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >>>>>>
> >>>>>> #if LLVM_WITH_Z3
> >>>>>>
> >>>>>> #include
> >>>>>>
> >>>>>> namespace {
> >>>>>> . . .
> >>>>>> } // end anonymous namespace
> >>>>>>
> >>>>>> #endif
> >>>>>>
> >>>>>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> >>>>>> #if LLVM_WITH_Z3
> >>>>>> return llvm::make_unique();
> >>>>>> #else
> >>>>>> llvm::report_fatal_error("LLVM was not compiled with Z3 support,
> >>>>>> rebuild "
> >>>>>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> >>>>>> false);
> >>>>>> return nullptr;
> >>>>>> #endif
> >>>>>> }
> >>>>>>
> >>>>>> (There are other places LLVM_WITH_Z3 is used but the
> >>>>>> above is suggestive.)
> >>>>>>
> >>>>>> Working backwards finds that:
> >>>>>>
> >>>>>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMa
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
>
> > On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> >> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> >>> [I found something known to be missing in the
> >>> in at least some versions of
> >>> llvm/cmake/modules/CrossCompile.cmake that messes
> >>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >>>
> >>> On 2019-Aug-6, at 20:23, Mark Millard wrote:
> >>>
> >>>
> >>>
> >>>> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >>>>
> >>>>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>>>>>
> >>>>>>> I'd prefer to disable this dependency. There's a knob that worked in
> >>>>>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> >>>>>>> present and I've failed to find a knob to disable it. For now, the
> >>>>>>> easy
> >>>>>>> workaround is probably to disable options LIT. We could make that the
> >>>>>>> default on non-LLVM platforms is that makes sense.
> >>>>>>>
> >>>>>>> -- Brooks
> >>>>>>
> >>>>>> Okay.
> >>>>>>
> >>>>>> poudriere-devel automatically built math/z3 because
> >>>>>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>>>>> previously built: I've never had other use of it. So
> >>>>>> my context was not one of an implicit autodetect.
> >>>>>
> >>>>> The dependency is there because if z3 is installed then the package
> >>>>> that is built depends on z3. Thus I had not choice but to add a z3
> >>>>> dependency until I find a way to turn it off. You can either help find
> >>>>> a way to disable z3 detection in the cmake infrastructure or turn off
> >>>>> LIT. I don't have any use for reports on the effects of commenting out
> >>>>> the DEPENDS line. I know what that does.
> >>>>
> >>>>
> >>>> I hope this helps. (I'm not a cmake expert.)
> >>>>
> >>>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >>>>
> >>>> #if LLVM_WITH_Z3
> >>>>
> >>>> #include
> >>>>
> >>>> namespace {
> >>>> . . .
> >>>> } // end anonymous namespace
> >>>>
> >>>> #endif
> >>>>
> >>>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> >>>> #if LLVM_WITH_Z3
> >>>> return llvm::make_unique();
> >>>> #else
> >>>> llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
> >>>> "
> >>>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> >>>> false);
> >>>> return nullptr;
> >>>> #endif
> >>>> }
> >>>>
> >>>> (There are other places LLVM_WITH_Z3 is used but the
> >>>> above is suggestive.)
> >>>>
> >>>> Working backwards finds that:
> >>>>
> >>>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> >>>>
> >>>> shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> >>>>
> >>>> set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> >>>> solver.")
> >>>>
> >>>> find_package(Z3 4.7.1)
> >>>>
> >>>> if (LLVM_Z3_INSTALL_DIR)
> >>>> if (NOT Z3_FOUND)
> >>>> message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> >>>> LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> >>>> endif()
> >>>> endif()
> >>>>
> >>>> set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> >>>>
> >>>> option(LLVM_ENABLE_Z3_SOLVER
> >>>> "Enable Support for the Z3 con
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> > [I found something known to be missing in the
> > in at least some versions of
> > llvm/cmake/modules/CrossCompile.cmake that messes
> > up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >
> > On 2019-Aug-6, at 20:23, Mark Millard wrote:
> >
> >
> >
> > > On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> > >
> > >> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> > >>>
> > >>>
> > >>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> > >>>
> > >>>> I'd prefer to disable this dependency. There's a knob that worked in
> > >>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> > >>>> present and I've failed to find a knob to disable it. For now, the
> > >>>> easy
> > >>>> workaround is probably to disable options LIT. We could make that the
> > >>>> default on non-LLVM platforms is that makes sense.
> > >>>>
> > >>>> -- Brooks
> > >>>
> > >>> Okay.
> > >>>
> > >>> poudriere-devel automatically built math/z3 because
> > >>> I'd indicated to build devel/llvm90 . math/z3 was not
> > >>> previously built: I've never had other use of it. So
> > >>> my context was not one of an implicit autodetect.
> > >>
> > >> The dependency is there because if z3 is installed then the package
> > >> that is built depends on z3. Thus I had not choice but to add a z3
> > >> dependency until I find a way to turn it off. You can either help find
> > >> a way to disable z3 detection in the cmake infrastructure or turn off
> > >> LIT. I don't have any use for reports on the effects of commenting out
> > >> the DEPENDS line. I know what that does.
> > >
> > >
> > > I hope this helps. (I'm not a cmake expert.)
> > >
> > > llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> > >
> > > #if LLVM_WITH_Z3
> > >
> > > #include
> > >
> > > namespace {
> > > . . .
> > > } // end anonymous namespace
> > >
> > > #endif
> > >
> > > llvm::SMTSolverRef llvm::CreateZ3Solver() {
> > > #if LLVM_WITH_Z3
> > > return llvm::make_unique();
> > > #else
> > > llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
> > > "
> > > "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> > > false);
> > > return nullptr;
> > > #endif
> > > }
> > >
> > > (There are other places LLVM_WITH_Z3 is used but the
> > > above is suggestive.)
> > >
> > > Working backwards finds that:
> > >
> > > /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> > >
> > > shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> > >
> > > set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> > > solver.")
> > >
> > > find_package(Z3 4.7.1)
> > >
> > > if (LLVM_Z3_INSTALL_DIR)
> > > if (NOT Z3_FOUND)
> > >message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> > > LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> > > endif()
> > > endif()
> > >
> > > set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> > >
> > > option(LLVM_ENABLE_Z3_SOLVER
> > > "Enable Support for the Z3 constraint solver in LLVM."
> > > ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> > > )
> > >
> > > if (LLVM_ENABLE_Z3_SOLVER)
> > > if (NOT Z3_FOUND)
> > >message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3
> > > is not available.")
> > > endif()
> > >
> > > set(LLVM_WITH_Z3 1)
> > > endif()
> > >
> > > if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> > > set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> > > endif()
> > >
> > >
> > > If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> > > appears to override the default (that tracks if z3 was found
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> [I found something known to be missing in the
> in at least some versions of
> llvm/cmake/modules/CrossCompile.cmake that messes
> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
>
> On 2019-Aug-6, at 20:23, Mark Millard wrote:
>
>
>
> > On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >
> >> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>
> >>>
> >>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>>
> >>>> I'd prefer to disable this dependency. There's a knob that worked in
> >>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> >>>> present and I've failed to find a knob to disable it. For now, the easy
> >>>> workaround is probably to disable options LIT. We could make that the
> >>>> default on non-LLVM platforms is that makes sense.
> >>>>
> >>>> -- Brooks
> >>>
> >>> Okay.
> >>>
> >>> poudriere-devel automatically built math/z3 because
> >>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>> previously built: I've never had other use of it. So
> >>> my context was not one of an implicit autodetect.
> >>
> >> The dependency is there because if z3 is installed then the package
> >> that is built depends on z3. Thus I had not choice but to add a z3
> >> dependency until I find a way to turn it off. You can either help find
> >> a way to disable z3 detection in the cmake infrastructure or turn off
> >> LIT. I don't have any use for reports on the effects of commenting out
> >> the DEPENDS line. I know what that does.
> >
> >
> > I hope this helps. (I'm not a cmake expert.)
> >
> > llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >
> > #if LLVM_WITH_Z3
> >
> > #include
> >
> > namespace {
> > . . .
> > } // end anonymous namespace
> >
> > #endif
> >
> > llvm::SMTSolverRef llvm::CreateZ3Solver() {
> > #if LLVM_WITH_Z3
> > return llvm::make_unique();
> > #else
> > llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild "
> > "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> > false);
> > return nullptr;
> > #endif
> > }
> >
> > (There are other places LLVM_WITH_Z3 is used but the
> > above is suggestive.)
> >
> > Working backwards finds that:
> >
> > /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> >
> > shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> >
> > set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> > solver.")
> >
> > find_package(Z3 4.7.1)
> >
> > if (LLVM_Z3_INSTALL_DIR)
> > if (NOT Z3_FOUND)
> >message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> > LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> > endif()
> > endif()
> >
> > set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> >
> > option(LLVM_ENABLE_Z3_SOLVER
> > "Enable Support for the Z3 constraint solver in LLVM."
> > ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> > )
> >
> > if (LLVM_ENABLE_Z3_SOLVER)
> > if (NOT Z3_FOUND)
> >message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is
> > not available.")
> > endif()
> >
> > set(LLVM_WITH_Z3 1)
> > endif()
> >
> > if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> > set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> > endif()
> >
> >
> > If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> > appears to override the default (that tracks if z3 was found).
>
> I saw a reference to:
>
> diff --git a/llvm/cmake/modules/CrossCompile.cmake
> b/llvm/cmake/modules/CrossCompile.cmake
> index bc3b210f018..0c30b88f80f 100644
> --- a/llvm/cmake/modules/CrossCompile.cmake
> +++ b/llvm/cmake/modules/CrossCompile.cmake
> @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name
> toolchain buildtype)
> -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
> -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
>
> -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
> +-DLLVM_ENABLE_
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote: > > > On 2019-Aug-6, at 09:55, Brooks Davis wrote: > > > I'd prefer to disable this dependency. There's a knob that worked in > > the 8.0 timeframe, but the lit build now autodetects z3 when it is > > present and I've failed to find a knob to disable it. For now, the easy > > workaround is probably to disable options LIT. We could make that the > > default on non-LLVM platforms is that makes sense. > > > > -- Brooks > > Okay. > > poudriere-devel automatically built math/z3 because > I'd indicated to build devel/llvm90 . math/z3 was not > previously built: I've never had other use of it. So > my context was not one of an implicit autodetect. The dependency is there because if z3 is installed then the package that is built depends on z3. Thus I had not choice but to add a z3 dependency until I find a way to turn it off. You can either help find a way to disable z3 detection in the cmake infrastructure or turn off LIT. I don't have any use for reports on the effects of commenting out the DEPENDS line. I know what that does. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
I'd prefer to disable this dependency. There's a knob that worked in the 8.0 timeframe, but the lit build now autodetects z3 when it is present and I've failed to find a knob to disable it. For now, the easy workaround is probably to disable options LIT. We could make that the default on non-LLVM platforms is that makes sense. -- Brooks On Mon, Aug 05, 2019 at 08:45:31PM -0700, Mark Millard via freebsd-toolchain wrote: > Building math/z3 involves: > > # grep compiler /usr/ports/math/z3/Makefile > USES= compiler:c++11-lang python:2.7,build > > But devel/llvm90 requires math/z3 to have been built before > devel/llvm90 is built: > > # pkg info -d llvm90 > llvm90-9.0.0.r1: > libxml2-2.9.9 > z3-4.8.5_1 > python36-3.6.9 > perl5-5.28.2 > libedit-3.1.20190324,1 > # pkg info -B llvm90 > llvm90-9.0.0.r1: > libpython3.6m.so.1.0 > libedit.so.0 > libz3.so.0 > libxml2.so.2 > > > Hopefully this cycle can be avoided for system > clang to eventually have progressed to clang 9. > (I do not know the details.) > > For architectures still at gcc/g++ 4.2.1, some > alternate c++ tool chain needs to be used to > build libz3.so but the result needs to be > compatible with llvm90 later using the libz3.so's > content. (I do not know the details.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > freebsd-toolch...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" > signature.asc Description: PGP signature
Re: devel/llvm80 requires many python 2.7 ports?
On Thu, Jul 25, 2019 at 02:57:29PM -0700, Kevin Oberman wrote: > I just went to build llvm80 after discovering that I could not install the > package without moving from the drfault samba48 back to the deprecated > samba47. > > When I try to build the port, I get: > Upgrade llvm80-8.0.0_2 to llvm80-8.0.1 > Install textproc/py-recommonmark@py27 > Install textproc/py-docutils@py27 > Install textproc/py-sphinx@py27 > Install devel/py-Jinja2@py27 > Install devel/py-babel@py27 > Install devel/py-pytz@py27 > Install textproc/py-MarkupSafe@py27 > Install devel/py-typing@py27 > Install graphics/py-imagesize@py27 > Install textproc/py-alabaster@py27 > Install textproc/py-pygments@py27 > Install textproc/py-snowballstemmer@py27 > Install textproc/py-pystemmer@py27 > Install textproc/py-sphinx_rtd_theme@py27 > Install textproc/py-sphinxcontrib-websupport@py27 > Install www/py-requests@py27 > Install dns/py-idna@py27 > Install net/py-urllib3@py27 > Install net/py-ipaddress@py27 > Install net/py-pysocks@py27 > Install security/py-certifi@py27 > Install security/py-cryptography@py27 > Install devel/py-asn1crypto@py27 > Install devel/py-cffi@py27 > Install devel/py-pycparser@py27 > Install security/py-openssl@py27 > Install textproc/py-chardet@py27 > Install devel/py-pytest-runner@py27 > Install devel/py-setuptools_scm@py27 > > Is llvm80 really still stuck using v2 Python? I looked at the very complex > Makefile, and it's very clear: _USES_PYTHON?= python:2.7,build > > Will this going away some day soon? I know that end of 2.7 support is > approaching and I have only a handfull of python 2.7 ports left, mostly to > support print/hplip (HP printer drivers for CUPS) and hope to get rid of > them soime day soon. Historically LLVM has required Python v2. I've not checked if 8.0.1 can be pinned to 3.6 like I've done with llvm-devel. llvm90 (coming soon) will use python 3.6. I'll keep switching llvm80 in mind, but given that such a change will require everyone to rebuild it I'll probably wait and combine it with other changes. -- Brooks signature.asc Description: PGP signature
LLVM 7.1.0: how to proceed?
LLVM 7.1.0 will be release shortly and contains a single fix which breaks the LLVM Libra ABI in order to fix an incompatibility with GCC 8.2. A bug describing the issue is at https://bugs.llvm.org/show_bug.cgi?id=39427. My current plan is: - Copy devel/llvm70 to devel/llvm71 and update. - Perform a coordinated switch of all dependencies, to llvm71 (e.g. do an exp-run with the switch made and llvm70 removed). All ports with library dependencies would get PORT_REVISION bumps. - DEPRECATE llvm70 and set a short expiration. Does this sound like a reasonable plan? -- Brooks signature.asc Description: PGP signature
Re: sphinx-build not found
On Fri, Jan 18, 2019 at 05:03:54PM -0700, Russell L. Carter wrote: > Greetings, > > Quite a few ports are now being skipped by the not unheard of > problem with "sphinx-build not found". Including llvm6 and 7. > I've checked UPDATING and google, but no hints, other than this > problem has happened in the past. > > Is there something I can do or should I just be patient? NBD > if I need to be patient. Hmm, textproc/py-sphinx should be installing sphinx-build. I wonder if there's an edge case your config is triggering where the flavor that gets installed isn't the one with the unversioned script. I'd rather not depend on a fixed flavor in llvm[67]0, but if there's someting I'm not understanding about python port flavors, I could follow what I did in llvm-devel to allow py-recommonmark to work reliably. -- Brooks signature.asc Description: PGP signature
Re: git checkout branch in makefile
On Mon, Jul 09, 2018 at 08:19:13PM +0200, Michael Gmelin wrote: > > > > On 9. Jul 2018, at 19:34, blubee blubeeme wrote: > > > > Is it possible to do a git checkout of a specific branch in a ports > > makefile? > > > > How would I go about checking out a particular branch from a github project. > > As branches aren???t stable this won???t buy you anything, that???s why you > should always go for a tag or commit (which is branch agnostic). If you want to make it easy to update to the latest commit on a branch, take a look at devel/llvm-devel/files/gen-Makefile.snapshot.sh for an example of automatically extracting that information from the github API. -- Brooks signature.asc Description: PGP signature
Re: RTTI support in devel/llvm40 (and maybe other llvm ports)
On Sun, Nov 26, 2017 at 11:15:53PM +0700, Alexey Dokuchaev wrote: > On Sun, Nov 12, 2017 at 07:41:04PM +0700, Alexey Dokuchaev wrote: > > On Sun, Nov 12, 2017 at 08:03:19AM +0000, Brooks Davis wrote: > > > On Fri, Nov 10, 2017 at 02:07:48PM +0700, Alexey Dokuchaev wrote: > > > > 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's been a few years since we disabled it so I don't remember the > > > details of the decision. I'll look into it, but am not in a position > > > to test for breakage to other ports. > > > > Well it's probably OK to expect users or maintainers of those ports > > would speak up if enabling RTTI breaks their software. :-) > > > > > IIRC there were once ports that failed to build both with and > > > without so it may be that we need to wait for flavors to make this > > > change. > > > > Hmm, that's weird: I'd expect it is easier to *not* use RTTI when > > one does not need it than try to find the way around when it is not > > available (which might not be possible). I also don't see why we > > should wait for FLAVORS: if needed, we can always make it optional > > (cf. existing EXTRAS LIT LLD LLDB options) but enabled by default. > > Did you have a chance to make up your mind on this? (If you worry > that enabling RTTI might break some ports we can always ask portmgr@ > for an exp-run). Between travel and US holidays I've had no time for this. I'll take a look at it soon. -- Brooks signature.asc Description: PGP signature
Re: Suggestion: USES=autoplist
On Thu, Nov 23, 2017 at 12:51:56AM -0800, Yuri wrote: > On 11/22/17 08:59, Brooks Davis wrote: > > Looking to the future, is the port an obviously candidate for FLAVORS or > > multi-packages? If so, they you probably want to keep the current > > plist. If not, then I guess it depends on your confidence that the port > > will remain well behaved. > > > Flavors and multi-packages will work fine with autoplist. autoplist > always generates the plist according to the currently selected options. Flavors maybe, multi-packages, definitely not. With multi-packages each component needs to be tagged in the plist with the package it will be part of. You can do that programatically, but autoplist can't do it generically (except perhaps in the most trivial, path based cases). -- Brooks signature.asc Description: PGP signature
Re: Suggestion: USES=autoplist
On Tue, Nov 21, 2017 at 09:04:22PM -0800, Yuri wrote: > While trying to update math/vtk, I found that its plist is very complex, > with many optional files, some files depending on multiple port options. > > But it is a well-behaved project, and it only installs the correct file > set. It is much easier to just trust it. > > > So I am suggesting USES=autoplist: https://reviews.freebsd.org/D13181 > > > Any thoughts? Looking to the future, is the port an obviously candidate for FLAVORS or multi-packages? If so, they you probably want to keep the current plist. If not, then I guess it depends on your confidence that the port will remain well behaved. -- Brooks signature.asc Description: PGP signature
Re: What is the correct way to require a specific version of clang?
On Wed, Nov 15, 2017 at 01:43:29PM -0800, Yuri wrote:
> On 11/15/17 11:58, Brooks Davis wrote:
> > You'll need to start a shell in your poudreire instance and see what is
> > failing. I'd expect that to work.
> >
> > Note that it is possible to misconfigure the llvm38 port such that this
> > config is broken by disabling the CLANG option.
>
>
> What's happening is that framework calls ${CC} before it installs
> BUILD_DEPENDS.
Ah, it looks like USES=compiler is incompatible with setting CC. It
would be great it someone would create compiler:clang support, but I've
not found the time thus far.
-- Brooks
signature.asc
Description: PGP signature
Re: What is the correct way to require a specific version of clang?
On Wed, Nov 15, 2017 at 10:37:37AM -0800, Yuri wrote:
> There is no such thing as USES=clang:38, for example.
>
> When I try this:
>
> .include
>
> .if ${OPSYS} == FreeBSD && ${OSVERSION} < 110
> BUILD_DEPENDS=?? clang38:lang/clang38
> RUN_DEPENDS=?? clang38:lang/clang38
> CC= clang38
> CXX=?? clang++38
>
> .endif
>
>
> It prints warnings in pourdriere 10i386 machine:
>
> clang38: not found
> make: "/usr/ports/Mk/Uses/compiler.mk" line 69: warning: "clang38
> --version" returned non-zero status
> make: "/usr/ports/Mk/Uses/compiler.mk" line 112: warning: "clang++38
> -### /dev/null 2>&1" returned non-zero status
>
>
> How to do this without such messages?
You'll need to start a shell in your poudreire instance and see what is
failing. I'd expect that to work.
Note that it is possible to misconfigure the llvm38 port such that this
config is broken by disabling the CLANG option.
-- Brooks
signature.asc
Description: PGP signature
Re: [Bug 223383] pathconf querying for posix_falloc not supported on freebsd [devel/llvm*'s lld's are also broken by this for zfs and need updating]
I'll work on this. -- Brooks On Thu, Nov 09, 2017 at 07:09:00PM -0800, Mark Millard wrote: > [ devel/llvm* also have the issue in their > lld 's.] > > On 2017-Nov-7, at 4:43 PM, bugzilla-noreply at freebsd.org wrote: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223383 > > > > --- Comment #7 from commit-h...@freebsd.org --- > > A commit references this bug: > > > > Author: emaste > > Date: Wed Nov 8 00:39:04 UTC 2017 > > New revision: 325523 > > URL: https://svnweb.freebsd.org/changeset/base/325523 > > > > Log: > > MFC r325420: lld: accept EINVAL to indicate posix_fallocate is unsupported > > > > As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to > > indicate that the operation is not supported. (I think this is a strange > > choice of errno on the part of POSIX.) > > > > PR: 223383, 223440 > > Reported by: Mark Millard > > Sponsored by: The FreeBSD Foundation > > > > Changes: > > _U stable/11/ > > stable/11/contrib/llvm/lib/Support/Unix/Path.inc > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > [Context a zfs file system.] > > From /usr/src/UPDATING: > > 20171106: > The naive and non-compliant support of posix_fallocate(2) in ZFS > has been removed as of r325320. The system call now returns EINVAL > when used on a ZFS file. Although the new behavior complies with the > standard, some consumers are not prepared to cope with it. > One known victim is lld prior to r325420. > > > The issue is not limited to the system clang's > associated lld. > > Here is an attempt to use clang++50, implicitly using > its associated lld: > > # clang++50 -v exception_test.cc > clang version 5.0.0 (tags/RELEASE_500/final) > Target: x86_64-portbld-freebsd12.0 > Thread model: posix > InstalledDir: /usr/local/llvm50/bin > "/usr/local/llvm50/bin/clang-5.0" -cc1 -triple x86_64-portbld-freebsd12.0 > -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cc > -mrelocation-model static -mthread-model posix -mdisable-fp-elim > -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v > -dwarf-column-info -debugger-tuning=gdb -resource-dir > /usr/local/llvm50/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 > -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 > -fmessage-length 200 -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-baadc9.o > -x c++ exception_test.cc > clang -cc1 version 5.0.0 based upon LLVM 5.0.0 default target > x86_64-portbld-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/include/c++/v1 > /usr/local/llvm50/lib/clang/5.0.0/include > /usr/include > End of search list. > "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker > /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out > /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib > /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s > --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o > /usr/lib/crtn.o > /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid > argument > clang-5.0: error: linker command failed with exit code 1 (use -v to see > invocation) > > > https://svnweb.freebsd.org/ports/head/devel/?dir_pagestart=1000 > > does not yet suggest updates to devel/llvm* 's for > the issue. > > === > Mark Millard > markmi at dsl-only.net > signature.asc Description: PGP signature
Re: RTTI support in devel/llvm40 (and maybe other llvm ports)
On Fri, Nov 10, 2017 at 02:07:48PM +0700, 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.
>
> The patch is very simple (apart port revision bump):
>
> @@ -39,7 +41,7 @@
> SUB_LIST=LLVM_PREFIX="${LLVM_PREFIX}" LLVM_SUFFIX="${LLVM_SUFFIX}"
> CMAKE_INSTALL_PREFIX= ${LLVM_PREFIX}
> -CMAKE_ARGS= -DLLVM_BUILD_LLVM_DYLIB=ON
> +CMAKE_ARGS= -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON
>
> Could you review/commit it, and check if other LLVM ports could
> also benefit from it? Thanks,
It's been a few years since we disabled it so I don't remember the
details of the decision. I'll look into it, but am not in a position
to test for breakage to other ports. IIRC there were once ports that
failed to build both with and without so it may be that we need to wait
for flavors to make this change.
-- Brooks
signature.asc
Description: PGP signature
Re: make ports use system clang & llvm
On Fri, Oct 06, 2017 at 11:10:58PM +0100, tech-lists wrote: > Hello, > > Is there a way to make ports use system clang & llvm (now at v5) rather than > pulling in llvm4? If so, please tell me what it is! Short verison: no. Longer version: Ports that depend on a specific LLVM version typically do so because they link to LLVM libraries. LLVM provides *no* API stability between releases so programs can only link to a narrow range of LLVM versions (1 version is common) and we can not ship the libraries with the base system because we would then be stuck with a single LLVM and clang version for the life of a STABLE branch (usually 5+ years). -- Brooks signature.asc Description: PGP signature
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote: > On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote: > > > > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > >> On 26 Mar 2017, at 23:36, Mark Millard wrote: > >>> ... > >>> Also interesting was: > >>> > >>> Installed packages to be REMOVED: > >>> llvm40-4.0.0.r4 > >>> > >>> Number of packages to be removed: 1 > >>> > >>> The operation will free 49 GiB. > >> > >> Yes, this is big. But there is no real need to build the llvm ports > >> with debug information, unless you want to hack on llvm itself. > > > > Cc'ing jmd@ and rezny@. > > > > I've been watching increasing size of our LLVM packages with increasing > > worry. This is from my tinderbox cache: > > > > $ % env LANG=C ls -lh llvm3* > > -rw-r--r-- 1 root wheel17M Jan 29 2016 llvm35-3.5.2_1.txz > > -rw-r--r-- 1 root wheel18M Mar 7 2016 llvm36-3.6.2_2.txz > > -rw-r--r-- 1 root wheel27M Feb 28 01:05 llvm37-3.7.1_4.txz > > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > > > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? > > Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY > parts, with separate ports for e.g. compiler-rt and other LLVM projects. It's mostly that we build both shared and static libraries. llvm37 merged clang and llvm (with a clang37 metaport). Dynamic builds were broken for a while too which blew up program size. > > They take lots of time to build and package. And given that llvm > > is indirect dependency of any X11-related port, it pessimises their > > build times as well (devel/libclc now requires devel/llvm40 after > > r437268). > > The previous split looks pretty hard to maintain, so that is most likely > the reason for combining all components in one port after 3.8. > Unfortunately the side effect is that it is way less granular. I kept it up for several revisions past when it was desupported, but it's absolutly impossible with the cmake infrastructure unless we want want to build all of LLVM four times to get clang, llvm, lldb, and lld. I'm pretty sure that would case more complaints. :) > If we ever get infrastructure for generating multiple packages out of > one port, the devel/llvm* ports are very good candidates. :) Very much so. > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > > hardware would just not be capable enough. > > As said, this is because of WITH_DEBUG. Don't use that for the llvm > ports, for now. It will also allow you to build them with much less RAM > in the machine: especially linking can take multiple GB when debuginfo > is enabled, and optimization is off. I'm looking into improving WITH_DEBUG. -- Brooks P.S. Somewhat off topice, but related. FAIR WARNING: the days of self-hosted 32-bit systems are numbered. Switching to lld from our ancient BFD linker will probably buy us some time, but I'd be surprised if you will be able to build LLVM+CLANG with a 2GB address space in 5 years. The sooner people make their peace with this, the better. signature.asc Description: PGP signature
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > >> > >> I upgraded from llvm40 r4 to final. An interesting result was > >> its creation of a backup package for llvm40-4.0.0.r4: > >> > >> about 13 cpu-core-hours running pkg create > >> > >> (Remember: I've been building with WITH_DEBUG= ) Its > >> single-threaded status stands out via elapsed time > >> approximately matching. > >> > >> I'll note that it was somewhat under 6 elapsed hours for > >> staging to have been populated (-j4 with 4 cores present > >> helps for this part). > >> > >> (Of course these elapsed-time figures are rather system > >> dependent, although the ratio might be more stable.) > >> > >> > >> > >> Also interesting was: > >> > >> Installed packages to be REMOVED: > >>llvm40-4.0.0.r4 > >> > >> Number of packages to be removed: 1 > >> > >> The operation will free 49 GiB. > > > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. And > > in that case, you are better served by a Subversion checkout or Git > > clone from upstream instead. > > > > -Dimitry > > FYI: > > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. > > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG= . > I'm more concerned with the time it takes than with > the file system space involved. In the case of LLVM, enabling debug builds does a LOT more than adding symbols. It's much more like enabling WITNESS and INVARIANTS in your kernel, except that the performance of the resulting binary is much worse than a WITNESS kernel (more like 10x slowdown). As Dimitry points out, these builds are of questionable value in ports so garbage collecting the knob might be the sensable thing to do. -- Brooks signature.asc Description: PGP signature
Re: hard links in llvm39 and binutils
On Thu, Jan 26, 2017 at 10:18:19AM -0800, j...@theusgroup.com wrote: > In your message you wrote: > > ... > >On Wed, Jan 25, 2017 at 10:54:27PM -0800, john--- via freebsd-ports > >wrote: > Both llvm39 and binutils failed to install recently because > >they both have > hard links that cross directories. On this machine, > >those directories, both > in /usr/local on on different zfs filesystems. > >> > I've had this directory structure for several years without issue, > >so this use > of hard links is new. > > Is this use of hard links > >something I should expect to see looking forward or > is it an error? > > > >Some cross directory hardlinks in llvm## have been around since at least > >October 2013. Without a specific example I can't say more. > > > >-- Brooks > > > > Here's one example: > > # ls -il /usr/ports/devel/llvm39/work/stage/usr/local/llvm39/bin/lit > 4797459 -r-xr-xr-x 4 root wheel 82 Jan 24 10:17 lit > > # ls -il /usr/ports/devel/llvm39/work/stage/usr/local/bin/llvm-lit39 > 4797459 -r-xr-xr-x 4 root wheel 82 Jan 24 10:17 llvm-lit39 > > As I stated above llvm37 and the previous version of binutils both installed > without issue. > > # pkg info llvm\* > llvm33-3.3_10 > llvm34-3.4.2_1 > llvm35-3.5.2 > llvm36-3.6.2_2 > llvm37-3.7.1_3 > > # pkg info llvm37 > Name : llvm37 > Version: 3.7.1_3 > Installed on : Fri Sep 23 09:09:32 2016 PDT > Origin : devel/llvm37 > Architecture : freebsd:10:x86:64 > Prefix : /usr/local > Categories : devel lang > Licenses : > Maintainer : bro...@freebsd.org > WWW: http://llvm.org/ > Comment: LLVM and Clang > Options: > CLANG : on > COMPILER_RT: on > DOCS : off > EXTRAS : on > GOLD : on > LIT: on > > Checking /usr/local/llvm37/bin shows no file named "lit", so I assume these > hard links came with files that didn't exist in llvm37. > > John Theus > TheUs Group > LLD: on > LLDB : on > OPENMP : on > I can only guess that you don't have them because an older version of pkg failed to tell you that they weren't installed because llvm37 definitely does create such a link in the port. Something has definitely gone wrong on your system, but I'm at a lost a to what it it. Here's what I'd expect to see: $ ls -li /usr/local/bin/*lit*37 /usr/local/llvm37/bin/*lit* 1580744 -r-xr-xr-x 4 root wheel 82 Dec 27 05:29 /usr/local/bin/lit37 1580744 -r-xr-xr-x 4 root wheel 82 Dec 27 05:29 /usr/local/bin/llvm-lit37 1580744 -r-xr-xr-x 4 root wheel 82 Dec 27 05:29 /usr/local/llvm37/bin/lit 1580744 -r-xr-xr-x 4 root wheel 82 Dec 27 05:29 /usr/local/llvm37/bin/llvm-lit That being said, I could switch them to symlinks. In general I don't like this as a precedent. I'm definitely not willing to support arbitrary filesystem hierarchies so if we're going to do this, we need some sort of principles for splits that we're willing to support. -- Brooks signature.asc Description: PGP signature
Re: hard links in llvm39 and binutils
On Wed, Jan 25, 2017 at 10:54:27PM -0800, john--- via freebsd-ports wrote: > Both llvm39 and binutils failed to install recently because they both have > hard links that cross directories. On this machine, those directories, both > in /usr/local on on different zfs filesystems. > > I've had this directory structure for several years without issue, so this use > of hard links is new. > > Is this use of hard links something I should expect to see looking forward or > is it an error? Some cross directory hardlinks in llvm## have been around since at least October 2013. Without a specific example I can't say more. -- Brooks signature.asc Description: PGP signature
Re: clang support for compiler:openmp
On Mon, Nov 07, 2016 at 10:12:59PM +0100, Matthieu Volat wrote: > On Mon, 7 Nov 2016 16:59:36 + > Brooks Davis wrote: > > > On Sun, Nov 06, 2016 at 08:36:22AM +0100, Marcus von Appen wrote: > > > Hi, > > > > > > is there a specific reason, why we do not (yet) have openmp support for > > > clang via compiler:openmp? With devel/openmp in the ports tree, I'd > > > expect compiler:openmp to set > > > > > > LIB_DEPENDS+= libomp.so:devel/openmp > > > > > > for compiler=clang. CFLAGS and LIBS/LDFLAGS might be tweaked on a > > > per-port level. > > > > I talked with Baptiste about this in Belgrade. I think the best way > > forward would be to remove the OPENMP option from the llvm ports and > > alter the clang-patch-fopenmp.diff patch to use the .so from > > devel/openmp. > > > > I have a major deadline at the end of the week so it definitely won't > > happen this week. > > > > Would not that make that every clang use the llvm 3.8 libomp snapshot? It > might be useful to use later versions in some cases, but anyway, that would > be great! It would mean sticking to a single version, but I'd be pretty surprised if mixing them ended well so that's probably for the best. > It would also be awesome if base clang would be able to find omp.h and libomp > more "out of the box" once the package is installed... libomp is pretty easy once I realized I needed to hardcode the path to the .so, I'll have to see what's involved for omp.h. -- Brooks signature.asc Description: PGP signature
Re: clang support for compiler:openmp
On Sun, Nov 06, 2016 at 08:36:22AM +0100, Marcus von Appen wrote: > Hi, > > is there a specific reason, why we do not (yet) have openmp support for > clang via compiler:openmp? With devel/openmp in the ports tree, I'd > expect compiler:openmp to set > > LIB_DEPENDS+= libomp.so:devel/openmp > > for compiler=clang. CFLAGS and LIBS/LDFLAGS might be tweaked on a > per-port level. I talked with Baptiste about this in Belgrade. I think the best way forward would be to remove the OPENMP option from the llvm ports and alter the clang-patch-fopenmp.diff patch to use the .so from devel/openmp. I have a major deadline at the end of the week so it definitely won't happen this week. -- Brooks signature.asc Description: PGP signature
Re: 398 out of 1025 ports failed because of llvm37 compilation error
On Sat, Oct 22, 2016 at 05:44:39PM +, Grzegorz Junka wrote: > > On 22/10/2016 16:04, Grzegorz Junka wrote: > > How to fix it? > > > > [00:52:02] >> [02][00:42:43] Finished build of devel/llvm37: > > Failed: build > > > > Exception occurred: > > File "/usr/local/lib/python2.7/site-packages/sphinx/environment.py", > > line 1261, in get_doctree > > doctree = pickle.load(f) > > EOFError > > The full traceback has been saved in /tmp/sphinx-err-naeTZg.log, if > > you want to report the issue to the developers. > > Disabling the documentation helped which probably means something is > wrong in that part of the port. There's a known, hard to reproduce, race condition in sphinx. Trying again generally works. :( -- Brooks ___ 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 build fail, FreeBSD 10.3
On Sun, Sep 11, 2016 at 12:30:59PM +0100, Dave wrote: > building llvm37 from ports (via portupgrade), fails on at least 10.3 > > Requires re2c and ninja but neither are pulled in, build fails unless > manually installed first. Something is seriously out of wack with portupgrade or perhaps your ports tree. I don't portupgrade any more so can't really do much to diagnose this problem without a log (and I'm not really sure what I'd do with one). llvm37/Makefile includes USES=ninja which causes ninja to be a build depend. Off hand, the only way I could see that not happening is of something was wrong with Mk/Uses/ninja.mk. -- Brooks signature.asc Description: PGP signature
Re: Help with making a port C11 compliant
On Fri, May 06, 2016 at 04:16:54PM +, Montgomery-Smith, Stephen wrote: > Here is my problem: > http://beefy2.nyi.freebsd.org/data/93amd64-default/414631/logs/GiNaC-1.7.0.log > > the configure script says: > configure: error: Standard ISO C++ headers are missing > > In the Makefile I have the line: > USES= compiler:c++11-lang > > Is there anything else I need to do? I should add that seems to be a > FreeBSD-9 only problem - it builds fine on FreeBSD-10 and higher. You may need compiler:c++11-lib to get a standard library. That said, compiler:c++11-lib doesn't actually result in a fully functional C++11 environment on 9.x so you may need to abandon the port on 9.x. -- Brooks signature.asc Description: PGP signature
Re: head / poudriere && devel/llvm37 Killing timed out build after 86400 seconds
On Tue, May 03, 2016 at 02:46:15PM +0200, Matthias Apitz wrote: > El d??a Tuesday, May 03, 2016 a las 10:11:44AM +0100, Bob Eager escribi??: > > > I was forced to build llvm37 without documentation. It worked then. > > My poudriere oven at home is a Dell M4400 with 2 CPUs and 4 GB RAM. I > have built devel/llvm37 right now outside of poudriere in some VM on the same > system as the jail, but DOCS disabled. The build of the the package took > around 90 minutes. The VM has only 3 GB RAM. > > I'm now a bit confused. > > I will re-run the single port in my poudriere oven, as well with DOCS > disabled, and report back. 3GB is likely enough if nothing else is going on and you're not presenting more than one virtual CPU. With two CPUs and other builds going on, you're likely swapping which is going to hurt even more in a vm. You might consider turning off OPTIONS you don't need beyond doc (in particular LLDB is large and hard for our ancient linker to link). -- Brooks P.S. build time on a lightly loaded 24-core machine with SSD and 256GB of RAM exceeds 10 minutes and performs several GB of disk IO so taking more than a day seems long, but not completely implausible on your system. signature.asc Description: PGP signature
Re: Pulling from github as a vendorized dependency in poudriere
On Fri, Feb 19, 2016 at 07:13:04AM -0500, Derek (freebsd lists) wrote: > Hi, > > I'm attempting to port a project over, and it is dependent on a > "vendorizing" program, which then pulls in the source of the > dependencies to build. (The final artifact is statically linked, > so there shouldn't be a problem as far as installing unversioned > libraries outside of the package/ports framework, for example.) > > My port works fine in my local ports tree, and also I can build > the project by hand without the port no problem. > > When I try to use poudriere testport, and it's time to pull in > the dependencies (as part of a build step), I get: > > fatal: unable to access 'https://github.com/foo/bar': Couldn't > connect to server > > Is there something in poudriere that makes the network special? > i.e. do build scripts not have network access in that context? > > I can provide more specifics on my project: > > - The vendorizing program is "gb vendor" > - I have PATCH_DEPENDS on gb, and git > - The pre-patch step runs `make deps`, a target which ultimately > runs `gb vendor restore`, the step that gives the error message, > and the build fails > > I can provide more detail, but would like to know if I'm doing > something horribly wrong first (i.e. trying to access the network > with gb as a make target, versus some other way to do this). When you run "gb vendor", what stage does that happen in? IIRC poudriere only configures network access during the fetch stage so you must find a way to run it as part of the fetch process or capture and emulate its result. -- Brooks signature.asc Description: PGP signature
Re: error upgrading graphics/dri port "/usr/local/llvm36/bin/clang: not found"
On Sun, Jan 17, 2016 at 07:08:14PM +1100, Graham Menhennitt wrote: > Does anybody have any clues, please? > > Thanks, > Graham > > root@starker# uname -a > FreeBSD starker 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r294103: Sun Jan > 17 13:26:05 AEDT 2016 > gfm@starker:/usr/obj/usr/data/FreeBSD/src_11-Current/sys/starker amd64 > root@starker# ll /usr/local/llvm36/bin > total 22384 > -rwxr-xr-x 1 root wheel277720 Jan 6 19:54 bugpoint > -rwxr-xr-x 1 root wheel 18292472 Sep 25 07:49 clang-cpp > -rwxr-xr-x 1 root wheel 7288 Jan 6 19:53 count > -r-xr-xr-x 2 root wheel220280 Jan 6 19:54 FileCheck > -r-xr-xr-x 4 root wheel82 Jan 6 19:54 lit > -rwxr-xr-x 1 root wheel117368 Jan 6 19:54 llc > -rwxr-xr-x 1 root wheel 96128 Jan 6 19:54 lli > -rwxr-xr-x 1 root wheel 14648 Jan 6 19:54 lli-child-target > -rwxr-xr-x 1 root wheel 58200 Jan 6 19:54 llvm-ar > -rwxr-xr-x 1 root wheel 16960 Jan 6 19:54 llvm-as > -rwxr-xr-x 1 root wheel 46088 Jan 6 19:54 llvm-bcanalyzer > -rwxr-xr-x 1 root wheel 91416 Jan 6 19:54 llvm-config > -rwxr-xr-x 1 root wheel 92552 Jan 6 19:54 llvm-cov > -rwxr-xr-x 1 root wheel 49200 Jan 6 19:54 llvm-diff > -rwxr-xr-x 1 root wheel 20432 Jan 6 19:54 llvm-dis > -rwxr-xr-x 1 root wheel 32992 Jan 6 19:54 llvm-dsymutil > -rwxr-xr-x 1 root wheel 24888 Jan 6 19:54 llvm-dwarfdump > -rwxr-xr-x 1 root wheel 33008 Jan 6 19:54 llvm-extract > -rwxr-xr-x 1 root wheel 24904 Jan 6 19:54 llvm-link > -r-xr-xr-x 4 root wheel82 Jan 6 19:54 llvm-lit > -rwxr-xr-x 1 root wheel 74560 Jan 6 19:54 llvm-mc > -rwxr-xr-x 1 root wheel 18072 Jan 6 19:54 llvm-mcmarkup > -rwxr-xr-x 1 root wheel 79432 Jan 6 19:54 llvm-nm > -rwxr-xr-x 1 root wheel244848 Jan 6 19:54 llvm-objdump > -rwxr-xr-x 1 root wheel 46400 Jan 6 19:54 llvm-profdata > lrwxr-xr-x 1 root wheel 7 Jan 6 19:54 llvm-ranlib -> llvm-ar > -rwxr-xr-x 1 root wheel314824 Jan 6 19:54 llvm-readobj > -rwxr-xr-x 1 root wheel 52520 Jan 6 19:54 llvm-rtdyld > -rwxr-xr-x 1 root wheel 64744 Jan 6 19:54 llvm-size > -rwxr-xr-x 1 root wheel 64640 Jan 6 19:54 llvm-stress > -rwxr-xr-x 1 root wheel 64736 Jan 6 19:54 llvm-symbolizer > -rwxr-xr-x 1 root wheel 1622424 Jan 6 19:53 llvm-tblgen > -rwxr-xr-x 1 root wheel 39064 Jan 6 19:54 llvm-vtabledump > -rwxr-xr-x 1 root wheel 36944 Jan 6 19:54 macho-dump > -rwxr-xr-x 1 root wheel 41112 Jan 6 19:53 not > -rwxr-xr-x 1 root wheel 47168 Jan 6 19:54 obj2yaml > -rwxr-xr-x 1 root wheel302320 Jan 6 19:54 opt > -rwxr-xr-x 1 root wheel 34264 Jan 6 19:54 verify-uselistorder > -rwxr-xr-x 1 root wheel 66032 Jan 6 19:54 yaml2obj > root@starker# pkg info|grep llvm > llvm36-3.6.2_2 Low Level Virtual Machine > root@starker# portupgrade -aWw > [Reading data from pkg(8) ... - 854 packages found - done] > ---> Upgrading 'dri-11.0.7_1,2' to 'dri-11.0.8,2' (graphics/dri) > ---> Building '/usr/ports/graphics/dri' > ===> dri-11.0.8,2 depends on executable: makedepend - found > ===> dri-11.0.8,2 depends on package: libclc>=0.0.r222830 - not found > ===> Building for libclc-0.1.0.20150710 > [8/979] LLVM-CC r600--/lib/math/mad.cl.cedar.bc > FAILED: /usr/local/llvm36/bin/clang -MMD -MF > r600--/lib/math/mad.cl.cedar.bc.d -target r600-- -I`dirname > generic/lib/math/mad.cl` -Igeneric/include -fno-builtin > -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 > -D__CLC_INTERNAL -emit-llvm -mcpu=cedar -c -o > r600--/lib/math/mad.cl.cedar.bc generic/lib/math/mad.cl > /bin/sh: /usr/local/llvm36/bin/clang: not found > [8/979] LLVM-CC r600--/lib/math/tables.cl.cedar.bc > FAILED: /usr/local/llvm36/bin/clang -MMD -MF > r600--/lib/math/tables.cl.cedar.bc.d -target r600-- -I`dirname > generic/lib/math/tables.cl` -Igeneric/include -fno-builtin > -Dcl_clang_storage_class_specifiers -Dcl_khr_fp64 -Dcles_khr_int64 > -D__CLC_INTERNAL -emit-llvm -mcpu=cedar -c -o > r600--/lib/math/tables.cl.cedar.bc generic/lib/math/tables.cl > /bin/sh: /usr/local/llvm36/bin/clang: not found > ... You appear not to have lang/clang36 installed. I don't know why portupgrade isn't installing it since it is a BUILD_DEPEND of graphics/dri, but installing it by hand should work around the problem. -- Brooks signature.asc Description: PGP signature
Re: llvm37 python3 problem
On Tue, Oct 27, 2015 at 11:03:07AM +, loic.b...@unix-experience.fr wrote: > Any news for this problem ? Upstream does not yet support python 3 so it remain broken. I've not yet had time to see if I can force the use of 2.7 when building. Simple changes haven't worked. You can work around this by disabling the LLDB option when building. -- Brooks > 12 octobre 2015 19:50 "Brooks Davis" a ??crit: > > On Fri, Oct 09, 2015 at 04:38:57PM +0200, Walter Schwarzenfeld wrote: > > > >> Can't test the patch in the above link, cause the port ignores python > >> 3.4 and I don't want deinstall python 2.7. > > > > I've figured out how to reconfigure poudriere to be able to test this. > > Several other files need this sort of fix. I've managed to fix some > > with patches from upstream, but it appears that lldb is incompatible > > with python 3. The C code is using obsolete interfaces and doesn't > > compile. > > > > -- Brooks > signature.asc Description: PGP signature
Re: 9.3 to 10.2 migration, determining if clang is used
On Tue, Oct 13, 2015 at 11:13:11AM -0700, Patrick Powell wrote: > I just started doing a 9.3 to 10.2 migration of a bunch of applications > and discovered that some of the options used > to generate the applications were slightly different. I just know that > this has been covered before, but I could not > find a definitive method or set of methods to use to determine if the > old GCC compiler or the new CLANG compiler > is being used. Could the ports wizards (and/or autoconf experts) help > me a bit? > > (Aside: the clang compiler diagnostics and warnings are very thorough > and quite clear. Nicely done, especially > the addition of the information about the flag to turn this warning > off. I also like the pragmas to > control warnings and the push/pop pragma facility. This may have been > in the GCC compiler but I missed it.) > > 1. If the application is to be generated via the PORT infrastructure, > what do you > put in the port Makefile to determine if CLANG (10.2) or GCC (9.3) > is being used? > > > Something like below. Note: the examples below are a bit contrived, > but the idea is to set > some MAKE variable to different values depending on CLANG or GCC in use. > > .if defined(CC_IS_CLANG) > MYFLAGS+= -Wall -Werror -Wno-error=unused > .else > .if defined(CC_IS_GCC) > MYFLAGS+= -Wall -Werror -Wno-unused > .endif > .endif For ports, I think you are looking for USES=compiler:features (see ports/Mk/Uses/compiler.mk). I don't know the answer for autoconf. -- Brooks signature.asc Description: PGP signature
Re: llvm37 python3 problem
On Fri, Oct 09, 2015 at 04:38:57PM +0200, Walter Schwarzenfeld wrote: > Can't test the patch in the above link, cause the port ignores python > 3.4 and I don't want deinstall python 2.7. I've figured out how to reconfigure poudriere to be able to test this. Several other files need this sort of fix. I've managed to fix some with patches from upstream, but it appears that lldb is incompatible with python 3. The C code is using obsolete interfaces and doesn't compile. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm36/plist has 2 non existant files
On Wed, Sep 23, 2015 at 12:18:48AM +0200, Julian H. Stacey wrote: > Brooks Davis wrote: > > Content-Transfer-Encoding: quoted-printable > > > > On Tue, Sep 22, 2015 at 05:10:06PM +0200, Julian H. Stacey wrote: > > >=20 > > > Brooks Davis wrote: Mon, 21 Sep 2015 21:21:30 + > > > > Content-Transfer-Encoding: quoted-printable > > > >=20 > > > > On Mon, Sep 21, 2015 at 01:30:54AM +0200, Julian H. Stacey wrote: > > > > > Hi bro...@freebsd.org, > > > > > cc: po...@freebsd.org > > > > >=3D20 > > > > > with current devel/llvm36 > > > > > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12135:= > > Thu=3D > > > > Sep 17 14:54:15 CEST 2015 > > > > j...@lapr.js.berklix.net:/usr/src/sys/amd= > > 64/c=3D > > > > ompile/LAPR.small amd64 > > > > >=3D20 > > > > > make install > > > > > =3D3D=3D3D=3D3D> Installing for llvm36-3.6.2_2 > > > > > =3D3D=3D3D=3D3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/pyt= > > hon2.7 - f=3D > > > > ound > > > > > =3D3D=3D3D=3D3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/per= > > l5.20.2 - =3D > > > > found > > > > > =3D3D=3D3D=3D3D> llvm36-3.6.2_2 depends on shared library: libedit.= > > so.0 - fou=3D > > > > nd (/usr/local/lib/libedit.so.0) > > > > > actual-package-depends: dependency on /usr/local/bin/perl5.20.2 not r= > > egis=3D > > > > tered (normal if it belongs to base) > > > > > =3D3D=3D3D=3D3D> Registering installation for llvm36-3.6.2_2 > > > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/port= > > s/de=3D > > > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js:= > > No =3D > > > > such file or directory > > > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/port= > > s/de=3D > > > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.= > > js: =3D > > > > No such file or directory > > > > > *** Error code 74 > > > > >=3D20 > > > > > I've started a remake with this: > > > > > - > > > > > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/jhs/devel/llvm36/= > > pkg-=3D > > > > plist.REL=3D3D11.0-CURRENT.diff > > > > >=3D20 > > > > > Mon Sep 21 00:41:55 CEST 2015 > > > > >=3D20 > > > > > There is no jquery-1.11.1.js underscore-1.3.1.js > > > > >=3D20 > > > > > *** 11.0-CURRENT/ports/devel/llvm36/pkg-plist Mon Sep 21 00:27:44 2015 > > > > > --- new-generic/ports/devel/llvm36/pkg-plist Mon Sep 21 00:29:40 2015 > > > > > *** > > > > > *** 1052,1058 > > > > > %%PORTDOCSDOCSDIR%%/html/genindex.html > > > > > %%PORTDOCSDOCSDIR%%/html/index.html > > > > > %%PORTDOCSDOCSDIR%%/html/index.txt > > > > > - %%PORTDOCSDOCSDIR%%/html/jquery-1.11.1.js > > > > > %%PORTDOCSDOCSDIR%%/html/jquery.js > > > > > %%PORTDOCSDOCSDIR%%/html/lines.gif > > > > > %%PORTDOCSDOCSDIR%%/html/linpack-pc.png > > > > > --- 1052,1057 > > > > > *** > > > > > *** 1109,1115 > > > > > %%PORTDOCSDOCSDIR%%/html/searchtools.js > > > > > %%PORTDOCSDOCSDIR%%/html/tblgen.html > > > > > %%PORTDOCSDOCSDIR%%/html/tblgen.txt > > > > > - %%PORTDOCSDOCSDIR%%/html/underscore-1.3.1.js > > > > > %%PORTDOCSDOCSDIR%%/html/underscore.js > > > > > %%PORTDOCSDOCSDIR%%/html/up-pressed.png > > > > > %%PORTDOCSDOCSDIR%%/html/up.png > > > > > --- 1108,1113 > > > >=20 > > > > These appeared at some point on package builders. At the time it didn't > > > > appear on my build systems unless I used poudriere. Now they always > > > > appear. I suspect this is due to a change in the upstream sphinx > > > > version, but I've not investigated sufficiently to add an appropriate > > > > version dependency. > > > >=20 > > > > -- Brooks > > >=20 > > > They break the build on my non poudriere system. Patched out, the make w= > > orks. > > > I'd suggest/request yo
Re: devel/llvm36/plist has 2 non existant files
On Tue, Sep 22, 2015 at 05:10:06PM +0200, Julian H. Stacey wrote: > > Brooks Davis wrote: Mon, 21 Sep 2015 21:21:30 + > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Sep 21, 2015 at 01:30:54AM +0200, Julian H. Stacey wrote: > > > Hi bro...@freebsd.org, > > > cc: po...@freebsd.org > > >=20 > > > with current devel/llvm36 > > > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12135: Thu= > > Sep 17 14:54:15 CEST 2015 > > j...@lapr.js.berklix.net:/usr/src/sys/amd64/c= > > ompile/LAPR.small amd64 > > >=20 > > > make install > > > =3D=3D=3D> Installing for llvm36-3.6.2_2 > > > =3D=3D=3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/python2.7 - f= > > ound > > > =3D=3D=3D> llvm36-3.6.2_2 depends on file: /usr/local/bin/perl5.20.2 - = > > found > > > =3D=3D=3D> llvm36-3.6.2_2 depends on shared library: libedit.so.0 - fou= > > nd (/usr/local/lib/libedit.so.0) > > > actual-package-depends: dependency on /usr/local/bin/perl5.20.2 not regis= > > tered (normal if it belongs to base) > > > =3D=3D=3D> Registering installation for llvm36-3.6.2_2 > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/ports/de= > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js: No = > > such file or directory > > > pkg-static: Unable to access file /data/release/11.0-CURRENT/usr/ports/de= > > vel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.js: = > > No such file or directory > > > *** Error code 74 > > >=20 > > > I've started a remake with this: > > > - > > > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/jhs/devel/llvm36/pkg-= > > plist.REL=3D11.0-CURRENT.diff > > >=20 > > > Mon Sep 21 00:41:55 CEST 2015 > > >=20 > > > There is no jquery-1.11.1.js underscore-1.3.1.js > > >=20 > > > *** 11.0-CURRENT/ports/devel/llvm36/pkg-plist Mon Sep 21 00:27:44 2015 > > > --- new-generic/ports/devel/llvm36/pkg-plist Mon Sep 21 00:29:40 2015 > > > *** > > > *** 1052,1058 > > > %%PORTDOCSDOCSDIR%%/html/genindex.html > > > %%PORTDOCSDOCSDIR%%/html/index.html > > > %%PORTDOCSDOCSDIR%%/html/index.txt > > > - %%PORTDOCSDOCSDIR%%/html/jquery-1.11.1.js > > > %%PORTDOCSDOCSDIR%%/html/jquery.js > > > %%PORTDOCSDOCSDIR%%/html/lines.gif > > > %%PORTDOCSDOCSDIR%%/html/linpack-pc.png > > > --- 1052,1057 > > > *** > > > *** 1109,1115 > > > %%PORTDOCSDOCSDIR%%/html/searchtools.js > > > %%PORTDOCSDOCSDIR%%/html/tblgen.html > > > %%PORTDOCSDOCSDIR%%/html/tblgen.txt > > > - %%PORTDOCSDOCSDIR%%/html/underscore-1.3.1.js > > > %%PORTDOCSDOCSDIR%%/html/underscore.js > > > %%PORTDOCSDOCSDIR%%/html/up-pressed.png > > > %%PORTDOCSDOCSDIR%%/html/up.png > > > --- 1108,1113 > > > > These appeared at some point on package builders. At the time it didn't > > appear on my build systems unless I used poudriere. Now they always > > appear. I suspect this is due to a change in the upstream sphinx > > version, but I've not investigated sufficiently to add an appropriate > > version dependency. > > > > -- Brooks > > They break the build on my non poudriere system. Patched out, the make works. > I'd suggest/request you comment them out until its resolved if needed, > & if so, why not generated. Given the choice between working package builds and working in arbitrary ports configuraiton I'll choose packages. I had hope the issues was transient, but apparently not so I'll try to find a solution. Could you tell me what version of textproc/py-sphinx you have installed? -- Brooks pgpJDs7CCO8zv.pgp Description: PGP signature
Re: devel/llvm36/plist has 2 non existant files
On Mon, Sep 21, 2015 at 01:30:54AM +0200, Julian H. Stacey wrote: > Hi bro...@freebsd.org, > cc: po...@freebsd.org > > with current devel/llvm36 > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12135: Thu Sep > 17 14:54:15 CEST 2015 > j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 > > make install > ===> Installing for llvm36-3.6.2_2 > ===> llvm36-3.6.2_2 depends on file: /usr/local/bin/python2.7 - found > ===> llvm36-3.6.2_2 depends on file: /usr/local/bin/perl5.20.2 - found > ===> llvm36-3.6.2_2 depends on shared library: libedit.so.0 - found > (/usr/local/lib/libedit.so.0) > actual-package-depends: dependency on /usr/local/bin/perl5.20.2 not > registered (normal if it belongs to base) > ===> Registering installation for llvm36-3.6.2_2 > pkg-static: Unable to access file > /data/release/11.0-CURRENT/usr/ports/devel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js: > No such file or directory > pkg-static: Unable to access file > /data/release/11.0-CURRENT/usr/ports/devel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.js: > No such file or directory > *** Error code 74 > > I've started a remake with this: > - > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/jhs/devel/llvm36/pkg-plist.REL=11.0-CURRENT.diff > > Mon Sep 21 00:41:55 CEST 2015 > > There is no jquery-1.11.1.js underscore-1.3.1.js > > *** 11.0-CURRENT/ports/devel/llvm36/pkg-plist Mon Sep 21 00:27:44 2015 > --- new-generic/ports/devel/llvm36/pkg-plist Mon Sep 21 00:29:40 2015 > *** > *** 1052,1058 > %%PORTDOCSDOCSDIR%%/html/genindex.html > %%PORTDOCSDOCSDIR%%/html/index.html > %%PORTDOCSDOCSDIR%%/html/index.txt > - %%PORTDOCSDOCSDIR%%/html/jquery-1.11.1.js > %%PORTDOCSDOCSDIR%%/html/jquery.js > %%PORTDOCSDOCSDIR%%/html/lines.gif > %%PORTDOCSDOCSDIR%%/html/linpack-pc.png > --- 1052,1057 > *** > *** 1109,1115 > %%PORTDOCSDOCSDIR%%/html/searchtools.js > %%PORTDOCSDOCSDIR%%/html/tblgen.html > %%PORTDOCSDOCSDIR%%/html/tblgen.txt > - %%PORTDOCSDOCSDIR%%/html/underscore-1.3.1.js > %%PORTDOCSDOCSDIR%%/html/underscore.js > %%PORTDOCSDOCSDIR%%/html/up-pressed.png > %%PORTDOCSDOCSDIR%%/html/up.png > --- 1108,1113 These appeared at some point on package builders. At the time it didn't appear on my build systems unless I used poudriere. Now they always appear. I suspect this is due to a change in the upstream sphinx version, but I've not investigated sufficiently to add an appropriate version dependency. -- Brooks pgpHnf1QleR7_.pgp Description: PGP signature
Re: Does OpenMP (iomp5) work for clang-devel?
On Wed, Aug 05, 2015 at 10:21:26PM +0930, Shane Ambler wrote:
> 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 -L > 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
Hmm, I hadn't tested openmp yet. I had hoped that setting the cmake variable
to default to libomp has sufficient but apparently it isn't. I'd like to get
-fopenmp working on it's own, but probably won't have a whole lot of time to
push this forward.
> 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.
This looks like qtcreator is being too smart for it's own good and is using
two versions of lldb at the same time. That seems likely to not work.
> 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.
You might test with clang-devel first, but submitting this upstream
is a good idea. I don't develop llvm myself so can't do anything
particularly useful with crash reports.
-- Brooks
pgpsVPYbrf3Wl.pgp
Description: PGP signature
Re: svn commit: r392851 - in head: . devel devel/libiomp5-devel devel/llvm-devel devel/llvm-devel/files lang/clang-devel lang/clang-devel/files
On Fri, Jul 24, 2015 at 11:40:10PM +, Brooks Davis wrote: > Author: brooks > Date: Fri Jul 24 23:40:09 2015 > New Revision: 392851 > URL: https://svnweb.freebsd.org/changeset/ports/392851 > > Log: > Mostly complete redo to the build of -devel LLVM ports: >- Switch to cmake. >- Combine all builds into devel/llvm-devel. > - Remove devel/libiomp5-devel > - Make lang/clang-devel a metaport so people can still find it. > > Upgrade a snapshot shortly after the 3.7 branch point. I'm aiming to introduce a devel/llvm37 port next week based on this framework so please test if you anticipate wanting to use 3.7. -- Brooks pgp3mo4NjgjcZ.pgp Description: PGP signature
Re: Does OpenMP (iomp5) work for clang-devel?
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' 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. Simple programs to work if you link with -liomp5 manually. > Is there a compile-time test involved somewhere, perhaps in llvm build? Assuming I manage to include the openmp runtime in the next update, I think it will work and I plan to configure the > Should /usr/local/llvm-devel/lib/ be in /etc/ld.so.conf? (That doesn't > seem to help). ldconfig should be handled correctly by the ports infrastructure. -- Brooks pgpmrEZx_NKOU.pgp Description: PGP signature
Re: mail/postfix default build options request: SASL
On Tue, Jul 07, 2015 at 03:45:53PM +1000, Kubilay Kocak wrote: > On 7/07/2015 3:31 PM, Gregory Orange wrote: > > Hi Olli and ports@, > > > > I don't know if this is a helpful forum to raise it, but I would like to > > request that SASL be enabled in the default build options for > > mail/postfix. I am attempting to use binary-only packages wherever > > possible, and so far this is the first where I currently have to build > > it myself. > > > > I would have thought SASL is in use across many Postfix installations, > > but of course I could be wrong. I was tempted to try out > > SMTP-after-IMAP, but since Postfix has the support, I think SASL is far > > cleaner. > > > > Would any responders please include me in the CC? I am not subscribed to > > the list. > > > > Thanks, > > Greg. > > > > If consensus can't be achieved or there is a good reason not to enable > this by default, then postfix-sasl as a slave port may be a desirable > alternative, which I believe has existed in the past. > > I'm generally: > > +1 on security related options enabled by default > +1 on OPTIONS_DEFAULT matching upstream defaults > -1 on OPTIONS_DEFAULT introducing large dependency sets We need a port that allows dovecot2 SASL by default. There are a bunch of turorials on setting up such systems and all of the have to start with "build everything by hand" which makes us look bad. I've been somewhat tempted to adding a slave port mail/postfix-useful with SASL, TLS, and DANE turned on. A less trollish name might be better though. :) -- Brooks pgpoAoPowNjRp.pgp Description: PGP signature
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
It appears that I added powerpc64 (and several others) to the devel/llvm* ports version of this patch, but didn't do it for lang/clang*. I'll sync them up. -- Brooks On Tue, Mar 17, 2015 at 08:02:47PM -0700, Mark Millard wrote: > patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 entry, such > as illustrated below. > > $ svnlite diff /usr/ports/lang/clang36 > Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > === > --- /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > (revision 381120) > +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > (working copy) > @@ -3,7 +3,7 @@ > > --- utils/llvm-build/llvmbuild/main.py.orig > +++ utils/llvm-build/llvmbuild/main.py > -@@ -633,7 +633,13 @@ > +@@ -633,7 +633,14 @@ > > # We handle a few special cases of target names here for historical > # reasons, as these are the names configure currently comes up with. > @@ -13,6 +13,7 @@ > + 'i386' : 'X86', > + 'mips' : 'Mips', > + 'powerpc' : 'PowerPC', > ++ 'powerpc64' : 'PowerPC', > + 'sparc64' : 'Sparc', > + 'x86' : 'X86', > 'x86_64' : 'X86', > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-16, at 11:00 PM, Mark Millard wrote: > > The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem. > > So this specific problem is powerpc64 specific. > > Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) > works fine. (In absence of any c++ port lang/clang36 automatically installed > lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) > > Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 > already installed first) still reports an error for not declaring ::sscanf, > just like powerpc64 based on gcc5 for bootstrapping did. > > (This might be llvm/clang making use of only where an include of > would be required to be involved in order to guarantee the :: > (global) declaration/definition. The way the C++ standard (all vintages) is > written gcc 4.8.4 and gcc5 could be this different and both be > valid/conforming.) > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-16, at 05:04 PM, Mark Millard wrote: > > Basic context (more context details listed later): > > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 > 19:23:14 PDT 2015 > root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG > powerpc powerpc64 > > > The problem: > > portmaster -tDK --no-confirm lang/clang36 is how I started the build. > > The error report was after it reported entering the directory: > > /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/ > > The report was: > > llvm-build: error: invalid native target: 'powerpc64' (not in project) > > > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 > likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. > > I'll note that with top -PaSCHopid I watched it compile the PowerPc code > generator software: it shoudl be able to handle PowerPCs fine. > > My guess is a conversion of naming conventions is required someplace: > > FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) > > This likely would matter for little endian naming as well (ppc64le on the > clang end of things I expect). > > > > > Context details: > > # svnlite info /usr/ports/lang/clang36 > Path: lang/clang36 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 > Relative URL: ^/head/lang/clang36 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: brooks > Last Changed Rev: 380295 > Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) > > It used gcc5 to bootstrap as there was no clang present and that is the only > gcc port installed: > > # svnlite info /usr/ports/lang/gcc5 > Path: lang/gcc5 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 > Relative URL: ^/head/lang/gcc5 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: gerald > Last Changed Rev: 380943 > Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > #WITH_DEBUG= > MALLOC_PRODUCTION= >
Re: Place of LICENSE_FILE in Makefile
On Fri, Sep 19, 2014 at 08:35:36PM +0200, Fernando Apestegu?a wrote:
> Hi,
>
> I'm facing a situation with a new Makefile.
> I want to set LICENSE_FILE to the location of the license file of the
> distribution. The file is located under ${WRKSRC} that has been set to
> ${WRKDIR}/${GH_ACCOUNT}-${GH_PROJECT}-${GH_COMMIT}
>
> If I use LICENSE_FILE _after_ setting WRKSRC, I get an error from
> portlint. Also, all the GH_* variables need to be set before I can use
> them to point LICENSE_FILE to the proper path, so... in which order
> should I define these variables so portlint doesn't complain?
It should not matter that the variable are not yet defined. Variables
are expanded at point of use not point of assignment.
-- Brooks
pgpZTynPmCCwO.pgp
Description: PGP signature
Re: Updating ports that require cclang33 almost comes to a standstill!
On Mon, Sep 08, 2014 at 05:48:59PM +0200, Leslie Jensen wrote: > > Brooks Davis skrev 2014-07-17 16:10: > > On Thu, Jul 17, 2014 at 02:54:09PM +0200, Leslie Jensen wrote: > >> Dimitry Andric skrev 2014-07-17 00:10: > >>> On 16 Jul 2014, at 11:21, Leslie Jensen wrote: > >>>> Hello list. > >>>> > >>>> I'm experiencing a very slow build of clang33 > >>>> > >>>> It seems that it's when building clang33/work/llvm-3.3 that is slows > >>>> down. > >>>> > >>>> Using top I can see that my system is almost idle, 99,4, and cc1plus has > >>>> two processes using WCPU at 1,80% and 0.10% > >>> cc1plus is actually gcc's C++ compiler, so clang isn't to blame here. :) > >>> Isn't there anything else going on, like linking (look for any 'ld' > >>> processes)? Or is the machine short on RAM (look at swap usage in top)? > >>> > >>> -Dimitry > >>> > >> When the machine is idle these are the values. > >> > >> > >> Mem: 27M Active, 236M Inact, 173M Wired, 10M Cache, 58M Buf, 21M Free > >> > >> > >> Swap: 971M Total, 53M Used, 918M Free, 5% Inuse > > I suspect you need more swap. I'd recommend installing clang33 as a > > binary package. > > > > -- Brooks > > I'm still struggling with this update! I've added memory upp to 1 Gb. > Swap is also 1 Gb. > > The error I get now does not point to shortage of memory or swap space I > think. > > > gmake[2]: Entering directory > `/usr/ports/lang/clang33/work/llvm-3.3.src/tools/clang/unittests/Tooling' > llvm[2]: Compiling CommentHandlerTest.cpp for Release build > llvm[2]: Compiling CompilationDatabaseTest.cpp for Release build > llvm[2]: Compiling RecursiveASTVisitorTest.cpp for Release build > c++: Internal error: Killed: 9 (program cc1plus) > Please submit a full bug report. > See http://gcc.gnu.org/bugs.html> for instructions. > rm: > /usr/ports/lang/clang33/work/llvm-3.3.src/tools/clang/unittests/Tooling/Release/RecursiveASTVisitorTest.d.tmp: > > No such file or directory > gmake[2]: *** > [/usr/ports/lang/clang33/work/llvm-3.3.src/tools/clang/unittests/Tooling/Release/RecursiveASTVisitorTest.o] > > Error 1 > gmake[2]: Leaving directory > `/usr/ports/lang/clang33/work/llvm-3.3.src/tools/clang/unittests/Tooling' > gmake[1]: *** [Tooling/.makeall] Error 2 > gmake[1]: *** Waiting for unfinished jobs > llvm[2]: Linking Release unit test ASTMatchers (without symbols) > llvm[2]: === Finished Linking Release Unit test ASTMatchers (without > symbols) > gmake[2]: Leaving directory > `/usr/ports/lang/clang33/work/llvm-3.3.src/tools/clang/unittests/ASTMatchers' > gmake[1]: Leaving directory > `/usr/ports/lang/clang33/work/llvm-3.3.src/tools/clang/unittests' > gmake: *** [all] Error 1 > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** [do-build] Error code 1 > > Stop in /usr/ports/lang/clang33. > *** [build] Error code 1 > > Stop in /usr/ports/lang/clang33. Please try setting MAKE_JOBS_UNSAFE=yes. Also make sure to check dmesg to see if a reason for the processing being killed. -- Brooks pgpg7bRio62TE.pgp Description: PGP signature
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Thu, Jul 17, 2014 at 11:07:39PM +0200, Baptiste Daroussin wrote:
> On Thu, Jul 17, 2014 at 01:57:52PM -0700, Adrian Chadd wrote:
> > On 17 July 2014 13:54, Baptiste Daroussin wrote:
> > > On Thu, Jul 17, 2014 at 10:21:17PM +0200, Andreas Nilsson wrote:
> > >> On Thu, Jul 17, 2014 at 10:15 PM, Navdeep Parhar
> > >> wrote:
> > >>
> > >> > On 07/17/14 13:12, Adrian Chadd wrote:
> > >> > > On 17 July 2014 13:03, Alberto Mijares wrote:
> > >> > >> On Thu, Jul 17, 2014 at 2:58 PM, Adrian Chadd
> > >> > wrote:
> > >> > >>> Hi!
> > >> > >>>
> > >> > >>> 3) The binary packages need to work out of the box
> > >> > >>> 4) .. which means, when you do things like pkg install apache, it
> > >> > >>> can't just be installed and not be enabled, because that's a bit
> > >> > >>> of a
> > >> > >>> problem;
> > >> > >>
> > >> > >>
> > >> > >> No. Please NEVER do that! The user must be able to edit the files
> > >> > >> and
> > >> > >> start the service by himself.
> > >> > >
> > >> > > Cool, so what's the single line command needed to type in to start a
> > >> > > given package service?
> > >> >
> > >> > Aren't sysrc(8) and service(8) for this kind of stuff?
> > >> >
> > >>
> > >> They sure are.
> > >>
> > >> Well, pkg install $service ; sysrc ${service}_enable="YES" would do.
> > >> Although some services have different names than the packge, which is
> > >> sort
> > >> of annoying.
> > >
> > > Maybe service needs to be extended (seriously sysrc
> > > ${service}_enable="YES" is
> > > not user friendly) we have service -l that list the services, maybe a
> > > service
> > > ${service} on that create /etc/rc.conf.d/${service} with
> > > ${service}_enable="YES"
> > > in it and service ${service} off to remove it
> > >
> > > maybe service -l could also be extended to show the current status (maybe
> > > with a
> > > -v switch)
> > >
> > > but for sure having the service off by default is a good idea :)
> >
> > Yeah, maybe having it populate an entry of service_enable="NO" for now .
>
> then you need to extend rcng to support /usr/local/etc/rc.conf.d so the
> packages
> can install them without touching base :) and we will need to wait for all
> supported FreeBSD version to have the said modification)
Here's a totally untested patch to do that. I was rather surprised that
this wasn't configurable already.
-- Brooks
Index: defaults/rc.conf
===
--- defaults/rc.conf(revision 268825)
+++ defaults/rc.conf(working copy)
@@ -56,6 +56,7 @@
local_startup="/usr/local/etc/rc.d" # startup script dirs.
script_name_sep=" "# Change if your startup scripts' names contain spaces
rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
+rc_conf_dirs="/etc/rc.conf.d /usr/local/etc/rc.conf.d"
# ZFS support
zfs_enable="NO"# Set to YES to automatically mount ZFS file
systems
Index: rc.subr
===
--- rc.subr (revision 268825)
+++ rc.subr (working copy)
@@ -1289,10 +1289,12 @@
fi
_rc_conf_loaded=true
fi
- if [ -f /etc/rc.conf.d/"$_name" ]; then
- debug "Sourcing /etc/rc.conf.d/${_name}"
- . /etc/rc.conf.d/"$_name"
- fi
+ for _dir in ${rc_conf_dirs}; do
+ if [ -f "$_dir"/"$_name" ]; then
+ debug "Sourcing ${_dir}/${_name}"
+ . "$dir"/"$_name"
+ fi
+ done
# Set defaults if defined.
for _var in $rcvar; do
pgp70OxID1KyT.pgp
Description: PGP signature
Re: Updating ports that require cclang33 almost comes to a standstill!
On Thu, Jul 17, 2014 at 02:54:09PM +0200, Leslie Jensen wrote: > > Dimitry Andric skrev 2014-07-17 00:10: > > On 16 Jul 2014, at 11:21, Leslie Jensen wrote: > >> Hello list. > >> > >> I'm experiencing a very slow build of clang33 > >> > >> It seems that it's when building clang33/work/llvm-3.3 that is slows down. > >> > >> Using top I can see that my system is almost idle, 99,4, and cc1plus has > >> two processes using WCPU at 1,80% and 0.10% > > cc1plus is actually gcc's C++ compiler, so clang isn't to blame here. :) > > Isn't there anything else going on, like linking (look for any 'ld' > > processes)? Or is the machine short on RAM (look at swap usage in top)? > > > > -Dimitry > > > > When the machine is idle these are the values. > > > Mem: 27M Active, 236M Inact, 173M Wired, 10M Cache, 58M Buf, 21M Free > > > Swap: 971M Total, 53M Used, 918M Free, 5% Inuse I suspect you need more swap. I'd recommend installing clang33 as a binary package. -- Brooks pgplwcKBuaavY.pgp Description: PGP signature
Re: FreeBSD ports that you maintain require staging updates
On Fri, Jun 13, 2014 at 03:44:54AM -0500, Mark Linimon wrote: > On Fri, Jun 13, 2014 at 09:35:53AM +0900, oyaaji wrote: > > Dear Sir/Madam, > > > > I have received following e-mail. > > However I am not a port maintainer and never was. > > Apparently this was sent to a mailing list: > > > To: v...@freebsd.org There's an argument that since vbox@ isn't a team, but rather an alias for emulation@ that we should reset ports and PRs to reflect that. -- Brooks pgpBzlw3U1XyZ.pgp Description: PGP signature
Re: i386 emacs run-time dependency on gcc?
On Tue, May 06, 2014 at 01:41:10PM -0500, James R. Van Artsdalen wrote: > I realize emacs needs to be built with gcc on i386, but should there be > a run-time dependency too? The emacs package tarball requires gcc to > install. Things built with ports gcc often have dependencies on libraries that are part of the port. For now that means you need the whole complier installed. -- Brooks pgpt96YCqhB9V.pgp Description: PGP signature
Re: Mysterious patches
On Fri, Mar 28, 2014 at 09:47:54PM +0100, A.J. 'Fonz' van Werven wrote:
> Henry Hu wrote:
>
> > They apply to src/raster-png.cxx and src/raster.cxx
>
> Note to self: look inside the actual patch files themselves, it says right
> there which files they apply to *oops*.
>
> However, this does leave me puzzled about the file names. If a patch
> applies to, say, src/foo/bar.c, shouldn't it be called
> files/patch-src__foo__bar.c? This is how it's described in the Porter's
> Handbook. Given a filename such as files/patch-png.cxx I would expect that
> patch to apply to a file ${WRKDIR}/png.cxx.
>
> What am I misunderstanding here?
The rule hasn't been around forever. It's also inappropriate for some
types of patches that apply to multiple files and might be removed
later. The warning patch is a boarderline example of the latter, but I
use the pattern in the clang and llvm ports for patches pulled from the
upstream svn repo.
New ports should follow the rule where it makes sense, but renaming
files used to be annoyingly expensive so older ports were typically left
alone.
-- Brooks
pgpks_BtOv_Dz.pgp
Description: PGP signature
Re: Mysterious patches
On Fri, Mar 28, 2014 at 09:11:21PM +0100, A.J. 'Fonz' van Werven wrote: > Having a look at graphics/libgfx (I'm using that port but it's currently > unmaintained so I might feel like taking maintainership), I noticed that > there are two patches in /usr/ports/graphics/libgfx/files/ *BUT* I can't > for the life of me find the files they are supposed to be applied to. > > Can someone please either clarify what I'm overlooking or confirm that > these patches are superfluous? I can't comment on their usefulness, but the files they apply to are obvious if you understand the patch format. For example files/patch-png.cxx has these lines: --- src/raster-png.cxx.orig 2004-09-27 06:45:31.0 +0200 +++ src/raster-png.cxx 2012-05-04 12:59:52.0 +0200 and it applies to src/raster-png.cxx. The warnings patch applies to several files, just look for the ---/+++ pairs. -- Brooks pgp2wWBNdznsg.pgp Description: PGP signature
Re: CLang flags query:: I'm wanting to port software to FreeBSD
On Wed, Feb 26, 2014 at 06:43:38PM -0500, Joe Nosay wrote: > I've noticed different flags such as -Wno-parentheses and such along with > the -Wno-unused-variable. I would like to know where would be a good source > online to find the flags; and, I would like to know what flags are used by > porters to optimize builds. These will be placed on the Makefile of the > source such that it can be built natively on FreeBSD. I would be able to > test software. There is unfortunately no central reference for Clang warning flags. The closest I've found is http://clang.llvm.org/docs/UsersManual.html#options-to-control-error-and-warning-messages but it omits most of them. Flags of the form -Wno-* disable warnings, usually because the code in question is vendor code we don't want to touch, a mess no one want's to clean up, or both. You should generally avoid them. I'm confused why you talk about optimization in the context of these flags. They have no impact on code generation. -- Brooks pgpmNNrcXGIpw.pgp Description: PGP signature
Re: Integrating Custom Ports
On Tue, Dec 10, 2013 at 12:03:46PM -0500, Rick Miller wrote: > On Tue, Dec 10, 2013 at 11:44 AM, Kris Moore wrote: > > > On 12/10/2013 09:37, Rick Miller wrote: > > > > > > This is my first foray into Ports beyond just installing what is > > available. > > > So, just looking for some feedback from others doing similar. Is there > > > someone that can provide a few pointers in putting together and managing > > > such a system? > > > > > > > Rick, > > > > So the way we've been doing it is with git. > > > > I started by forking the ports tree from here: > > > > https://github.com/freebsd/freebsd-ports/ > > > > After cloning the fork to disk, I added a new "remote" for the original > > ports tree: > > > > % git remote add freebsd https://github.com/freebsd/freebsd-ports.git > > > > I then added any custom ports / patches to our fork. When I want to > > import changes from upstream I just go to my fork and do a new pull: > > > > % git pull freebsd master > > > > Merge any conflicts and commit. > > > > Haha. Thanks, Kris! I was making this harder than it needed to be :) I > appreciate the simple solution! A couple more options: If you won't be modifying the upstream tree, it's quite plausible to merge a local directory into a portsnap managed ports tree using the -l option. For another option, portshaker lets you build custom port's tree from multiple sources. -- Brooks pgpswUVU463te.pgp Description: PGP signature
Re: devel/llvm33 Makefile
I've committed a fix. If you don't need the extra asserts you probably
want to turn them off as they slow things down and break serveral llvm
consumers.
-- Brooks
On Tue, Oct 29, 2013 at 10:15:16PM +, Cary wrote:
> Hello,
>
> On 9.2-RELEASE llvm33-3.3_7 installation failed here:
>
> install -s -o root -g wheel -m 555
> /usr/ports/devel/llvm33/work/llvm-3.3.src/Release/bin/FileCheck
> / /usr/ports/devel/llvm33/work/stage/usr/local/llvm33/bin/
> install: /usr/ports/devel/llvm33/work/llvm-3.3.src/Release/bin/FileCheck: No
> such file or directory
>
> *** [post-install] Error code 71
>
> Stop in /usr/ports/devel/llvm33.
> *** [install] Error code 1
>
> Stop in /usr/ports/devel/llvm33.
>
>
>
> The file to be installed was:
> /usr/ports/devel/llvm33/work/llvm-3.3src/Release+Asserts/bin/FileCheck
>
> After patching Makefile installation succeeded.
> --
> c...@sdf.org
> SDF Public Access UNIX System - http://sdf.org
> 214c214
> < ${INSTALL_PROGRAM} ${WRKSRC}/Release/bin/FileCheck \
> ---
> > ${INSTALL_PROGRAM} ${WRKSRC}/Release+Asserts/bin/FileCheck \
> 226c226
> < TEST_CMD= '(cd ${WRKSRC}/test; ${SETENV} ${MAKE_ENV}
> LD_LIBRARY_PATH=${WRKSRC}/Release/lib ${GMAKE} check-local-lit)'
> ---
> > TEST_CMD= '(cd ${WRKSRC}/test; ${SETENV} ${MAKE_ENV}
> > LD_LIBRARY_PATH=${WRKSRC}/Release+Asserts/lib ${GMAKE} check-local-lit)'
> ___
> 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"
pgpbxPP8MSOEY.pgp
Description: PGP signature
Re: llvm33 update
On Thu, Oct 17, 2013 at 05:57:02AM -0400, Ajtim wrote: > Hi! > > I tried to update llvm33-3.3_4 to llvm33-3.3_5 on FreeBSD 10.0-BETA1 but > I got an error: > > Compressing man pages > ===> Installing ldconfig configuration file > ===> Installing for llvm33-3.3_5 > ===> Checking if devel/llvm33 already installed > ===> Registering installation for llvm33-3.3_5 as automatic > pkg-static: lstat(/usr/ports/devel/llvm33/work/stage/llvm33bin/lit): No > such file or directory pkg-static: > lstat(/usr/ports/devel/llvm33/work/stage/llvm33bin/llvm-lit): No such > file or directory pkg-static: > lstat(/usr/ports/devel/llvm33/work/stage/llvm33bin/FileCheck): No such > file or directory *** Error code 74 Fixed, please try again. I'm still getting the hang of testing with stage. It's much better that before, but my brain hadn't fully registerd the fact that plist changes have no effect until you restage. -- Brooks pgpJQ2YxxoJFd.pgp Description: PGP signature
Re: CLANG 3.3/LLVM 3.3 question regarding devel/llvm vs. devel/llvm33
On Wed, Jul 10, 2013 at 09:32:36AM +0200, O. Hartmann wrote: > > No is 9.1-STABLE en route also equipted with CLANG 3.3, as it is with > CURRENT. The ports system still differs between the "standard" > devel/llvm, which is in fact LLVM 3.2 and devel/llvm33, which is then > LLVM 3.3. > > devel/llvm installs some tools not in the standard manner, like > llvm-config, which is then llvm-config33. This introduces some trouble > and it seems a bit "out of sync". > > Is there a chance that devel/llvm becomes llvm 3.3 in a short time? I'm in the process of moving to devel/llvm## + devel/llvm-devel and removing devel/llvm. As with the lang/gcc* ports all llvm and clang programs will be installed with a ## suffix. This rearrangement is a low priority at work and I needed to set up some internal infrastructure to make testing practical so I've not finished it up yet. -- Brooks pgpz851ML7ISf.pgp Description: PGP signature
dropping maintainership of some ports
Due to a change of jobs I'm planning to drop maintainership of a number of ports I no longer use or have test systems for. If you would like to maintain them, please let me know: databases/nagios-check_postgres_replication net/openmpi net/pypvm net/vncreflector www/trac-addcomment www/trac-discussion www/trac-downloads www/trac-email2trac www/trac-email2trac-postfix www/trac-fivestarvote www/trac-fullblog www/trac-fullblognotification www/trac-graphviz www/trac-iniadmin www/trac-math www/trac-mercurial www/trac-navadd www/trac-pydotorgtheme www/trac-tags www/trac-themeengine www/trac-ticketimport www/trac-vote www/trac-wikitopdf Thanks, Brooks pgpAlLb3i_LzW.pgp Description: PGP signature
Re: llvm-3.2 tarball rerolled?
On Mon, Jan 14, 2013 at 11:26:40AM +0100, Per olof Ljungmark wrote: > On 2013-01-13 16:00, Dimitry Andric wrote: > > On 2013-01-12 22:54, Ion-Mihai Tetcu wrote: > >> I'm seeing this size mismatch, any idea what it is about? > >> > >> root(itetcu)@it/SU >-SSH-> /usr/ports/devel/llvm [23:50:47] 0 > >> # make > >> ===> Found saved configuration for llvm-3.1 > >> => llvm-3.2.src.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > >> => Attempting to fetch http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz > >> fetch: http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz: size > >> mismatch: expected 12275252, actual 12275082 > >> => Attempting to fetch > >> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/llvm-3.2.src.tar.gz > >> fetch: > >> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/llvm-3.2.src.tar.gz: > >> File unavailable (e.g., file not found, no access) > >> => Couldn't fetch it - please try to retrieve this > > > > See the (rather long) thread starting here: > > > >http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/057964.html > > > > Short version: the tarball got re-rolled because somebody noticed an > > obsolete directory in it. Stupid, but probably just a mistake. > > > > The complete difference of the old and new tarballs, extracted: > > > > $ diff -upr llvm-3.2.src-2012-12-21 llvm-3.2.src-2013-01-11 > > Only in llvm-3.2.src-2012-12-21/lib/Target: PTX > > Would it be possible for someone to put the old tarball back? Or are we > going to live with this for the moment? The LLVM project has restored the file after a fair bit of debate. Hopefully this won't happen again. -- Brooks pgpzrk4oRomZh.pgp Description: PGP signature
Re: Dropbox on FreeBSD
On Thu, Dec 20, 2012 at 10:07:05AM -0500, Jerry wrote: > On Thu, 20 Dec 2012 13:45:13 + > Chris Rees articulated: > > > It needs porting to kevent. > > > > Someone may do it for payment, some may do it for fun, but no-one > > will do it for you until you learn some manners. > > > > Or you could do it yourself. > > I have suggested several times that FreeBSD create a fund specifically > for the hiring of professional programmers to take care of these edge > problems. There is such a fund. http://www.freebsdfoundation.org/donate/ -- Brooks pgpz9vDVPXLPH.pgp Description: PGP signature
Re: something had broken in *.mk?
On Wed, Oct 17, 2012 at 02:52:05PM +0200, John Marino wrote: > On 10/17/2012 14:30, Baptiste Daroussin wrote: > > > I don't know much about this, I just know that current is going to use > > bmake, > > and the only incompatibility I have spotted so far from our make to bmake > > is the > > :L becoming :tl and :U becoming :tu > > > > Once 8.3 and 9.0 are EOLed all version of freebsd make support both syntax, > > so > > the ports could safely use both bmake and make (once we change in the ports > > tree > > all the :U and :L occurence.) > > > > which means everything should just continue working ootb for everyone on > > supported version of FreeBSD :) > > > > regards, > > Bapt > > The incompatible "-V" switch causes problems too. There is quite a few > uses of -V in bsd.*.mk. This has been fixed. The behavior of -V is configurable based on a variable in the most recent release and this will be set in sys.mk to preserve the more sensible FreeBSD behavior. -- Brooks pgpSleZqLA7uZ.pgp Description: PGP signature
Re: www/libxul: fails to compile with CLANG and fails to install with GCC
On Wed, Sep 19, 2012 at 03:50:45PM +0200, O. Hartmann wrote: > I already filed a PR (ports/171566) regarding the CLANG compilation > issue, but since CLANG is a troublemaker for several ports, I also used > USE_GCC=4.6 to compile the port www/libxul and this works - but fails > then installing with > > [...] > adding: hyphenation/hyph_hu.dic (deflated 62%) > /usr/ports/www/libxul/work/mozilla-esr10/dist/bin/xpcshell: Undefined > symbol "JSVAL_NULL" > gmake[1]: *** [install] Error 1 > gmake[1]: Leaving directory > `/usr/ports/www/libxul/work/mozilla-esr10/xulrunner/installer' > gmake: *** [install] Error 2 > *** [gecko-pre-install] Error code 2 > > Stop in /usr/ports/www/libxul. > *** [install] Error code 1 Hmm. Sounds like a miscompile. If you're up for an experiment, I'd be interested in the results of applying the linked patch and building with USE_GCC=4.2. http://people.freebsd.org/~brooks/patches/really-use-gcc.diff It turns out that USE_GCC incorrectly assumes that CC/CPP/CXX don't need to be changed when the requested version of gcc is in the base system. -- Brooks pgpILvFJySm9F.pgp Description: PGP signature
Re: Can we please just remove the old Makefile headers?
On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: > The old Makefile headers, ala: > > # New ports collection makefile for:BIND 9.9.x > # Date created: 27 January 2012 > # Whom: dougb > # > # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ > > have not served a purpose for longer than almost anyone who has a ports > commit bit has been around. My proposal is simple, let's remove > everything before the # $FreeBSD$. > > In the past when this has been proposed the objection was that it would > cause too much churn. If we had done this back when we had 5,000 ports > then we would have solved the problem with less churn, and no drama for > the 15,000 ports that followed. Every day we don't do this we make the > "churn" problem worse, and deepen the roots of something that has no > relevance. > > Can we please just deal with this now and be done with it? ... and yes, > I am volunteering to help with and/or do the work myself. Yes please! We've got a nice repository that stores all the data in question much more accurately than a silly header. -- Brooks pgppCJv0YgbyO.pgp Description: PGP signature
Re: port unmaintained since 2005? drop it? misc/gpt*
On Mon, Jun 11, 2012 at 01:45:40AM -0400, Michael Scheidell wrote: > > > On 6/11/12 4:31 AM, per...@pluto.rain.com wrote: > > Dunno what (if anything) they are currently good for, but it seems > > that, at a minimum, the PORTVERSION and/or MASTER_SITES -- and the > > pkg-descr -- need to be updated. > They still don't build. > And, they still aren't need by anything in ports tree (again, globus was > deleted from ports tree in 2008) > > anyone want to maintain them? I'll tag your name on the ports for you. As the person who originally ported and committed them, I say they should be taken out and shot. They were unmaintainable from the start without a significant number of users to drive the upstream to stop making bad decisions. -- Brooks pgpwlwIKa9BIq.pgp Description: PGP signature
Re: Creation of users in ports
On Wed, Dec 07, 2011 at 07:54:07PM +, Chris Rees wrote:
> Hi all,
>
> I'm at a loss as to how to restore functionality for creating (or
> using) customised users in ports. For example, using the old method
> (pkg-install scripts) many ports allowed the user to change the
> username used for the port.
>
> With the new functionality, if the username isn't found in
> /usr/ports/UIDs it's rejected, and the port can't use it.
>
> Can anyone explain to me why it would be a bad idea to include the
> system's passwd and group files in the search? This would allow the
> ports system to accept any user that already exists, as well as
> creating the correct code in the plist.
>
> For example; someone wants to install postgresql as username Fred, so
> s/he sets PG_USER=Fred in /etc/make.conf. Currently this causes an
> error on build, because Fred is not in /usr/ports/UIDs. Were
> /etc/master.passwd and /etc/group searched too, that wouldn't cause a
> problem.
>
> Any obvious oversights?
It seems like a better (but more complicatd) solution would use "getent
passwd ${USER}" to check for existing users. (You need to check
explicitly rather than treating the output without /etc/passwd because
some nss modules don't enumerate to avoid listing the thousands or tens
of thousands of users in a corporate AD or LDAP installation).
-- Brooks
pgp1v1sjlbwRG.pgp
Description: PGP signature
Re: Plan to add a bsd.pure.mk
On Mon, Dec 05, 2011 at 01:28:33AM -0600, Mark Linimon wrote: > I would like to hold off on any more disruptive changes to the tree > until we can get this release out the door. If that means devel/clang > needs to stay at its current value (and only clang-devel updated), then > that's fine. We don't actually need to add a bsd.pure.mk to upgrade llvm. We would need to complete the repocopy in ports/163030 and change the build and run depends in lang/pure which would change the depends of the 12ish ports involved. Similar changes are needed in a couple other ports. I'll leave it up to portmgr to decide if that's too disruptive. IMO if any change of this scope (an upgrade triggering less than dozen rebuilds, mostly of ports that aren't widely used) should be approved, it should be this one given our general toolchain focus. -- Brooks pgpU7Cr8Ql124.pgp Description: PGP signature
Re: sysutils/sge6[012]: Sun Grid Engine - still broklen due to utmpx?
On Fri, Sep 23, 2011 at 10:58:33AM -0500, Brooks Davis wrote: > On Fri, Sep 23, 2011 at 09:04:49AM +0200, Hartmann, O. wrote: > > I was wondering if the SUN Grid Engine, located in port > > sysutils/sge6[012] is still broken due to utmpx. > > > > My department uses this GRID engine on Linux and since a long time I > > wish to use it also on FreeBSD. > > I've not had a decent 9.0 system available until quite recently and haven't > had as much time as I'd like for FreeBSD HPC stuff lately. I'm taking a > look at it today. It looks like I should be able to get it fixed, but > ancient version of tcsh that is failing to compile is really annoying to > patch for utmpx. I've committed a fix to the sge62 port. Assuming the change makes it through some testing without me acquiring more pointyhats I'll add it to the older ones next week. -- Brooks pgpu6AnMperBX.pgp Description: PGP signature
Re: sysutils/sge6[012]: Sun Grid Engine - still broklen due to utmpx?
On Fri, Sep 23, 2011 at 09:04:49AM +0200, Hartmann, O. wrote: > I was wondering if the SUN Grid Engine, located in port > sysutils/sge6[012] is still broken due to utmpx. > > My department uses this GRID engine on Linux and since a long time I > wish to use it also on FreeBSD. I've not had a decent 9.0 system available until quite recently and haven't had as much time as I'd like for FreeBSD HPC stuff lately. I'm taking a look at it today. It looks like I should be able to get it fixed, but ancient version of tcsh that is failing to compile is really annoying to patch for utmpx. -- Brooks pgpHjF5pFb1jp.pgp Description: PGP signature
Re: [CFT] Likewise-open preliminary port
On Tue, Jun 21, 2011 at 10:09:23AM +0200, Ganael Laplanche wrote: > Hi everyone, > > Over the past few weeks, I've been working on a Likewise-open [1] port and am > starting to get something useable. > > Technically speaking, the port builds fine on x86 and amd64 platforms (gcc- > only ATM) and is able to use libraries from the ports tree instead of the > ones > bundled in the source tarball. > > Basic functionality has been tested : with a local account database (SQLite), > I was able to retrieve account information through nsswitch as well as > authenticate a user on sshd through PAM. The CIFS server also works : a local > Likewise user is able to connect to it. > > Anyway, I am not a Likewise expert and there are still several -important- > tests to perform : > - Try to join an Active Directory server and use it as an authentication > source, instead of the local SQLite DB > - Play with client-side commands (lwio-copy, lwio-fuse-mount) ; I could not > get them work (see below) but I may have missed something > - Try advanced CIFS server configurations > > Here are also remaining tasks that have to be done before the port can hit > the > tree : > - Write a rc.d startup script (probably a wrapper to the provided init.d > scripts) > - Fix build with clang > - Try to build with Heimdal (?) > > I would be pleased to get feedback from you... any help or comment is welcome > ! Have you tried asking Likewise for the ports they appear to be using internally to build packages for FreeBSD? While the normal Likewise install location in /opt/likewise is non-standard, I suspect most likewise users hardcode it in their scripts. I know I do. It seems generally useful to ease the upgrade path from a likewise-open port to likewise-enterprise. -- Brooks pgpfHGuHWeErA.pgp Description: PGP signature
Re: Lightspark port and LLVM bug
On Wed, Jun 15, 2011 at 04:52:10AM -0500, Brooks Davis wrote: > On Wed, Jun 15, 2011 at 10:58:30AM -0500, Rusty Nejdl wrote: > > I might be interested in taking over maintainership of this port but at > > present, this will not compile. I have submitted a PR for an updated > > version of libxml++26 but also, the versions of LLVM (including -devel) > > both contain a bug that prevents this from compiling: > > > > http://llvm.org/bugs/show_bug.cgi?id=9869 > > > > This suggests that I might be able to get it to compile using LLVM > > r131062. > > It's been a while since I update the -devel ports, I'll kick off an > update cycle today. I've updated the -devel port to r133062. -- Brooks pgpYAUPe23gZh.pgp Description: PGP signature
Re: Lightspark port and LLVM bug
On Wed, Jun 15, 2011 at 10:58:30AM -0500, Rusty Nejdl wrote: > I might be interested in taking over maintainership of this port but at > present, this will not compile. I have submitted a PR for an updated > version of libxml++26 but also, the versions of LLVM (including -devel) > both contain a bug that prevents this from compiling: > > http://llvm.org/bugs/show_bug.cgi?id=9869 > > This suggests that I might be able to get it to compile using LLVM > r131062. It's been a while since I update the -devel ports, I'll kick off an update cycle today. -- Brooks pgp2XYGaHNmAu.pgp Description: PGP signature
Re: build failure of ganglia-monitor-core-3.1.7
On Wed, May 25, 2011 at 12:33:10PM +0100, Anton Shterenlikht wrote: > On Tue, May 24, 2011 at 08:46:42AM -0500, Brooks Davis wrote: > > On Tue, May 24, 2011 at 09:14:54PM +0100, Anton Shterenlikht wrote: > > > On Tue, May 24, 2011 at 02:37:42AM -0500, Brooks Davis wrote: > > > > On Tue, May 24, 2011 at 10:19:40AM +0100, Anton Shterenlikht wrote: > > > > > On ia64 and sparc64, both current, I get > > > > > a build failure of ganglia-monitor-core-3.1.7 > > > > > when updating from 3.1.1_6: > > > > > > > > > > ===> Building for ganglia-monitor-core-3.1.7 > > > > > make: cannot open Makefile. > > > > > *** Error code 1 > > > > > > > > > > Stop in /usr/ports/sysutils/ganglia-monitor-core. > > > > > > > > Does it work for you on any other platforms? > > > > > > yes, builds on amd64. I should've checked, just > > > I don't need ganglia on amd64. > > > > Good, my testing was amd64. > > > > > > If so, there is probably a > > > > configure failure above that needs to be analyzed. > > > > > > http://seis.bris.ac.uk/~mexas/sparc64-ganglia-3.1.7-config.log > > > http://seis.bris.ac.uk/~mexas/ia64-ganglia-3.1.7-config.log > > > > Looking at the log I think I'm missing a dependency on pcre. Could you > > try installing devel/pcre and seeing if that fixes it? > > yes, this fixed it, thanks. Great, I'll add the dependancy to the port. > > It's rather bizarre that configure exits with 0 when this happens, it > > should report an error. That's certainly a bug upstream? > > Do you want me to do anything about it? Nope, I'll see if I can spot anything obvious in the autoconf code and pester the devs about it. -- Brooks pgp0PWPPCnBpU.pgp Description: PGP signature
Re: build failure of ganglia-monitor-core-3.1.7
On Tue, May 24, 2011 at 09:14:54PM +0100, Anton Shterenlikht wrote: > On Tue, May 24, 2011 at 02:37:42AM -0500, Brooks Davis wrote: > > On Tue, May 24, 2011 at 10:19:40AM +0100, Anton Shterenlikht wrote: > > > On ia64 and sparc64, both current, I get > > > a build failure of ganglia-monitor-core-3.1.7 > > > when updating from 3.1.1_6: > > > > > > ===> Building for ganglia-monitor-core-3.1.7 > > > make: cannot open Makefile. > > > *** Error code 1 > > > > > > Stop in /usr/ports/sysutils/ganglia-monitor-core. > > > > Does it work for you on any other platforms? > > yes, builds on amd64. I should've checked, just > I don't need ganglia on amd64. Good, my testing was amd64. > > If so, there is probably a > > configure failure above that needs to be analyzed. > > http://seis.bris.ac.uk/~mexas/sparc64-ganglia-3.1.7-config.log > http://seis.bris.ac.uk/~mexas/ia64-ganglia-3.1.7-config.log Looking at the log I think I'm missing a dependency on pcre. Could you try installing devel/pcre and seeing if that fixes it? It's rather bizarre that configure exits with 0 when this happens, it should report an error. That's certainly a bug upstream? Thanks, Brooks pgp2In81insOD.pgp Description: PGP signature
Re: build failure of ganglia-monitor-core-3.1.7
On Tue, May 24, 2011 at 10:19:40AM +0100, Anton Shterenlikht wrote: > On ia64 and sparc64, both current, I get > a build failure of ganglia-monitor-core-3.1.7 > when updating from 3.1.1_6: > > ===> Building for ganglia-monitor-core-3.1.7 > make: cannot open Makefile. > *** Error code 1 > > Stop in /usr/ports/sysutils/ganglia-monitor-core. Does it work for you on any other platforms? If so, there is probably a configure failure above that needs to be analyzed. The output these commands after a failed build might also be helpful: cd /usr/ports/sysutils/ganglia-monitor-core ls -l `make -V WRKSRC` > I contacted the maintainer, but haven't heard > anything back. I'm writing to the list in > case I missed something about this update. Sorry I missed your message, the only messages I saw that obviously related to ganglia were about the broken fetch URL. -- Brooks pgpnR19ZcUKYi.pgp Description: PGP signature
Re: FreeBSD Port: squeezeboxserver-7.5.3, build okay but fails to start.
On Wed, Apr 27, 2011 at 07:15:07AM -0700, spotter wrote: > I am having the exact same problem with a brand new FreeBSD 8.1-RELEASE > install and a fresh squeezeboxserver (v7.5.3) port build. > (Slimserver was working fine under FreeBSD 6.2, until I tried to get > miniDLNA working, as well, for a BluRay player access to same music library. > sigh) > Any solutions worked out for squeezeboxserver v7.5.3 under FreeBSD > 8.1-RELEASE? Assuming you aren't using mysql for anything else, you might try manually installing an older version and then reinstalling the port. My squeezeboxserver is running with 5.0. If that works we should be able to restrict the allowed versions of mysql to ones that work. -- Brooks > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/FreeBSD-Port-squeezeboxserver-7-5-3-build-okay-but-fails-to-start-tp3861984p4343776.html > Sent from the freebsd-ports mailing list archive at Nabble.com. > ___ > 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" > pgpntJVefKeex.pgp Description: PGP signature
Re: Proposal moving *spell dicts to ports/textproc/*spell/dicts
On Sun, Dec 05, 2010 at 03:16:05PM +0100, Julian H. Stacey wrote:
> > > Hello,
> > >
> > >> As I said some weeks ago I personally don't like much the use of
> > >> ports/{french,chinese,whatever}/ directories. I saw that openbsd
> > >> created sub directories in the aspell port. I think this is a really
> > >> good idea, it's really easier to find.
> > >>
> > >> I don't think german/ispell french/aspell textproc/gu-aspell are
> > >> really easy to find.
> > >>
> > >> I propose creating a ports/textproc/aspell/dicts and same for
> > >> textproc/ispell and textproc/hunspell and moving every spellings ports
> > >> to these directories.
> > >
> > > I don't know about hunspell and ispell, but aspell's dictionaries are
> > > maintained and updated independently, at different dates: its why these
> > > are separate ports.
> > >
> > > Regards,
> > > --
> > > Th. Thomas.
> > >
> >
> > Yes but I don't want to make one big dict/ port. I would like to move
> > all aspell languages ports into aspell/dicts/ and then you go under
> > ports/textproc/aspell/dicts/fr && make install for example :)
>
> Problem:
> Scripts assuming 2 levels for all ports.
> Paths such as */*/pkg-plist would no longer be complete.
Including the package registration code in bsd.port.mk
-- Brooks
pgpUODmEOUnGg.pgp
Description: PGP signature
Re: update of security/pssh
On Thu, Dec 02, 2010 at 12:24:27PM +0100, Olivier Smedts wrote: > Hello, > > According to : > http://www.theether.org/pssh/ > > parallel-ssh (pssh) is now maintained on > http://code.google.com/p/parallel-ssh/ by Andrew McNabb. Current > version is 2.1.1. > > Would you have time to look into a maintainer-update ? Thanks for the pointer. Added to my todo list. -- Brooks pgpA2PjbzOXUf.pgp Description: PGP signature
Re: audio/squeezeboxserver still broken
On Sat, Jul 03, 2010 at 12:45:49PM -0700, George Hartzell wrote: > Emanuel Haupt writes: > > George Hartzell wrote: > > > Emanuel Haupt writes: > > > > Hi > > > > > > > > The current audio/squeezeboxserver port is still broken for me. I > > > > just built a package set with an up to date ports tree and > > > > installed them in a vanilla jail to make sure that there is no > > > > previous cruft which could possibly be a problem. > > > > > > > > After installing the package set I started the server and > > > > configured it over the webinterface - just basic stuff, file > > > > location, playlist location, that's it. Then I run > > > > > > > > $ /usr/local/squeezeboxserver/scanner.pl --wipe --rescan > > > > > > > > And I get: > > > > > > > > # /usr/local/squeezeboxserver/scanner.pl --rescan --wipe > > > > Your locale was detected as C, you may have problems with > > > > non-Latin filenames. Consider changing your LANG variable to the > > > > correct locale, i.e. en_US.utf8 [10-07-03 14:38:04.1610] > > > > main::main (180) Starting Squeezebox Server scanner (v7.5.1, > > > > r30836, Tue Jun 1 07:00:00 MDT 2010) perl 5.010001 [10-07-03 > > > > 14:38:04.2226] Carp::Clan::__ANON__ (227) Warning: > > > > Class::C3::Componentised::load_components(): Use of > > > > DBIx::Class::UTF8Columns is strongly discouraged. See > > > > documentation of DBIx::Class::UTF8Columns for more info [10-07-03 > > > > 14:38:04.3794] main::main (271) Removing artwork cache... > > > > [10-07-03 14:38:04.3823] Slim::Music::Import::runImporter (566) > > > > Starting Slim::Music::MusicFolderScan scan [10-07-03 > > > > 14:38:04.3945] Slim::Utils::Scanner::scanDirectory (320) Found 49 > > > > files in /mp3 [10-07-03 14:38:04.3956] > > > > Slim::Utils::Scanner::scanDirectory (333) Scanning: /mp3/foo.mp3 > > > > [10-07-03 14:38:04.4332] Slim::Schema::Storage::throw_exception > > > > (82) Error: DBI Exception: DBD::mysql::db begin_work failed: > > > > Already in a transaction [10-07-03 14:38:04.4336] > > > > Slim::Schema::Storage::throw_exception (82) Backtrace: > > > > > > > >frame 0: Slim::Utils::Log::logBacktrace > > > > (/usr/local/squeezeboxserver/Slim/Schema/Storage.pm line 82) frame > > > > 1: Slim::Schema::Storage::throw_exception > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1187) frame 2: DBIx::Class::Storage::DBI::__ANON__ > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1329) frame 3: DBIx::Class::Storage::DBI::__ANON__ > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 738) frame 4: DBIx::Class::Storage::DBI::__ANON__ > > > > (/usr/local/lib/perl5/site_perl/5.10.1/Try/Tiny.pm line 76) frame > > > > 5: (eval) (/usr/local/lib/perl5/site_perl/5.10.1/Try/Tiny.pm line > > > > 67) frame 6: Try::Tiny::try > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 749) frame 7: DBIx::Class::Storage::DBI::dbh_do > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1329) frame 8: DBIx::Class::Storage::DBI::_dbh_begin_work > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/DBI.pm > > > > line 1310) frame 9: DBIx::Class::Storage::DBI::txn_begin > > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage/TxnScopeGuard.pm > > > > line 12) frame 10: DBIx::Class::Storage::TxnScopeGuard::new > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Storage.pm line > > > > 333) frame 11: DBIx::Class::Storage::txn_scope_guard > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Schema.pm line > > > > 672) frame 12: DBIx::Class::Schema::txn_scope_guard > > > > > (/usr/local/lib/perl5/site_perl/5.10.1/DBIx/Class/Relationship/CascadeActions.pm > > > > line 49) frame 13: > > > > DBIx::Class::Relationship::CascadeActions::update > > > > (/usr/local/squeezeboxserver/Slim/Schema/DBI.pm line 39) frame 14: > > > > Slim::Schema::DBI::update > > > > (/usr/local/squeezeboxserver/Slim/Schema.pm line 2766) frame 15: > > > > Slim::Schema::_postCheckAttributes > > > > (/usr/local/squeezeboxserver/Slim/Schema.pm line 1079) frame 16: > > > > Slim::Schema::newTrack > > > > (/usr/local/squeezeboxserver/Slim/Utils/Scanner.pm line 347) frame > > > > 17: Slim::Utils::Scanner::scanDirectory > > > > (/usr/local/squeezeboxserver/Slim/Music/MusicFolderScan.pm line > > > > 79) frame 18: Slim::Music::MusicFolderScan::startScan > > > > (/usr/local/squeezeboxserver/Slim/Music/Import.pm line 568) frame > > > > 19: Slim::Music::Import::runImporter > > > > (/usr/local/squeezeboxserver/Slim/Music/Import.pm line 373) frame > > > > 20: Slim::Music::Import::runScan > > > > (/usr/local/squeezeboxserver/scanner.pl line 305) frame 21: (eval) > > > > (/usr/local/squeezeboxserver/scanner.pl line 299) frame 22: > > > > mai
Re: [RFC] Tools/ script for automatically making a tar out of svn sources
On Wed, Dec 09, 2009 at 10:27:58PM +0200, Eitan Adler wrote: > The attached script is designed to work with the 20+ ports that > currently have to resort to hacks to automatically figure out the head > version, checkout from svn, make a tar file, and then upload the file > to freefall. > > It is based on some my earlier work/proposals > (http://wiki.freebsd.org/EitanAdler/ports-svn) to put this directly > into ports.*.mk. While that proposal was rejected by a large part of > the community making a simple standard script to put into Tools was > suggested by a few people as a better solution and one more likely to > get accepted by the community and portmgr. > > This port requires that three values be defined in the ports Makefile. > Of these two are already defined for most of the ports that use the > hacks mentioned above. > USE_SCM="svn" is required as I plan on including support for other > common SCMs that might be used in the ports collection already (git > and cvs come to mind) > SVN_REV=12345 is required unless you use the "-h" option which gets > the version from head > SVN_URL=svn://goo.com/svn_repo - this is where the source is fetched from. > > If I could get any comments (1) on the script in particular and (2) if > the approach I'm taking now is better than the one I tried a few weeks > ago (see wiki page) it would be really good. I don't see the script. -- Brooks pgpJl4ba9ho32.pgp Description: PGP signature
Re: squeezecenter 7.3.2 no longer starts with latest ports
On Thu, Dec 03, 2009 at 12:24:55AM +, Mark Knight wrote: > In message <91b92520912021328j34373653r838ba135a41f5...@mail.gmail.com>, > Sandra Kachelmann writes > >I even removed the whole database and performed a complete rebuild: > > > >$ portupgrade -rf squeezeboxserver > > > >This port is broken... > > Hi, > > Back out to: > > p5-Class-XSAccessor-1.03,1 > p5-DBIx-Class-0.08112 > > ...and I think it'll work. > > Alternatively there are some PRs that may help when brooks@ gets a > chance to look at them: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/140662 > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141106 I think I've got it fixed. Sorry for the delay, I've been traveling. -- Brooks pgpYfrHXoH80B.pgp Description: PGP signature
Re: RFC: svn for make fetch
On Mon, Nov 09, 2009 at 02:28:52PM -0800, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eitan Adler wrote: > > I was hoping to get a bit more of a response to a recent posting of > > mine with regard to using svn to fetch files for ports > > My proposal: > > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html > > A summary of what has been going on: > > http://wiki.freebsd.org/EitanAdler/ports-svn > > > > This is something that more than 2 people should have an input on > > Just my $0.02 but I think it would be great if we can do: > > - "make fetch" would prefer using a pre-packaged tarball, but fallback > to a svn/whatever checkout with a specific revision number, then > generate a tarball from the export. > - "make checksum" would check the tarball's checksum. It's probalby not practical to generate an archive with consistently identical checksums due to the various timestamps (at least without adding a tar writer to svn which would be kind of cool. :) > Maybe we can also have some variables to control that we actually want > the 'HEAD' revision without checking any checksum. However, I think it > would be nice if we can do a checksum'ed checkout for specific SCM > revision, especially if we want to have ports to work not only for > *-devel ports where we would prefer signed source code. While this wasn't the intent of the -DBOOTSTRAP stuff I added to the llvm port, people are finding it useful so if we can find I clean way to support this I think it would be cool. -- Brooks pgpJG8wxgpti5.pgp Description: PGP signature
Re: RFC: svn for make fetch
On Sun, Nov 08, 2009 at 07:07:25PM +, Marcin Wisnicki wrote:
> On Sun, 08 Nov 2009 17:31:57 +0200, Eitan Adler wrote:
>
> > I was hoping to get a bit more of a response to a recent posting of mine
> > with regard to using svn to fetch files for ports My proposal:
> > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html A
> > summary of what has been going on:
> > http://wiki.freebsd.org/EitanAdler/ports-svn
> >
> > This is something that more than 2 people should have an input on
>
> Unless you solve plist problem (and completely automated plist generation
> would be a fantastic thing to have!), such functionality should not be
> available (or at least advertised) to end-users.
> You may also consider moving it to separate file (bsd.maintainer.mk).
>
> I don't quite get the logic behind ${USER} == ${SVN_USER} conditional.
> Why do you assume that if my username is the same as username for svn
> checkout then I want to upload snapshot to freefall ? In addition not
> every maintainer has @freebsd.org account. Uploading should be
> customizable (maybe UPLOAD_CMD - like FETCH_CMD).
It's a generalization of an ugly hack I put in my llvm-devel port. I
don't really think it should be part of the base.
-- Brooks
pgp9vsVWHpiAN.pgp
Description: PGP signature
Re: using svn to fetch for ports (yet again!)
On Thu, Nov 05, 2009 at 10:17:10PM +0200, Eitan Adler wrote: > > I'd much rather see this used as something that reduced the amount of > > code required for maintainers to build tarballs from SVN. ?For example > > something similar in spirit to what I've done in devel/llvm-devel. ?That > > means mirroring or otherwise transfering the source around is possible. > Would a patch like the one below be what you are looking for? > (Note that I didn't test this patch that much...) Not quite. What I like about overriding do-fetch is that you can do: make -DBOOTSTRAP makesum to both generate the tarball and generate the checksum. You can then go on and build the port like you would otherwise. I also find the auto determination of the latest revision to be very useful. I probably would't include the scp to freefall bit. That's excessivly evil. :) > > There will likely be some objections to putting maintainer functionality > > in bsd.port.mk, but I think it would be useful enough in this case. > > Alternativly we could formalize the process a bit and put something > > Tools/scripts. > > While I have no trouble writing a script to perform these tasks this > is something that I'd like to see available to end users. > I think it would useful to allow users to do something like > SVN_REV=1436 make install clean > and thus fetch from svn and install newer/older versions. I think the users would rather build a tarball in that case so they don't have to download everything again when they start tweaking and testing patches. One option might be to set NO_CHECKSUM if the user overrides the revision. You'd need another switch so the maintainer can use makesum in that case, but that should be easy enough. -- Brooks pgpWz9xyDICJp.pgp Description: PGP signature
Re: using svn to fetch for ports (yet again!)
On Wed, Nov 04, 2009 at 08:23:02PM +0200, Eitan Adler wrote: > I have a small patch to bsd.port.mk which would allow a port to > replace its do-fetch with a svn export of a /specific revision/ of a > remote repo. > > I know there have been some attempts at trying this before and from > what I've been reading I addressed some of the major concerns: > 1) Past attempts didn't include a basic implementation. > 2) Past attempts didn't allow for a specific revision number and thus > possibly causing security issues > 3) Subversion does not have to be part of the base system for my patch to work > > Allowing the port to fetch from svn is beneficial for a number of > reasons some of which are listed below > 1) Many project's only or main means of distribution is svn (I'm > thinking of mplayer) > 2) It is easier for the port maintainer to update the port > 3) It is easy for a user to quickly switch versions (outside of the > ports system) without the need for lots o knowledge about the ports > system > > Some of the problems: > 1) Its harder if not impossible for freeBSD to mirror the port's > source (I'm sure I could easily code a svn-to-tarball script but who > knows if the svn build servers want svn) > 2) Many users may want the program they are installing but not svn > 3) What about SCM's other than svn? I'd much rather see this used as something that reduced the amount of code required for maintainers to build tarballs from SVN. For example something similar in spirit to what I've done in devel/llvm-devel. That means mirroring or otherwise transfering the source around is possible. There will likely be some objections to putting maintainer functionality in bsd.port.mk, but I think it would be useful enough in this case. Alternativly we could formalize the process a bit and put something Tools/scripts. -- Brooks pgpjc0sHXsmth.pgp Description: PGP signature
Re: Installing in cgi-bin
On Sat, Mar 28, 2009 at 04:07:30PM -0400, Jerry wrote:
> On Sat, 28 Mar 2009 12:43:13 -0500
> Brooks Davis wrote:
>
> >On Sat, Mar 28, 2009 at 01:33:15PM -0400, Jerry wrote:
> >> I have a Perl program that I am thinking of porting to FreeBSD. The
> >> program has to be installed in the 'cgi-bin'.
> >>
> >> I was thinking something like:
> >> "$(WWWDIR}/apache${APACHE_VERSION}/cgi-bin" might be the way to
> >> direct the install to the correct directory. Is there a better way?
> >> I cannot find a macro that directly references the cgi-bin.
> >
> >We have a policy against installations that would automaticlly be on
> >the network. You need to install it elsewhere (often a directory
> >under WWWDIR) and tell people how to add the appropriate configuration
> >directives to http.conf or to copy the file into cgi-bin in
> >pkg-message.
>
>
> The program is DADA Mail. It installs a 'mail.cgi' in the cgi-bin and
> then installs the rest of its files, perl modules, etc. in a hierarchy
> several layers deep in the cgi-bin directory. We are talking
> about a lot of files here. Expecting the end user to properly move the
> files from a temporary directory to the cgi-bin and then properly
> changing the file(s) properties would seem a little extreme. However,
> if that is the only way I can do it, I will investigate writing a
> script that the end user could invoke to accomplish this feat. It does
> seem a little over the top however. Due to the way DADA Mail is
> written, the author does not believe it can be run from other than that
> directory along with its associated files.
Sounds seriously broken. :) I might suggest installing in www/dada and
providing a script to make appropriate symlinks along with an instruction
to enable following symlinks in cgi-bin. It seems like shockingly bad
design to require that it live at http://.../cgi-bin/mail.cgi, but
that's certainly not uncommon. :(
-- Brooks
pgpOn77FZYYNc.pgp
Description: PGP signature
Re: Installing in cgi-bin
On Sat, Mar 28, 2009 at 01:33:15PM -0400, Jerry wrote:
> I have a Perl program that I am thinking of porting to FreeBSD. The
> program has to be installed in the 'cgi-bin'.
>
> I was thinking something like:
> "$(WWWDIR}/apache${APACHE_VERSION}/cgi-bin" might be the way to direct
> the install to the correct directory. Is there a better way? I cannot
> find a macro that directly references the cgi-bin.
We have a policy against installations that would automaticlly be on
the network. You need to install it elsewhere (often a directory
under WWWDIR) and tell people how to add the appropriate configuration
directives to http.conf or to copy the file into cgi-bin in pkg-message.
-- Brooks
pgpFPUHdW2yCL.pgp
Description: PGP signature
Re: FreeBSD Port: pssh-1.3.1_1
Sorry for not getting to this sooner. I've finaly updated the port. -- Brooks On Thu, Nov 27, 2008 at 04:49:47PM +0300, Michael wrote: > Hi, Brooks. > > Upgrade pssh-1.3.1_1 to the pssh-1.4.3 plz. > > pslurp doesn't work: > > pslurp -L ~/ -r /tmp/1 1 > [1] 16:34:24 [FAILURE] softsearch1.softsearch.ru (22, 'Invalid argument') > [2] 16:34:24 [FAILURE] softsearch2.softsearch.ru (22, 'Invalid argument') > [3] 16:34:24 [FAILURE] softsearch3.softsearch.ru (22, 'Invalid argument') > [4] 16:34:24 [FAILURE] softsearch4.softsearch.ru (22, 'Invalid argument') > [5] 16:34:24 [FAILURE] softsearch5.softsearch.ru (22, 'Invalid argument') > > pslurp from pssh-1.4.3 work fine: > > pslurp -L ~/ -r /tmp/1 1 > [1] 16:44:07 [SUCCESS] softsearch1.softsearch.ru 22 > [2] 16:44:07 [SUCCESS] softsearch4.softsearch.ru 22 > [3] 16:44:07 [SUCCESS] softsearch5.softsearch.ru 22 > [4] 16:44:30 [SUCCESS] softsearch3.softsearch.ru 22 > [5] 16:44:31 [SUCCESS] softsearch2.softsearch.ru 22 > > > -- > Michael > pgpSDTIZx3TqM.pgp Description: PGP signature
Re: wildcards in pkg-plist?
On Thu, Jan 29, 2009 at 02:26:07AM +, Sevan / Venture37 wrote: > Hello again > OpenNMS generates a bunch of cache files which have dynamically generated > filenames (everytime a build is attempted the filenames change), how does > one address this in the pkg-plist, I tried using *.cache.html & > \*.cache.html with no success. An appropriate @unexec directive should do the job. Search the tree or look in the ports handbook for examples. -- Brooks pgpnumW9venIr.pgp Description: PGP signature
Re: Slimserver port broken
On Sun, Jan 18, 2009 at 05:32:57PM -0600, Troy wrote: > Hi, > > The Slimeserver port cannot fetch the file the port is calling for. I > manually looked at each of the locations and the file doesn't exist. I've fixed the URL, but also set DEPRECATED. You should use audio/squeezecenter instead. > -Troy > > /usr/ports/audio/slimserver# make > ===> Vulnerability check disabled, database not found > ===> Found saved configuration for slimserver-6.2.2_1 > > Define SLIMDIR to override default of 'slimserver'. > > => SlimServer_v6.5.4.no-cpan-arch.tar.gz doesn't seem to exist in > /usr/ports/distfiles/slimserver. > => Attempting to fetch from > http://downloads.slimdevices.com/downloads/SlimServer_v6.5.4/. > fetch: > http://downloads.slimdevices.com/downloads/SlimServer_v6.5.4/SlimServer_v6.5.4.no-cpan-arch.tar.gz: > Not Found > => Attempting to fetch from > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/slimserver/. > fetch: > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/slimserver/SlimServer_v6.5.4.no-cpan-arch.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/slimserver and try again. > *** Error code 1 > > Stop in /usr/ports/audio/slimserver. > *** Error code 1 > > Stop in /usr/ports/audio/slimserver. > Exit 1 > pgpKAzoW0MGKG.pgp Description: PGP signature
Re: A place to upload distfiles?
On Mon, Nov 24, 2008 at 10:58:28AM -0800, [EMAIL PROTECTED] wrote: > I maintain a port for which the vendor provided me a customized distfile. > They don't have it available for download from their site, so I need to > find a home for it. Does the FreeBSD Project or Foundation provide hosting > space for such cases or do I need to find my own space? Committers have the ability to host such distfiles using the MASTER_SITE_LOCAL variable. You'll have to provide the person who commits the port and updates with some way to obtain the files, but as long as they are fully redistributable, we can do that. -- Brooks pgpR5b6I98hVX.pgp Description: PGP signature
Re: Making ports from source with weird download restrictions
On Mon, Sep 08, 2008 at 10:03:22AM -0700, Steve Franks wrote: > Hi, > > There are two embedded software tools > I've been wanting to port for some time. Both have inconsistent/funky > downloads, so I have no idea how to get them into a port. Both are > very active projects, and used by pretty much all embedded ARM7/9 > developers (embedded as in microwaves & thermostats not PDA's & > IPods). > > 1) lpc21isp - http://tech.groups.yahoo.com/group/lpc21isp/ - the > source for this project is only located in the "files" section of this > yahoo group, and I'm pretty sure you need a yahoo password to get it. > Also it's guarded by a bunch of antisocial types, if you know what I > mean. I got flamed for suggesting a feature that would increase > flexibility. I suspect the only choice here is to make sure the > license is open, and branch it to a new sourceforge project, correct? > Otherwise, there's really no way for someone to get the source in an > automated fashion. As long as the license allows redistribution, we can host it on FreeBSD infrastructure using MASTER_SITE_LOCAL. > 2) openocd - http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD > - this is a bit more sensible - there's a stable SVN repository for > it, it's just that the only ports I've seen are on sourceforge, and > come from release .tgz archives, not a SVN archive (although I've > never gotten a broken version from the openocd SVN). If someone > pointed me at a port that built from SVN instead of a .tgz, I'm sure I > could get the port done. Doing an svn export in the fetch stage is possible, but probably not ideal. In my devel/llvm-devel port I have a do-fetch target that fetches a snapshot and makes a tarball out of it, but I only use that for my own use and host a snapshot on the FreeBSD ftp servers for normal users since a tarball allows users to do a make clean and retry without having to fetch files again. -- Brooks pgpWvq02Uu17s.pgp Description: PGP signature
Re: octave-forge
On Fri, Aug 22, 2008 at 10:29:48PM -0500, Stephen Montgomery-Smith wrote: > Dear Maho, > > I see that octave-forge has been broken for quite a while. Do you mind if > I have a go at redoing it? > > I presume that you would want to do it meta-port style, that is, lots of > ports with names like octave-forge-plot-1.0.5. > > I would be happy to do the work, and I think I could get it done quite > quickly, but I don't want to do it if you are about to do it yourself. Please find attached the work I've done on this so far, but never found time to commit. This adds a bsd.octave.mk (currently in the wrong place) and includes io and signal ports. I think adding the rest of the modules should be fairly easy. -- Brooks octave-forge.tar.gz Description: Binary data pgpXBkWMAdsnS.pgp Description: PGP signature
Re: FreeBSD Port: squeezecenter-7.0.1_4
On Thu, Aug 07, 2008 at 10:59:06PM +0200, Kenny Lasse Hoff Levinsen wrote: > Hi! > > I'm sorry to bother, but i just wanted to ask when this port is gonna be > updated (it's 7.1 now)? > Know it's a simple app and i can just install it from sources (which is > perl, to make it even simpler), but i just like having it in the package > database, so it's easier to handle... > Just wondering Thanks for the reminder. I did the work last week, but was away my computer for a long weekend and thus didn't commit it. I'll finish the last of the cleanup and commit it shortly. -- Brooks pgpIAFTfklWL6.pgp Description: PGP signature
