Re: skipping a mirror
On 8 June 2012 22:21, Warren Block wbl...@wonkity.com wrote: Is there an easy way to skip a particular distfile mirror that, say, wants to timeout forever for Gnome files? try adding RANDOMIZE_MASTER_SITES= yes to /etc/make.conf as well. -- Eitan Adler ___ 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: skipping a mirror
On Fri, Jun 8, 2012 at 11:10 PM, Eitan Adler li...@eitanadler.com wrote: On 8 June 2012 22:21, Warren Block wbl...@wonkity.com wrote: Is there an easy way to skip a particular distfile mirror that, say, wants to timeout forever for Gnome files? try adding RANDOMIZE_MASTER_SITES= yes to /etc/make.conf as well. I love this port! http://www.freebsd.org/cgi/cvsweb.cgi/ports/ports-mgmt/fastest_sites/ Parses bsd.sites.mk, and uses it to generate data for fastest mirrors, then uses it for installations :) -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh ___ 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: [CFT] gdal 1.9.1 update and other changes
Le 07.06.2012 15:52, Frank Broniewski a écrit :
Yes, that worked.
I tested it with py-gdal. First I had some problems because there were
some other programs depending gdal-grass (QGIS, Grass GIS) which linked
to the older gdal libs, but after deleting gdal-grass, I could import
the module into python and run successfully some tests against some
scripts I had written.
Thank you for the works. I will make tests today with all my
scritps/plugins.
Just a few remarks for now :
- graphics/gdal
Maybe add this options :
ARMADILLO Faster TPS transform computation
CONFIGURE_ARGS+=--with-armadillo=yes
FREEXL FreeXL support
LIB_DEPENDS+= freexl:${PORTSDIR}/textproc/freexl
CONFIGURE_ARGS+=--with-freexl=${LOCALBASE}
MDB Include MDB driver (need Java)
CONFIGURE_ARGS+=--with-mdb --with-java= ; Maybe with java bindings ?
For PDF (Poppler OR podofo)
POPPLER Poppler support (for PDF)
LIB_DEPENDS+= poppler:${PORTSDIR}/graphics/poppler
CONFIGURE_ARGS+=--with-poppler=${LOCALBASE}
PODOFO PoDoFo support (for PDF)
LIB_DEPENDS+= podofo:${PORTSDIR}/graphics/podofo
CONFIGURE_ARGS+=--with-podofo=${LOCALBASE}
--with-podofo-lib=${LOCALBASE}/lib
SPATIALITE Spatialite support
CONFIGURE_ARGS+=--with-spatialite=${LOCALBASE}
I'm working for the other options, but need add some ports (libgdata ;
ogdi ; ESRI GDB Api ; RASDAMAN)
Is it possible to add bindings options directly into graphics/gdal ?
For other bindings :
Maybe add java bindings (for MDB protocol, very useful)
For QGIS port (and maybe other like Grass)
Will need adding py-gdal when python is checked (used by plugins
GdalTools ; fTools ; openlayers ; GoogleLayers ... and many others)
Your works is very helpful thank you !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
options: xterm and wide characters
The xterm port just told me You installed xterm with wide chars support. This introduces some problems... Except WIDE_CHARS was not and still is not enabled in the port options. ___ 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: [HEADSUP] Please convert your ports to new options framework
On 8 June 2012 23:01, Doug Barton do...@freebsd.org wrote: On 06/08/2012 06:34, Chris Rees wrote: So I have a question from a consumer standpoint as opposed to a maintainer standpoint. If we use portconf to store all of our WITH_* options for ports, will that continue to work with ports that have switched to optionsng or is there something I need to change in my ports.conf file for the options to continue to be recognized? With Baptiste's latest work on backwards compatibility this should work fine now, however you should double-check that the same WITH_/WITHOUT_ knobs you have in your port.conf are still the ones defined in the ports' Makefiles. I'll make you a nice script for that purpose later. Chris, as much as I appreciate your efforts in doing this, asking the user to run scripts to convert stuff is not the answer. We need a ports system that is transparently backwards compatible for users, not one where they constantly have to jump through hoops to make things work again that have worked fine for them for years. Oh no, you're absolutely right, however people do need to migrate their configurations so we're not supporting this in ten years from now. The compat code needs ripping out at some point, and the more time people have to migrate (and test!) the better. 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
Re: libreoffice, Makefile fix proposal...
On 7 June 2012 15:28, Hiroto Kagotani hiroto.kagot...@gmail.com wrote:
2012/6/7 Sergio de Almeida Lenzi lenzi.ser...@gmail.com:
Well, now that libreoffice build is
solved, than what about insert
a line:
CONFLICTS_BUILD= boost*
near line 63 of Makefile???
libreoffice does not conflict with boost;
just Makefile has a problem.
Attached is the patch.
The only functional difference here is removing the BDB includes from CPPFLAGS;
from bsd.port.mk
.if defined(HAS_CONFIGURE)
@(cd ${CONFIGURE_WRKSRC} \
${SET_LATE_CONFIGURE_ARGS} \
if ! ${SETENV} CC=${CC} CPP=${CPP} CXX=${CXX} \
CFLAGS=${CFLAGS} CPPFLAGS=${CPPFLAGS} CXXFLAGS=${CXXFLAGS} \
So CPPFLAGS and LDFLAGS are already added to CONFIGURE_ARGS.
I would suspect something more subtle is at work here.
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
Re: [HEADSUP] Please convert your ports to new options framework
from Doug Barton do...@freebsd.org: My understanding is that one of the benefits of the new OPTIONS On 06/08/2012 06:34, Chris Rees wrote: So I have a question from a consumer standpoint as opposed to a maintainer standpoint. If we use portconf to store all of our WITH_* options for ports, will that continue to work with ports that have switched to optionsng or is there something I need to change in my ports.conf file for the options to continue to be recognized? With Baptiste's latest work on backwards compatibility this should work fine now, however you should double-check that the same WITH_/WITHOUT_ knobs you have in your port.conf are still the ones defined in the ports' Makefiles. I'll make you a nice script for that purpose later. Chris, as much as I appreciate your efforts in doing this, asking the user to run scripts to convert stuff is not the answer. We need a ports system that is transparently backwards compatible for users, not one where they constantly have to jump through hoops to make things work again that have worked fine for them for years. Doug Where is all this about the new options framework documented? There ought to be something in UPDATING file telling users what to do to stay properly in sync. Tom ___ 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: [HEADSUP] Please convert your ports to new options framework
On 09/06/2012 09:38, Thomas Mueller wrote: Where is all this about the new options framework documented? Here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html There ought to be something in UPDATING file telling users what to do to stay properly in sync. Users basically don't need to do anything different at the moment. OPTIONS dialogues may look a bit different, and the descriptive text might change a bit, but they work in exactly the same way from the user perspective. If you have WITH_FOO or WITHOUT_FOO definitions in /etc/make.conf or similar, then you will probably need to do some editing at some point. Not all WITH_/WITHOUT_ options are going: just the ones that are controlled by OPTIONS dialogues. For now, I believe everything should still keep working as before -- deleting the compatibility code is planned, but it's going to be a while yet before the ports is anywhere near ready for that to happen. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: [HEADSUP] Please convert your ports to new options framework
On 9 June 2012 09:38, Thomas Mueller muelle...@insightbb.com wrote: from Doug Barton do...@freebsd.org: My understanding is that one of the benefits of the new OPTIONS On 06/08/2012 06:34, Chris Rees wrote: So I have a question from a consumer standpoint as opposed to a maintainer standpoint. If we use portconf to store all of our WITH_* options for ports, will that continue to work with ports that have switched to optionsng or is there something I need to change in my ports.conf file for the options to continue to be recognized? With Baptiste's latest work on backwards compatibility this should work fine now, however you should double-check that the same WITH_/WITHOUT_ knobs you have in your port.conf are still the ones defined in the ports' Makefiles. I'll make you a nice script for that purpose later. Chris, as much as I appreciate your efforts in doing this, asking the user to run scripts to convert stuff is not the answer. We need a ports system that is transparently backwards compatible for users, not one where they constantly have to jump through hoops to make things work again that have worked fine for them for years. Doug Where is all this about the new options framework documented? There ought to be something in UPDATING file telling users what to do to stay properly in sync. OPTIONSng is fully backwards compatible-- there have been a few nits that have been ironed out. Currently there is no need to do anything to ensure that everything works fine-- your legacy configuration will work for the foreseeable future. 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
devel/git compile clash with kwallet
When trying to install git I get the following: === kwallet-4.8.3 conflicts with installed package(s): kdeutils-4.7.3 They install files into the same place. You may want to stop build with Ctrl + C. === License check disabled, port has not defined LICENSE = kwallet-4.8.3.tar.xz doesn't seem to exist in /usr/ports/distfiles/KDE. = Attempting to fetch http://mirrors.isc.org/pub/kde/stable/4.8.3/src/kwallet-4.8.3.tar.xz kwallet-4.8.3.tar.xz 100% of 276 kB 147 kBps === Extracting for kwallet-4.8.3 = SHA256 Checksum OK for KDE/kwallet-4.8.3.tar.xz. /bin/mkdir -p /usr/ports/security/kwallet/work/kwallet-4.8.3/build === Patching for kwallet-4.8.3 === kwallet-4.8.3 depends on file: /usr/local/bin/moc-qt4 - found === kwallet-4.8.3 depends on file: /usr/local/bin/qmake-qt4 - found === kwallet-4.8.3 depends on file: /usr/local/bin/rcc - found === kwallet-4.8.3 depends on file: /usr/local/bin/uic-qt4 - found === kwallet-4.8.3 depends on file: /usr/local/bin/automoc4 - found === kwallet-4.8.3 depends on file: /usr/local/kde4/lib/libkdecore.so.7 - found === kwallet-4.8.3 depends on file: /usr/local/bin/cmake - found === Configuring for kwallet-4.8.3 How is this best resolved if I need to have some version or other of git? Thanks in advance David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
VirtualBox on FreeBSD is looking for you!
Hi VirtualBox users! We are again at the point where I am kindly asking if someone is interested to help with the VirtualBox on FreeBSD work. We started with an active team of around 3 people but since about one year I ended up being a lonely ranger. Maintaining such a beast/high profile port by a single person is not possible for a longer period so we should really try to form a team to improve the situation. Additionally I started working on redports.org which requires more and more time so I cannot dedicate all my work to virtualbox. The situation of the port right now is not bad but I always end up fire fighting and only concentrate on serious problems due to the limited time I have. So it happens that people send bugreports and patches for virtualbox and don't get a response for weeks if at all. A lot of bugs that we have since day one are still present and the list of items that we should seriously do is getting longer. Many things of them are userland and porting stuff but there are also a lot of things to do in the kernel modules. Andriy Gapon has rewritten the r0 memory allocation stuff which significantly improved the situation in that area but the networking kernel modules are still in a bad shape. There are various known bugs (performance problems, instabilities, ...) in that area so it would be great if someone with networking expertise could have a look at the code. The USB stuff needs some love too. It is there but only works for a few special combinations of Device and Guest OS. Since VirtualBox 4.1 there is experimental support for PCI Passthrough so if we want that we need some Kernel API for the Intel/AMD IOMMU. I think the IOMMU code has already been written for BeHyVe so we need someone who puts all the stuff together and wants to find out how to integrate that in the kernel and vbox. The vbox developers offered their help on that but they need a Kernel API before we can start talking about it. So what is it that the virtualbox team needs to do? - regulary test latest SVN sources to find new problems early (build, runtime testing, create build fixes) - maintain all 8 ports (changes in CURRENT or other port updates keep breaking virtualbox around once per month) - update ports to new bugfix releases - review patches from the community and send them upstream then nag vbox developers to get them committed - help users to diagnose problems (help debugging, get stacktraces, collect information, give hints) - further porting efforts (coordinate and probably do it yourself) - optionsng adaptions - FreeBSD installer for the vbox additions to be able to build a VBoxAdditions.iso with FreeBSD support - implement vboxsf support (Shared Folders) - PCI Passthrough support - USB support (needs fixing) - Networking support (needs fixing) It is unrealistic that one single person can do a majority of these things so we seriously need a few people from different areas to improve the situation. Be it kernel developers, ports people or just power users that can help testing and diagnosing bugs. If you have an interest in VirtualBox on FreeBSD and a few spare cycles please get in contact with us (me?) to coordinate the further steps. I will do my best to help answering questions and help you with your first steps in vbox land. Don't worry if you think you are not experienced enough for the task. We all started that way and you get the chance to learn a lot - it just needs some time to get used to it. I have also created a dedicated VirtualBox on FreeBSD channel on freenode: #freebsd-vbox so you're welcome to join us! -- Bernhard Froehlich http://www.bluelife.at/ ___ 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/ess CONFLICTS with devel/noweb, help with CONFLICTS= needed
On Fri, 08 Jun 2012 22:03:49 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 08/06/2012 19:41, Christopher J. Ruwe wrote: From http://www.freebsd.org/doc/en/books/porters-handbook/book.html#CONFLICTS I gather that I should add something like CONFLICTS=noweb Usually you'ld put something like: CONFLICTS=noweb-[0-9]* just to avoid accidentally matching a package which happened to have the string 'noweb' in its name. As it is, there is only devel/noweb that would match in the ports at the moment, but making that glob expression more specific is a good principle. to the Makefile. Am I correct in my assumption on using CONFLICTS instead of CONFLICTS_INSTALL and am I correct on the naming of noweb? CONFLICTS_INSTALL means you can build your package in the presence of the conflicting package. I'd guess that most of the conflicts in the ports tree are actually of this type: due to file name collisions in the installed packages. However, plain CONFLICTS is the popular choice for Makefiles, as it takes effect before you waste too much time building a package you can't install. In principle, CONFLICTS_INSTALL is frequently going to be the more correct choice. In practice, it seems to be up to the port maintainer to choose which to specify, and most just use plain CONFLICTS. Cheers, Matthew Thanks for your quick answer. Incidentally, I am at this moment also preparing a maintainer update for a new version of math/ess. Should I perpare two PRs, one for the CONFLICTS and one for the actual update or is it permissable to pack these two into one? Thanks, cheers, -- Christopher J. Ruwe TZ: GMT + 1h signature.asc Description: PGP signature
[HEADSUP] swtiching GLUT implementation from libGLUT to freeGLUT
Hi! The FreeBSD x11 team is working on switching GLUT (OpenGL Utility Toolkit) implementation from libGLUT to freeGLUT, and the switch will happen soon. About 100 ports is affected by this and will need to be recompiled, other than that the change should be invisible to users. This change is in line with what other distributions are doing, and is because the libGLUT license does not allow for modifications, improvements or even bug fixes. FreeGLUT is a compatible rewrite under the X-consortium license and under active development. Regards -- Niclas Zeising on behalf of the FreeBSD x11 team ___ 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/ess CONFLICTS with devel/noweb, help with CONFLICTS= needed
On Fri, 08 Jun 2012 22:03:49 +0100, Matthew Seaman wrote: However, plain CONFLICTS is the popular choice for Makefiles, as it takes effect before you waste too much time building a package you can't install. In principle, CONFLICTS_INSTALL is frequently going to be the more correct choice. In practice, it seems to be up to the port maintainer to choose which to specify, and most just use plain CONFLICTS. CONFLICTS_INSTALL/BUILD are relatively new, that's why they are less spread than plain CONFLICTS. Max ___ 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/ess CONFLICTS with devel/noweb, help with CONFLICTS= needed
On 09/06/2012 12:25, Christopher J. Ruwe wrote: Thanks for your quick answer. Incidentally, I am at this moment also preparing a maintainer update for a new version of math/ess. Should I perpare two PRs, one for the CONFLICTS and one for the actual update or is it permissable to pack these two into one? It is best to put all the changes you want to make into one PR. That will get it processed most efficiently. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
mail/thunderbird: FreeBSD 10.0-CURRENT/amd64 and CLANG fail to build Thunderbird 13
My FreeBSD 10-CURRENT/amd64 boxes fail to build Thunderbird 13 compiling with CLANG. The error is very much the same as when I try compiling Firefox 13 on the same box with CLANG. I tried to track down the problem, but I failed. Bot systems are used to have very similar setups and ports, both boxes have FreeBSD 10.0-CURRENT/amd64 (FreeBSD 10.0-CURRENT #0 r236694: Wed Jun 6 23:06:12 CEST 2012), both OSes have been compiled with CLANG. The box in question is a very new Sandy-Bridge-E system with 32GB RAM, while the box compiling well is a older Core2Duo (I mention this since I read about differences in how LLVM/CLANG 3.1 may behave on different CPUs, even with -O2 enabled). I'm confused about this, since Firefox 13 and even 12 fail at the same point with a very similar error message in this xpcom module. On the box in question, I already did a portmaster -f thunderbird to force every prerequisite been built, but with no success. By the way: I use WITH_NEW_XORG in /etc/make.conf. I don't know whether this is an issue or necessary hint ... Any help appreciated. Thanks in advance, Oliver - clang++ -o ClearOnShutdown.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include ../../config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API -DMOZ_THUNDERBIRD=1 -DOSTYPE=\FreeBSD10\ -DOSARCH=FreeBSD -DEXCLUDE_SKIA_DEPENDENCIES -DOS_LINUX=1 -DOS_POSIX=1 -D_IMPL_NS_COM -I../../ipc/chromium/src -I../../ipc/glue -I../../ipc/ipdl/_ipdlheaders -I./../build -I../../xpcom/ds -I. -I. -I../../dist/include -I../../dist/include/nsprpub -I/usr/local/include/nspr -I/usr/ports/mail/thunderbird/work/comm-release/mozilla/dist/include/nss -fPIC -Qunused-arguments -I/usr/local/include -fno-rtti -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-unknown-warning-option -Wno-return-type-c-linkage -O3 -pipe -fno-strict-aliasing -DLDAP_DEPRECATED -march=native -DLDAP_DEPRECATED -fno-exceptions -fno-strict-aliasing -std=gnu++0x -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED -fno-omit-frame-pointer -D_THREAD_SAFE -D_REENTRANT -I/usr/local/include/gtk-2.0 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libpng15 -I/usr/local/include/libdrm -I/usr/local/include/gtk-unix-print-2.0-Qunused-arguments -I/usr/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/ClearOnShutdown.cpp nsIConsoleListener.idl /usr/local/bin/python2.7 ../../config/pythonpath.py \ -I../../other-licenses/ply \ -I../../xpcom/idl-parser \ -I../../xpcom/typelib/xpt/tools \ ../../xpcom/idl-parser/typelib.py --cachedir=../../xpcom/idl-parser/cache -I. -I../../dist/idl /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/nsIConsoleListener.idl -d .deps/nsIConsoleListener.xpt.pp -o _xpidlgen/nsIConsoleListener.xpt /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/nsStackWalk.cpp:1196:29: error: use of undeclared identifier '_Unwind_Backtrace' _Unwind_Reason_Code t = _Unwind_Backtrace(unwind_callback, info); ^ 1 error generated. gmake[5]: *** [nsStackWalk.o] Error 1 gmake[5]: *** Waiting for unfinished jobs In file included from /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/ClearOnShutdown.cpp:8: ../../dist/include/mozilla/ClearOnShutdown.h:113:5: warning: delete called on 'mozilla::ClearOnShutdown_Internal::ShutdownObserver' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor] delete observer; ^ 1 warning generated. /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/nsTraceRefcntImpl.cpp:403:42: warning: format specifies type 'unsigned long long' but the argument has type 'PRUint64' (aka 'unsigned long') [-Wformat] fprintf(out, %4d %-40.40s %8d %8llu %8llu %8llu (%8.2f +/- %8.2f) %8llu %8llu (%8.2f +/- %8.2f)\n, ^ %8lu /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/nsTraceRefcntImpl.cpp:403:48: warning: format specifies type 'unsigned long long' but the argument has type 'PRUint64' (aka 'unsigned long') [-Wformat] fprintf(out, %4d %-40.40s %8d %8llu %8llu %8llu (%8.2f +/- %8.2f) %8llu %8llu (%8.2f +/- %8.2f)\n, ^ %8lu
Re: mail/thunderbird: FreeBSD 10.0-CURRENT/amd64 and CLANG fail to build Thunderbird 13
On 2012-06-09 14:14, O. Hartmann wrote: My FreeBSD 10-CURRENT/amd64 boxes fail to build Thunderbird 13 compiling with CLANG. The error is very much the same as when I try compiling Firefox 13 on the same box with CLANG. ... I'm not sure this problem is related to clang at all, see below. I tried to track down the problem, but I failed. Bot systems are used to have very similar setups and ports, both boxes have FreeBSD 10.0-CURRENT/amd64 (FreeBSD 10.0-CURRENT #0 r236694: Wed Jun 6 23:06:12 CEST 2012), both OSes have been compiled with CLANG. The box in question is a very new Sandy-Bridge-E system with 32GB RAM, while the box compiling well is a older Core2Duo (I mention this since I read about differences in how LLVM/CLANG 3.1 may behave on different CPUs, even with -O2 enabled). I'm confused about this, since Firefox 13 and even 12 fail at the same point with a very similar error message in this xpcom module. ... /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/nsStackWalk.cpp:1196:29: error: use of undeclared identifier '_Unwind_Backtrace' _Unwind_Reason_Code t = _Unwind_Backtrace(unwind_callback, info); This simply looks like a problem in nsStackWalk.cpp; it should include unwind.h to get the proper declaration for _Unwind_Backtrace(). I don't have the time to look into this at the moment, but my suspicion would be that whatever Mozilla uses for its configuration scripts is not finding the proper unwind.h header. ___ 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: mail/thunderbird: FreeBSD 10.0-CURRENT/amd64 and CLANG fail to build Thunderbird 13
On 06/09/12 14:53, Dimitry Andric wrote: On 2012-06-09 14:14, O. Hartmann wrote: My FreeBSD 10-CURRENT/amd64 boxes fail to build Thunderbird 13 compiling with CLANG. The error is very much the same as when I try compiling Firefox 13 on the same box with CLANG. ... I'm not sure this problem is related to clang at all, see below. I tried to track down the problem, but I failed. Bot systems are used to have very similar setups and ports, both boxes have FreeBSD 10.0-CURRENT/amd64 (FreeBSD 10.0-CURRENT #0 r236694: Wed Jun 6 23:06:12 CEST 2012), both OSes have been compiled with CLANG. The box in question is a very new Sandy-Bridge-E system with 32GB RAM, while the box compiling well is a older Core2Duo (I mention this since I read about differences in how LLVM/CLANG 3.1 may behave on different CPUs, even with -O2 enabled). I'm confused about this, since Firefox 13 and even 12 fail at the same point with a very similar error message in this xpcom module. ... /usr/ports/mail/thunderbird/work/comm-release/mozilla/xpcom/base/nsStackWalk.cpp:1196:29: error: use of undeclared identifier '_Unwind_Backtrace' _Unwind_Reason_Code t = _Unwind_Backtrace(unwind_callback, info); This simply looks like a problem in nsStackWalk.cpp; it should include unwind.h to get the proper declaration for _Unwind_Backtrace(). I don't have the time to look into this at the moment, but my suspicion would be that whatever Mozilla uses for its configuration scripts is not finding the proper unwind.h header. Thank you for looking into this. Well, I did the follwoing. I search per find / -name unwind.h -print for unwind.h. On all of my boxes, there are plenty of them found: root@thor [~] find / -name unwind.h -print /usr/local/include/unwind.h /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.4/include/unwind.h /usr/src/include/unwind.h /usr/src/contrib/libcxxrt/unwind.h /usr/src/contrib/llvm/tools/clang/lib/Headers/unwind.h /usr/src/sys/ia64/include/unwind.h /usr/obj/usr/src/tmp/usr/include/c++/v1/unwind.h /usr/obj/usr/src/tmp/usr/include/clang/3.1/unwind.h /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_tools/unwind.h /usr/obj/usr/src/gnu/lib/libgcc/unwind.h /usr/obj/usr/src/gnu/lib/libstdc++/unwind.h /usr/obj/usr/src/gnu/lib/libsupc++/unwind.h /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/unwind.h /usr/obj/usr/src/lib32/usr/include/c++/v1/unwind.h /usr/obj/lib32/usr/src/gnu/lib/libgcc/unwind.h /usr/obj/lib32/usr/src/gnu/lib/libstdc++/unwind.h /usr/obj/lib32/usr/src/gnu/lib/libsupc++/unwind.h /usr/include/c++/v1/unwind.h /usr/include/clang/3.1/unwind.h Lppking at other places: ohartmann@thor: [~] apropos unwind _U_dyn_cancel(3) - -- cancel unwind-info for dynamically generated code _U_dyn_register(3) - -- register unwind-info for dynamically generated code libunwind(3) - -- a (mostly) platform-independent unwind API libunwind-dynamic(3) - -- libunwind-support for runtime-generated code libunwind-ia64(3)- -- IA-64-specific support in libunwind libunwind-ptrace(3) - -- ptrace() support in libunwind libunwind-setjmp(3) - -- libunwind-based non-local gotos unw_create_addr_space(3) - -- create address space for remote unwinding unw_destroy_addr_space(3) - -- destroy unwind address space unw_init_local(3)- -- initialize cursor for local unwinding unw_init_remote(3) - -- initialize cursor for remote unwinding unw_set_caching_policy(3) - -- set unwind caching policy ohartmann@thor: [~] pkg_info |grep unwind libunwind-20110911 A generic stack unwinding library ohartmann@thor: [~] pkg_info -R libunwind-20110911 Information for libunwind-20110911: Required by: blender-2.63_1 Well, on all boxes in question I/we have installed port blender and blender reels in port libunwind. I will check by deleting port libunwind wether I can build firefox/thunderbird with CLANG (gcc 4.6 works fine). Regards, oh signature.asc Description: OpenPGP digital signature
Re: [HEADSUP] Please convert your ports to new options framework
On 6/9/2012 3:38 AM, Thomas Mueller wrote: Where is all this about the new options framework documented? There's a What users need to know section here: http://wiki.freebsd.org/Ports/Options/OptionsNG 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
Firefox and firefox-remote options issues
After upgrading a system from 8 to 9 I am reinstalling all ports. Unfortunately, neither www/firefox nor www/firefox-remote is handling options correctly. I'm just guessing that it is related to optionsng. The options dialog always comes up with the default options showing. If I modify these, they are not being stored and the port seems to build without the selected options. Worse, when I used portmaster to install firefox-remote, I was queried for options at the start and again before the install and then the install failed because the build had not built the option I specified. I have never seen this sort of behavior and it appears to be only these two ports. Neither has converted to optionsng. The re-install of all ports will be running for a while as there are about 700 ports still to be installed, but after it finishes I will try to figure out what is going wrong, but I'll have to admit that my make experience is fairly basic. Any idea why these two ports seem to be failing to process options correctly? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Firefox and firefox-remote options issues
On Jun 9, 2012 4:52 PM, Kevin Oberman kob6...@gmail.com wrote: After upgrading a system from 8 to 9 I am reinstalling all ports. Unfortunately, neither www/firefox nor www/firefox-remote is handling options correctly. I'm just guessing that it is related to optionsng. The options dialog always comes up with the default options showing. If I modify these, they are not being stored and the port seems to build without the selected options. Worse, when I used portmaster to install firefox-remote, I was queried for options at the start and again before the install and then the install failed because the build had not built the option I specified. I have never seen this sort of behavior and it appears to be only these two ports. Neither has converted to optionsng. The re-install of all ports will be running for a while as there are about 700 ports still to be installed, but after it finishes I will try to figure out what is going wrong, but I'll have to admit that my make experience is fairly basic. Any idea why these two ports seem to be failing to process options correctly? --, Does the file /var/db/ports/firefox/options exist? Can you put it up somewhere? 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
Re: Firefox and firefox-remote options issues
On Sat, Jun 9, 2012 at 8:55 AM, Chris Rees utis...@gmail.com wrote: On Jun 9, 2012 4:52 PM, Kevin Oberman kob6...@gmail.com wrote: After upgrading a system from 8 to 9 I am reinstalling all ports. Unfortunately, neither www/firefox nor www/firefox-remote is handling options correctly. I'm just guessing that it is related to optionsng. The options dialog always comes up with the default options showing. If I modify these, they are not being stored and the port seems to build without the selected options. Worse, when I used portmaster to install firefox-remote, I was queried for options at the start and again before the install and then the install failed because the build had not built the option I specified. I have never seen this sort of behavior and it appears to be only these two ports. Neither has converted to optionsng. The re-install of all ports will be running for a while as there are about 700 ports still to be installed, but after it finishes I will try to figure out what is going wrong, but I'll have to admit that my make experience is fairly basic. Any idea why these two ports seem to be failing to process options correctly? --, Does the file /var/db/ports/firefox/options exist? Can you put it up somewhere? Wow! Not what I expected to find! Yes, /var/db/ports/firefox/options is there, but /var/db/ports/firefox-remote/options is not. And, when I look at /var/db/ports/firefox/options, it actually contains the options for firefox-remote! If I go into www/firefox and make config, /var/db/ports/firefox-remote/options contains the right options. Ouch. I'll need to re-build firefox-remote later, but at least I now expect firefox to build as I want it to. Something in parsing the port name seems to have been broken. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/gcc46 building stuff in $TMPDIR
On 06/06/2012 23:15, Gerald Pfeifer wrote: On Wed, 6 Jun 2012, Doug Barton wrote: I purposely have a tiny /tmp, and while building gcc46 today it filled up with stuff from the gcc build. Is there any way to modify this process so that it keeps everything in WRKDIR? GCC in general should put all its build stuff in WRKDIR and only stash really temporary things (coming from an individual invocation of GCC such as assembly files if any) in /tmp for short periods of time. I am not aware of anything we could do beyond what I already have in the port, but then this is the first time I hear about this, in the context of FreeBSD and also upstream. Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. Doug -- This .signature sanitized for your protection ___ 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: Documenting 'make config' options
On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? Doug -- This .signature sanitized for your protection ___ 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: Documenting 'make config' options
On 06/09/2012 11:35 AM, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? I think it is a good idea. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/16873: commit references a PR
The following reply was made to PR ports/16873; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: ports/16873: commit references a PR Date: Sat, 9 Jun 2012 16:43:42 + (UTC) rakuco 2012-06-09 16:43:33 UTC FreeBSD ports repository Modified files: net/gnu-dico Makefile Log: - Adjust the gsasl dependency to the current shlib version. - Bump PORTREVISION. PR: ports/16873 Submitted by: rakuco Revision ChangesPath 1.6 +2 -2 ports/net/gnu-dico/Makefile ___ cvs-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to cvs-all-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/git compile clash with kwallet
David Southwell ad...@vizion2000.net writes: When trying to install git I get the following: Just for posterity's sake, this is probably git with the SVN option enabled, and devel/subversion with KWALLET enabled. === kwallet-4.8.3 conflicts with installed package(s): kdeutils-4.7.3 They install files into the same place. You may want to stop build with Ctrl + C. Take a look at the UPDATING entry from 20120525 about many KDE ports having been split. kdeutils4 is now a metaport that depends on the many kdeutils applications that have each been moved into a separate port. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
I try to track down problems on one of our FreeBSD 10.0-CURRENT/amd64
boxes and therefore, I try recompiling xorg.
One box is constantly failing to compile port graphics/dri with a
obviously well know error, as googling reveals (
http://lists.freedesktop.org/archives/mesa-dev/2011-December/016348.html).
I share /etc/make.conf and /etc/src.conf on those FreeBSD 10.0-CURRENT
boxes, they are supposed to have set
WITH_NEW_XORG=yes
WITHOUT_NOUVEAU=yes
There was a time when also WITH_KMS=yes was set on the box in question,
but I disabled that again (commented out).
The problem is sticky. I also tried portmaster -f graphics/dri,
everything is compiled well (CLANG) until it comes to graphics/dri itself.
graphics/libdrm is compiled without KMS.
Somehow bad things slipped into the system and I feel like floating like
a dead man in the water. I considered deleting /var/db/pkg/*, since
sometimes I need to delete manually specific folders in that directory
to make a port compiling again. But I do not know wether this is
introducing larger problems.
Compiling the whole ports (implies deleting them all) is no option for
this moment.
Does anyone know this problem and has a solution to get rid of this
sticky thing?
Regards,
Oliver
[...]
../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/local/include -I/usr/local/include/libdrm-DFEATURE_GL=1
-I/usr/local/include -I/usr/local/include/libdrm
-I/usr/local/include/nouveau -I/usr/local/include -O3 -pipe
-fno-strict-aliasing -march=native -Wall -Wmissing-prototypes -std=c99
-fno-strict-aliasing -O3 -pipe -fno-strict-aliasing -march=native -fPIC
-DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -fvisibility=hidden
nouveau_scratch.c -o nouveau_scratch.o
clang -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mapi
-I../../../../../src/mesa -I../../../../../src/egl/main
-I../../../../../src/egl/drivers/dri -I/usr/local/include
-I/usr/local/include/libdrm-DFEATURE_GL=1 -I/usr/local/include
-I/usr/local/include/libdrm -I/usr/local/include/nouveau
-I/usr/local/include -O3 -pipe -fno-strict-aliasing -march=native -Wall
-Wmissing-prototypes -std=c99 -fno-strict-aliasing -O3 -pipe
-fno-strict-aliasing -march=native -fPIC -DUSE_X86_64_ASM
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -fvisibility=hidden nouveau_array.c -o
nouveau_array.o
nouveau_array.c:49:16: error: illegal storage class on function
*extract_u = EXTRACT(char, unsigned, 1);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:49:16: error: expected ';' at end of declaration
*extract_u = EXTRACT(char, unsigned, 1);
^
nouveau_array.c:39:50: note: expanded from macro 'EXTRACT'
out_t f(struct nouveau_array *a, int i, int j) {\
^
nouveau_array.c:50:16: error: illegal storage class on function
*extract_f = EXTRACT(char, float, SCHAR_MAX);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:50:16: error: expected ';' at end of declaration
*extract_f = EXTRACT(char, float, SCHAR_MAX);
^
nouveau_array.c:39:50: note: expanded from macro 'EXTRACT'
out_t f(struct nouveau_array *a, int i, int j) {\
^
nouveau_array.c:53:16: error: illegal storage class on function
*extract_u = EXTRACT(unsigned char, unsigned, 1);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:53:16: error: expected ';' at end of declaration
*extract_u = EXTRACT(unsigned char, unsigned, 1);
^
nouveau_array.c:39:50: note: expanded from macro 'EXTRACT'
out_t f(struct nouveau_array *a, int i, int j) {\
^
nouveau_array.c:54:16: error: illegal storage class on function
*extract_f = EXTRACT(unsigned char, float, UCHAR_MAX);
^
nouveau_array.c:38:3: note: expanded from macro 'EXTRACT'
auto out_t f(struct nouveau_array *, int, int); \
^
nouveau_array.c:54:16: error: expected ';' at end of declaration
*extract_f
Re: Documenting 'make config' options
On Sat, Jun 09, 2012 at 09:35:12AM -0700, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? Doug -- This .signature sanitized for your protection ___ 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 There was a PR[1] to use some dialog(1) feature to expose it to the user, would be nice if that extended description could implemented that way (using help button from dialog(1)) I do not plan to work on this now if someone want to do it that will be great 1: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123185 regards, Bapt pgpdCLwnNscxz.pgp Description: PGP signature
Re: graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 2012-06-09 19:00, O. Hartmann wrote: ... I try to track down problems on one of our FreeBSD 10.0-CURRENT/amd64 boxes and therefore, I try recompiling xorg. One box is constantly failing to compile port graphics/dri with a obviously well know error, as googling reveals ( http://lists.freedesktop.org/archives/mesa-dev/2011-December/016348.html). I share /etc/make.conf and /etc/src.conf on those FreeBSD 10.0-CURRENT boxes, they are supposed to have set WITH_NEW_XORG=yes WITHOUT_NOUVEAU=yes There was a time when also WITH_KMS=yes was set on the box in question, but I disabled that again (commented out). The problem is sticky. I also tried portmaster -f graphics/dri, everything is compiled well (CLANG) until it comes to graphics/dri itself. You asked the same question a few weeks ago: http://docs.freebsd.org/cgi/mid.cgi?4F9BC101.8090305 I posted a patch here: http://docs.freebsd.org/cgi/mid.cgi?4F9C2047.8020108 Afterwards, I asked either the libGL maintainers or x11@ if it was OK to commit, but I received no response. ___ 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
How to uninstall pkgng
I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/git compile clash with kwallet
On Sat, Jun 09, 2012 at 01:51:22PM -0300, Raphael Kubo da Costa wrote: David Southwell ad...@vizion2000.net writes: When trying to install git I get the following: Just for posterity's sake, this is probably git with the SVN option enabled, and devel/subversion with KWALLET enabled. === kwallet-4.8.3 conflicts with installed package(s): kdeutils-4.7.3 They install files into the same place. You may want to stop build with Ctrl + C. Take a look at the UPDATING entry from 20120525 about many KDE ports having been split. kdeutils4 is now a metaport that depends on the many kdeutils applications that have each been moved into a separate port. Since when would git have any direct relationship to KDE ? -- - (2^(N-1)) ___ 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: How to uninstall pkgng
On 6/9/2012 7:46 PM, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. Have you looked at http://pkgbeta.freebsd.org/freebsd-9-amd64/latest/ ? What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. ___ 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: How to uninstall pkgng
On 09/06/2012 18:46, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. Not easy. You'ld have to delete the pkg port, undo any additional configuration you may have added to eg. /etc/make.conf (ie. remove WITH_PKGNG settings), undo any patches to portmaster (if you're using that) and then reinstall all your ports using the original package tools to rebuild /var/db/pkg/ contents. /usr/sbin/pkg is part of base nowadays. You don't want to delete that. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: devel/git compile clash with kwallet
Jason Hellenthal jhellent...@dataix.net writes: Since when would git have any direct relationship to KDE ? It doesn't have a direct relationship. Please see what I wrote here: Just for posterity's sake, this is probably git with the SVN option enabled, and devel/subversion with KWALLET enabled. ___ 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: Imagemagick: FAIL: Magick++/tests/averageImages.sh
On 05/26/2012 17:01, Doug Barton wrote: What would be helpful to diagnose this? I'm on current r236118 FYI, it's the OPENMP option that causes this to fail. All of my other options work fine. hth, Doug -- This .signature sanitized for your protection ___ 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: How to uninstall pkgng
On Sat, Jun 09, 2012 at 07:03:23PM +0100, Matthew Seaman wrote: On 09/06/2012 18:46, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. Not easy. You'ld have to delete the pkg port, undo any additional configuration you may have added to eg. /etc/make.conf (ie. remove WITH_PKGNG settings), undo any patches to portmaster (if you're using that) and then reinstall all your ports using the original package tools to rebuild /var/db/pkg/ contents. /usr/sbin/pkg is part of base nowadays. You don't want to delete that. When was pkgng made part of base ? /usr/sbin/pkg would be from pkgng if you are using it to delete itself then the problem you are experiencing is the file is busy at the time of deletion. Try pkg_delete instead ? -- - (2^(N-1)) ___ 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: NO_OPTIONS_SORT makes options disappear
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2012 23:04, Baptiste Daroussin wrote: On Mon, Jun 04, 2012 at 03:58:24PM -0700, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2012 15:40, Baptiste Daroussin wrote: Can you try with this patch ? http://people.freebsd.org/~bapt/bsd.options.mk.diff Still adding NO_OPTIONS_SORT=yes With this change the options are no longer sorted, and do appear, but they appear twice. FYI, you can test this yourself in the dns/bind* ports. Fixed Sorry for the late response, but I can confirm that this is fixed, along with my other concerns about backwards compatibility. Thanks for addressing these issues so quickly. I think that this will greatly ease the transition to the new system, and significantly improve the user experience. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP05V7AAoJEFzGhvEaGryE0gMIAKN5OY38rvCte2UM9ZsfVdJp 5BclP9Gwza6W1h73o+C+TsZLed/vxCGcx6nc3AcQ4MISBKmmMilo7eFTwm+4y+5p coQURm0/Kq3UZBeBeJpJBQ9g9j8ADACIfadCAr7MTUiw3uNpAzxr8zvIA6jy4atS BkkOnXDUhJy0zoIlPcQebt7dxdUceWj87/2O41T5YSGvIELWFWGdfhFjMNHP1dJ+ pu6v6oRBEJ8rHtqeRgjUAdntlhbI4OWmInJUwMNJMErV1zTQL0FwIBOch34dIapt 91EzNiMkUDfehRZaQ1G+9VToDHZWkv5wZQ2hBgysBaCRCTS3pMcH1MbS8ffhWzQ= =VwWh -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: How to uninstall pkgng
On Sat, Jun 9, 2012 at 8:23 PM, Jason Hellenthal jhellent...@dataix.net wrote: On Sat, Jun 09, 2012 at 07:03:23PM +0100, Matthew Seaman wrote: On 09/06/2012 18:46, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. Not easy. You'ld have to delete the pkg port, undo any additional configuration you may have added to eg. /etc/make.conf (ie. remove WITH_PKGNG settings), undo any patches to portmaster (if you're using that) and then reinstall all your ports using the original package tools to rebuild /var/db/pkg/ contents. /usr/sbin/pkg is part of base nowadays. You don't want to delete that. So I guess that if I have empty /usr/local, no make.conf and no /var/db/pkg/local.sqlite then I'm fine ? When was pkgng made part of base ? It seems to be a simple wrapper/bootstrapper (see src/usr.sbin/pkg) that just downloads real thing. /usr/sbin/pkg would be from pkgng if you are using it to delete itself then the problem you are experiencing is the file is busy at the time of deletion. Try pkg_delete instead ? It have deleted itself just fine. -- - (2^(N-1)) ___ 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: How to uninstall pkgng
On 6/9/2012 8:23 PM, Jason Hellenthal wrote: On Sat, Jun 09, 2012 at 07:03:23PM +0100, Matthew Seaman wrote: On 09/06/2012 18:46, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. Not easy. You'ld have to delete the pkg port, undo any additional configuration you may have added to eg. /etc/make.conf (ie. remove WITH_PKGNG settings), undo any patches to portmaster (if you're using that) and then reinstall all your ports using the original package tools to rebuild /var/db/pkg/ contents. /usr/sbin/pkg is part of base nowadays. You don't want to delete that. When was pkgng made part of base ? The bootstrap binary is in base, not pkgng. /usr/sbin/pkg would be from pkgng if you are using it to delete itself then the problem you are experiencing is the file is busy at the time of deletion. Try pkg_delete instead ? Wrong, this is the bootstrap binary. The pkg binary is in LOCALBASE. ___ 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: Firefox and firefox-remote options issues
On 09/06/2012 17:02, Kevin Oberman wrote: Wow! Not what I expected to find! Yes, /var/db/ports/firefox/options is there, but /var/db/ports/firefox-remote/options is not. And, when I look at /var/db/ports/firefox/options, it actually contains the options for firefox-remote! If I go into www/firefox and make config, /var/db/ports/firefox-remote/options contains the right options. Ouch. I'll need to re-build firefox-remote later, but at least I now expect firefox to build as I want it to. Something in parsing the port name seems to have been broken. That looks to be an accident. Both those ports share the same options file: % cd /usr/ports % make -C www/firefox -V OPTIONSFILE /var/db/ports/firefox/options % make -C www/firefox-remote -V OPTIONSFILE /var/db/ports/firefox/options Ultimately this is because both those ports have PORTNAME=firefox, which means both of them end up with the same UNIQUENAME, which is clearly a bit contrary to the intent of that variable. This would have been the case even before OPTIONSng -- the location where options would be stored hasn't changed. However, firefox-remote doesn't set any options of its own, so previously it wouldn't have used its options file at all. One of the effects of OPTIONSng is that every port technically now uses options so would now use an options file. So collisions like this are going to show up. However, not all ports sharing OPTIONSFILEs are accidental. For instance Postgresql ports all use a shared file quite deliberately. Attached is a list of all the ports with a non-unique UNIQUENAME setting. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW uniquename | portname -+--- ImageMagick | graphics/ImageMagick ImageMagick | graphics/ImageMagick-nox11 PackageKit | ports-mgmt/packagekit PackageKit | ports-mgmt/packagekit-qt4 WebCalendar | www/webcalendar WebCalendar | www/webcalendar-devel akode | audio/akode akode | audio/akode-plugins-ffmpeg alienarena | games/alienarena alienarena | games/alienarena-data amanda | misc/amanda26-client amanda | misc/amanda26-server amanda | misc/amanda32-client amanda | misc/amanda32-server amanda-client | misc/amanda-client amanda-client | misc/amanda25-client amanda-server | misc/amanda-server amanda-server | misc/amanda25-server amule | net-p2p/amule amule | net-p2p/amule-devel apr | devel/apr0 apr | devel/apr1 apr | devel/apr2 argus | net-mgmt/argus argus | net-mgmt/argus3 argus-clients | net-mgmt/argus-clients argus-clients | net-mgmt/argus3-clients asterisk| net/asterisk asterisk| net/asterisk10 asterisk| net/asterisk14 asterisk| net/asterisk16 atlas | math/atlas atlas | math/atlas-devel avahi | net/avahi avahi | net/avahi-app avahi | net/avahi-autoipd avahi | net/avahi-gtk avahi | net/avahi-libdns avahi | net/avahi-qt3 avahi | net/avahi-qt4 avahi | net/avahi-sharp avant-window-navigator | x11/avant-window-navigator avant-window-navigator | x11/avant-window-navigator-gnome barnyard2 | security/barnyard2 barnyard2 | security/barnyard2-sguil bird| net/bird bird| net/bird-devel blender | graphics/blender blender | graphics/blender-doc bluefish| www/bluefish bluefish| www/bluefish-devel boehm-gc| devel/boehm-gc boehm-gc| devel/boehm-gc-redirect boehm-gc| devel/boehm-gc-threaded bogofilter | mail/bogofilter bogofilter | mail/bogofilter-sqlite bogofilter | mail/bogofilter-tc boxbackup | sysutils/boxbackup boxbackup | sysutils/boxbackup-devel cairo | graphics/cairo
Re: How to uninstall pkgng
On Sat, Jun 09, 2012 at 08:32:03PM +0200, Julien Laffaye wrote: On 6/9/2012 8:23 PM, Jason Hellenthal wrote: On Sat, Jun 09, 2012 at 07:03:23PM +0100, Matthew Seaman wrote: On 09/06/2012 18:46, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. Not easy. You'ld have to delete the pkg port, undo any additional configuration you may have added to eg. /etc/make.conf (ie. remove WITH_PKGNG settings), undo any patches to portmaster (if you're using that) and then reinstall all your ports using the original package tools to rebuild /var/db/pkg/ contents. /usr/sbin/pkg is part of base nowadays. You don't want to delete that. When was pkgng made part of base ? The bootstrap binary is in base, not pkgng. /usr/sbin/pkg would be from pkgng if you are using it to delete itself then the problem you are experiencing is the file is busy at the time of deletion. Try pkg_delete instead ? Wrong, this is the bootstrap binary. The pkg binary is in LOCALBASE. Missed that. This is pretty confusing as stable/8 releng/9 does not have a pkg while head and stable/9 do. -- - (2^(N-1)) ___ 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: Firefox and firefox-remote options issues
On Sat, Jun 9, 2012 at 11:54 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 09/06/2012 17:02, Kevin Oberman wrote: Wow! Not what I expected to find! Yes, /var/db/ports/firefox/options is there, but /var/db/ports/firefox-remote/options is not. And, when I look at /var/db/ports/firefox/options, it actually contains the options for firefox-remote! If I go into www/firefox and make config, /var/db/ports/firefox-remote/options contains the right options. Ouch. I'll need to re-build firefox-remote later, but at least I now expect firefox to build as I want it to. Something in parsing the port name seems to have been broken. That looks to be an accident. Both those ports share the same options file: % cd /usr/ports % make -C www/firefox -V OPTIONSFILE /var/db/ports/firefox/options % make -C www/firefox-remote -V OPTIONSFILE /var/db/ports/firefox/options Ultimately this is because both those ports have PORTNAME=firefox, which means both of them end up with the same UNIQUENAME, which is clearly a bit contrary to the intent of that variable. This would have been the case even before OPTIONSng -- the location where options would be stored hasn't changed. However, firefox-remote doesn't set any options of its own, so previously it wouldn't have used its options file at all. One of the effects of OPTIONSng is that every port technically now uses options so would now use an options file. So collisions like this are going to show up. However, not all ports sharing OPTIONSFILEs are accidental. For instance Postgresql ports all use a shared file quite deliberately. Attached is a list of all the ports with a non-unique UNIQUENAME setting. Ahh. If I'd had some time, I suspect I would have spotted it. I am amazed that it has never bitten me in the past as I have had this port installed for over a decade. Of course, it would not have shown up using portupgrade, but portmaster does show it as it queries for options for all ports to be built BEFORE it starts building. I guess I never noticed that firefox-remote always asks for options but was seldom rebuilt while firefox is built frequently, but I guess I've never done a system where both were installed by portmaster in a single operation. Thanks. I'll drop the maintainer of firefox-remote a note open a PR on it. R. Kevin Oberman - Network Engineer rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: math/ess CONFLICTS with devel/noweb, help with CONFLICTS= needed
On 9-6-2012 14:02, Matthew Seaman wrote: On 09/06/2012 12:25, Christopher J. Ruwe wrote: Thanks for your quick answer. Incidentally, I am at this moment also preparing a maintainer update for a new version of math/ess. Should I perpare two PRs, one for the CONFLICTS and one for the actual update or is it permissable to pack these two into one? It is best to put all the changes you want to make into one PR. That will get it processed most efficiently. And if there's a PR for the conflict problem, then mention in your update PR that this update closes PR xx. -- Mel ___ 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: libreoffice, Makefile fix proposal...
On 9-6-2012 9:42, Chris Rees wrote:
On 7 June 2012 15:28, Hiroto Kagotani hiroto.kagot...@gmail.com wrote:
2012/6/7 Sergio de Almeida Lenzi lenzi.ser...@gmail.com:
Well, now that libreoffice build is
solved, than what about insert
a line:
CONFLICTS_BUILD=boost*
near line 63 of Makefile???
libreoffice does not conflict with boost;
just Makefile has a problem.
Attached is the patch.
The only functional difference here is removing the BDB includes from
CPPFLAGS;
from bsd.port.mk
.if defined(HAS_CONFIGURE)
@(cd ${CONFIGURE_WRKSRC} \
${SET_LATE_CONFIGURE_ARGS} \
if ! ${SETENV} CC=${CC} CPP=${CPP} CXX=${CXX} \
CFLAGS=${CFLAGS} CPPFLAGS=${CPPFLAGS} CXXFLAGS=${CXXFLAGS} \
So CPPFLAGS and LDFLAGS are already added to CONFIGURE_ARGS.
I would suspect something more subtle is at work here.
If this fixes things, then some /real/ configure options are the
culprit. This fix doesn't work like the author thinks it does, since
CONFIGURE_ARGS is /not/ CONFIGURE_ENV. So this would effectively result
in environment variables being passed as arguments to the configure
script. You'd have to look at the configure script implementation to see
what the consequences are of that.
--
Mel
___
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: Imagemagick: FAIL: Magick++/tests/averageImages.sh
Doug Barton writes: FYI, it's the OPENMP option that causes this to fail. All of my other options work fine. Um ... with OPENMP de-selected IM hangs in tests/validate-streams.sh. Robert mileage may vary 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: graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 06/09/12 19:34, Dimitry Andric wrote: On 2012-06-09 19:00, O. Hartmann wrote: ... I try to track down problems on one of our FreeBSD 10.0-CURRENT/amd64 boxes and therefore, I try recompiling xorg. One box is constantly failing to compile port graphics/dri with a obviously well know error, as googling reveals ( http://lists.freedesktop.org/archives/mesa-dev/2011-December/016348.html). I share /etc/make.conf and /etc/src.conf on those FreeBSD 10.0-CURRENT boxes, they are supposed to have set WITH_NEW_XORG=yes WITHOUT_NOUVEAU=yes There was a time when also WITH_KMS=yes was set on the box in question, but I disabled that again (commented out). The problem is sticky. I also tried portmaster -f graphics/dri, everything is compiled well (CLANG) until it comes to graphics/dri itself. You asked the same question a few weeks ago: http://docs.freebsd.org/cgi/mid.cgi?4F9BC101.8090305 I posted a patch here: http://docs.freebsd.org/cgi/mid.cgi?4F9C2047.8020108 Afterwards, I asked either the libGL maintainers or x11@ if it was OK to commit, but I received no response. O, sorry. I deleted the /usr/ports completely on that specific box. Now, with your patch set installed again, graphics/dri compiles without a flaw. I was wondering why there are not more people/FreeBSD users out there having the very same problem. I'd appreciate your patch getting permanent soon. Thanks, Oliver signature.asc Description: OpenPGP digital signature
Re: Imagemagick: FAIL: Magick++/tests/averageImages.sh
On 06/09/2012 12:53, Robert Huff wrote: Doug Barton writes: FYI, it's the OPENMP option that causes this to fail. All of my other options work fine. Um ... with OPENMP de-selected IM hangs in tests/validate-streams.sh. What I did was to start with the defaults and make sure that it passed all the tests. Then I added stuff until it failed. My working set: OPTIONS_FILE_SET+=IMAGEMAGICK_16BIT_PIXEL OPTIONS_FILE_SET+=IMAGEMAGICK_BZLIB OPTIONS_FILE_UNSET+=IMAGEMAGICK_DJVU OPTIONS_FILE_UNSET+=IMAGEMAGICK_DOT OPTIONS_FILE_SET+=IMAGEMAGICK_FFTW OPTIONS_FILE_SET+=IMAGEMAGICK_FONTCONFIG OPTIONS_FILE_UNSET+=IMAGEMAGICK_FPX OPTIONS_FILE_UNSET+=IMAGEMAGICK_GSLIB OPTIONS_FILE_SET+=IMAGEMAGICK_JBIG OPTIONS_FILE_SET+=IMAGEMAGICK_JPEG OPTIONS_FILE_SET+=IMAGEMAGICK_JPEG2000 OPTIONS_FILE_SET+=IMAGEMAGICK_LCMS2 OPTIONS_FILE_UNSET+=IMAGEMAGICK_LCMS OPTIONS_FILE_SET+=IMAGEMAGICK_LZMA OPTIONS_FILE_SET+=IMAGEMAGICK_LQR OPTIONS_FILE_SET+=IMAGEMAGICK_MODULES OPTIONS_FILE_UNSET+=IMAGEMAGICK_OPENEXR OPTIONS_FILE_UNSET+=IMAGEMAGICK_OPENMP OPTIONS_FILE_SET+=IMAGEMAGICK_PANGO OPTIONS_FILE_SET+=IMAGEMAGICK_PDF OPTIONS_FILE_SET+=IMAGEMAGICK_PERL OPTIONS_FILE_SET+=IMAGEMAGICK_PNG OPTIONS_FILE_SET+=IMAGEMAGICK_SVG OPTIONS_FILE_SET+=IMAGEMAGICK_TESTS OPTIONS_FILE_SET+=IMAGEMAGICK_TIFF OPTIONS_FILE_SET+=IMAGEMAGICK_TTF OPTIONS_FILE_SET+=IMAGEMAGICK_WEBP OPTIONS_FILE_UNSET+=IMAGEMAGICK_WMF OPTIONS_FILE_SET+=THREADS hth, Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/dri: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 2012-06-09 21:57, O. Hartmann wrote: ... Now, with your patch set installed again, graphics/dri compiles without a flaw. I was wondering why there are not more people/FreeBSD users out there having the very same problem. Most likely because neither WITH_NEW_XORG nor CC=clang are defaults (at least not yet ;). I haven't exactly followed the new xorg import, but I imagine it has been a huge effort to get everything upgraded without breaking too much existing stuff. However, this kind of major update always causes a few edge cases to blow up. That's why miwi sent the call for testing to several mailing lists. So please test, and if possible, send fixes! :) I'd appreciate your patch getting permanent soon. Since this particular fix isn't yet integrated into the latest MesaLib release, I filed a PR, ports/168902. ___ 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 x11/xdm list of installed files incomplete?
Mel alerted me to the fact that my original post got mangled (due to my screemap mis-configuration). So I resend it. # þkg infø -xl xðm xðm-¹.¹.¹¹ øwns the følløwing files: /usr/løcãl/bin/xðm /usr/løcãl/lib/X¹¹/xðm/ãuthðir /usr/løcãl/lib/X¹¹/xðm/chøøser /usr/løcãl/lib/X¹¹/xðm/libXðmGreet.lã /usr/løcãl/lib/X¹¹/xðm/libXðmGreet.sø /usr/løcãl/lib/X¹¹/xðm/þixmãþs/xørg-bw.xþm /usr/løcãl/lib/X¹¹/xðm/þixmãþs/xørg.xþm /usr/løcãl/mãn/mãn¹/xðm.¹.gz /usr/løcãl/shãre/X¹¹/ãþþ-ðefãults/©høøser /usr/løcãl/shãre/exãmþles/xðm/Give©ønsøle /usr/løcãl/shãre/exãmþles/xðm/Tãke©ønsøle /usr/løcãl/shãre/exãmþles/xðm/Xãccess /usr/løcãl/shãre/exãmþles/xðm/Xreset /usr/løcãl/shãre/exãmþles/xðm/Xresøurces /usr/løcãl/shãre/exãmþles/xðm/Xservers /usr/løcãl/shãre/exãmþles/xðm/Xsessiøn /usr/løcãl/shãre/exãmþles/xðm/Xsetuþ_0 /usr/løcãl/shãre/exãmþles/xðm/Xstãrtuþ /usr/løcãl/shãre/exãmþles/xðm/Xwilling /usr/løcãl/shãre/exãmþles/xðm/xðm-cønfig /usr/løcãl/shãre/licenses/xðm-¹.¹.¹¹/LÏ©ËNSË /usr/løcãl/shãre/licenses/xðm-¹.¹.¹¹/MÏT /usr/løcãl/shãre/licenses/xðm-¹.¹.¹¹/cãtãløg.mk However, these files are also installed by xdm: # ls -ãl /usr/løcãl/lib/X¹¹/xðm/ tøtãl ¹20 ðrwxr-xr-x 4 røøt wheel5¹2 Jun 8 ¹5:³5 . ðrwxr-xr-x ¹¹ røøt wheel5¹2 Jun 9 22:¹¹ .. -r-xr-xr-x ¹ røøt wheel³25 Jun 8 ¹5:³5 Give©ønsøle -r-xr-xr-x ¹ røøt wheel¹84 Jun 8 ¹5:³5 Tãke©ønsøle -r--r--r-- ¹ røøt wheel ³40¹ Jun 8 ¹5:³5 Xãccess -r-xr-xr-x ¹ røøt wheel¹9³ Jun 8 ¹5:³5 Xreset -r--r--r-- ¹ røøt wheel 2744 Jun 8 ¹5:³9 Xresøurces -r--r--r-- ¹ røøt wheel429 Jun 8 ¹5:³5 Xservers -r-xr-xr-x ¹ røøt wheel875 Jun 8 ¹5:³5 Xsessiøn -r-xr-xr-x ¹ røøt wheel 88 Jun 8 ¹5:³5 Xsetuþ_0 -r-xr-xr-x ¹ røøt wheel¹96 Jun 8 ¹5:³5 Xstãrtuþ -r-xr-xr-x ¹ røøt wheel29¹ Jun 8 ¹5:³5 Xwilling ðrwx-- ³ røøt wheel5¹2 Jun 8 ¹5:³5 ãuthðir -r-xr-xr-x ¹ røøt wheel 20568 Jun 8 ¹5:³5 chøøser -rwxr-xr-x ¹ røøt wheel ¹47¹ Jun 8 ¹5:³5 libXðmGreet.lã -rwxr-xr-x ¹ røøt wheel 62079 Jun 8 ¹5:³5 libXðmGreet.sø ðrwxr-xr-x 2 røøt wheel5¹2 Jun 8 ¹5:³5 þixmãþs -r--r--r-- ¹ røøt wheel ¹³46 Jun 8 ¹5:³5 xðm-cønfig # most of which are not shown with pkg info -l Maybe something is wrong with plist? Or am I confusing myself? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Documenting 'make config' options
On Sat, 9 Jun 2012, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? The user needs to know what the options mean when they appear, and having to go look them up in another file is just another hassle. Difficult to do in some situations, too. Better to show them when the user scrolls to that option. Here's what I suggested in -stable: http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068187.html No new files, only one copy of the descriptions so they don't get out of sync. ___ 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: Documenting 'make config' options
On 06/09/2012 17:54, Warren Block wrote: On Sat, 9 Jun 2012, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? The user needs to know what the options mean when they appear, and having to go look them up in another file is just another hassle. Difficult to do in some situations, too. Better to show them when the user scrolls to that option. Here's what I suggested in -stable: http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068187.html No new files, only one copy of the descriptions so they don't get out of sync. That's a nice idea, how do you make it work with dialog? -- This .signature sanitized for your protection ___ 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: Documenting 'make config' options
On Sat, 9 Jun 2012, Doug Barton wrote: On 06/09/2012 17:54, Warren Block wrote: On Sat, 9 Jun 2012, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? The user needs to know what the options mean when they appear, and having to go look them up in another file is just another hassle. Difficult to do in some situations, too. Better to show them when the user scrolls to that option. Here's what I suggested in -stable: http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068187.html No new files, only one copy of the descriptions so they don't get out of sync. That's a nice idea, how do you make it work with dialog? No idea, this is still the design phase. :) Actually, a message I now can't find suggested that dialog may be able to do it unchanged. ___ 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: Documenting 'make config' options
On 06/09/2012 18:10, Warren Block wrote: That's a nice idea, how do you make it work with dialog? No idea, this is still the design phase. :) Actually, a message I now can't find suggested that dialog may be able to do it unchanged. We have a solution that unquestionably will work, now. It's not ideal from a UI standpoint, but it's better than the $nothing that we have now. I would not want to see us wait around for something that may or may not happen in the future. That said, if we can make this work with dialog now, and someone is willing to put the work in to make it happen, then sure, that's a better plan. But let's not let perfect be the enemy of good. Doug -- This .signature sanitized for your protection ___ 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: [CFT] Xorg 7.7 ready for testing!
I removed -current since it's out of scope for this. Also, I want to say up front that I'm excited to have the new version available. :) On 06/07/2012 05:37, Martin Wilke wrote: [...] What I'm trying to say is, I would love to see the newer xorg released as the default version, but i know this will break a lot of old hardware. The thing is, when we want to try to become a Modern Operating System, I dont see any other way to make the new xorg as default but to give Users the chance to compile the old xorg with a flag like WITH_OLD_XORG. Agreed, we have to continue supporting the current Xorg alongside the new one. No reason not to drop the oldest one though. If we can swing package support for 7.5 that would be great, we probably only need it for i386 and amd64. You might want to think about having a WITH_XORG flag that takes values of 75 or 77; and implies the right version of mesa. This is probably also a good time to think about changing the naming to be xorg77 and xorg75, rather than just plain xorg. That way the next time we have to go through this users who are at 77 can do the upgrade to what will then be the newer version gracefully. Think php here. A small merge script to merge the svn checkout into the real portstree can be found here: http://people.freebsd.org/~miwi/xorg/xorgmerge This is a good example of where having a projects branch in the new svn ports repo would be really useful. :) I think it's great that you're providing some tools that people can use to test this, but having to redo the patch every time I update my ports tree doesn't really appeal to me. Doug -- This .signature sanitized for your protection ___ 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
Imagemagick: FAIL, now in Magick++/demo/analyze.sh
The new version fails in a new location, even with the default options. -- This .signature sanitized for your protection ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 06/06/2012 12:18, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 It's very common for binaries built with gcc to link to libgcc, and/or libstdc++: ldd firefox-bin | grep gcc libstdc++.so.6 = /usr/local/lib/gcc46/libstdc++.so.6 (0x802b19000) libgcc_s.so.1 = /usr/local/lib/gcc46/libgcc_s.so.1 (0x8033a5000) In an ideal world, we would have separate packages for the runtime libs and the build tools so that packages could be more portable, but I would imagine that would be a lot of work. Doug -- This .signature sanitized for your protection ___ 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: Documenting 'make config' options
On Sat, 9 Jun 2012, Warren Block wrote: On Sat, 9 Jun 2012, Doug Barton wrote: On 06/09/2012 17:54, Warren Block wrote: On Sat, 9 Jun 2012, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? The user needs to know what the options mean when they appear, and having to go look them up in another file is just another hassle. Difficult to do in some situations, too. Better to show them when the user scrolls to that option. Here's what I suggested in -stable: http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068187.html No new files, only one copy of the descriptions so they don't get out of sync. That's a nice idea, how do you make it work with dialog? No idea, this is still the design phase. :) Actually, a message I now can't find suggested that dialog may be able to do it unchanged. Followup: dialog --item-help \ --checklist Contrived options description example 21 70 15 \ ABC Enable ABC encapsulation of convoluted insoluble... on \ variations when the complementary quantum reversal feature is undesirable \ DOCS Build and install documentation on \ XYZ Enabling XYZ sets compiler go-fast stripes, defeats ..., off \ all safeguards, and begins a wholesale, awesome, breathtaking data mangling \ NLS Native Language Support via gettext utilities on Now some code is needed to break descriptions too long to fit in the standard option box (preferably on spaces), right-justify ... or maybe + at the end to show the line is continued, and integrate that with bsd.port.mk. ___ 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
