FreeBSD Port: graphics/sane-backends
Install error for sane-backends-1.0.23_2 on FreeBSD 9.2 i386: === Staging rc.d startup script(s) === Correct pkg-plist sequence to create group(s) and user(s) === Building package for sane-backends-1.0.23_2 Creating package /usr/ports/graphics/sane-backends/work/sane-backends-1.0.23_2.tbz Registering depends: cups-client-1.5.4_1 gettext-0.18.3.1 libiconv-1.14_1 tiff-4.0.3 jbigkit-1.6 libv4l-0.8.8_1 jpeg-8_4. Creating bzip'd tar ball in '/usr/ports/graphics/sane-backends/work/sane-backends-1.0.23_2.tbz' tar: man/man5/sane-canon_pp.5.gz: Cannot stat: No such file or directory tar: man/man5/sane-hpsj5s.5.gz: Cannot stat: No such file or directory tar: man/man5/sane-mustek_pp.5.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 Stop in /usr/ports/graphics/sane-backends. *** [install] Error code 1 Stop in /usr/ports/graphics/sane-backends. BEASTIE# ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: graphics/sane-backends
This is tripped by the CUPS option. Disabling CUPS is a work around. -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-Port-graphics-sane-backends-tp5853315p5853316.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
[QAT] r330985: 4x leftovers
- Update to 4.0051 - Sort PLIST - Fix PLIST: use %%PERL_ARCH%% instead of mach Changes:http://search.cpan.org/dist/HTML-FormHandler/Changes - Build ID: 20131020070400-28317 Job owner: sunp...@freebsd.org Buildtime: 26 minutes Enddate: Sun, 20 Oct 2013 07:29:35 GMT Revision: r330985 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=330985 - Port:www/p5-HTML-FormHandler 0.40051_1,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131020070400-28317-210232/p5-HTML-FormHandler-0.40051_1,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131020070400-28317-210233/p5-HTML-FormHandler-0.40051_1,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131020070400-28317-210234/p5-HTML-FormHandler-0.40051_1,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131020070400-28317-210235/p5-HTML-FormHandler-0.40051_1,1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131020070400-28317 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/20/2013 03:49, Paul Schmehl wrote:
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
I'm the maintainer, and I can assure you I tested it thoroughly. The
port has built without error on many machines before this came up. I've
personally built and tested it numerous times.
With the MYSQL option set on? The default is off, so building the
default configuration numerous times would not have hit this.
Nevertheless, I will take a look at what you've discussed and attempt to
determine what the problem is. It appears that something may have
changed in 9.2 that is causing the problem. Unfortunately I don't have
a 9.2 install, so I'll have to set one up before I can test it.
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition. That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port. Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: multimedia/xbmc's default dependency on lame
I'll try and send a patch for this soon. In the meantime, any idea why this fails on 10.x? gmake[2]: Entering directory `/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer/DVDCodecs/Video' CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.o CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecLibMpeg2.o CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoPPFFmpeg.o CPP xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.o VAAPI.cpp:77:10: error: unknown type name 'weak_ptr' static weak_ptrCDisplay display_global; ^ VAAPI.cpp:77:18: error: expected unqualified-id static weak_ptrCDisplay display_global; ^ VAAPI.cpp:79:23: error: use of undeclared identifier 'display_global' CDisplayPtr display(display_global.lock()); ^ VAAPI.cpp:120:3: error: use of undeclared identifier 'display_global' display_global = display; ^ VAAPI.cpp:233:25: warning: cast to 'unsigned char *' from smaller integer type 'VASurfaceID' (aka 'unsigned int') [-Wint-to-pointer-cast] pic-data[3]= (uint8_t*)surface; ^ 1 warning and 4 errors generated. I have boost installed and it has the definitions for weak_ptr, so I'm not sure what's going on here. gmake(1) tries to compile like this: root@coyote:/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer/DVDCodecs/Video# gmake -n rm -f VAAPI.o echo CPP xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.o; c++ -MF VAAPI.d -MD -c -O2 -O2 -pipe -fno-strict-aliasing -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG=1 -I/usr/local/include -DTARGET_POSIX -DTARGET_FREEBSD -D_LINUX -D_FILE_DEFINED -D__STDC_CONSTANT_MACROS -DBIN_INSTALL_PATH=\/usr/local/lib/xbmc\ -DINSTALL_PATH=\/usr/local/share/xbmc\ -DHAS_SDL_JOYSTICK -D'GIT_REV=Unknown' -DHAVE_CONFIG_H -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/lib -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc -DDBUS_API_SUBJECT_TO_CHANGE -D_GNU_SOURCE=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/SDL -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/hal -I/usr/local/include/libcec -I/usr/local/include/libpng15 -I/usr/local/include/taglib -I/usr/ports/multimedia/xbmc/work/xbmc-12.2 -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/lib/ffmpeg -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/linux -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer VAAPI.cpp -o VAAPI.o \ cp VAAPI.d VAAPI.P sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e '/^$/ d' -e 's/$/ :/' VAAPI.d VAAPI.P rm -f VAAPI.d || ( rm -f VAAPI.P VAAPI.o exit 1 ) echo AR xbmc/cores/dvdplayer/DVDCodecs/Video/Video.a; ar crus Video.a DVDVideoCodecFFmpeg.o DVDVideoCodecLibMpeg2.o DVDVideoPPFFmpeg.o VAAPI.o ... Oh, then I tried being explicit about that namespace, et voila! It compiles fine. See attached patch. But then the pkg-plist somehow doesn't match any longer :( === Installing for xbmc-12.2_1 === Checking if multimedia/xbmc already installed === Registering installation for xbmc-12.2_1 pkg-static: lstat(/usr/ports/multimedia/xbmc/work/stage/usr/local/lib/xbmc/system/libcmyth-x86_64-freebsd.so): No such file or directory *** Error code 74 Sigh. The generated Makefile has ifeq (0,1) LIB_DIRS += lib/cmyth CMYTH=cmyth endif so it's unlikely I'll get it built, config.log has nothing about this and I have no idea what that java thing at the start of the build tries to do. Now I only need to figure out why all the unicode conversions are broken with that new internal iconv support in 10.x :( Cheers, Uli 2013/10/19 Mickaël Maillot mickael.mail...@gmail.com: You can remove LAME from default options. it's just used for MP3 encoding from CD, not really used by people. 2013/10/18 Ulrich Spörlein u...@freebsd.org Hey Mickael, Baptiste, multimedia/xbmc is currently broken for me on 10.x (worked fine about 1-2 months ago) and I wanted to check the build cluster to see if the problem is on my end. The problem? multimedia/xbmc is skipped because of the default dependency on lame (and that is restricted). So this http://beefy1.isc.freebsd.org/bulk/head-i386-default/2013-10-17_19h54m49s/ will not show me if xbmc builds for other people. Mickael, is the default dependency on lame required? It means we'll never ship a pre-built port for it .. Baptiste, is it possible to still build these packages and packages that depend on them, but just not publish/distribute them? Thanks! UIi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fail to build shells/zsh on 10.0-BETA1 due to conflict of 'bool' definition between rpcsvc/yp_prot.h and stdbool.h
From: Yasuhiro KIMURA y...@utahime.org
Subject: Fail to build shells/zsh on 10.0-BETA1 due to conflict of 'bool'
definition between rpcsvc/yp_prot.h and stdbool.h
Date: Sun, 20 Oct 2013 02:26:31 +0900 (JST)
On 10.0-BETA1 amd64, build of shells/zsh fails as following:
(snip)
cc -c -I. -I../Src -I../Src -I../Src/Zle -I. -I/usr/local/include
-DHAVE_CONFIG_H -O2 -pipe -fno-strict-aliasing -o hashnameddir.o
hashnameddir.c
In file included from hashnameddir.c:52:
/usr/include/rpcsvc/yp_prot.h:71:15: error: cannot combine with previous
'type-name' declaration specifier
typedef u_int bool;
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
1 error generated.
*** Error code 1
Stop.
Accoding to the error message, there seems to be conflict about
definition of 'bool' between /usr/include/rpcsvc/yp_prot.h and
/usr/include/stdbool.h.
Then how to fix this issue?
Applying attached patch to port tree is tentative workaround, but I
blieve this issue should be fixed by base system.
Removing line 70-73 of yp_prot.h is simple idea but I am not certain
it is really solution.
---
Yasuhiro KIMURA
Index: shells/zsh/Makefile
===
--- shells/zsh/Makefile (revision 330965)
+++ shells/zsh/Makefile (working copy)
@@ -25,7 +25,7 @@
USES= iconv ncurses
GNU_CONFIGURE= yes
-CPPFLAGS+= -I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include -DBOOL_DEFINED
LDFLAGS+= -L${LOCALBASE}/lib
CONFIGURE_ARGS=--with-term-lib=ncursesw ncurses --with-tcsetpgrp \
--enable-function-subdirs
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: graphics/sane-backends
Hi, On 2013-10-20 03:12 -0400, Robert Burmeister robert.burmeis...@utoledo.edu wrote: Install error for sane-backends-1.0.23_2 on FreeBSD 9.2 i386: === Staging rc.d startup script(s) === Correct pkg-plist sequence to create group(s) and user(s) === Building package for sane-backends-1.0.23_2 Creating package /usr/ports/graphics/sane-backends/work/sane-backends-1.0.23_2.tbz Registering depends: cups-client-1.5.4_1 gettext-0.18.3.1 libiconv-1.14_1 tiff-4.0.3 jbigkit-1.6 libv4l-0.8.8_1 jpeg-8_4. Creating bzip'd tar ball in '/usr/ports/graphics/sane-backends/work/sane-backends-1.0.23_2.tbz' tar: man/man5/sane-canon_pp.5.gz: Cannot stat: No such file or directory tar: man/man5/sane-hpsj5s.5.gz: Cannot stat: No such file or directory tar: man/man5/sane-mustek_pp.5.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 Stop in /usr/ports/graphics/sane-backends. *** [install] Error code 1 Stop in /usr/ports/graphics/sane-backends. BEASTIE# Fixed in r331001. -- pozdrawiam / with regards Paweł Pękala ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: petsc-2.3.3.p0_7,1
Hi, Would it possible to update Petsc to version 3.4.3 ? Create a new port for slepc-3.4.3 (extension for petsc) could be also nice. Thank in advance. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: 10.0-hosted tinderbox: 8.4 builds broken?
On Sun, Oct 13, 2013 at 01:36:45PM +0100, Chris Rees wrote: It appears that really weird SRCBASE assumptions are made throughout the code. I'll have to put a temporary hack in to just make SRCBASE appear inside the chroot whatever it's set to. Setting and unsetting SRCBASE just breaks different things in weird ways, and this is the only reliable fix I've found. I've just setup another tinderbox here on 11-CURRENT and did a fresh checkout from CVS; I confirm that I can build packages for both 9.2 and 10.0-BETA just fine now, thanks! However I've noticed another regression: doing chmod g+w /usr/ports/distfiles in the middle of the tinder run totally confuses it: all build attempts after chmod fail with identical tiny log files: building lcms2-2.5 in directory /usr/home/danfe/tb/9.2-wip make: cannot open /a/ports/Mk/bsd.port.mk. cd: /usr/ports/graphics/lcms2: No such file or directory The reason for a chmod: I normally build ports from a user, and to allow it to fetch distfiles, give write permissions to wheel group. I also do ./tc configDistfile -c /usr/ports/distfiles, and it always changed perms back. It's annoying, but I can live with it: just chmod the damn directory again. chmod'ing in the middle of tinder run is because I often do the runs while installing something from ports manually at the same time. Previously tinderbox simply complained like this in the end of the build log: Fatal error: filesystem was touched prior to 'make install' phase distcache changed permissions expected 0755 found 0775 But this (and subsequent) packages were still built successfully. Now chmod'ing totally screws up the whole (remaining) build. BTW, would it be possible to prevent forcing 0755 perms? I don't really see any point for doing this in the first place... ./danfe ___ 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
CURRENT 10.0/11.0 amd64: gcc46 compiled ports tend to coredump (SIGNAL 11 (SIGSEGV))
I realise that several ports which get compiled with gcc (no matter whether 4.6.3, 4.7 or 4.8) do not work anymore and segfaulting immediately after start. In particular, I use port math/fityk, which segfaults on ALL CURRENT and 10.-ALPHA boxes I run fityk on (or better: ran). This doesn't occur on FreebSD 9.2-STABLE. Another port indicating this behaviour is games/warzone2100 (but not so important, just for adding it up). Is there something I miss? Oliver P.S. please set me CC, I'm not subscribing ... signature.asc Description: PGP signature
[QAT] r331026: 4x leftovers
A Ruby framework for rapid API development with great conventions. WWW: http://github.com/ddollar/foreman PR: ports/182675 Submitted by: Loic Blot loic.b...@unix-experience.fr - Build ID: 20131020152000-59358 Job owner: swi...@freebsd.org Buildtime: 9 minutes Enddate: Sun, 20 Oct 2013 15:29:27 GMT Revision: r331026 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=331026 - Port:devel/rubygem-foreman 0.63.0 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131020152000-59358-210392/rubygem-foreman-0.63.0.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131020152000-59358-210393/rubygem-foreman-0.63.0.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131020152000-59358-210394/rubygem-foreman-0.63.0.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131020152000-59358-210395/rubygem-foreman-0.63.0.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131020152000-59358 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r331027: 4x leftovers
- Convert to staging - Build ID: 20131020152600-4701 Job owner: ead...@freebsd.org Buildtime: 13 minutes Enddate: Sun, 20 Oct 2013 15:39:15 GMT Revision: r331027 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=331027 - Port:devel/p5-File-Append-TempFile 0.05_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020152600-4701-210396/p5-File-Append-TempFile-0.05_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020152600-4701-210397/p5-File-Append-TempFile-0.05_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020152600-4701-210398/p5-File-Append-TempFile-0.05_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020152600-4701-210399/p5-File-Append-TempFile-0.05_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131020152600-4701 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r331029: 4x leftovers
- Convert to staging - Build ID: 20131020153000-15477 Job owner: ead...@freebsd.org Buildtime: 10 minutes Enddate: Sun, 20 Oct 2013 15:40:06 GMT Revision: r331029 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=331029 - Port:net-mgmt/p5-Net-IP 1.26 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020153000-15477-210404/p5-Net-IP-1.26.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020153000-15477-210405/p5-Net-IP-1.26.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020153000-15477-210406/p5-Net-IP-1.26.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131020153000-15477-210407/p5-Net-IP-1.26.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131020153000-15477 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: math/saga: does not build after recent changes on 10.0 and HEAD
Am 19.10.2013 10:22, schrieb Rainer Hurling: I am the maintainer of math/saga (SAGA GIS). For a few weeks now math/saga does not build anymore on 10.0 and HEAD. Until mid of September, it builts fine on all my 10.0-CURRENT boxes. Now I get errors, which I did not have seen before and which are also mentioned for example at http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2013-10-17_23h06m42s/logs/saga-2.1.0_2.log As proposed by the error message, I added the following to the ports Makefile: CXXFLAGS+=-std=c++0x Now the build continuous, but runs into new problems a bit later. Here again, x11-toolkits/wxgtk29 is involved: [..snip..] Making all in saga_api /bin/sh ../../../libtool --tag=CXX--mode=compile g++46 -DHAVE_CONFIG_H -I. -I../../.. -fPIC -Wall `/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --cxxflags` -D_SAGA_LINUX -D_SAGA_UNICODE -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_API_EXPORTS -O2 -pipe -I/usr/local/include -D_SAGA_DONOTUSE_HARU -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=c++0x -Wl,-rpath=/usr/local/lib/gcc46 -MT api_callback.lo -MD -MP -MF .deps/api_callback.Tpo -c -o api_callback.lo api_callback.cpp libtool: compile: g++46 -DHAVE_CONFIG_H -I. -I../../.. -fPIC -Wall -I/usr/local/lib/wx/include/gtk2-unicode-2.9 -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE -D_SAGA_LINUX -D_SAGA_UNICODE -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_API_EXPORTS -O2 -pipe -I/usr/local/include -D_SAGA_DONOTUSE_HARU -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=c++0x -Wl,-rpath=/usr/local/lib/gcc46 -MT api_callback.lo -MD -MP -MF .deps/api_callback.Tpo -c api_callback.cpp -fPIC -DPIC -o .libs/api_callback.o In file included from /usr/local/include/wx-2.9/wx/crt.h:20:0, from /usr/local/include/wx-2.9/wx/string.h:4353, from /usr/local/include/wx-2.9/wx/stdpaths.h:17, from api_callback.cpp:66: /usr/local/include/wx-2.9/wx/wxcrt.h: In function 'long long int wxStrtoll(const char*, char**, int)': /usr/local/include/wx-2.9/wx/wxcrt.h:904:1: error: 'strtoll' was not declared in this scope /usr/local/include/wx-2.9/wx/wxcrt.h: In function 'long long unsigned int wxStrtoull(const char*, char**, int)': /usr/local/include/wx-2.9/wx/wxcrt.h:905:1: error: 'strtoull' was not declared in this scope *** Error code 1 Stop. make[6]: stopped in /usr/ports/math/saga_svn/work/saga-gis/src/saga_core/saga_api [..snip..] After some further investigation I found a hint at http://trac.wxwidgets.org/ticket/11012 . The not declared 'strtoull' seems to be a consequence of using '-std=c++0x' (see above), while this long long function needs C99? I really could need some help with this. Many thanks in advance, Rainer Hurling I suspect the changes in 10.0 and HEAD of the last weeks to be liable for this? But I have no clue what to do to correct the port. Any help is really appreciated. Please let me know, if I should give more information or test something. Thanks in advance, Rainer Hurling ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: 10.0-hosted tinderbox: 8.4 builds broken?
On 2013-10-20 15:51, Alexey Dokuchaev wrote: On Sun, Oct 13, 2013 at 01:36:45PM +0100, Chris Rees wrote: It appears that really weird SRCBASE assumptions are made throughout the code. I'll have to put a temporary hack in to just make SRCBASE appear inside the chroot whatever it's set to. Setting and unsetting SRCBASE just breaks different things in weird ways, and this is the only reliable fix I've found. I've just setup another tinderbox here on 11-CURRENT and did a fresh checkout from CVS; I confirm that I can build packages for both 9.2 and 10.0-BETA just fine now, thanks! However I've noticed another regression: doing chmod g+w /usr/ports/distfiles in the middle of the tinder run totally confuses it: all build attempts after chmod fail with identical tiny log files: building lcms2-2.5 in directory /usr/home/danfe/tb/9.2-wip make: cannot open /a/ports/Mk/bsd.port.mk. cd: /usr/ports/graphics/lcms2: No such file or directory The reason for a chmod: I normally build ports from a user, and to allow it to fetch distfiles, give write permissions to wheel group. I also do ./tc configDistfile -c /usr/ports/distfiles, and it always changed perms back. It's annoying, but I can live with it: just chmod the damn directory again. chmod'ing in the middle of tinder run is because I often do the runs while installing something from ports manually at the same time. Previously tinderbox simply complained like this in the end of the build log: Fatal error: filesystem was touched prior to 'make install' phase distcache changed permissions expected 0755 found 0775 But this (and subsequent) packages were still built successfully. Now chmod'ing totally screws up the whole (remaining) build. BTW, would it be possible to prevent forcing 0755 perms? I don't really see any point for doing this in the first place... This annoys me for the same reason, and eventually I gave up doing make fetch without sudo :P I would very much like to fix that, so I shall try to see what I can do. I think it may be an mtree thing. Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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
iconv in base breaks multiple ports
Hey all, ever since that iconv thing replaced the ports version, I run into trouble with several ports that I have installed on a -CURRENT (now stable/10 system). These are not compile-time errors, but crashes or limited functionality where I blame iconv :) 1. www/newsbeuter crashes during startup, somewhere in the stfl code that deals with wide char functions. 2. devel/git: when using git-svn, it'll segfault in the perl code, not sure how to get a backtrace here as gdb's follow-fork doesn't quite work. 3. multimedia/xbmc is no longer able to decode unicode filenames and other things are broken. It spews an endless stream of 19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from WCHAR_T to UTF-8, errno=22(Invalid argument) 19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from UTF-8 to WCHAR_T, errno=22(Invalid argument) 19:37:00 T:34594644992 ERROR: Previous line repeats 9656 times. Is my system hexed? I've rebuilt the ports/packages a dozen times now. Am I seeing ghosts? Thanks, Uli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: multimedia/rtmpdump shared lib issue... (now not work)
Andrey Fesenko f0and...@gmail.com wrote in ca+k5srnu5s5zb9_uuhq2kir_vi65ma5fvccpgqw7sfogc20...@mail.gmail.com: f0 This patch http://www.freebsd.org/cgi/query-pr.cgi?pr=180283 now not work f0 f0 # uname -a f0 FreeBSD x220.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r256773: Sun f0 Oct 20 03:42:58 MSK 2013 f0 andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 f0 f0 multimedia/rtmpdump # make install clean f0 === Building for rtmpdump-2.4.20130923 f0 --- librtmp/librtmp.a --- f0 --- rtmpsrv --- f0 cc -Wl,-rpath=/usr/local/lib -L/usr/local/lib -fstack-protector -o f0 rtmpsrv rtmpsrv.o thread.o -pthread -Llibrtmp -lrtmp -lssl -lcrypto f0 -lz f0 /usr/bin/ld: warning: libssl.so.7, needed by f0 /usr/local/lib/librtmp.so, may conflict with libssl.so.8 f0 /usr/bin/ld: warning: libcrypto.so.7, needed by f0 /usr/local/lib/librtmp.so, may conflict with libcrypto.so.8 f0 rtmpsrv.o: In function `doServe': f0 rtmpsrv.c:(.text+0x1955): undefined reference to `RTMP_TLS_Accept' f0 rtmpsrv.o: In function `main': f0 rtmpsrv.c:(.text+0x1e36): undefined reference to `RTMP_TLS_AllocServerContext' f0 rtmpsrv.c:(.text+0x1f67): undefined reference to `RTMP_TLS_FreeServerContext' f0 cc: error: linker command failed with exit code 1 (use -v to see invocation) Do you have openssl port installed on your system? -- Hiroki pgp3wzVvQW3L5.pgp Description: PGP signature
Re: multimedia/rtmpdump shared lib issue... (now not work)
On Sun, Oct 20, 2013 at 10:56 PM, Hiroki Sato h...@freebsd.org wrote: Andrey Fesenko f0and...@gmail.com wrote in ca+k5srnu5s5zb9_uuhq2kir_vi65ma5fvccpgqw7sfogc20...@mail.gmail.com: f0 This patch http://www.freebsd.org/cgi/query-pr.cgi?pr=180283 now not work f0 f0 # uname -a f0 FreeBSD x220.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r256773: Sun f0 Oct 20 03:42:58 MSK 2013 f0 andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 Do you have openssl port installed on your system? -- Hiroki Yes installed, actual version security/openssl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: iconv in base breaks multiple ports
On Sun, 20 Oct 2013 20:27:23 +0200 Ulrich Spörlein wrote:
ever since that iconv thing replaced the ports version, I run into
trouble with several ports that I have installed on a -CURRENT (now
stable/10 system).
These are not compile-time errors, but crashes or limited functionality
where I blame iconv :)
1. www/newsbeuter crashes during startup, somewhere in the stfl code
that deals with wide char functions.
2. devel/git: when using git-svn, it'll segfault in the perl code, not
sure how to get a backtrace here as gdb's follow-fork doesn't quite
work.
3. multimedia/xbmc is no longer able to decode unicode filenames and
other things are broken. It spews an endless stream of
19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from
WCHAR_T to UTF-8, errno=22(Invalid argument)
19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from
UTF-8 to WCHAR_T, errno=22(Invalid argument)
19:37:00 T:34594644992 ERROR: Previous line repeats 9656 times.
Is my system hexed? I've rebuilt the ports/packages a dozen times now.
Am I seeing ghosts?
Can you try the attached patch? It includes the one from
http://www.freebsd.org/cgi/query-pr.cgi?pr=182994
Index: lib/libc/iconv/citrus_mapper.c
===
--- lib/libc/iconv/citrus_mapper.c (revision 256803)
+++ lib/libc/iconv/citrus_mapper.c (working copy)
@@ -341,14 +341,15 @@ _citrus_mapper_open(struct _citrus_mappe
/* open mapper */
UNLOCK(cm_lock);
ret = mapper_open(ma, cm, module, variable);
- WLOCK(cm_lock);
if (ret)
- goto quit;
+ goto quit_unlocked;
+ WLOCK(cm_lock);
cm-cm_key = strdup(mapname);
if (cm-cm_key == NULL) {
ret = errno;
+ UNLOCK(cm_lock);
_mapper_close(cm);
- goto quit;
+ goto quit_unlocked;
}
/* insert to the cache */
@@ -359,7 +360,7 @@ _citrus_mapper_open(struct _citrus_mappe
ret = 0;
quit:
UNLOCK(cm_lock);
-
+quit_unlocked:
return (ret);
}
@@ -381,7 +382,9 @@ _citrus_mapper_close(struct _citrus_mapp
_CITRUS_HASH_REMOVE(cm, cm_entry);
free(cm-cm_key);
}
+ UNLOCK(cm_lock);
mapper_close(cm);
+ return;
quit:
UNLOCK(cm_lock);
}
signature.asc
Description: PGP signature
Hotel reservation needed.
Reservation Department, I am Planning to make a reservation for three separate bedrooms in your hotel for me and my family from 7th/November/2013 to 18th/Vovember/2013. I do need confirmation that the hotel will be able to guarantee that we can stay in a non-smoking unit. (1). Mr and Mrs David (Double room) (2). Sam David (25) years... (Single room) (3). Emma David (23) years... (Single room) 2 SINGLE ROOMS AND 1 DOUBLE ROOM Starting from: 7th/November/2013 to 18th/November/2013.Kindly Quote the price and the conditions, if available calculate the all nights total together, and let me know your method of payment ? or the type of credit card you accept for the booking as we will like to make the payment in advance before our arrival Thanks your anticipation in advance. Best Regard Jackson Conall David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
--On October 20, 2013 9:34:36 AM +0200 John Marino
freebsd.cont...@marino.st wrote:
On 10/20/2013 03:49, Paul Schmehl wrote:
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
I'm the maintainer, and I can assure you I tested it thoroughly. The
port has built without error on many machines before this came up. I've
personally built and tested it numerous times.
With the MYSQL option set on? The default is off, so building the
default configuration numerous times would not have hit this.
Yes, of course it was set. I wouldn't submit a port without testing all
its options, and committers wouldn't commit a port that doesn't build with
any options set.
Nevertheless, I will take a look at what you've discussed and attempt to
determine what the problem is. It appears that something may have
changed in 9.2 that is causing the problem. Unfortunately I don't have
a 9.2 install, so I'll have to set one up before I can test it.
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition.
You're wrong. The RUN_DEPENDS does not have a shell command embedded in it
anywhere.
That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port.
You're pretty sure? Rather than hard code a version, which would break the
port the moment mysqltcl was updated, I chose to use the existing port
version, which would work no matter what version was current on any
particular box.
Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Yes, and that is a problem. I noticed that last night when I was looking
at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD}
$$(${MYSQLTCL_CMDS}).
It looks like that port has changed, however, because it no longer appends
the version number to the name of the port, so I can probably drop that
entirely. I won't know until I test it.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
What do you suggest it be hardcoded to? ${PORTSDIR} can be set to anything
on an individual system. Using your construction forces it to be in
/usr/ports. Although that's the default, it's by no means guaranteed that
the ports tree will exist there on any given system. That's why we use
macros in Makefiles - to avoid forcing users to stick to the default
structure.
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should fail.
It didn't. I can't explain why. (I've slept since I last worked on that
port.) I can assure you I tested the port with the option enabled and it
built and ran fine.
But I doubt seriously that has anything to do with the error that the OP
reported. It's probably related to the change to bmake, which I will have
to investigate, if I have to continue to define the port version for
mysqltcl. It looks like I might not have to any more.
I'll also have to update the port to use the new STAGE syntax, so this will
take a little while.
In the future, I would appreciate it if you adopt a less smug attitude
about somebody else's work. Or take over the port if you think you're so
much better. There's three sguil ports. You're welcome to take over
maintainership if you think you're God's gift to port building.
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: py27-httplib2-0.8
Hello, This seems to be affecting the httplib2 package on FreeBSD as well: https://code.google.com/p/httplib2/issues/detail?id=251 -- Douglas William Thrift doug...@douglasthrift.net http://douglasthrift.net/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: SVN RELEASE_9_2_0
Today I tripped over another package that had broken dependencies even thought It was supposedly a package that was from 9.2-RELEASE release process. It was celestia, installed from 9.2-release packages, which depended on libpangox.so.1. I tried to roll my own. The build was broken too. My question still stands. Is FreeBSD now building packages prior to the actual tagging of the ports tree as RELEASE_9_2_0? It seems like this is the case since the dates of the packages in the FTP archive pre-date the release date. For many many releases now I have run only unmodified -release with the equivalent ports. And it was good. Now I'm having issues with the quality of the ports. I am concerned that it is due to a failure in the release process. I might be wrong. If I'm not, then my request is to not put the cart before the horse and ship ports labelled in the FTP archive as -release when they are really just a snapshot of a point in time close the release date. That's very unFreeBSD like. i.e.: freeze it build it fix it build it no errors? no changes? tag it ship it It seems like we skipped freeze it, fix it, and check for errors. We just built it and shipped it, then later we tagged it for release. Or maybe we never did the above and I personally just got lucky for 4 major versions. I do seem to recall things like ports freeze on the RE schedule. Regards, Jason C. Wells ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: SVN RELEASE_9_2_0
On 10/20/2013 8:42 PM, Jason C. Wells wrote: Today I tripped over another package that had broken dependencies even thought It was supposedly a package that was from 9.2-RELEASE release process. It was celestia, installed from 9.2-release packages, which depended on libpangox.so.1. I tried to roll my own. The build was broken too. My question still stands. Is FreeBSD now building packages prior to the actual tagging of the ports tree as RELEASE_9_2_0? It seems like this is the case since the dates of the packages in the FTP archive pre-date the release date. For many many releases now I have run only unmodified -release with the equivalent ports. And it was good. Now I'm having issues with the quality of the ports. I am concerned that it is due to a failure in the release process. I might be wrong. If I'm not, then my request is to not put the cart before the horse and ship ports labelled in the FTP archive as -release when they are really just a snapshot of a point in time close the release date. That's very unFreeBSD like. i.e.: freeze it build it fix it build it no errors? no changes? tag it ship it It seems like we skipped freeze it, fix it, and check for errors. We just built it and shipped it, then later we tagged it for release. Or maybe we never did the above and I personally just got lucky for 4 major versions. I do seem to recall things like ports freeze on the RE schedule. Regards, Jason C. Wells Yes this was all done. Ports have never been 100% building without error though. Many ports were broken during 9.2 time. 1959 ports (of 24,000) are either failing or broken for upcoming 10. This is why we are now sending out weekly build error emails to maintainers. Absolutely many will be broken in the 10 -release tag still. This is a best effort and there is no stable ports tree. I'm frankly not sure why anyone would run the -release ports tag as it is immediately old, insecure and unsupported. It's not possible for anyone to help fix issues you find there. On the other hand if you report errors in the real ports tree, we can fix them. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 00:47, Paul Schmehl wrote:
--On October 20, 2013 9:34:36 AM +0200 John Marino
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition.
You're wrong. The RUN_DEPENDS does not have a shell command embedded in
it anywhere.
When you indent, it executes the command in the shell. Notice that only
make targets are indented.
That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port.
You're pretty sure? Rather than hard code a version, which would break
the port the moment mysqltcl was updated, I chose to use the existing
port version, which would work no matter what version was current on any
particular box.
Yes, I am sure. You can tell it that the port is the dependency
regardless of version. If you absolutely wanted to specify a file, you
can specify a different one that the file name doesn't change. Yes, you
can a RUN_DEPENDS without that line in ways that are robust.
Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Yes, and that is a problem. I noticed that last night when I was
looking at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD}
$$(${MYSQLTCL_CMDS}).
Again, completely unnecessary. Specify the *NON-INDENTED* RUN_DEPENDS
in a better way.
It looks like that port has changed, however, because it no longer
appends the version number to the name of the port, so I can probably
drop that entirely. I won't know until I test it.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
What do you suggest it be hardcoded to? ${PORTSDIR} can be set to
anything on an individual system. Using your construction forces it to
be in /usr/ports. Although that's the default, it's by no means
guaranteed that the ports tree will exist there on any given system.
That's why we use macros in Makefiles - to avoid forcing users to stick
to the default structure.
I just showed you. Replace ${PORTSDIR} with ${.CURDIR}/../../
I know you haven't believed a thing I've said so far, but using
${PORTSDIR} can break the build in specific configurations. And yes,
we've been replacing it with .CURDIR in other ports.
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should
fail. It didn't. I can't explain why. (I've slept since I last worked
on that port.) I can assure you I tested the port with the option
enabled and it built and ran fine.
So you state previously that it *HAD* to be defined for RUN_DEPENDS to
work, and now state that it wasn't defined but RUN_DEPENDS did work?
Doubtful and easily verifiable. Find an old platform where it worked
and type make -V RUN_DEPENDS and see if mysqltcl is in the list. I
believe it simply wasn't defined which didn't prevent this build from
building (it was indented, remember?). I think the error was masked
with the previous version of make.
But I doubt seriously that has anything to do with the error that the OP
reported. It's probably related to the change to bmake, which I will
have to investigate, if I have to continue to define the port version
for mysqltcl. It looks like I might not have to any more.
I'll also have to update the port to use the new STAGE syntax, so this
will take a little while.
In the future, I would appreciate it if you adopt a less smug attitude
about somebody else's work. Or take over the port if you think you're
so much better. There's three sguil ports. You're welcome to take over
maintainership if you think you're God's gift to port building.
Sigh
I guess you still feel this way after what I just wrote?
What did I do, beside help one of the port's users get going and point
out the problems with it and telling the user to write a PR?
You know, you could have just said, Thank you as I've spent a
considerable time on this topic when nobody else did.
John
___
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
