Question about depends
Hello all. Update for nss and ca root produced rebuild of all packages in my poudriere :) Isn't it so necessary? Maybe there should be new type of dependency introduced - like, INFO_DEPENDS, means that no rebuilld of any depended packages required, they all only use some info from that package. Is there such type of dependency currently? Is there any reason why not introduce one? -- Regards, Alexander Yerenkow ___ 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: emulators/virtualbox-ose failing to build, 8.2-p9 on amd64
On 2013/01/06, at 02:48, Bernhard Fröhlich wrote: Looks like your libsdl version is either very old or too new. Could you please check which libsdl version you have installed? 1.2.15-_2,2. It's the current ports version (as of this afternoon when I updated my ports tree). ___ 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: Using http mirrors
On 5 January 2013 11:14, Chris Rees utis...@gmail.com wrote: Hi all, The submitter of ports/174427 tells me that using http for mirrors is faster, due to the lack of authentication etc. I'm not convinced that the speed difference is huge, but can anyone think of any reasons not to apply this patch? It will affect large numbers of ports. http://www.freebsd.org/cgi/query-pr.cgi?pr=174427 Please apply this. HTTP is a generally saner protocols, especially for people behind firewalls. -- Simon L. B. Nielsen ___ 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
LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
While working with an OpenCL port that is depending on LLVM 3.2, I feel very uncomfortable haveng to have devel/llvm-devel installed while the official release of LLVM is 3.2. The port devel/llvm is still the older 3.1. Is this going to be changed? I guess it must be synchronized with FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). Well, this brings up again another piece of question. While FreeBSD's base system already has LLVM/CLANG, it is missing some important LLVM pieces, like llvm-config and others. Having a crippled LLVM aboard AND the need having installed a port is a kind of none-sense. Why should I install port devel/llvm to have a working LLVM backend? The last time I brought up this issue, it was mentioned that the long compile time is one of the reasons. Can this be fixed by having an additional knob like WITH_LLVM_EXTRAS? Personally I feel much better having the complete LLVM in the base than having the very same (or with bad luck, a slightly different in the ports) LLVM from the ports. Since it depends on the preferences of search paths, software used to choose the port's version prior over the base system - that caused trouble for me in the past. Oliver signature.asc Description: OpenPGP digital signature
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Den 06/01/2013 kl. 13.55 skrev O. Hartmann ohart...@zedat.fu-berlin.de: While FreeBSD's base system already has LLVM/CLANG, it is missing some important LLVM pieces, like llvm-config and others. llvm-config is a build dependency that spits out some lib paths that you can just hard-code for FreeBSD. So what in others does your port need? I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. This might require that a larger part of the LLVM source tree is imported into src/contrib, though. Erik ___ 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: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 2013-01-06 13:55, O. Hartmann wrote: While working with an OpenCL port that is depending on LLVM 3.2, I feel very uncomfortable haveng to have devel/llvm-devel installed while the official release of LLVM is 3.2. Please prod the port maintainer (Brooks) to update the llvm port instead. I have CC'd him on this mail. The port devel/llvm is still the older 3.1. Is this going to be changed? Obviously, but this is at the discretion of the port maintainer. If Brooks needs more time, then you will have be a little patient. Also please remember that ports just came out of feature freeze. If Brooks has no time, I can update the port too, but since I am not a ports committer, I will still need his review and approval. I guess it must be synchronized with FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). No, there is no need to be synchronized at all. That is the whole point of a port. With a port, you are free to update the port independently of the base system, or even have multiple versions installed at the same time. Well, this brings up again another piece of question. While FreeBSD's base system already has LLVM/CLANG, it is missing some important LLVM pieces, like llvm-config and others. That is on purpose. The base system only supplies the compiler, with a minimum of dependencies, for now. If we start supplying other LLVM components, such as shared libraries, we will be stuck with their APIs, and will need to maintain those for the lifetimes of the branches in which they occur. Having a crippled LLVM aboard AND the need having installed a port is a kind of none-sense. Why should I install port devel/llvm to have a working LLVM backend? Because then you would have a stock LLVM, with all the bells and whistles that you have configured. The version of llvm/clang in base has a few FreeBSD-specific modifications, and some additional upstream changes that are not in the release version. It is impossible to appease everybody with the version of llvm/clang integrated into the base system. Its function, for now, is simply to be able to bootstrap the system, and function as a system compiler. (Read that as: it is *not* necessarily the compiler for ports, ports can obviously make their own decisions about using other compilers, prepackaged ones, if necessary.) The last time I brought up this issue, it was mentioned that the long compile time is one of the reasons. Can this be fixed by having an additional knob like WITH_LLVM_EXTRAS? No, the compile time is not the reason. The reason is having yet another API to be maintained in base. At the moment, clang is just one monolithic executable, without any dependencies. This is an advantage. The only option added (on request from some users) is WITH_CLANG_EXTRAS, which builds a number of tools like llc, opt, and so on. But these really belong in the port too. Personally I feel much better having the complete LLVM in the base than having the very same (or with bad luck, a slightly different in the ports) LLVM from the ports. Since it depends on the preferences of search paths, software used to choose the port's version prior over the base system - that caused trouble for me in the past. In my opinion, the ports system should set up things so that it always finds components under $PREFIX first, not those in the base system. At least, in most cases. So if a port is dependent on devel/llvm32, it should ensure the include and library paths are set up so it will find the correct llvm headers and libraries. ___ 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: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 2013-01-06 15:16, Erik Cederstrand wrote: ... I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. Well, it would be easy enough to build llvm-config, but what should its output be? We do not install llvm/clang headers or libraries into the system, so llvm-config would not give any meaningful -I or -L flags. :) llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. Again, build time is not the problem. The libraries are already built, but in static form; making them dynamic would not be that difficult, but installing them would add another maintenance and compatibility burden. The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. Yes, this seems to be the proper approach. But, as far as I understand, the ports system cannot yet do one work tree build, and package that up in different packages, such as -libs, -devel, and so on. This might require that a larger part of the LLVM source tree is imported into src/contrib, though. I am not sure what you mean by this. Why would the ports require something in the base system, other than a compiler? ___ 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/OpenEXR gcc 4.6.3 ISSUE error: 'memset' was not declared in this scope
libtool: compile: g++46 -DHAVE_CONFIG_H -I. -I. -I../config -D_THREAD_SAFE -I/usr/local/include/OpenEXR -I.. -I../config -O2 -pipe -march=pentium4 -mtune=pentium4 -Wno-error -w -pipe -O2 -pipe -march=pentium4 -mtune=pentium4 -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -O2 -pipe -march=pentium4 -mtune=pentium4 -Wno-error -w -Wl,-rpath=/usr/local/lib/gcc46 -MT ImfChromaticities.lo -MD -MP -MF .deps/ImfChromaticities.Tpo -c ImfChromaticities.cpp -fPIC -DPIC -o .libs/ImfChromaticities.o In file included from ./ImfChromaticities.h:47:0, from ImfChromaticities.cpp:43: /usr/local/include/OpenEXR/ImathMatrix.h: In constructor 'Imath::Matrix44T::Matrix44() [with T = float]': ImfChromaticities.cpp:110:17: instantiated from here /usr/local/include/OpenEXR/ImathMatrix.h:1813:5: error: 'memset' was not declared in this scope gmake[2]: *** [ImfChromaticities.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/OpenEXR/work/openexr-1.7.0/IlmImf' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/OpenEXR/work/openexr-1.7.0/IlmImf' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/graphics/OpenEXR. *** Error code 1 Stop in /usr/ports/graphics/OpenEXR. Gcc 4.2+ works, but graphics/ilmbase should be compiled with 4.2+ either. ___ 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: Using http mirrors
On 6 January 2013 12:13, Simon L. B. Nielsen si...@qxnitro.org wrote: On 5 January 2013 11:14, Chris Rees utis...@gmail.com wrote: Hi all, The submitter of ports/174427 tells me that using http for mirrors is faster, due to the lack of authentication etc. I'm not convinced that the speed difference is huge, but can anyone think of any reasons not to apply this patch? It will affect large numbers of ports. http://www.freebsd.org/cgi/query-pr.cgi?pr=174427 Please apply this. HTTP is a generally saner protocols, especially for people behind firewalls. Thanks, committed. 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: graphics/OpenEXR gcc 4.6.3 ISSUE error: 'memset' was not declared in this scope
On 1/6/2013 16:03, awarecons wrote: `/usr/ports/graphics/OpenEXR/work/openexr-1.7.0/IlmImf' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/graphics/OpenEXR. *** Error code 1 Stop in /usr/ports/graphics/OpenEXR. Gcc 4.2+ works, but graphics/ilmbase should be compiled with 4.2+ either. ___ We've fixed this in DPorts, like many others: https://github.com/jrmarino/DPorts/blob/master/graphics/OpenEXR/dragonfly/patch-IlmImf_ImfAutoArray.h You need this one too: https://github.com/jrmarino/DPorts/blob/master/graphics/OpenEXR/dragonfly/patch-exrenvmap_blurImage.cpp John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Am 01/06/13 15:52, schrieb Dimitry Andric: On 2013-01-06 13:55, O. Hartmann wrote: While working with an OpenCL port that is depending on LLVM 3.2, I feel very uncomfortable haveng to have devel/llvm-devel installed while the official release of LLVM is 3.2. Please prod the port maintainer (Brooks) to update the llvm port instead. I have CC'd him on this mail. The port devel/llvm is still the older 3.1. Is this going to be changed? Obviously, but this is at the discretion of the port maintainer. If Brooks needs more time, then you will have be a little patient. Also please remember that ports just came out of feature freeze. If Brooks has no time, I can update the port too, but since I am not a ports committer, I will still need his review and approval. I guess it must be synchronized with FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). No, there is no need to be synchronized at all. That is the whole point of a port. With a port, you are free to update the port independently of the base system, or even have multiple versions installed at the same time. In my case, I had some confusions with some LLVM related software (POCL, portable openCL library). Well, this brings up again another piece of question. While FreeBSD's base system already has LLVM/CLANG, it is missing some important LLVM pieces, like llvm-config and others. That is on purpose. The base system only supplies the compiler, with a minimum of dependencies, for now. If we start supplying other LLVM components, such as shared libraries, we will be stuck with their APIs, and will need to maintain those for the lifetimes of the branches in which they occur. It is hard for my little brain to accept those things ... A personal tragedy, I guess. I like it the way to have everything at hand in the base someone need, but as a non-maintainer, I often forget about the point of maintaining. Having a crippled LLVM aboard AND the need having installed a port is a kind of none-sense. Why should I install port devel/llvm to have a working LLVM backend? Because then you would have a stock LLVM, with all the bells and whistles that you have configured. The version of llvm/clang in base has a few FreeBSD-specific modifications, and some additional upstream changes that are not in the release version. Well, then the question is whether it is a big deal to build the other portions with a special knob enabling them. The maintainer also has to split the LLVM system anyway, apply the patches and so on. In my imagination, then some IFDEFS/IFs are applied to get rid of what is not needed. It is impossible to appease everybody with the version of llvm/clang integrated into the base system. Its function, for now, is simply to be able to bootstrap the system, and function as a system compiler. (Read that as: it is *not* necessarily the compiler for ports, ports can obviously make their own decisions about using other compilers, prepackaged ones, if necessary.) The last time I brought up this issue, it was mentioned that the long compile time is one of the reasons. Can this be fixed by having an additional knob like WITH_LLVM_EXTRAS? No, the compile time is not the reason. The reason is having yet another API to be maintained in base. At the moment, clang is just one monolithic executable, without any dependencies. This is an advantage. I agree. The only option added (on request from some users) is WITH_CLANG_EXTRAS, which builds a number of tools like llc, opt, and so on. But these really belong in the port too. Personally I feel much better having the complete LLVM in the base than having the very same (or with bad luck, a slightly different in the ports) LLVM from the ports. Since it depends on the preferences of search paths, software used to choose the port's version prior over the base system - that caused trouble for me in the past. In my opinion, the ports system should set up things so that it always finds components under $PREFIX first, not those in the base system. At least, in most cases. So if a port is dependent on devel/llvm32, it should ensure the include and library paths are set up so it will find the correct llvm headers and libraries. The confusing part (at least for me) starts there, where a port rquires a compiler, like clang not providing the absolute path to the binary. i had in the past trouble with that where port lang/clang was installed and having used FreeBSD's aboard/base clang compiler in 10.0-CUR. It caused some problems. Well, what you say at the end is, that a port also should then rely on a port compiler from the ports? That would be the logical clean slate solution. I might be wrong here. I'm still hoping, from the point of an user with scietific purposes, that one day FreeBSD will make use of heterogenous execution facilities, like OpenCL introduces: having CPU AND GPU as possible calculation
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Am 01/06/13 15:57, schrieb Dimitry Andric: On 2013-01-06 15:16, Erik Cederstrand wrote: ... I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. Well, it would be easy enough to build llvm-config, but what should its output be? We do not install llvm/clang headers or libraries into the system, so llvm-config would not give any meaningful -I or -L flags. :) The problem at this point is that I personally do not exactly understand the real dependency of the software i try to build as a port (POCL, now RC2 at sourceforge). The build system requires llvm-config and I guess the LLVM backend for the LLVM IR for the target (at the moment, only the CPU). llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. Again, build time is not the problem. The libraries are already built, but in static form; making them dynamic would not be that difficult, but installing them would add another maintenance and compatibility burden. The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. Yes, this seems to be the proper approach. But, as far as I understand, the ports system cannot yet do one work tree build, and package that up in different packages, such as -libs, -devel, and so on. Why splitting up? My problem is NOT the compile time, the burden on an oldish Intel Core2Duo E8400 is not that much and I'm, personally, have installed the port devel/llvm-devel. So I guess now I reeled in everything I need and want to have (without exactly knowing what to need). My question was to have the whole thing in the base. But you made clear this is more an disadvantage than advantage. This might require that a larger part of the LLVM source tree is imported into src/contrib, though. I am not sure what you mean by this. Why would the ports require something in the base system, other than a compiler? signature.asc Description: OpenPGP digital signature
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Am 01/06/13 15:52, schrieb Dimitry Andric: On 2013-01-06 13:55, O. Hartmann wrote: While working with an OpenCL port that is depending on LLVM 3.2, I feel very uncomfortable haveng to have devel/llvm-devel installed while the official release of LLVM is 3.2. Please prod the port maintainer (Brooks) to update the llvm port instead. I have CC'd him on this mail. The port devel/llvm is still the older 3.1. Is this going to be changed? Obviously, but this is at the discretion of the port maintainer. If Brooks needs more time, then you will have be a little patient. Also please remember that ports just came out of feature freeze. I also filed a PR ( http://www.freebsd.org/cgi/query-pr.cgi?pr=175059). It seems, that the port devel/llvm-devel also misses some pieces of the most recent LLVM 3.2, as it is needed to compile POCL properly, but I leave this with the experts to change. I try to follow a logical path: devel/llvm represents the recent release, while devel/llvm-devel should be the development branch, 3.3 by now. I do not know whether we need LLVM 3.1 any more, since apart from the POCL device driver backend via LLVM for OpenCL target I know about nothing in the FreeBSD realm by now using LLVM. I might be wrong ... So, I see forward to hear from the decissions made ;-) Oliver signature.asc Description: OpenPGP digital signature
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 6 Jan 2013, at 12:55, O. Hartmann wrote: Having a crippled LLVM aboard AND the need having installed a port is a kind of none-sense. Why should I install port devel/llvm to have a working LLVM backend? The issue is the same as the issue for anything in the FreeBSD base system, which is: what level of compatibility do we want to provide? In general, we aim to provide a backwards-compatible ABI across an entire major release. This means that anything that runs on 9.0 should work on 9.1 and so on. It should also work on 10.x with the relevant compat packages installed. In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. There is no problem with other base-system tools linking against the base system LLVM libraries, but in this case llvm-config does not need to be installed (and neither do the LLVM headers), because such tools will be built as part of the base system itself. David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Am 01/06/13 17:49, schrieb David Chisnall: On 6 Jan 2013, at 12:55, O. Hartmann wrote: Having a crippled LLVM aboard AND the need having installed a port is a kind of none-sense. Why should I install port devel/llvm to have a working LLVM backend? The issue is the same as the issue for anything in the FreeBSD base system, which is: what level of compatibility do we want to provide? In general, we aim to provide a backwards-compatible ABI across an entire major release. This means that anything that runs on 9.0 should work on 9.1 and so on. It should also work on 10.x with the relevant compat packages installed. In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. Indeed, this is a serious point and the developer of LLVM has to be blamed for that. There is no problem with other base-system tools linking against the base system LLVM libraries, but in this case llvm-config does not need to be installed (and neither do the LLVM headers), because such tools will be built as part of the base system itself. llvm-config is simply as an example. It shows up the first when the build of POCL fails, so I have chossen it to be checked for as the relevant dependency - it was a hunch for the port Makefile I intend to provide. Since I was more focused on having POCL running for my OpenCL moveon on FreeBSD, I wasn't very careful about choosing what to check against. I will change this before I will send the port to be reviewed and revised. David ___ signature.asc Description: OpenPGP digital signature
kde4 errors and no .xsession-errors file!
Hi I cannot find a .xession-errors file - what turns it off or on? I need to find out what is going wrong. Kde4 is not loading Thanks David -- David Southwell ARPS AFIAP Photographic Arts Trained experienced competition judge, mentor, trainer, lecturer, Advanced digital techniques, international project photography ___ 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: emulators/virtualbox-ose failing to build, 8.2-p9 on amd64
On 2013/01/06, at 04:46, Matthew Pounsett wrote: On 2013/01/06, at 02:48, Bernhard Fröhlich wrote: Looks like your libsdl version is either very old or too new. Could you please check which libsdl version you have installed? 1.2.15-_2,2. It's the current ports version (as of this afternoon when I updated my ports tree). Ah.. I found the problem. The libsdl port config file had an old WITHOUT_X11 it was holding on to.. I got rid of that, rebuilt, and virtualbox compiles fine now. Thanks for the lead! ___ 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: emulators/virtualbox-ose failing to build, 8.2-p9 on amd64
Great. Thanks for reporting your results. Am 06.01.2013 20:23 schrieb Matthew Pounsett m...@conundrum.com: On 2013/01/06, at 04:46, Matthew Pounsett wrote: On 2013/01/06, at 02:48, Bernhard Fröhlich wrote: Looks like your libsdl version is either very old or too new. Could you please check which libsdl version you have installed? 1.2.15-_2,2. It's the current ports version (as of this afternoon when I updated my ports tree). Ah.. I found the problem. The libsdl port config file had an old WITHOUT_X11 it was holding on to.. I got rid of that, rebuilt, and virtualbox compiles fine now. Thanks for the lead! ___ 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: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 6 Jan 2013 14:57, Dimitry Andric d...@freebsd.org wrote: On 2013-01-06 15:16, Erik Cederstrand wrote: ... I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. Well, it would be easy enough to build llvm-config, but what should its output be? We do not install llvm/clang headers or libraries into the system, so llvm-config would not give any meaningful -I or -L flags. :) llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. Again, build time is not the problem. The libraries are already built, but in static form; making them dynamic would not be that difficult, but installing them would add another maintenance and compatibility burden. The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. Yes, this seems to be the proper approach. But, as far as I understand, the ports system cannot yet do one work tree build, and package that up in different packages, such as -libs, -devel, and so on. No, but it can be done if the parts are compiled separately, à la postgresql-* ports. Is this definitely impossible? It's crudely but effectively done with pgsql by only running make in certain directories... 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: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Den 06/01/2013 kl. 18.25 skrev O. Hartmann ohart...@zedat.fu-berlin.de: In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. Indeed, this is a serious point and the developer of LLVM has to be blamed for that. You can't seriously blame LLVM for making progress. If ports rely on a specific version of LLVM, it would be far better to create devel/llvm31, devel/llvm32 etc. Erik ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD wiki offline for a bit
Hey, tl;dr Wiki is back, and everybody with account need to reset their password. On 4 January 2013 22:38, Simon L. B. Nielsen si...@freebsd.org wrote: Due to a security issue in the moinmoin wiki software, the FreeBSD wiki will be offline for a bit. I do not yet know if the issue actually has been exploited in the FreeBSD wiki (haven't had the time yet to examine it), but I took the wiki down just in case. Note that even if the software was compromised, it was considered untrusted from the start and as such heavily sandboxed (including jailed) to keep it away from any sensitive FreeBSD.org parts, so there is absolutely no reason to believe a compromise would go any further than the wiki itself. I hope to have the wiki back within 24 hours, assuming not too much gets in the way. For further reference see: http://moinmo.in/SecurityFixes and http://permalink.gmane.org/gmane.linux.debian.devel.announce/1754 . PS. this is entirely unrelated to the 2012 November FreeBSD.org compromise. The wiki is back now. Looking at logs it there were people attempting to exploit this back in July but I do not think they actually succeeded. It seemed to mostly automated bot and not a target attempt. The wiki has been reinstalled from scratch and users and pages were copied. As I did a very selective copy it's entirely possible I made the wiki unhappy, so let me know if you see issues. Just to be extra safe I have reset all password, so everybody will need need to use the standard account recovery process to set a new password. On a side note we have ~23000 user accounts and had 26000 empty pages mostly caused by spammers, so someone(tm) will likely need to find a way to change how we handle wiki user accounts to fix this. PS. only reason I could see that they tried back in July was that I found out I had forgotten to set up log rotation, so the wiki logfile was over 3GB :-). (It was the internal log file which doesn't contain user IP's so privacy part isn't really an issue.) -- Simon L. B. Nielsen Hat: clusteradm ___ 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
LDAP Account Manager
please update my port http://www.freebsd.org/cgi/query-pr.cgi?pr=175075 ___ 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: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 2013-01-06 21:38, Erik Cederstrand wrote: Den 06/01/2013 kl. 18.25 skrev O. Hartmann ohart...@zedat.fu-berlin.de: In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. Indeed, this is a serious point and the developer of LLVM has to be blamed for that. You can't seriously blame LLVM for making progress. If ports rely on a specific version of LLVM, it would be far better to create devel/llvm31, devel/llvm32 etc. Yes, I think that is probably the most effective approach. It should also be possible to install multiple versions simultaneously. ___ 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: kde4 errors and no .xsession-errors file!
David Southwell da...@vizion2000.net writes: I cannot find a .xession-errors file - what turns it off or on? I need to find out what is going wrong. Kde4 is not loading How are you starting KDE? If you're using startx, you just need to redirect startkde's output to .xsession-errors. ___ 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
