cups-client broken on ia64, blocks 70 ports, please help
http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 Compiling adminutil.c... cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o adminutil.c adminutil.c:1: warning: -fstack-protector not supported for this target In file included from pwg-private.h:25, from cups-private.h:31, from adminutil.c:33: ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory gmake[2]: *** [adminutil.o] Error 1 gmake[2]: Leaving directory `/wrkdirs/usr/ports/print/cups-client/work/cups-1.7.1/cups' The last working version is cups-client-1.5.4_1 Thanks Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems after upgrade to CUPS 1.7.1 - gstoraster error
Am Thu, 03 Apr 2014 20:51:15 +0400 schrieb Boris Samorodov : > The patch changes three files. So you may restore them all. > You may use PATCH(1) with -R option to restore status quo. > Yeah of course, sorry, did only a quick check of your patch at that time. > I use just delete an old package and then build and install a new one > using the portstree. Should be OK to use vice versa (from a new > version to an old one). > I even did not have to delete the old package. I just patched and subsequently built print/cups-filters. And pkg is happy: cups-1.7.1 = up-to-date with port cups-base-1.7.1= up-to-date with port cups-client-1.7.1 = up-to-date with port cups-filters-1.0.50= up-to-date with port cups-image-1.7.1 = up-to-date with port cups-pstoraster-8.15.4_7 = up-to-date with port gutenprint-cups-5.2.8_1= up-to-date with port And patching was successful, cups is working now as expected. That's great, thank you, Boris. So there is currently no need to downgrade again :-) Did I get you right, that a modified version of this patch will go into ports tree as soon as it will be able to cover FreeBSD 8.x as well? Regards, Peter ___ 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: cups-client broken on ia64, blocks 70 ports, please help
04.04.2014 12:07, Anton Shterenlikht пишет: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 > > Compiling adminutil.c... > cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. > -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing > -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE > -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o > adminutil.c > adminutil.c:1: warning: -fstack-protector not supported for this target > In file included from pwg-private.h:25, > from cups-private.h:31, > from adminutil.c:33: > ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory Hm. cups/cups.h has the following code: - # ifdef __BLOCKS__ #include # endif /* __BLOCKS__ */ - It seems that the whole dispath is an Apple thing. How does it come about that it get used by FreeBSD? I think this check may be removed. Anyway please try the following patch (place it in to the print/cups/file directory -- mind print/cups origin, not print/cups-client) and retry: ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h > gmake[2]: *** [adminutil.o] Error 1 > gmake[2]: Leaving directory `/wrkdirs/usr/ports/print/cups-client/work/cups-1.7.1/cups' > > The last working version is cups-client-1.5.4_1 > > Thanks > > Anton > ___ > 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" > -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: working with port options from commandline
On 4/3/2014 4:26 AM, Volodymyr Kostyrko wrote: > Hi all. > > I'm all about automation. I'd like to automate most tasks so I can > schedule them or write a script with which everything would be done > automatically. > > I have some difficulties with current port options framework: > > 1. Is there a good way to set/unset any option from command line without > firing up dialog? Something like 'make -C port/dir -DSET=OPT1,OPT2 > -DUNSET=OPT3 updateconfig'. This should work: make ... OPTIONS_SET="OPT OPT OPT" OPTIONS_UNSET="OPT OPT OPT" BATCH=1 > > 2. Is there a good way to query for option updates? You know when you > are building a port the option dialog will still be shown if there are > new options not present in current config. Can I get those options > somehow like 'make -C port/dir changedconfig'? The current handling uses: make -V NEWOPTIONS You can also use 'make pretty-print-config' for a parseable output. > > I think I need to write some scripts to handle this situations myself > but I just want to ask whether someone had done that before or maybe > such functionality is pending? > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: working with port options from commandline
On Fri, Apr 04, 2014 at 06:05:13AM -0500, Bryan Drewery wrote: > On 4/3/2014 4:26 AM, Volodymyr Kostyrko wrote: > > Hi all. > > > > I'm all about automation. I'd like to automate most tasks so I can > > schedule them or write a script with which everything would be done > > automatically. > > > > I have some difficulties with current port options framework: > > > > 1. Is there a good way to set/unset any option from command line without > > firing up dialog? Something like 'make -C port/dir -DSET=OPT1,OPT2 > > -DUNSET=OPT3 updateconfig'. > > This should work: > make ... OPTIONS_SET="OPT OPT OPT" OPTIONS_UNSET="OPT OPT OPT" BATCH=1 The rigth way is make WITH="OPT1 OPT2 OPT3" WITHOUT="OPT4 OPT5" BATCH=1 regards, Bapt pgpxfnnE6Q6Wd.pgp Description: PGP signature
Re: cups-client broken on ia64, blocks 70 ports, please help
On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote: > 04.04.2014 12:07, Anton Shterenlikht пишет: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 > > > > Compiling adminutil.c... > > cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. > > -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing > > -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE > > -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o > > adminutil.c > > adminutil.c:1: warning: -fstack-protector not supported for this target > > In file included from pwg-private.h:25, > > from cups-private.h:31, > > from adminutil.c:33: > > ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory > > Hm. cups/cups.h has the following code: > - > # ifdef __BLOCKS__ > #include > # endif /* __BLOCKS__ */ > - > > It seems that the whole dispath is an Apple thing. How does it come > about that it get used by FreeBSD? I think this check may be removed. > > Anyway please try the following patch (place it in to the > print/cups/file directory -- mind print/cups origin, > not print/cups-client) and retry: > ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h > That is on recent head, due to the import of _BLOCKS_ support but we don't have libdispatch regards, Bapt pgppFfWsZexU1.pgp Description: PGP signature
Re: cups-client broken on ia64, blocks 70 ports, please help
04.04.2014 15:49, Baptiste Daroussin пишет: > On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote: >> 04.04.2014 12:07, Anton Shterenlikht пишет: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 >>> >>> Compiling adminutil.c... >>> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. >>> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing >>> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE >>> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o >>> adminutil.c >>> adminutil.c:1: warning: -fstack-protector not supported for this target >>> In file included from pwg-private.h:25, >>> from cups-private.h:31, >>> from adminutil.c:33: >>> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory >> >> Hm. cups/cups.h has the following code: >> - >> # ifdef __BLOCKS__ >> #include >> # endif /* __BLOCKS__ */ >> - >> >> It seems that the whole dispath is an Apple thing. How does it come >> about that it get used by FreeBSD? I think this check may be removed. >> >> Anyway please try the following patch (place it in to the >> print/cups/file directory -- mind print/cups origin, >> not print/cups-client) and retry: >> ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h >> > > That is on recent head, due to the import of _BLOCKS_ support but we don't > have > libdispatch Makes sense, thanks. Wait a little, I don't get any defines: - % uname -a FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #77 r264083: Fri Apr 4 00:30:01 SAMT 2014 bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 % grep __BLOCKS__ -r /usr/include /usr/include/heimbase.h:#ifdef __BLOCKS__ /usr/include/heimbase.h:#ifdef __BLOCKS__ /usr/include/heimbase.h:#ifdef __BLOCKS__ /usr/include/stdlib.h:#ifdef __BLOCKS__ /usr/include/stdlib.h:#ifdef __BLOCKS__ /usr/include/stdlib.h:#ifdef __BLOCKS__ /usr/include/stdlib.h:#ifdef __BLOCKS__ /usr/include/hx509-protos.h:#ifdef __BLOCKS__ /usr/include/hx509-protos.h:#endif /* __BLOCKS__ */ /usr/include/dirent.h:#ifdef __BLOCKS__ - -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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"
Python install catch 22
Hi, I've tried to upgrade my python 2.7 which did not work. Then I deinstalled all python stuff and tried to install python3 (aka 3.3) The system everytime refuses to install because of missing a database: pkg-static: lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so): No such file or directory *** [fake-pkg] Error code 74 [ replace python33 by python27 te get the similar error for 2.7 ] And then hints: Note that some of the standard modules are provided as separate ports since they require extra dependencies: gdbmdatabases/py-gdbm sqlite3 databases/py-sqlite3 tkinter x11-toolkits/py-tkinter Install them as needed. Which is nasty catch22, because one needs a recent/working python to actually be able to do this. How do other cope with this? --WjW ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems after upgrade to CUPS 1.7.1 - gstoraster error
04.04.2014 13:51, Dr. Peter Voigt пишет: > Am Thu, 03 Apr 2014 20:51:15 +0400 > schrieb Boris Samorodov : > >> The patch changes three files. So you may restore them all. >> You may use PATCH(1) with -R option to restore status quo. >> > Yeah of course, sorry, did only a quick check of your patch at that > time. > >> I use just delete an old package and then build and install a new one >> using the portstree. Should be OK to use vice versa (from a new >> version to an old one). >> > I even did not have to delete the old package. I just patched and > subsequently built print/cups-filters. And pkg is happy: > > cups-1.7.1 = up-to-date with port > cups-base-1.7.1= up-to-date with port > cups-client-1.7.1 = up-to-date with port > cups-filters-1.0.50= up-to-date with port > cups-image-1.7.1 = up-to-date with port > cups-pstoraster-8.15.4_7 = up-to-date with port > gutenprint-cups-5.2.8_1= up-to-date with port > > And patching was successful, cups is working now as expected. That's > great, thank you, Boris. So there is currently no need to downgrade > again :-) OK, glad to be helpful. Thanks for testing and reporting back. > Did I get you right, that a modified version of this patch will go into > ports tree as soon as it will be able to cover FreeBSD 8.x as well? Correct. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: cups-client broken on ia64, blocks 70 ports, please help
On Fri, Apr 04, 2014 at 04:08:13PM +0400, Boris Samorodov wrote: > 04.04.2014 15:49, Baptiste Daroussin пишет: > > On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote: > >> 04.04.2014 12:07, Anton Shterenlikht пишет: > >>> > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 > >>> > >>> Compiling adminutil.c... > >>> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. > >>> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing > >>> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE > >>> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o > >>> adminutil.o adminutil.c > >>> adminutil.c:1: warning: -fstack-protector not supported for this target > >>> In file included from pwg-private.h:25, > >>> from cups-private.h:31, > >>> from adminutil.c:33: > >>> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or > >>> directory > >> > >> Hm. cups/cups.h has the following code: > >> - > >> # ifdef __BLOCKS__ > >> #include > >> # endif /* __BLOCKS__ */ > >> - > >> > >> It seems that the whole dispath is an Apple thing. How does it come > >> about that it get used by FreeBSD? I think this check may be removed. > >> > >> Anyway please try the following patch (place it in to the > >> print/cups/file directory -- mind print/cups origin, > >> not print/cups-client) and retry: > >> ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h > >> > > > > That is on recent head, due to the import of _BLOCKS_ support but we don't > > have > > libdispatch > > Makes sense, thanks. > > Wait a little, I don't get any defines: > - > % uname -a > FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #77 r264083: Fri > Apr 4 00:30:01 SAMT 2014 > bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 > > % grep __BLOCKS__ -r /usr/include > /usr/include/heimbase.h:#ifdef __BLOCKS__ > /usr/include/heimbase.h:#ifdef __BLOCKS__ > /usr/include/heimbase.h:#ifdef __BLOCKS__ > /usr/include/stdlib.h:#ifdef __BLOCKS__ > /usr/include/stdlib.h:#ifdef __BLOCKS__ > /usr/include/stdlib.h:#ifdef __BLOCKS__ > /usr/include/stdlib.h:#ifdef __BLOCKS__ > /usr/include/hx509-protos.h:#ifdef __BLOCKS__ > /usr/include/hx509-protos.h:#endif /* __BLOCKS__ */ > /usr/include/dirent.h:#ifdef __BLOCKS__ > - > The compilers defines it, this is probably due to using gcc on ia64, I'm CCing Pedro and David on this as the are the guilty one about __BLOCKS__ support :) and may know better regards, Bapt pgpXNqk6XLkXT.pgp Description: PGP signature
Re: cups-client broken on ia64, blocks 70 ports, please help
>From b...@passap.ru Fri Apr 4 11:55:13 2014 >04.04.2014 12:07, Anton Shterenlikht пиÑеÑ: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 >> >> Compiling adminutil.c... >> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. >> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing >> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE >> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o >> adminutil.c >> adminutil.c:1: warning: -fstack-protector not supported for this target >> In file included from pwg-private.h:25, >> from cups-private.h:31, >> from adminutil.c:33: >> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory > >Hm. cups/cups.h has the following code: >- ># ifdef __BLOCKS__ >#include ># endif /* __BLOCKS__ */ >- > >It seems that the whole dispath is an Apple thing. How does it come >about that it get used by FreeBSD? I think this check may be removed. > >Anyway please try the following patch (place it in to the >print/cups/file directory -- mind print/cups origin, >not print/cups-client) and retry: >ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h did you mean print/cups-base/files? If I put it under print/cups/files it makes no difference, but if I put the patch under print/cups-base/files, then cups-client and cups-image do build and install. Will you commit the patch? BTW, what's this warning on stack protector: warning: -fstack-protector not supported for this target Thank you Anton ___ 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: cups-client broken on ia64, blocks 70 ports, please help
04.04.2014 16:42, Anton Shterenlikht пишет: >>From b...@passap.ru Fri Apr 4 11:55:13 2014 >> 04.04.2014 12:07, Anton Shterenlikht аПаИбаЕб: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 >>> >>> Compiling adminutil.c... >>> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. >>> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing >>> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE >>> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o >>> adminutil.c >>> adminutil.c:1: warning: -fstack-protector not supported for this target >>> In file included from pwg-private.h:25, >>> from cups-private.h:31, >>> from adminutil.c:33: >>> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory >> >> Hm. cups/cups.h has the following code: >> - >> # ifdef __BLOCKS__ >> #include >> # endif /* __BLOCKS__ */ >> - >> >> It seems that the whole dispath is an Apple thing. How does it come >> about that it get used by FreeBSD? I think this check may be removed. >> >> Anyway please try the following patch (place it in to the >> print/cups/file directory -- mind print/cups origin, >> not print/cups-client) and retry: >> ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h > > did you mean print/cups-base/files? Err, sure. Sorry. > If I put it under print/cups/files it makes > no difference, but if I put the patch under > print/cups-base/files, then cups-client and > cups-image do build and install. Thanks for confirmation. > Will you commit the patch? Yes, but I'd like understand which systems are influenced [the thread is continuing]. > BTW, what's this warning on stack protector: > > warning: -fstack-protector not supported for this target This is just a warning... -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: cups-client broken on ia64, blocks 70 ports, please help
On 4 Apr 2014, at 13:13, Baptiste Daroussin wrote:
> On Fri, Apr 04, 2014 at 04:08:13PM +0400, Boris Samorodov wrote:
>> 04.04.2014 15:49, Baptiste Daroussin пишет:
>>> On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote:
04.04.2014 12:07, Anton Shterenlikht пишет:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161
>
> Compiling adminutil.c...
> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I..
> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing
> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE
> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o
> adminutil.o adminutil.c
> adminutil.c:1: warning: -fstack-protector not supported for this target
> In file included from pwg-private.h:25,
> from cups-private.h:31,
> from adminutil.c:33:
> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or
> directory
Hm. cups/cups.h has the following code:
-
# ifdef __BLOCKS__
#include
# endif /* __BLOCKS__ */
-
It seems that the whole dispath is an Apple thing. How does it come
about that it get used by FreeBSD? I think this check may be removed.
Anyway please try the following patch (place it in to the
print/cups/file directory -- mind print/cups origin,
not print/cups-client) and retry:
ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h
>>>
>>> That is on recent head, due to the import of _BLOCKS_ support but we don't
>>> have
>>> libdispatch
>>
>> Makes sense, thanks.
>>
>> Wait a little, I don't get any defines:
>> -
>> % uname -a
>> FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #77 r264083: Fri
>> Apr 4 00:30:01 SAMT 2014
>> bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64
>>
>> % grep __BLOCKS__ -r /usr/include
>> /usr/include/heimbase.h:#ifdef __BLOCKS__
>> /usr/include/heimbase.h:#ifdef __BLOCKS__
>> /usr/include/heimbase.h:#ifdef __BLOCKS__
>> /usr/include/stdlib.h:#ifdef __BLOCKS__
>> /usr/include/stdlib.h:#ifdef __BLOCKS__
>> /usr/include/stdlib.h:#ifdef __BLOCKS__
>> /usr/include/stdlib.h:#ifdef __BLOCKS__
>> /usr/include/hx509-protos.h:#ifdef __BLOCKS__
>> /usr/include/hx509-protos.h:#endif /* __BLOCKS__ */
>> /usr/include/dirent.h:#ifdef __BLOCKS__
>> -
>>
>
> The compilers defines it, this is probably due to using gcc on ia64,
> I'm CCing Pedro and David on this as the are the guilty one about __BLOCKS__
> support :) and may know better
$ echo | clang -dM -x c - -E | grep BLOCK
$ echo | clang -fblocks -dM -x c - -E | grep BLOCK
#define __BLOCKS__ 1
$ echo | gcc -dM -x c - -E | grep BLOCK
#define __BLOCKS__ 1
$ echo | gcc -fno-blocks -dM -x c - -E | grep BLOCK
It's an inconsistency between base gcc and base clang: one defaults to
supporting blocks, the other defaults to not supporting them. I'd like to
blame Pedro, but actually I think the base-system bug is that is that clang
doesn't default to -fblocks behaviour.
So, the simplest fix is simply to add -fno-blocks to the CFLAGS for this port.
Given that it has libdispatch support, however, it would be nice if we could
have an option for using libdispatch that would (as well as passing the correct
configure options and so on) add -fblocks to CFLAGS if building with
libdispatch and -fn-blocks otherwise.
It would also be nice to tell the cups developers that it's not particularly
clever to use the existence of a compiler feature to test for the presence of a
library. They seem to have come up with an interesting spelling of #ifdef
__APPLE__, rather than adding a proper configure check.
If we've got a baseline, the attached diff enables blocks support by default in
clang and so an exprun can see how many ports break by assuming that blocks
support means libdispatch / Cocoa / OS X...
David
Index: contrib/llvm/tools/clang/lib/Driver/ToolChains.h
===
--- contrib/llvm/tools/clang/lib/Driver/ToolChains.h(revision 263972)
+++ contrib/llvm/tools/clang/lib/Driver/ToolChains.h(working copy)
@@ -519,6 +519,8 @@
return Generic_ELF::IsIntegratedAssemblerDefault();
}
+ virtual bool IsBlocksDefault() const { return true; }
+
virtual bool UseSjLjExceptions() const;
protected:
virtual Tool *buildAssembler() const;
___
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: working with port options from commandline
04.04.2014 14:05, Bryan Drewery написав(ла): On 4/3/2014 4:26 AM, Volodymyr Kostyrko wrote: Hi all. I'm all about automation. I'd like to automate most tasks so I can schedule them or write a script with which everything would be done automatically. I have some difficulties with current port options framework: 1. Is there a good way to set/unset any option from command line without firing up dialog? Something like 'make -C port/dir -DSET=OPT1,OPT2 -DUNSET=OPT3 updateconfig'. This should work: make ... OPTIONS_SET="OPT OPT OPT" OPTIONS_UNSET="OPT OPT OPT" BATCH=1 I know but my target is to manage different machines with different options remotely. I'm currently experimenting with sysutils/py-salt and I found it already has required functionality in ports.config - I can remotely update ports configuration without building them. The given line actually doesn't change port configuration, it just makes port behave differently in the current run. Why I didn't like this is because it works only on current port but not on the ports required by this one. Imagine you have a number of _differently_ configured machines and you want to manage updates remotely. Poudriere doesn't help as packages actually may very from system to system, what I need is number of command line tools to inspect what should be build, inspect what options should be changed, update options from central datastore and rebuild ports - without using a GUI. 2. Is there a good way to query for option updates? You know when you are building a port the option dialog will still be shown if there are new options not present in current config. Can I get those options somehow like 'make -C port/dir changedconfig'? The current handling uses: make -V NEWOPTIONS Exactly what I needed. You can also use 'make pretty-print-config' for a parseable output. Nice thing, I'll remember this one. -- Sphinx of black quartz, judge my vow. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
can anyone help taking down deprecated port net-im/tkabber-devel?
Hi all. I just fired a PR about that one. I know there should be a maintainer timeout but domain with maintainers email vanished. All distfiles links point to this vanished domain too. http://www.freebsd.org/cgi/query-pr.cgi?pr=188260 -- Sphinx of black quartz, judge my vow. ___ 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: working with port options from commandline
On 2014-04-04 09:26, Volodymyr Kostyrko wrote: 04.04.2014 14:05, Bryan Drewery написав(ла): On 4/3/2014 4:26 AM, Volodymyr Kostyrko wrote: Hi all. I'm all about automation. I'd like to automate most tasks so I can schedule them or write a script with which everything would be done automatically. I have some difficulties with current port options framework: 1. Is there a good way to set/unset any option from command line without firing up dialog? Something like 'make -C port/dir -DSET=OPT1,OPT2 -DUNSET=OPT3 updateconfig'. This should work: make ... OPTIONS_SET="OPT OPT OPT" OPTIONS_UNSET="OPT OPT OPT" BATCH=1 I know but my target is to manage different machines with different options remotely. I'm currently experimenting with sysutils/py-salt and I found it already has required functionality in ports.config - I can remotely update ports configuration without building them. The given line actually doesn't change port configuration, it just makes port behave differently in the current run. Why I didn't like this is because it works only on current port but not on the ports required by this one. Imagine you have a number of _differently_ configured machines and you want to manage updates remotely. Poudriere doesn't help as packages actually may very from system to system, Poudriere handles that situation fine. You setup sets for each configuration you want. Your options can either be in the /var/db/ports format or in a make.conf with OPTIONS_SET/OPTIONS_UNSET/uniquename_OPTIONS... poudriere bulk -j JAIL -z SET This will use: /usr/local/etc/poudriere.d/SET-make.conf /usr/local/etc/poudriere.d/make.conf /usr/local/etc/poudriere.d/SET-options So with 1 jail you can build package sets for each target machine. You can use poudriere options to configure these in the /var/db/ports format which automatically creates the SET-options dir: poudriere options -z SET Poudriere will rebuild packages when the selected options change or new defaults are added. what I need is number of command line tools to inspect what should be build, inspect what options should be changed, update options from central datastore and rebuild ports - without using a GUI. 2. Is there a good way to query for option updates? You know when you are building a port the option dialog will still be shown if there are new options not present in current config. Can I get those options somehow like 'make -C port/dir changedconfig'? The current handling uses: make -V NEWOPTIONS Exactly what I needed. You can also use 'make pretty-print-config' for a parseable output. Nice thing, I'll remember this one. -- Regards, Bryan Drewery ___ 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: cups-client broken on ia64, blocks 70 ports, please help
(I had to do some copy-pasting to get this email out due to some yahoo smtp brokeness, sorry for the mess) On 04/04/2014 07:56, David Chisnall wrote: > On 4 Apr 2014, at 13:13, Baptiste Daroussin wrote: > >> On Fri, Apr 04, 2014 at 04:08:13PM +0400, Boris Samorodov wrote: >>> 04.04.2014 15:49, Baptiste Daroussin пишет: On Fri, Apr 04, 2014 at 02:18:15PM +0400, Boris Samorodov wrote: > 04.04.2014 12:07, Anton Shterenlikht пишет: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161 >> >> Compiling adminutil.c... >> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I.. >> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing >> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE >> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o >> adminutil.o adminutil.c >> adminutil.c:1: warning: -fstack-protector not supported for this target >> In file included from pwg-private.h:25, >> from cups-private.h:31, >> from adminutil.c:33: >> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or >> directory > > Hm. cups/cups.h has the following code: > - > # ifdef __BLOCKS__ > # include > # endif /* __BLOCKS__ */ > - > > It seems that the whole dispath is an Apple thing. How does it come > about that it get used by FreeBSD? I think this check may be removed. > > Anyway please try the following patch (place it in to the > print/cups/file directory -- mind print/cups origin, > not print/cups-client) and retry: > ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h > That is on recent head, due to the import of _BLOCKS_ support but we don't have libdispatch >>> >>> Makes sense, thanks. >>> >>> Wait a little, I don't get any defines: >>> - >>> % uname -a >>> FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #77 r264083: Fri >>> Apr 4 00:30:01 SAMT 2014 >>> bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X amd64 >>> >>> % grep __BLOCKS__ -r /usr/include >>> /usr/include/heimbase.h:#ifdef __BLOCKS__ >>> /usr/include/heimbase.h:#ifdef __BLOCKS__ >>> /usr/include/heimbase.h:#ifdef __BLOCKS__ >>> /usr/include/stdlib.h:#ifdef __BLOCKS__ >>> /usr/include/stdlib.h:#ifdef __BLOCKS__ >>> /usr/include/stdlib.h:#ifdef __BLOCKS__ >>> /usr/include/stdlib.h:#ifdef __BLOCKS__ >>> /usr/include/hx509-protos.h:#ifdef __BLOCKS__ >>> /usr/include/hx509-protos.h:#endif /* __BLOCKS__ */ >>> /usr/include/dirent.h:#ifdef __BLOCKS__ >>> - >>> >> >> The compilers defines it, this is probably due to using gcc on ia64, >> I'm CCing Pedro and David on this as the are the guilty one about __BLOCKS__ >> support :) and may know better > > $ echo | clang -dM -x c - -E | grep BLOCK > $ echo | clang -fblocks -dM -x c - -E | grep BLOCK > #define __BLOCKS__ 1 > $ echo | gcc -dM -x c - -E | grep BLOCK > #define __BLOCKS__ 1 > $ echo | gcc -fno-blocks -dM -x c - -E | grep BLOCK > > It's an inconsistency between base gcc and base clang: one defaults to > supporting blocks, the other defaults to not supporting them. I'd like to > blame Pedro, but actually I think the base-system bug is that is that clang > doesn't default to -fblocks behaviour. > The policy in Apple's GCC and in FreeBSD since r260311 is to enable blocks support by default unless std=C99 is set. > So, the simplest fix is simply to add -fno-blocks to the CFLAGS for this > port. Given that it has libdispatch support, however, it would be nice if we > could have an option for using libdispatch that would (as well as passing the > correct configure options and so on) add -fblocks to CFLAGS if building with > libdispatch and -fn-blocks otherwise. > > It would also be nice to tell the cups developers that it's not particularly > clever to use the existence of a compiler feature to test for the presence of > a library. They seem to have come up with an interesting spelling of #ifdef > __APPLE__, rather than adding a proper configure check. > I agree that the main issue here is that the cups developers shouldn't be using language features to determine if the platform has libdispatch. This is, however, an exciting opportunity to use libdispatch more extensively. I will be committing a small patch to make it easier to build libdispatch with GCC on 11.x and 10.x. Regards, Pedro. ___ 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: working with port options from commandline
04.04.2014 18:25, Bryan Drewery wrote: On 2014-04-04 09:26, Volodymyr Kostyrko wrote: 04.04.2014 14:05, Bryan Drewery wrote: On 4/3/2014 4:26 AM, Volodymyr Kostyrko wrote: Hi all. I'm all about automation. I'd like to automate most tasks so I can schedule them or write a script with which everything would be done automatically. I have some difficulties with current port options framework: 1. Is there a good way to set/unset any option from command line without firing up dialog? Something like 'make -C port/dir -DSET=OPT1,OPT2 -DUNSET=OPT3 updateconfig'. This should work: make ... OPTIONS_SET="OPT OPT OPT" OPTIONS_UNSET="OPT OPT OPT" BATCH=1 I know but my target is to manage different machines with different options remotely. I'm currently experimenting with sysutils/py-salt and I found it already has required functionality in ports.config - I can remotely update ports configuration without building them. The given line actually doesn't change port configuration, it just makes port behave differently in the current run. Why I didn't like this is because it works only on current port but not on the ports required by this one. Imagine you have a number of _differently_ configured machines and you want to manage updates remotely. Poudriere doesn't help as packages actually may very from system to system, Poudriere handles that situation fine. You setup sets for each configuration you want. Your options can either be in the /var/db/ports format or in a make.conf with OPTIONS_SET/OPTIONS_UNSET/uniquename_OPTIONS... poudriere bulk -j JAIL -z SET This will use: /usr/local/etc/poudriere.d/SET-make.conf /usr/local/etc/poudriere.d/make.conf /usr/local/etc/poudriere.d/SET-options So with 1 jail you can build package sets for each target machine. You can use poudriere options to configure these in the /var/db/ports format which automatically creates the SET-options dir: poudriere options -z SET Poudriere will rebuild packages when the selected options change or new defaults are added. That sounds interesting. Looks like I missed a lot about it, time to catch up. :) -- Sphinx of black quartz, judge my vow. ___ 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: cups-client broken on ia64, blocks 70 ports, please help
04.04.2014 16:42, Anton Shterenlikht пишет:
>>From b...@passap.ru Fri Apr 4 11:55:13 2014
>> 04.04.2014 12:07, Anton Shterenlikht аПаИбаЕб:
>>>
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=188161
>>>
>>> Compiling adminutil.c...
>>> cc -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -I..
>>> -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing
>>> -DOPENSSL_DISABLE_OLD_DES_SUPPORT -D_LARGEFILE_SOURCE -D_THREAD_SAFE
>>> -D_REENTRANT -D_CUPS_NO_DEPRECATED=1 -D_PPD_DEPRECATED="" -c -o adminutil.o
>>> adminutil.c
>>> adminutil.c:1: warning: -fstack-protector not supported for this target
>>> In file included from pwg-private.h:25,
>>> from cups-private.h:31,
>>> from adminutil.c:33:
>>> ../cups/cups.h:34:35: error: dispatch/dispatch.h: No such file or directory
>>
>> Hm. cups/cups.h has the following code:
>> -
>> # ifdef __BLOCKS__
>> #include
>> # endif /* __BLOCKS__ */
>> -
>>
>> It seems that the whole dispath is an Apple thing. How does it come
>> about that it get used by FreeBSD? I think this check may be removed.
>>
>> Anyway please try the following patch (place it in to the
>> print/cups/file directory -- mind print/cups origin,
>> not print/cups-client) and retry:
>> ftp://ftp.wart.ru/pub/misc/patch-cups-cups.h
>
> did you mean print/cups-base/files?
>
> If I put it under print/cups/files it makes
> no difference, but if I put the patch under
> print/cups-base/files, then cups-client and
> cups-image do build and install.
>
> Will you commit the patch?
OK, I've got a patch that may be committed. It's just a band-aid
for now, until a better patch using clang and gcc, blocks and
libdispatch with different FreeBSD versions is created.
Anton, can you test the patch (remove the previous one from
cups-base/files)? Thank you.
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
Index: cups-base/Makefile
===
--- cups-base/Makefile (revision 350133)
+++ cups-base/Makefile (working copy)
@@ -82,6 +82,7 @@
INSTALL_WRKSRC=${WRKSRC}/cups
PLIST= ${MASTERDIR}/pkg-plist.client
USES+= iconv
+CFLAGS+= -fno-blocks
LDFLAGS+= ${ICONV_LIB}
USE_LDCONFIG= yes
PKGMESSAGE=${NONEXISTENT}
___
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"
lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start
After updating ports today and a lot of the php-stuff, I get this error restarting apache24: httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/libphp5.so into server: Cannot open "/usr/local/libexec/apache24/libphp5.so" I tried to rebuild apache24 as well as lang/php5 with first rmconfig and then config again avoiding missing something. No effect. What happened here? /usr/ports/UPDATING doesn't have any kind of information regarding this subject. Oliver signature.asc Description: PGP signature
Re: lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start
On Apr 04, 2014 07:28 PM +0200, O. Hartmann wrote: > After updating ports today and a lot of the php-stuff, I get this error > restarting > apache24: > > httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: Cannot > load libexec/apache24/libphp5.so into server: Cannot open > "/usr/local/libexec/apache24/libphp5.so" > > I tried to rebuild apache24 as well as lang/php5 with first rmconfig and then > config > again avoiding missing something. No effect. > > What happened here? /usr/ports/UPDATING doesn't have any kind of information > regarding > this subject. > > > Oliver I had this same issue, too. Installing www/mod_php5 will fix it. pgpgpwpe9s8eS.pgp Description: PGP signature
Re: lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start
Hello, On 4/4/14, 1:28 PM, O. Hartmann wrote: After updating ports today and a lot of the php-stuff, I get this error restarting apache24: httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/libphp5.so into server: Cannot open "/usr/local/libexec/apache24/libphp5.so" I tried to rebuild apache24 as well as lang/php5 with first rmconfig and then config again avoiding missing something. No effect. What happened here? /usr/ports/UPDATING doesn't have any kind of information regarding this subject. From UPDATING: 20140327: AFFECTS: users of lang/php5 and lang/php55 with Apache module AUTHOR: a...@freebsd.org The Apache PHP module has been separated from the main PHP port. If it is needed, install either www/mod_php5 or www/mod_php55. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain ___ 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"
mnemosyne: gcc related error
Hi all,
I get the following error when running mnemosyne (games/py-mnemosyne):
% mnemosyne
(:0)
An unexpected error has occurred.
Please forward the following info to the developers:
Traceback (innermost last):
File "/usr/local/bin/mnemosyne", line 155, in
debug_file=options.debug_file)
File
"/usr/local/lib/python2.7/site-packages/mnemosyne/libmnemosyne/__init__.py",
line 164, in initialise
self.register_components()
File
"/usr/local/lib/python2.7/site-packages/mnemosyne/libmnemosyne/__init__.py",
line 215, in register_components
exec("from %s import %s" % (module_name, class_name))
File "", line 1, in
File
"/usr/local/lib/python2.7/site-packages/mnemosyne/pyqt_ui/statistics_wdgts_plotting.py",
line 7, in
from matplotlib import rcParams
File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line
151, in
from matplotlib.rcsetup import (defaultParams,
File "/usr/local/lib/python2.7/site-packages/matplotlib/rcsetup.py", line 20,
in
from matplotlib.colors import is_color_like
File "/usr/local/lib/python2.7/site-packages/matplotlib/colors.py", line 52,
in
import numpy as np
File "/usr/local/lib/python2.7/site-packages/numpy/__init__.py", line 153, in
from . import add_newdocs
File "/usr/local/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13,
in
from numpy.lib import add_newdoc
File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py", line 18,
in
from .polynomial import *
File "/usr/local/lib/python2.7/site-packages/numpy/lib/polynomial.py", line
19, in
from numpy.linalg import eigvals, lstsq, inv
File "/usr/local/lib/python2.7/site-packages/numpy/linalg/__init__.py", line
50, in
from .linalg import *
File "/usr/local/lib/python2.7/site-packages/numpy/linalg/linalg.py", line
29, in
from numpy.linalg import lapack_lite, _umath_linalg
ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
/usr/local/lib/gcc47/libgfortran.so.3 not found
There is no problem with importing numpy or matplotlib in python:
% python -c 'import numpy, matplotlib.pyplot'
What could be causing this problem?
I'm running FreeBSD 10.0-RELEASE with packages updated by pkgng.
Thank you in advance for help,
Henryk
PS please add my email to CC in reply
___
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"
mnemosyne: gcc related error
Hi all,
I get the following error when running mnemosyne (games/py-mnemosyne):
% mnemosyne
(:0)
An unexpected error has occurred.
Please forward the following info to the developers:
Traceback (innermost last):
File "/usr/local/bin/mnemosyne", line 155, in
debug_file=options.debug_file)
File
"/usr/local/lib/python2.7/site-packages/mnemosyne/libmnemosyne/__init__.py",
line 164, in initialise
self.register_components()
File
"/usr/local/lib/python2.7/site-packages/mnemosyne/libmnemosyne/__init__.py",
line 215, in register_components
exec("from %s import %s" % (module_name, class_name))
File "", line 1, in
File
"/usr/local/lib/python2.7/site-packages/mnemosyne/pyqt_ui/statistics_wdgts_plotting.py",
line 7, in
from matplotlib import rcParams
File "/usr/local/lib/python2.7/site-packages/matplotlib/__init__.py", line
151, in
from matplotlib.rcsetup import (defaultParams,
File "/usr/local/lib/python2.7/site-packages/matplotlib/rcsetup.py", line 20,
in
from matplotlib.colors import is_color_like
File "/usr/local/lib/python2.7/site-packages/matplotlib/colors.py", line 52,
in
import numpy as np
File "/usr/local/lib/python2.7/site-packages/numpy/__init__.py", line 153, in
from . import add_newdocs
File "/usr/local/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13,
in
from numpy.lib import add_newdoc
File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py", line 18,
in
from .polynomial import *
File "/usr/local/lib/python2.7/site-packages/numpy/lib/polynomial.py", line
19, in
from numpy.linalg import eigvals, lstsq, inv
File "/usr/local/lib/python2.7/site-packages/numpy/linalg/__init__.py", line
50, in
from .linalg import *
File "/usr/local/lib/python2.7/site-packages/numpy/linalg/linalg.py", line
29, in
from numpy.linalg import lapack_lite, _umath_linalg
ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
/usr/local/lib/gcc47/libgfortran.so.3 not found
There is no problem with importing numpy or matplotlib in python:
% python -c 'import numpy, matplotlib.pyplot'
What could be causing this problem?
I'm running FreeBSD 10.0-RELEASE with packages updated by pkgng.
Thank you in advance for help,
Henryk
PS please add my email to CC in reply
___
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"
pkgng vs. portupgrade reporting ports outdated
I'm a bit confused so I figured to see if someone can help me understand the new pkgng system better. Before using it, I have always done a cvs update (now svn update) to the ports tree and I would do a simple 'pkg_version -v|grep needs' to see what ports were out-of-date and then portupgrade those specific ports. After I successfully built the latest versions everything was in sync. With pkgng I issue a 'pkg update' followed by a 'pkg upgrade' and it shows me x number of ports that need to be updated. So it updates and completes just fine and of course it's much faster than building from source. So I still keep my source, ports and docs in sync via svn update. Here's where the issue comes in. After I have done the pkg upgrade and it tells me all is up-to-date, the 'pkg_version -v |grep needs' command shows me dozens of ports that are not up-to-date and further the versions it's saying I have installed are not consistent with the versions that were installed through pkgng. If I try and portupgrade it won't upgrade the ports and just returns me to the prompt as if there is nothing out of date. Why is there such a difference here? It seems that if I do a pkgng update / pkg upgrade it should be consistent with the same versions that are being reported after an 'svn update' and report back that all ports are up-to-date no matter which command I type. So now I can't seem to upgrade through portupgrade to get the rest of the ports to the versions reported in the ports tree and pkgng says I'm up-to-date. It's one thing if pkgng doesn't have all the packages pre-compiled but then it should let me portupgrade from the ports tree for those ports that aren't available through pkgng. I would like to get the rest of my ports up-to-date with the ports tree like it used to work. ___ 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"
Checking Installed Ports
Using pkg_libchk from Dominic Fandrey's excellent sysutils/bsdadminscripts port has helped locate ports that needed to be rebuilt before they became problems. Now there's pkg check, although I confess to not understanding the man page. Some options appear to check installed packages, while others appear to update stored checksums to match installed files. There's also pkg audit. It would be nice to put together a script that checks everything that can possibly be checked. So: pkg_libchk -o pkg check -s (although it produces some false positives, like /compat/linux/etc/ld.so.cache) pkg audit -F What else can be tested, preferably without false positives? ___ 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: pkgng vs. portupgrade reporting ports outdated
"sindrome" > With pkgng I issue a 'pkg update' followed by a 'pkg upgrade' and it > shows me x number of ports that need to be updated. So it updates > and completes just fine and of course it's much faster than building > from source. > > So I still keep my source, ports and docs in sync via svn update. > Here's where the issue comes in. After I have done the pkg upgrade > and it tells me all is up-to-date, the 'pkg_version -v |grep needs' > command shows me dozens of ports that are not up-to-date and further > the versions it's saying I have installed are not consistent with > the versions that were installed through pkgng. It is my understanding it is generally a bad idea to mix the old and new package systems. (It can be done, but it's beyond my pay grade and if you're asking this I'd guess it is - at the moment - beyond yours.) "pkgng" can do almost everything the old system can, and does it better. (Now if it only had a replacement for pkg_sort ) Each records its status quo in distinct and incompatible ways. When I want to know what needs updating I use: huff>> pkg version -v -l \< which I can send either to a file, or to e-mail, or to a script wrapped around portmaster. Does this help? Respectfully, Robert Huff ___ 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: Checking Installed Ports
On Fri, 4 Apr 2014, Warren Block wrote: Using pkg_libchk from Dominic Fandrey's excellent sysutils/bsdadminscripts port has helped locate ports that needed to be rebuilt before they became problems. Now there's pkg check, although I confess to not understanding the man page. Some options appear to check installed packages, while others appear to update stored checksums to match installed files. There's also pkg audit. It would be nice to put together a script that checks everything that can possibly be checked. So: pkg_libchk -o pkg check -s (although it produces some false positives, like /compat/linux/etc/ld.so.cache) pkg audit -F What else can be tested, preferably without false positives? I forgot to mention portmaster --check-depends, although I'm not positive it works with pkgng. ___ 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: pkgng vs. portupgrade reporting ports outdated
It is my understanding it is generally a bad idea to mix the old and new package systems. (It can be done, but it's beyond my pay grade and if you're asking this I'd guess it is - at the moment - beyond yours.) "pkgng" can do almost everything the old system can, and does it better. (Now if it only had a replacement for pkg_sort ) Each records its status quo in distinct and incompatible ways. When I want to know what needs updating I use: huff>> pkg version -v -l \< which I can send either to a file, or to e-mail, or to a script wrapped around portmaster. Does this help? Thanks Robert, but that wasn't the question. There is a major inconsistency with what pkg_version -v says is outdated and what pkgng says. Pkgng is reporting that everything is up-to-date and pkg_version is saying there are dozens of ports not up to date.I'd be more than happy to use pkgng but it's clearly not seeing the same information as pkg_version. ___ 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: pkgng vs. portupgrade reporting ports outdated
-Original Message- From: sindrome [mailto:sindr...@gmail.com] Sent: Friday, April 04, 2014 6:37 PM To: 'Robert Huff' Cc: po...@freebsd.org Subject: RE: pkgng vs. portupgrade reporting ports outdated It is my understanding it is generally a bad idea to mix the old and new package systems. (It can be done, but it's beyond my pay grade and if you're asking this I'd guess it is - at the moment - beyond yours.) "pkgng" can do almost everything the old system can, and does it better. (Now if it only had a replacement for pkg_sort ) Each records its status quo in distinct and incompatible ways. When I want to know what needs updating I use: huff>> pkg version -v -l \< which I can send either to a file, or to e-mail, or to a script wrapped around portmaster. Does this help? Here's more information foo:107:/home/foobar# pkg update Updating repository catalogue foo:108:/home/foobar# pkg upgrade Updating repository catalogue Nothing to do Now when I do a 'pkg_version -v|grep needs' I have foo:109:/home/foobar# pkg_version -v |grep needs it shows 240 ports that need updating. akonadi-1.11.0_1< needs updating (port has 1.12.0) analitza-4.12.2 < needs updating (port has 4.12.4) apr-1.4.8.1.5.3 < needs updating (port has 1.5.0.1.5.3) ark-4.12.2 < needs updating (port has 4.12.4) avogadro-1.1.1_1< needs updating (port has 1.1.1_2) bash-4.2.45_1 < needs updating (port has 4.3.0_1) blinken-4.12.2 < needs updating (port has 4.12.4) bomber-4.12.2 < needs updating (port has 4.12.4) bovo-4.12.2 < needs updating (port has 4.12.4) ca_root_nss-3.15.4 < needs updating (port has 3.15.5) cantor-4.12.2 < needs updating (port has 4.12.4) clang33-3.3_5 < needs updating (port has 3.3_6) cmake-2.8.12.1 < needs updating (port has 2.8.12.1_4) cups-client-1.5.4_1 < needs updating (port has 1.7.1) cups-image-1.5.4_1 < needs updating (port has 1.7.1) curl-7.35.0 < needs updating (port has 7.36.0) cyrus-sasl-2.1.26_4 < needs updating (port has 2.1.26_5) dconf-0.14.1< needs updating (port has 0.14.1_1) dejavu-2.34_2 < needs updating (port has 2.34_3) docbook-4.1_4 < needs updating (port has 4.5_1) docbook-4.2 < needs updating (port has 4.5_1) docbook-4.3 < needs updating (port has 4.5_1) docbook-4.4_2 < needs updating (port has 4.5_1) docbook-sk-4.1.2_4 < needs updating (port has 5.0_1) docbook-xml-4.3 < needs updating (port has 5.0_1) docbook-xml-4.4_1 < needs updating (port has 5.0_1) docbook-xml-4.5 < needs updating (port has 5.0_1) dragon-player-4.12.2< needs updating (port has 4.12.4) eigen-3.2.0 < needs updating (port has 3.2.1) facile-1.1_2< needs updating (port has 1.1_3) file-5.16 < needs updating (port has 5.18) filelight-4.12.2< needs updating (port has 4.12.4) flex-2.5.38_2 < needs updating (port has 2.5.39) fping-3.5 < needs updating (port has 3.8) freetype2-2.5.2 < needs updating (port has 2.5.3) gamin-0.1.10_6 < needs updating (port has 0.1.10_7) ghostscript9-9.06_4 < needs updating (port has 9.06_5) gmp-5.1.3 < needs updating (port has 5.1.3_1) gnupg1-1.4.16 < needs updating (port has 1.4.16_1) gnutls-2.12.23_3< needs updating (port has 2.12.23_4) granatier-4.12.2< needs updating (port has 4.12.4) gwenview-4.10.5_1 < needs updating (port has 4.12.4) imlib2-1.4.6,2 < needs updating (port has 1.4.6_1,2) isc-dhcp42-server-4.2.6 < needs updating (port has 4.2.6_1) ja-kiten-4.12.2 < needs updating (port has 4.12.4) jovie-4.12.2< needs updating (port has 4.12.4) juk-4.12.2 < needs updating (port has 4.12.4) kaccessible-4.12.2 < needs updating (port has 4.12.4) kactivities-4.10.5_3< needs updating (port has 4.12.4) kactivitymanagerd-4.10.5_3 < needs updating (port has 4.12.4) kajongg-4.10.5_1< needs updating (port has 4.12.4) kalgebra-4.12.2 < needs updating (port has 4.12.4) kalzium-4.12.2 < needs
Re: pkgng vs. portupgrade reporting ports outdated
On Fri, Apr 4, 2014 at 4:44 PM, sindrome wrote: > Here's more information > > foo:107:/home/foobar# pkg update > Updating repository catalogue > > foo:108:/home/foobar# pkg upgrade > Updating repository catalogue > Nothing to do > > Now when I do a 'pkg_version -v|grep needs' I have > pkg_* tools use the old packages database, while the pkg tool uses its own, new, database. After you upgraded to pkgng and started using it for all your package needs, your old database stopped being updated (because the old pkg_* tools aren't being used to install packages anymore). This is why the old pkg_* tools are still reporting old version information - they only see what's in their old database. Anton ___ 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"
misc/en-freebsd-doc doesn't build in rev. 350101
Updated my ports tree today, and misc/en-freebsd-doc does not build. It fails in some invisible way as shown in the attached script on both 8.4-STABLE and 9.2-STABLE. /etc/make.conf says: WITH_PKGNG=yes WITHOUT_CLANG=yes DISABLE_VULNERABILITIES=yes WITH_NEW_XORG=yes -- George typescript Description: Binary data ___ 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: pkgng vs. portupgrade reporting ports outdated
On Fri, 4 Apr 2014, sindrome wrote: There is a major inconsistency with what pkg_version -v says is outdated and what pkgng says. Of course. pkg_version looks at the text files in /var/db/pkg, while pkg looks at the database local.sqlite in that directory. The first step in using pkg is running pkg2ng, which imports the old information from the text files into the sqlite table. After that, pkg_version should not be used. It's getting information from an outdated database. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python install catch 22
On 04/04/2014 22:42, Willem Jan Withagen wrote: > Hi, > > I've tried to upgrade my python 2.7 which did not work. > Then I deinstalled all python stuff and tried to install python3 (aka 3.3) You can install both versions of python (2.7 & 3.3) at the same time, but currently you can only install a module to one of the versions at a time. So far there are still many modules that don't work with 3.x so you may want to use 2.7 if you want python with more than the default modules. The default python is still 2.7, if you want to use 3.3 then you might want to add DEFAULT_VERSIONS=PYTHON=3.3 PYTHON3=3.3 to your /etc/make.conf > The system everytime refuses to install because of missing a database: > > pkg-static: > lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so): > No such file or directory > *** [fake-pkg] Error code 74 > > [ replace python33 by python27 te get the similar error for 2.7 ] This would indicate that the dbm module wasn't built. It should be built and is a module that gives access to others that may be installed from the list below. The db modules below don't need to be installed first for _dbm.so to be built. This is an error compiling not related to the other modules. If your using a gui then scrollback in the terminal to see the error - increase scrollback limit if needed, from cli maybe use script to keep a log of the build to look through. gettext libiconv and gmake are the only things that need to be installed before python to build. Maybe there is an issue with you not building from /usr/ports ? > And then hints: > > Note that some of the standard modules are provided as separate > ports since they require extra dependencies: > > gdbmdatabases/py-gdbm > sqlite3 databases/py-sqlite3 > tkinter x11-toolkits/py-tkinter > > Install them as needed. > > > Which is nasty catch22, because one needs a recent/working python to > actually be able to do this. > > How do other cope with this? > Could using pkg to install a prebuilt binary package be an option? What FreeBSD version are you using? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RE: pkgng vs. portupgrade reporting ports outdated
So now the way to keep ports up-to-date is to execute 'pkg update' and 'pkg upgrade'? Are you saying I shouldn't svn update the ports tree anymore? oz:132:/usr/local/etc# pkg update oz:133:/usr/local/etc# pkg upgrade -Original Message- From: Warren Block [mailto:wbl...@wonkity.com] Sent: Friday, April 04, 2014 9:23 PM To: sindrome Cc: 'Robert Huff'; po...@freebsd.org Subject: RE: pkgng vs. portupgrade reporting ports outdated On Fri, 4 Apr 2014, sindrome wrote: > There is a major inconsistency with what pkg_version -v says is > outdated and what pkgng says. Of course. pkg_version looks at the text files in /var/db/pkg, while pkg looks at the database local.sqlite in that directory. The first step in using pkg is running pkg2ng, which imports the old information from the text files into the sqlite table. After that, pkg_version should not be used. It's getting information from an outdated database. ___ 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: pkgng vs. portupgrade reporting ports outdated
Okay so just 'pkg update' followed by 'pkg upgrade' after svn update? > On Apr 4, 2014, at 11:09 PM, Warren Block wrote: > >> On Fri, 4 Apr 2014, sindrome wrote: >> From: Warren Block [mailto:wbl...@wonkity.com] >> Sent: Friday, April 04, 2014 9:23 PM >> To: sindrome >> Cc: 'Robert Huff'; po...@freebsd.org >> Subject: RE: pkgng vs. portupgrade reporting ports outdated >> >>> On Fri, 4 Apr 2014, sindrome wrote: >>> >>> There is a major inconsistency with what pkg_version -v says is >>> outdated and what pkgng says. >> >> Of course. pkg_version looks at the text files in /var/db/pkg, while pkg >> looks at the database local.sqlite in that directory. The first step in >> using pkg is running pkg2ng, which imports the old information from the text >> files into the sqlite table. After that, pkg_version should not be used. >> It's getting information from an outdated database. >> >> >> So now the way to keep ports up-to-date is to execute 'pkg update' and 'pkg >> upgrade'? >> >> Are you saying I shouldn't svn update the ports tree anymore? > > No, I did not say that. > > By switching from the old pkg_* tools to pkg, all you have done is changed > which database is being used to track what is installed. Nothing else needs > to change. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RE: pkgng vs. portupgrade reporting ports outdated
On Fri, 4 Apr 2014, sindrome wrote: From: Warren Block [mailto:wbl...@wonkity.com] Sent: Friday, April 04, 2014 9:23 PM To: sindrome Cc: 'Robert Huff'; po...@freebsd.org Subject: RE: pkgng vs. portupgrade reporting ports outdated On Fri, 4 Apr 2014, sindrome wrote: There is a major inconsistency with what pkg_version -v says is outdated and what pkgng says. Of course. pkg_version looks at the text files in /var/db/pkg, while pkg looks at the database local.sqlite in that directory. The first step in using pkg is running pkg2ng, which imports the old information from the text files into the sqlite table. After that, pkg_version should not be used. It's getting information from an outdated database. So now the way to keep ports up-to-date is to execute 'pkg update' and 'pkg upgrade'? Are you saying I shouldn't svn update the ports tree anymore? No, I did not say that. By switching from the old pkg_* tools to pkg, all you have done is changed which database is being used to track what is installed. Nothing else needs to change. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkgng vs. portupgrade reporting ports outdated
On Fri, 4 Apr 2014, Sindrome wrote: On Apr 4, 2014, at 11:09 PM, Warren Block wrote: On Fri, 4 Apr 2014, sindrome wrote: From: Warren Block [mailto:wbl...@wonkity.com] On Fri, 4 Apr 2014, sindrome wrote: There is a major inconsistency with what pkg_version -v says is outdated and what pkgng says. Of course. pkg_version looks at the text files in /var/db/pkg, while pkg looks at the database local.sqlite in that directory. The first step in using pkg is running pkg2ng, which imports the old information from the text files into the sqlite table. After that, pkg_version should not be used. It's getting information from an outdated database. So now the way to keep ports up-to-date is to execute 'pkg update' and 'pkg upgrade'? Are you saying I shouldn't svn update the ports tree anymore? No, I did not say that. By switching from the old pkg_* tools to pkg, all you have done is changed which database is being used to track what is installed. Nothing else needs to change. Okay so just 'pkg update' followed by 'pkg upgrade' after svn update? [Please stop top-posting, it makes replying to your messages more difficult.] No. If you want to use ports (I do), use ports. pkg will keep track of them. Commands like pkg info replace the old versions of those commands, like pkg_info. pkg update or pkg upgrade are only used when the user wants to use binary packages instead of ports. ___ 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: lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start
On Fri, 04 Apr 2014 13:32:48 -0400 Jim Ohlstein wrote: > Hello, > > On 4/4/14, 1:28 PM, O. Hartmann wrote: > > After updating ports today and a lot of the php-stuff, I get this error > > restarting > > apache24: > > > > httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: > > Cannot > > load libexec/apache24/libphp5.so into server: Cannot open > > "/usr/local/libexec/apache24/libphp5.so" > > > > I tried to rebuild apache24 as well as lang/php5 with first rmconfig and > > then config > > again avoiding missing something. No effect. > > > > What happened here? /usr/ports/UPDATING doesn't have any kind of > > information regarding > > this subject. > > > > > From UPDATING: > > 20140327: >AFFECTS: users of lang/php5 and lang/php55 with Apache module >AUTHOR: a...@freebsd.org > >The Apache PHP module has been separated from the main PHP port. >If it is needed, install either www/mod_php5 or www/mod_php55. > > Yes, I saw this - and again, when I was firstly blind, rushed over things ... a second look - after posting here (a few seconds) made Apache work again :-( Sorry for the noise Regards, Oliver signature.asc Description: PGP signature
Re: lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start
On Fri, 4 Apr 2014 13:30:32 -0400 Shawn Webb wrote: > On Apr 04, 2014 07:28 PM +0200, O. Hartmann wrote: > > After updating ports today and a lot of the php-stuff, I get this error > > restarting > > apache24: > > > > httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: > > Cannot > > load libexec/apache24/libphp5.so into server: Cannot open > > "/usr/local/libexec/apache24/libphp5.so" > > > > I tried to rebuild apache24 as well as lang/php5 with first rmconfig and > > then config > > again avoiding missing something. No effect. > > > > What happened here? /usr/ports/UPDATING doesn't have any kind of > > information regarding > > this subject. > > > > > > Oliver > > I had this same issue, too. Installing www/mod_php5 will fix it. Yes, it will and it is also reported in the UPDATING file, but I was to unfocused to read the message carefully. Everything is shiny now ;-) Regards, Oliver signature.asc Description: PGP signature
