Re: Port lang/python33 does not build
Le 25/04/2013 04:23, Kubilay Kocak a écrit : > On 24/04/2013 11:18 PM, Florent Peterschmitt wrote: >> The same here. Default options, no CFLAGS tunning, up-to-date ports, >> sams system. >> >> Le 24/04/2013 14:40, Tzanetos Balitsaris a écrit : >>> Hello, >>> >>> The port lang/python33 cannot be built. It stops when it tries to >>> compile the module posixmodule.c >>> >>> cc -DNDEBUG -O2 -pipe -fno-strict-aliasing -O2 -pipe >>> -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -I. >>> -I./../Include -fPIC -DPy_BUILD_CORE -c ./../Modules/posixmodule.c -o >>> Modules/posixmodule.o >>> ./../Modules/posixmodule.c: In function 'posix_waitid': >>> ./../Modules/posixmodule.c:6883: error: 'idtype_t' undeclared (first use >>> in this function) >>> ./../Modules/posixmodule.c:6883: error: (Each undeclared identifier is >>> reported only once >>> ./../Modules/posixmodule.c:6883: error: for each function it appears in.) >>> ./../Modules/posixmodule.c:6883: error: expected ';' before 'idtype' >>> ./../Modules/posixmodule.c:6888: error: 'idtype' undeclared (first use >>> in this function) >>> ./../Modules/posixmodule.c: In function 'all_ins': >>> ./../Modules/posixmodule.c:11497: error: 'P_PID' undeclared (first use >>> in this function) >>> ./../Modules/posixmodule.c:11498: error: 'P_PGID' undeclared (first use >>> in this function) >>> ./../Modules/posixmodule.c:11499: error: 'P_ALL' undeclared (first use >>> in this function) >>> *** [Modules/posixmodule.o] Error code 1 >>> >>> Stop in /usr/ports/lang/python33/work/Python-3.3.0/portbld.shared. >>> *** [pre-build] Error code 1 >>> >>> Stop in /usr/ports/lang/python33. >>> *** [build] Error code 1 >>> >>> Stop in /usr/ports/lang/python33. >>> >>> This happens on a FreeBSD 9.1-RELEASE GENERIC amd64 system. >>> >>> >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >>> ___ >>> 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" >> >> > > Investigated and turned out it was related to the config.site changes > that were committed recently. This overrode what ./configure would have > otherwise found, namely that waitpid was not available. > > waitpid(2) is not in 9.1-RELEASE, but is in stable/9 onward. > > A fix has been committed: http://svnweb.freebsd.org/changeset/ports/316493 > > Please update your ports trees and try the build again. > > Thank you nox for making the link, and bdrewery for taking care of it so > quickly. > > -- > Ta, > > Koobs Build and install OK. Do you have any python script to test if it really works ? signature.asc Description: OpenPGP digital signature
Re: ports/176782: new port: dns/bind10
Synopsis: new port: dns/bind10 Responsible-Changed-From-To: po...@freebsd.org->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 25 09:48:42 UTC 2013 Responsible-Changed-Why: Canonicalize assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=176782 ___ 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: www/nginx pkg-plist + pkgng (detectable?)
On Thu, Apr 25, 2013 at 05:05:53AM +0200, Michael Gmelin wrote: > On Tue, 23 Apr 2013 17:48:52 +0100 > Chris Rees wrote: > > > On 13 April 2013 21:01, Michael Gmelin wrote: > > > On Wed, 10 Apr 2013 13:56:32 +0200 > > > Michael Gmelin wrote: > > > > > >> On Wed, 10 Apr 2013 09:02:29 +0100 > > >> Chris Rees wrote: > > >> > > >> > On 10 April 2013 07:13, Baptiste Daroussin > > >> > wrote: > > >> > > On Tue, Apr 09, 2013 at 08:59:50PM +0200, Michael Gmelin wrote: > > >> > >> On Tue, 9 Apr 2013 19:43:15 +0100 > > >> > >> Chris Rees wrote: > > >> > >> > > >> > >> > > >> > >> > > > >> > >> > No, it's a bug in pkgng; it should respect @cwd. > > >> > >> > > > >> > > > > >> > > No it is not. > > >> > > > > >> > > While i agree with pkgng that should repect @cwd (it surely > > >> > > does) > > >> > > > > >> > > There is nothing written anywhere that will waranty you that > > >> > > the @exec line will be parsed in order ro prepend @cwd path to > > >> > > a path you provide. the only thing doing that is %D. > > >> > > > > >> > > A user MUST add %D and have complete path in @exec lines > > >> > > > > >> > > In fact in that case it works by chance becauce of how > > >> > > pkg_install treat plist. > > >> > > > >> > Am I misunderstanding the meaning of "current working directory"? > > >> > > > >> > When mkdir is called, it should create the directory in @cwd. > > >> > pkg_install's behaviour is correct here, and pkgng's is not. > > >> > > > >> > Chris > > >> > > >> pkg_create(1) says: > > >> > > >> @cwd [directory] > > >> Set the internal directory pointer to point to > > >> directory. All subsequent *filenames* will be assumed relative to > > >> this directory. If no directory argument is given, it will set > > >> the internal directory pointer to the first prefix > > >> value. Note: @cd is also an alias for this command. > > >> > > >> but as far as the package manager is concerned, www/nginx-dist is > > >> an argument to mkdir in the exec call (@exec mkdir -p -m 755 > > >> www/nginx-dist) and not a filename. > > >> > > >> Also the porters handbook uses %D in all its examples, but offers > > >> no explicit explanation. > > >> > > >> That said, the way pkg_add is implemented, it changes to > > >> directories as a side effect of using its PUSHOUT macro in > > >> usr.sbin/pkg_install/add/extract.c (I only glanced at that, but > > >> that seems to be the reason why this is happening). So commands get > > >> executed within `pwd` == @cwd. > > >> > > >> So there is definitely a backwards compatibility problem for the > > >> sheer reason of that "it worked before". I don't thing pkg should > > >> adopt this behavior (it seems like a bad idea long term), but it > > >> should detect it somehow. A simple approach to detect this could > > >> be chdiring to /var/empty in pkg before executing the call so it > > >> will fail in case the path used within @exec is relative. > > >> > > >> Cheers, > > >> Michael > > >> > > > > > > So what now? Is anybody looking into this? Should I open a PR for > > > nginx and supply a patch that fixes this (theoretically it should > > > be applied despite the port freeze, since it's a build problem). > > > > Please do open a PR if you haven't already. > > Done, http://www.freebsd.org/cgi/query-pr.cgi?pr=178123 > > > > > > Regarding pkgng: Will anybody consider implementing automatic > > > checks to prevent something like this from happening (e.g. the > > > simplistic approach I suggested). Even if the files wouldn't be > > > left behind, the fact that something gets touched in pwd is really > > > bad - as an admin it should be safe to assume that I can start pkg > > > from any directory without altering it state (and be it > > > temporarily). > > > > I think a patch to portlint wouldn't go amiss. > > > > Feel up to the challenge? > > I won't touch portlint, but I implemented a small patch to pkg that > will mitigate some of the bad effects in an extremely trivial way, so > in the example at hand, instead of creating files/directories in > whichever pwd you started pkg from, it will show now: > > pkg add /tmp/nginx-1.2.7_1,1.txz > Installing nginx-1.2.7_1,1...===> Creating users and/or groups. > Using existing group 'www'. > Using existing user 'www'. > mkdir: www: Operation not permitted > chmod: www/nginx-dist: No such file or directory > done > > So: > a) You don't write files in a possibly very inappropriate/dangerous >place > b) Due to the error messages you might become aware that there's >something wrong > > I'll send the patch to Baptiste (Cc you) off list. > We already have a fix in pkgng now :) thanks, Bapt pgpdLQL5tjDT3.pgp Description: PGP signature
FreeBSD Port: devel/libcheck - bug in package
Hi! I don't know if the maintainer of devel/libcheck is active, so I forward this report to po...@freebsd.org, hoping that someone will look into it. /Martin -Ursprungligt meddelande- Från: Martin Olsson [mailto:martin.ols...@sentor.se] Skickat: den 24 april 2013 12:24 Till: 'sunp...@freebsd.org' Ämne: FreeBSD Port: devel/libcheck - bug in package Hi! I just wanted to report a bug I found when recompiling all packets on my FreeBSD 9.1 i386. I run: portmaster --no-confirm -adgf gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' gmake[2]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' gmake[2]: Nothing to be done for `install-exec-am'. test -z "/usr/local/share/doc/libcheck" || /bin/mkdir -p "/usr/local/share/doc/libcheck" install -o root -g wheel -m 444 SVNChangeLog ChangeLog ChangeLogOld NEWS README '/usr/local/share/doc/libcheck' test -z "/usr/local/share/aclocal" || /bin/mkdir -p "/usr/local/share/aclocal" install -o root -g wheel -m 444 check.m4 '/usr/local/share/aclocal' test -z "/usr/local/libdata/pkgconfig" || /bin/mkdir -p "/usr/local/libdata/pkgconfig" install -o root -g wheel -m 444 check.pc '/usr/local/libdata/pkgconfig' gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' Making install in checkmk gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' gmake[2]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin" test -z "/usr/local/man/man1" || /bin/mkdir -p "/usr/local/man/man1" install -o root -g wheel -m 444 doc/checkmk.1 '/usr/local/man/man1' gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' Making install in tests gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[2]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[2]: Nothing to be done for `install-exec-am'. gmake[2]: Nothing to be done for `install-data-am'. gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' install-info --quiet /usr/local/info/check.info /usr/local/info/dir ===> Compressing manual pages for libcheck-0.9.9 ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib ===> Registering installation for libcheck-0.9.9 ===>>> Creating a package for new version libcheck-0.9.9 tar: bin/checkmk: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 ===>>> Package creation of libcheck-0.9.9 failed ===>>> Aborting update ===>>> Update for devel/libcheck failed ===>>> Aborting update ===>>> Killing background jobs Terminated So it seems like the compilation is fine. However, when portmaster is trying to create a package for libcheck-0.9.9, it fails. /Martin smime.p7s Description: S/MIME cryptographic signature
Re: FreeBSD Port: devel/libcheck - bug in package
On Thu, Apr 25, 2013 at 03:01:24PM +0200, Martin Olsson wrote: > Hi! > I don't know if the maintainer of devel/libcheck is active, so I forward > this report to po...@freebsd.org, hoping that someone will look into it. > > /Martin > > -Ursprungligt meddelande- > Från: Martin Olsson [mailto:martin.ols...@sentor.se] > Skickat: den 24 april 2013 12:24 > Till: 'sunp...@freebsd.org' > Ämne: FreeBSD Port: devel/libcheck - bug in package > > Hi! > > I just wanted to report a bug I found when recompiling all packets on my > FreeBSD 9.1 i386. > > I run: > portmaster --no-confirm -adgf > > > gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' > gmake[2]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' > gmake[2]: Nothing to be done for `install-exec-am'. > test -z "/usr/local/share/doc/libcheck" || /bin/mkdir -p > "/usr/local/share/doc/libcheck" > install -o root -g wheel -m 444 SVNChangeLog ChangeLog ChangeLogOld NEWS > README '/usr/local/share/doc/libcheck' > test -z "/usr/local/share/aclocal" || /bin/mkdir -p > "/usr/local/share/aclocal" > install -o root -g wheel -m 444 check.m4 '/usr/local/share/aclocal' > test -z "/usr/local/libdata/pkgconfig" || /bin/mkdir -p > "/usr/local/libdata/pkgconfig" > install -o root -g wheel -m 444 check.pc '/usr/local/libdata/pkgconfig' > gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' > gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' > Making install in checkmk > gmake[1]: Entering directory > `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' > gmake[2]: Entering directory > `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' > test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin" > test -z "/usr/local/man/man1" || /bin/mkdir -p "/usr/local/man/man1" > install -o root -g wheel -m 444 doc/checkmk.1 '/usr/local/man/man1' > gmake[2]: Leaving directory > `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' > gmake[1]: Leaving directory > `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' > Making install in tests > gmake[1]: Entering directory > `/usr/ports/devel/libcheck/work/check-0.9.9/tests' > gmake[2]: Entering directory > `/usr/ports/devel/libcheck/work/check-0.9.9/tests' > gmake[2]: Nothing to be done for `install-exec-am'. > gmake[2]: Nothing to be done for `install-data-am'. > gmake[2]: Leaving directory > `/usr/ports/devel/libcheck/work/check-0.9.9/tests' > gmake[1]: Leaving directory > `/usr/ports/devel/libcheck/work/check-0.9.9/tests' > install-info --quiet /usr/local/info/check.info /usr/local/info/dir > ===> Compressing manual pages for libcheck-0.9.9 > ===> Running ldconfig > /sbin/ldconfig -m /usr/local/lib > ===> Registering installation for libcheck-0.9.9 > > ===>>> Creating a package for new version libcheck-0.9.9 > tar: bin/checkmk: Cannot stat: No such file or directory > tar: Error exit delayed from previous errors. > pkg_create: make_dist: tar command failed with code 256 > > ===>>> Package creation of libcheck-0.9.9 failed > ===>>> Aborting update > > ===>>> Update for devel/libcheck failed > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > > So it seems like the compilation is fine. > However, when portmaster is trying to create a package for libcheck-0.9.9, > it fails. > > /Martin This has been fixed, please update your ports tree. regards, Bapt pgpG2Sm21vFEN.pgp Description: PGP signature
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ textproc/py-jaxml | 3.02| 11.00 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: devel/libcheck - bug in package
This has been fixed, please update your ports tree. Hi Baptiste! I have updated the ports tree. Still same error. :-/ # portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Ports tree hasn't changed since last snapshot. No updates needed. Ports tree is already up to date. # portmaster --no-confirm -adgf ... ... /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o ex_output ex_output.o ../src/libcheck.la ../lib/libcompat.la -lrt libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o .libs/ex_output ex_output.o ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath -Wl,/usr/local/lib cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -MT ex_xml_output.o -MD -MP -MF .deps/ex_xml_output.Tpo -c -o ex_xml_output.o ex_xml_output.c mv -f .deps/ex_xml_output.Tpo .deps/ex_xml_output.Po /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o ex_xml_output ex_xml_output.o ../src/libcheck.la ../lib/libcompat.la -lrt libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o .libs/ex_xml_output ex_xml_output.o ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath -Wl,/usr/local/lib cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -MT ex_log_output.o -MD -MP -MF .deps/ex_log_output.Tpo -c -o ex_log_output.o ex_log_output.c mv -f .deps/ex_log_output.Tpo .deps/ex_log_output.Po /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o ex_log_output ex_log_output.o ../src/libcheck.la ../lib/libcompat.la -lrt libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o .libs/ex_log_output ex_log_output.o ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath -Wl,/usr/local/lib gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' ===>>> Creating a backup package for old version libcheck-0.9.9 tar: bin/checkmk: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 ===>>> Package creation failed for libcheck-0.9.9! ===>>> Ignore this error [i] ===>>> Abort update [a] ===>>> Retry [r] ===>>> How would you like to proceed? [i] Anything I can do to analyse this further for you? (I'm no programmer, though) /Martin On Thu, 25 Apr 2013, Baptiste Daroussin wrote: On Thu, Apr 25, 2013 at 03:01:24PM +0200, Martin Olsson wrote: Hi! I don't know if the maintainer of devel/libcheck is active, so I forward this report to po...@freebsd.org, hoping that someone will look into it. /Martin -Ursprungligt meddelande- Från: Martin Olsson [mailto:martin.ols...@sentor.se] Skickat: den 24 april 2013 12:24 Till: 'sunp...@freebsd.org' Ämne: FreeBSD Port: devel/libcheck - bug in package Hi! I just wanted to report a bug I found when recompiling all packets on my FreeBSD 9.1 i386. I run: portmaster --no-confirm -adgf gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' gmake[2]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' gmake[2]: Nothing to be done for `install-exec-am'. test -z "/usr/local/share/doc/libcheck" || /bin/mkdir -p "/usr/local/share/doc/libcheck" install -o root -g wheel -m 444 SVNChangeLog ChangeLog ChangeLogOld NEWS README '/usr/local/share/doc/libcheck' test -z "/usr/local/share/aclocal" || /bin/mkdir -p "/usr/local/share/aclocal" install -o root -g wheel -m 444 check.m4 '/usr/local/share/aclocal' test -z "/usr/local/libdata/pkgconfig" || /bin/mkdir -p "/usr/local/libdata/pkgconfig" install -o root -g wheel -m 444 check.pc '/usr/local/libdata/pkgconfig' gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' Making install in checkmk gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9/checkmk' gmake[2]: Entering dire
Re: FreeBSD Port: devel/libcheck - bug in package
On Thu, Apr 25, 2013 at 03:55:16PM +0200, Martin Olsson wrote: > > > This has been fixed, please update your ports tree. > > Hi Baptiste! > > I have updated the ports tree. Still same error. :-/ > > > # portsnap fetch update > Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. > Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. > Ports tree hasn't changed since last snapshot. > No updates needed. > Ports tree is already up to date. > > # portmaster --no-confirm -adgf > ... > ... > > /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe > -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o ex_output > ex_output.o ../src/libcheck.la ../lib/libcompat.la -lrt > libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic > -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings > -Wno-variadic-macros -o .libs/ex_output ex_output.o > ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath > -Wl,/usr/local/lib > cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -O2 -pipe > -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -MT > ex_xml_output.o -MD -MP -MF .deps/ex_xml_output.Tpo -c -o ex_xml_output.o > ex_xml_output.c > mv -f .deps/ex_xml_output.Tpo .deps/ex_xml_output.Po > /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe > -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o > ex_xml_output ex_xml_output.o ../src/libcheck.la ../lib/libcompat.la -lrt > libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic > -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings > -Wno-variadic-macros -o .libs/ex_xml_output ex_xml_output.o > ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath > -Wl,/usr/local/lib > cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -O2 -pipe > -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -MT > ex_log_output.o -MD -MP -MF .deps/ex_log_output.Tpo -c -o ex_log_output.o > ex_log_output.c > mv -f .deps/ex_log_output.Tpo .deps/ex_log_output.Po > /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe > -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o > ex_log_output ex_log_output.o ../src/libcheck.la ../lib/libcompat.la -lrt > libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic > -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings > -Wno-variadic-macros -o .libs/ex_log_output ex_log_output.o > ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath > -Wl,/usr/local/lib > gmake[2]: Leaving directory > `/usr/ports/devel/libcheck/work/check-0.9.9/tests' > gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' > > ===>>> Creating a backup package for old version libcheck-0.9.9 > tar: bin/checkmk: Cannot stat: No such file or directory > tar: Error exit delayed from previous errors. > pkg_create: make_dist: tar command failed with code 256 > > ===>>> Package creation failed for libcheck-0.9.9! > > ===>>> Ignore this error [i] > ===>>> Abort update [a] > ===>>> Retry [r] > > ===>>> How would you like to proceed? [i] > > > Anything I can do to analyse this further for you? > (I'm no programmer, though) > > /Martin > > > On Thu, 25 Apr 2013, Baptiste Daroussin wrote: > > > On Thu, Apr 25, 2013 at 03:01:24PM +0200, Martin Olsson wrote: > >> Hi! > >> I don't know if the maintainer of devel/libcheck is active, so I forward > >> this report to po...@freebsd.org, hoping that someone will look into it. > >> > >> /Martin > >> > >> -Ursprungligt meddelande- > >> Från: Martin Olsson [mailto:martin.ols...@sentor.se] > >> Skickat: den 24 april 2013 12:24 > >> Till: 'sunp...@freebsd.org' > >> Ämne: FreeBSD Port: devel/libcheck - bug in package > >> > >> Hi! > >> > >> I just wanted to report a bug I found when recompiling all packets on my > >> FreeBSD 9.1 i386. > >> > >> I run: > >> portmaster --no-confirm -adgf > >> > >> > >> gmake[1]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' > >> gmake[2]: Entering directory `/usr/ports/devel/libcheck/work/check-0.9.9' > >> gmake[2]: Nothing to be done for `install-exec-am'. > >> test -z "/usr/local/share/doc/libcheck" || /bin/mkdir -p > >> "/usr/local/share/doc/libcheck" > >> install -o root -g wheel -m 444 SVNChangeLog ChangeLog ChangeLogOld NEWS > >> README '/usr/local/share/doc/libcheck' > >> test -z "/usr/local/share/aclocal" || /bin/mkdir -p > >> "/usr/local/share/aclocal" > >> install -o root -g wheel -m 444 check.m4 '/usr/local/share/aclocal' > >> test -z "/usr/local/libdata/pkgconfig" || /bin/mkdir -p
Re: FreeBSD Port: devel/libcheck - bug in package
On Thu, Apr 25, 2013 at 04:41:34PM +0200, Martin Olsson wrote: > On Thu, 25 Apr 2013, Baptiste Daroussin wrote: > > Can you send me your config.log and the Makefile of libcheck (the port one) > > I removed the work dir > I updated the port tree again > I ran 'portmaster --no-confirm -adgf' again and get: > > /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe > -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o > ex_log_output ex_log_output.o ../src/libcheck.la ../lib/libcompat.la -lrt > libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic > -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings > -Wno-variadic-macros -o .libs/ex_log_output ex_log_output.o > ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath > -Wl,/usr/local/lib > gmake[2]: Leaving directory > `/usr/ports/devel/libcheck/work/check-0.9.9/tests' > gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' > > ===>>> Creating a backup package for old version libcheck-0.9.9 > tar: bin/checkmk: Cannot stat: No such file or directory > tar: Error exit delayed from previous errors. > pkg_create: make_dist: tar command failed with code 256 > > ===>>> Package creation failed for libcheck-0.9.9! > > ===>>> Ignore this error [i] > ===>>> Abort update [a] > ===>>> Retry [r] > > ===>>> How would you like to proceed? [i] a > > > ===>>> Package creation failed for libcheck-0.9.9 > ===>>> Aborting update > > ===>>> Update for devel/libcheck failed > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > > > So, as I was saying, the compile seem to go fine. > It is the creation of the package that bails (-g option to portmaster). > > > In /usr/ports/devel/libcheck/pkg-plist I see a reference to "bin/checkmk". > Should this be just "checkmk" without the "bin/" subdir perhaps? 'Cause I > see in my work dir that the dir checkmk/ exists there, without a > prepending bin dir: > -rwxr-xr-x 1 root wheel 9210 Apr 25 14:21 > /usr/ports/devel/libcheck/work/check-0.9.9/checkmk/checkmk* > > > Anyhow, see attached files. I don't get it, config.log is normal, and doing what is expected I tried on 2 of my systems and it works ok. I'll continue searching but without being able to reproduce it is hard. regards, Bapt pgpekdScdtN6R.pgp Description: PGP signature
Re: math/ggobi does not build, if graphics/graphviz installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/25/13 1:39 AM, Rainer Hurling wrote: > Am 24.04.2013 22:53 (UTC+1) schrieb Greg Larkin: >> On 4/24/13 1:38 PM, Rainer Hurling wrote: >>> Oops, sorry for answering myself. But the typo gremlin >>> appeared. >> >>> On 23.04.2013 18:38 (UTC+2), Rainer Hurling wrote: Dear developers, I am the maintainer of math/ggobi and I could need some help for a longstanding problem with the build of ggobi (not seen by tinderbox): With graphics/graphviz installed, math/ggobi finds this external installation by its configure script in plugins/GraphLayout. Then it tries to use it instead of its internal graphviz version and fails when trying to build the port. >> >>> The configure also sets HAVE_LIBGVC=1. >> The diff between graphics/graphviz/Makefile with/without external >>> ^^ plugins/GraphLayout/Makefile >> graphviz found is like this (the first version does not build): 158,159c158,159 < LIBGVC_CFLAGS = -I/usr/local/include/graphviz < LIBGVC_LIBS = -L/usr/local/lib/graphviz -lgvc -lgraph -lcdt --- > LIBGVC_CFLAGS = LIBGVC_LIBS = I am looking for either an elegant way to forbid this configure script to use the external graphviz or to use the external graphviz correctly, when installed. If this would be possible, an option in the ports Makefile could switch between them (and install external graphviz, if wanted). Could someone with more experience be so kind to push me in the right direction, please. Many thanks in advance, Rainer Hurling >> >> Hi Rainer, >> >> Can you post an excerpt of the build failure log file when >> math/ggobi attempts to build graphics/graphviz? > > Hi Greg, > > I created an excerpt of the build log and put it together with > config.log as a zip in the attachment. > > Please tell me, if I should provide more information. > > Many thanks for your answer, Rainer > >> >> Thank you, Greg >> Hi Rainer, Can you send all config.log files that appear in the ggobi work directory? That would include any that appear in the plugin build subdirectories. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF5RXcACgkQ0sRouByUApAQ+ACgkPX545xFUg1dbcYOT1lIRoZR wlMAoKo/+oaQDv7lslZBYhn/iPQ6RdR+ =dGHg -END PGP SIGNATURE- ___ 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: devel/libcheck - bug in package
On Thu, 25 Apr 2013, Baptiste Daroussin wrote: On Thu, Apr 25, 2013 at 04:41:34PM +0200, Martin Olsson wrote: On Thu, 25 Apr 2013, Baptiste Daroussin wrote: Can you send me your config.log and the Makefile of libcheck (the port one) I removed the work dir I updated the port tree again I ran 'portmaster --no-confirm -adgf' again and get: /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o ex_log_output ex_log_output.o ../src/libcheck.la ../lib/libcompat.la -lrt libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o .libs/ex_log_output ex_log_output.o ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath -Wl,/usr/local/lib gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' ===>>> Creating a backup package for old version libcheck-0.9.9 tar: bin/checkmk: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 ===>>> Package creation failed for libcheck-0.9.9! ===>>> Ignore this error [i] ===>>> Abort update [a] ===>>> Retry [r] ===>>> How would you like to proceed? [i] a ===>>> Package creation failed for libcheck-0.9.9 ===>>> Aborting update ===>>> Update for devel/libcheck failed ===>>> Aborting update ===>>> Killing background jobs Terminated So, as I was saying, the compile seem to go fine. It is the creation of the package that bails (-g option to portmaster). In /usr/ports/devel/libcheck/pkg-plist I see a reference to "bin/checkmk". Should this be just "checkmk" without the "bin/" subdir perhaps? 'Cause I see in my work dir that the dir checkmk/ exists there, without a prepending bin dir: -rwxr-xr-x 1 root wheel 9210 Apr 25 14:21 /usr/ports/devel/libcheck/work/check-0.9.9/checkmk/checkmk* Anyhow, see attached files. I don't get it, config.log is normal, and doing what is expected I tried on 2 of my systems and it works ok. I'll continue searching but without being able to reproduce it is hard. Does it have something to do with creating a backup package for ***old*** version of libcheck-0.9.9 ? If I compare the above with another port, that is sucessful, it looks like this: ===>>> Creating a backup package for old version hping-2.0.0r3,1 ===>>> Starting check for runtime dependencies ===>>> Gathering dependency list for net/hping from ports ===>>> No dependencies for net/hping ===> Installing for hping-2.0.0r3,1 ===> Generating temporary packing list ===> Checking if net/hping already installed ===> Compressing manual pages for hping-2.0.0r3,1 ===> Registering installation for hping-2.0.0r3,1 ===>>> Creating a package for new version hping-2.0.0r3,1 ===>>> Package saved to /usr/ports/packages/All ===>>> Re-installation of hping-2.0.0r3,1 succeeded /Martin ___ 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: devel/libcheck - bug in package
Well, I don't know what the problem was. But if I chose to [i]gnore the fault instead of [a]bort the whole run, a new package was created sucessfully. If I then re-ran the command to rebuild libcheck, it worked fine, probably because it could now sucessfully create that backup of the old version: portmaster --no-confirm -dg devel/libcheck gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' ===>>> Creating a backup package for old version libcheck-0.9.9 # No error creating the backup package of the old version # ===> Installing for libcheck-0.9.9 ===> Generating temporary packing list ===> Checking if devel/libcheck already installed ===> Compressing manual pages for libcheck-0.9.9 ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib ===> Registering installation for libcheck-0.9.9 ===>>> Creating a package for new version libcheck-0.9.9 ===>>> Package saved to /usr/ports/packages/All ===>>> Re-installation of libcheck-0.9.9 complete ===>>> Exiting So, I no longer have the problem. I'm still curious as to how it was introduced though. I do *nothing* out of the ordinary in the ports tree. /Martin On Thu, 25 Apr 2013, Baptiste Daroussin wrote: On Thu, Apr 25, 2013 at 04:41:34PM +0200, Martin Olsson wrote: On Thu, 25 Apr 2013, Baptiste Daroussin wrote: Can you send me your config.log and the Makefile of libcheck (the port one) I removed the work dir I updated the port tree again I ran 'portmaster --no-confirm -adgf' again and get: /bin/sh ../libtool --tag=CC --mode=link cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o ex_log_output ex_log_output.o ../src/libcheck.la ../lib/libcompat.la -lrt libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o .libs/ex_log_output ex_log_output.o ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath -Wl,/usr/local/lib gmake[2]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9/tests' gmake[1]: Leaving directory `/usr/ports/devel/libcheck/work/check-0.9.9' ===>>> Creating a backup package for old version libcheck-0.9.9 tar: bin/checkmk: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 ===>>> Package creation failed for libcheck-0.9.9! ===>>> Ignore this error [i] ===>>> Abort update [a] ===>>> Retry [r] ===>>> How would you like to proceed? [i] a ===>>> Package creation failed for libcheck-0.9.9 ===>>> Aborting update ===>>> Update for devel/libcheck failed ===>>> Aborting update ===>>> Killing background jobs Terminated So, as I was saying, the compile seem to go fine. It is the creation of the package that bails (-g option to portmaster). In /usr/ports/devel/libcheck/pkg-plist I see a reference to "bin/checkmk". Should this be just "checkmk" without the "bin/" subdir perhaps? 'Cause I see in my work dir that the dir checkmk/ exists there, without a prepending bin dir: -rwxr-xr-x 1 root wheel 9210 Apr 25 14:21 /usr/ports/devel/libcheck/work/check-0.9.9/checkmk/checkmk* Anyhow, see attached files. I don't get it, config.log is normal, and doing what is expected I tried on 2 of my systems and it works ok. I'll continue searching but without being able to reproduce it is hard. regards, Bapt ___ 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: A package for the ubuntu-font port?
On 25 April 2013 04:40, Grant D. Watson wrote: > Ports folks, > > I sent a message to Kevin Lo, since the ports search site lists his address > for ubuntu-font, but he said this isn't his area. > > I am a Linux user who's been playing with FreeBSD and enjoying it; in > creating and destroying experimental VMs I've made great use of binary > packages. For some reason the ubuntu-font port is not available as a > package. Would that be difficult to change? It's no hardship to > install it from ports of course, but having it as a package would be > convenient. > There's no reason it shouldn't have a package build, I think you'll just have to wait until the full package sets are up for use. If you can't wait, I built some amd64 ones for you :) http://www.bayofrum.net/tb/index.php?action=describe_port&id=2405 Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Change design of py-* ruby-* ports
Hello,
Currently the ports tree has unified ports for python and ruby modules with
origin like databases/py-sqlalchemy. When someone wants to bulk the ports tree
to create packages the databases/py-sqlalchemy will only be built against the
current python version set in Mk/bsd.python.mk (or overriden in make.conf).
This is a very bad design and we should fix that as soon as possible, we are a
lot of people and some portmgr folks included that is not the best way to
manage python / ruby modules.
Let say I want to install a package, unfortunately this one requires some
python modules that are only working for python 2.7 but me as a developer I
want to develop with python 3, then we are stuck.
What we need to do now, is to move *all* py-* and ruby-* to their respective
versions i.e py27-* and ruby19 (or 18?).
Then we will need to copy all of these and set them to the newer version so
py33 and ruby20.
Also this will remove the breakage of OPTIONS, all of these ports needs the
dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
This will blow out the ports tree by adding a lot of ports, but it's the best
way to cover the both version and future bulk generation for users.
Regards,
--
David Demelier
___
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: Change design of py-* ruby-* ports
On 25/04/2013 22:03, David Demelier wrote:
> Hello,
>
> Currently the ports tree has unified ports for python and ruby modules with
> origin like databases/py-sqlalchemy. When someone wants to bulk the ports
> tree
> to create packages the databases/py-sqlalchemy will only be built against the
> current python version set in Mk/bsd.python.mk (or overriden in make.conf).
>
> This is a very bad design and we should fix that as soon as possible, we are
> a
> lot of people and some portmgr folks included that is not the best way to
> manage python / ruby modules.
>
> Let say I want to install a package, unfortunately this one requires some
> python modules that are only working for python 2.7 but me as a developer I
> want to develop with python 3, then we are stuck.
>
> What we need to do now, is to move *all* py-* and ruby-* to their respective
> versions i.e py27-* and ruby19 (or 18?).
>
> Then we will need to copy all of these and set them to the newer version so
> py33 and ruby20.
>
> Also this will remove the breakage of OPTIONS, all of these ports needs the
> dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
>
> This will blow out the ports tree by adding a lot of ports, but it's the best
> way to cover the both version and future bulk generation for users.
>
> Regards,
>
I agree with you. I thought about a PYTHON_VERSION="27 33" variable in
/etc/make.conf, generating each version of the module for each python
version if the port is able to do it, but then you may build versions of
module you don't need.
But before (don't know when), it was like you say. py27-, py26, and
everything merged to py-
I was not as implied as now in FreeBSD project but it was surelly
motivated by something.
--
Florent Peterschmitt
+33 (0)6 64 33 97 92
flor...@peterschmitt.fr
O< ascii ribbon campaign
- stop html mail
- www.asciiribbon.org
signature.asc
Description: OpenPGP digital signature
Re: Change design of py-* ruby-* ports
Le jeudi 25 avril 2013 22:13:16 Florent Peterschmitt a écrit :
> On 25/04/2013 22:03, David Demelier wrote:
> > Hello,
> >
> > Currently the ports tree has unified ports for python and ruby modules
> > with
> > origin like databases/py-sqlalchemy. When someone wants to bulk the ports
> > tree to create packages the databases/py-sqlalchemy will only be built
> > against the current python version set in Mk/bsd.python.mk (or overriden
> > in make.conf).
> >
> > This is a very bad design and we should fix that as soon as possible, we
> > are a lot of people and some portmgr folks included that is not the best
> > way to manage python / ruby modules.
> >
> > Let say I want to install a package, unfortunately this one requires some
> > python modules that are only working for python 2.7 but me as a developer
> > I
> > want to develop with python 3, then we are stuck.
> >
> > What we need to do now, is to move *all* py-* and ruby-* to their
> > respective versions i.e py27-* and ruby19 (or 18?).
> >
> > Then we will need to copy all of these and set them to the newer version
> > so
> > py33 and ruby20.
> >
> > Also this will remove the breakage of OPTIONS, all of these ports needs
> > the
> > dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
> >
> > This will blow out the ports tree by adding a lot of ports, but it's the
> > best way to cover the both version and future bulk generation for users.
> >
> > Regards,
>
> I agree with you. I thought about a PYTHON_VERSION="27 33" variable in
> /etc/make.conf, generating each version of the module for each python
> version if the port is able to do it, but then you may build versions of
> module you don't need.
>
This is something I think about too, but I'm not sure if it will be easy to
generate make package creating two ones for each version?
And if a port requires a py- module but for a specific version, how is it
possible to share PYTHON_VERSION= through dependencies?
> But before (don't know when), it was like you say. py27-, py26, and
> everything merged to py-
>
> I was not as implied as now in FreeBSD project but it was surelly
> motivated by something.
--
David Demelier
___
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/ggobi does not build, if graphics/graphviz installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/25/13 12:02 PM, Rainer Hurling wrote: > On 25.04.2013 17:02 (UTC+2), Greg Larkin wrote: >> On 4/25/13 1:39 AM, Rainer Hurling wrote: >>> Am 24.04.2013 22:53 (UTC+1) schrieb Greg Larkin: On 4/24/13 1:38 PM, Rainer Hurling wrote: > Oops, sorry for answering myself. But the typo gremlin > appeared. > On 23.04.2013 18:38 (UTC+2), Rainer Hurling wrote: >> Dear developers, >> >> I am the maintainer of math/ggobi and I could need some >> help for a longstanding problem with the build of ggobi >> (not seen by tinderbox): >> >> With graphics/graphviz installed, math/ggobi finds this >> external installation by its configure script in >> plugins/GraphLayout. Then it tries to use it instead of >> its internal graphviz version and fails when trying to >> build the port. > The configure also sets HAVE_LIBGVC=1. >> >> The diff between graphics/graphviz/Makefile with/without >> external > ^^ plugins/GraphLayout/Makefile >> graphviz found is like this (the first version does not >> build): >> >> 158,159c158,159 < LIBGVC_CFLAGS = >> -I/usr/local/include/graphviz < LIBGVC_LIBS = >> -L/usr/local/lib/graphviz -lgvc -lgraph -lcdt --- >>> LIBGVC_CFLAGS = LIBGVC_LIBS = >> >> >> I am looking for either an elegant way to forbid this >> configure script to use the external graphviz or to use >> the external graphviz correctly, when installed. >> >> If this would be possible, an option in the ports >> Makefile could switch between them (and install external >> graphviz, if wanted). >> >> Could someone with more experience be so kind to push me >> in the right direction, please. >> >> Many thanks in advance, Rainer Hurling Hi Rainer, Can you post an excerpt of the build failure log file when math/ggobi attempts to build graphics/graphviz? >> >>> Hi Greg, >> >>> I created an excerpt of the build log and put it together with >>> config.log as a zip in the attachment. >> >>> Please tell me, if I should provide more information. >> >>> Many thanks for your answer, Rainer >> Thank you, Greg >> >> Hi Rainer, >> >> Can you send all config.log files that appear in the ggobi work >> directory? That would include any that appear in the plugin >> build subdirectories. > > Yep, of course. The attached zip should contain them all. > > Thanks again, Rainer > >> >> Thank you, Greg Hi Rainer, There doesn't appear to be an easy way to convince plugins/GraphLayout/configure to ignore an already-installed version of graphviz, and I don't see any patches for ggobi that enable it to support new versions of graphviz. At this point, I would add a post-configure target to the port Makefile and use it to patch plugins/GraphLayout/Makefile and plugins/GraphLayout/config.h to remove support for libgvc. I did that manually, and I was able to build the plugin by hand with graphviz still installed. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF5lGMACgkQ0sRouByUApDORACffqcxz3oX/3NMlgl5DzvsEdWz jggAoIknzIivDLQyNHPdK4/mdFojx4TI =hWTc -END PGP SIGNATURE- ___ 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/ggobi does not build, if graphics/graphviz installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/25/13 12:02 PM, Rainer Hurling wrote: > On 25.04.2013 17:02 (UTC+2), Greg Larkin wrote: >> On 4/25/13 1:39 AM, Rainer Hurling wrote: >>> Am 24.04.2013 22:53 (UTC+1) schrieb Greg Larkin: On 4/24/13 1:38 PM, Rainer Hurling wrote: > Oops, sorry for answering myself. But the typo gremlin > appeared. > On 23.04.2013 18:38 (UTC+2), Rainer Hurling wrote: >> Dear developers, >> >> I am the maintainer of math/ggobi and I could need some >> help for a longstanding problem with the build of ggobi >> (not seen by tinderbox): >> >> With graphics/graphviz installed, math/ggobi finds this >> external installation by its configure script in >> plugins/GraphLayout. Then it tries to use it instead of >> its internal graphviz version and fails when trying to >> build the port. > The configure also sets HAVE_LIBGVC=1. >> >> The diff between graphics/graphviz/Makefile with/without >> external > ^^ plugins/GraphLayout/Makefile >> graphviz found is like this (the first version does not >> build): >> >> 158,159c158,159 < LIBGVC_CFLAGS = >> -I/usr/local/include/graphviz < LIBGVC_LIBS = >> -L/usr/local/lib/graphviz -lgvc -lgraph -lcdt --- >>> LIBGVC_CFLAGS = LIBGVC_LIBS = >> >> >> I am looking for either an elegant way to forbid this >> configure script to use the external graphviz or to use >> the external graphviz correctly, when installed. >> >> If this would be possible, an option in the ports >> Makefile could switch between them (and install external >> graphviz, if wanted). >> >> Could someone with more experience be so kind to push me >> in the right direction, please. >> >> Many thanks in advance, Rainer Hurling Hi Rainer, Can you post an excerpt of the build failure log file when math/ggobi attempts to build graphics/graphviz? >> >>> Hi Greg, >> >>> I created an excerpt of the build log and put it together with >>> config.log as a zip in the attachment. >> >>> Please tell me, if I should provide more information. >> >>> Many thanks for your answer, Rainer >> Thank you, Greg >> >> Hi Rainer, >> >> Can you send all config.log files that appear in the ggobi work >> directory? That would include any that appear in the plugin >> build subdirectories. > > Yep, of course. The attached zip should contain them all. > > Thanks again, Rainer > >> >> Thank you, Greg Hi Rainer, There doesn't appear to be an easy way to convince plugins/GraphLayout/configure to ignore an already-installed version of graphviz, and I don't see any patches for ggobi that enable it to support new versions of graphviz. At this point, I would add a post-configure target to the port Makefile and use it to patch plugins/GraphLayout/Makefile and plugins/GraphLayout/config.h to remove support for libgvc. I did that manually, and I was able to build the plugin by hand with graphviz still installed. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF5lNQACgkQ0sRouByUApDbwwCfQhef13FAX/lfSjci+ouwLrB2 soQAnRGaiax5BN2bAWJruoc6+9nk7Mx6 =Lkg9 -END PGP SIGNATURE- ___ 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: Change design of py-* ruby-* ports
On, Thu Apr 25, 2013, David Demelier wrote:
> Hello,
>
> Currently the ports tree has unified ports for python and ruby modules with
> origin like databases/py-sqlalchemy. When someone wants to bulk the
> ports tree to create packages the databases/py-sqlalchemy will only
> be built against the current python version set in Mk/bsd.python.mk
> (or overriden in make.conf).
Or at the command-line for indiviual ports.
> This is a very bad design and we should fix that as soon as possible,
> we are a lot of people and some portmgr folks included that is not the
> best way to manage python / ruby modules.
>
> Let say I want to install a package, unfortunately this one requires some
> python modules that are only working for python 2.7 but me as a developer I
> want to develop with python 3, then we are stuck.
Correct. This is the general limitation of depending on a package
infrastructure for your specific operating system - or the developer's
fault, since he did not yet port the module to your specific version -
or the maintainer's, since he could not ensure that the port is stabe
enough for your favourite version.
> What we need to do now, is to move *all* py-* and ruby-* to their respective
> versions i.e py27-* and ruby19 (or 18?).
> Then we will need to copy all of these and set them to the newer version so
> py33 and ruby20.
And initiate a hell of repocopying and testing on each minor
release. And cause maintainers to have a lot of additional maintenance
efforts. And, and, and, ... No, thanks.
> Also this will remove the breakage of OPTIONS, all of these ports needs the
> dirty hack of OPTIONSFILE because of the ${PKGNAMEPREFIX}.
> This will blow out the ports tree by adding a lot of ports, but it's the best
> way to cover the both version and future bulk generation for users.
No, it is not. It is the best way you thought of so far.
Your problem description is too unspecific or too easy to solve. Right
now it reads as
* one shall be able to install py27-, py32-, ... ports (or ruby) in
parallel - fair enough, then we need to fix the following issue along
with some other minor side effects:
/usr/ports/devel/py-logilab-common # make PYTHON_DEFAULT_VERSION=python3.2
PYTHON3_DEFAULT_VERSION=python3.2 install
===> Installing for py32-logilab-common-0.59.0
===> py32-logilab-common-0.59.0 depends on file: /usr/local/bin/python3.2 -
found
===> Generating temporary packing list
===> Checking if devel/py-logilab-common already installed
===> An older version of devel/py-logilab-common is already installed
(py27-logilab-common-0.59.0)
Cheers
Marcus
pgpTUqYCnUwo0.pgp
Description: PGP signature
Re: Change design of py-* ruby-* ports
On, Thu Apr 25, 2013, David Demelier wrote:
[...]
> And if a port requires a py- module but for a specific version, how is it
> possible to share PYTHON_VERSION= through dependencies?
This is done at the moment by using
# Propagate the chosen python version to submakes.
.MAKEFLAGS: PYTHON_VERSION=python${_PYTHON_VERSION}
within bsd.python.mk, which opens a different can of worms (see
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167368 for details)
Cheers
Marcus
pgp6WMie1ERUw.pgp
Description: PGP signature
Re: math/ggobi does not build, if graphics/graphviz installed
Am 25.04.2013 22:40 (UTC+1) schrieb Greg Larkin: > On 4/25/13 12:02 PM, Rainer Hurling wrote: >> On 25.04.2013 17:02 (UTC+2), Greg Larkin wrote: >>> On 4/25/13 1:39 AM, Rainer Hurling wrote: Am 24.04.2013 22:53 (UTC+1) schrieb Greg Larkin: > On 4/24/13 1:38 PM, Rainer Hurling wrote: >> Oops, sorry for answering myself. But the typo gremlin >> appeared. > >> On 23.04.2013 18:38 (UTC+2), Rainer Hurling wrote: >>> Dear developers, >>> >>> I am the maintainer of math/ggobi and I could need some >>> help for a longstanding problem with the build of ggobi >>> (not seen by tinderbox): >>> >>> With graphics/graphviz installed, math/ggobi finds this >>> external installation by its configure script in >>> plugins/GraphLayout. Then it tries to use it instead of >>> its internal graphviz version and fails when trying to >>> build the port. > >> The configure also sets HAVE_LIBGVC=1. > >>> >>> The diff between graphics/graphviz/Makefile with/without >>> external >> ^^ plugins/GraphLayout/Makefile > >>> graphviz found is like this (the first version does not >>> build): >>> >>> 158,159c158,159 < LIBGVC_CFLAGS = >>> -I/usr/local/include/graphviz < LIBGVC_LIBS = >>> -L/usr/local/lib/graphviz -lgvc -lgraph -lcdt --- LIBGVC_CFLAGS = LIBGVC_LIBS = >>> >>> >>> I am looking for either an elegant way to forbid this >>> configure script to use the external graphviz or to use >>> the external graphviz correctly, when installed. >>> >>> If this would be possible, an option in the ports >>> Makefile could switch between them (and install external >>> graphviz, if wanted). >>> >>> Could someone with more experience be so kind to push me >>> in the right direction, please. >>> >>> Many thanks in advance, Rainer Hurling > > Hi Rainer, > > Can you post an excerpt of the build failure log file when > math/ggobi attempts to build graphics/graphviz? >>> Hi Greg, >>> I created an excerpt of the build log and put it together with config.log as a zip in the attachment. >>> Please tell me, if I should provide more information. >>> Many thanks for your answer, Rainer >>> > > Thank you, Greg > >>> >>> Hi Rainer, >>> >>> Can you send all config.log files that appear in the ggobi work >>> directory? That would include any that appear in the plugin >>> build subdirectories. > >> Yep, of course. The attached zip should contain them all. > >> Thanks again, Rainer > >>> >>> Thank you, Greg > > Hi Rainer, Hi Greg, > There doesn't appear to be an easy way to convince > plugins/GraphLayout/configure to ignore an already-installed version > of graphviz, and I don't see any patches for ggobi that enable it to > support new versions of graphviz. That's what I have been afraid of :( > At this point, I would add a post-configure target to the port > Makefile and use it to patch plugins/GraphLayout/Makefile and > plugins/GraphLayout/config.h to remove support for libgvc. I did that > manually, and I was able to build the plugin by hand with graphviz > still installed. For me it would be ok to disable the facility to use external graphviz installations. Would you agree to share your patch, so that I could use it in the port? There was no attached patch ;) You helped me a lot. I had been looking for some time now to find a solution for that problem. I really appreciate your help. Many thanks again, Rainer > > Hope that helps, > Greg ___ 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"
