Re: games/wesnoth: How to cope with invalid DSO for symbol `_ZN5boost6system15system_categoryEv'
On 1/14/2015 2:34 AM, Torsten Zuehlsdorff wrote: On 13.01.2015 22:04, Bryan Drewery wrote: On 1/9/2015 5:18 AM, Torsten Zuehlsdorff wrote: [ 3%] mo-update [wesnoth-dw-ar]: Creating mo file. /usr/bin/ld: g: invalid DSO for symbol `_ZN5boost6system15system_categoryEv' definition /usr/local/lib/libboost_system.so.1.55.0: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) --- cutter --- Usually this means -lboost_system is missing from the linker line. Recent binutils in recent FreeBSD head has been patched to be more clear about it. As you can see from the output of pkg info i have the most recent binutils installed. At an FreeBSD 10.1 - also the most recent released version. Therefore i don't understand your comment. Can you explain it further? Whats your advice? Remove this line because it should work? Or keep the line for compatibility reasons? Greetings, Torsten recent head means the development version of FreeBSD, aka FreeBSD 11. Not 10.1. The binutils I speak of is not from ports, it is in the base system. -- 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
libxul build problem
Hi everyone, I've already fill a bug report on freebsd bugzilla but I would like to known If this problem affect only me or not. I'm runnig 3 freebsd-box, all running 10-Stable (FreeBSD 10.1-STABLE #10 r275839), all ports is up2date. When I try to build the libxul ports just after it's begin the build stop (in fact not even really started) with this message === Configuring for libxul-31.4.0 (cd /usr/ports/www/libxul/work/mozilla-esr31 /usr/local/bin/autoconf-2.13) (cd /usr/ports/www/libxul/work/mozilla-esr31/js/src/ /usr/local/bin/autoconf-2.13) gmake[1]: Entering directory '/usr/ports/www/libxul' /usr/ports/www/libxul/work/mozilla-esr31/client.mk:114: *** missing separator. Stop. gmake[1]: Leaving directory '/usr/ports/www/libxul' === Script configure failed unexpectedly. Please report the problem to ge...@freebsd.org [maintainer] and attach the /usr/ports/www/libxul/work/mozilla-esr31/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /usr/ports/www/libxul Does anyone have this problem ? Regards. NB: The bug report : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196737 -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: jeu 15 jan 2015 01:03:53 CET ___ 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
net-mgmt/rancid and cisco ssh kexagorhitms
Hi, as of FreeBSD 9.3, it is not possible to ssh into some cisco routers (namely 1921 and 3925 in my case), unless option -o KexAlgorithms= diffie-hellman-group14-sha1 is specified. Probably, as a consequence, rancid stopped working for these routers since I upgraded OS on which it is installed to 9.3. How can I make this work again? Thank you in advance, -- Marko Cupać https://www.mimar.rs ___ 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: BIND REPLACE_BASE option
+--On 14 janvier 2015 07:23:01 -0800 Roger Marquis marq...@roble.com wrote: | That leaves the issue of cross-platform compatibility, which is still | broken without REPLACE_BASE. What about those of us who support | environments that aren't BSD monocultures? By using the named_conf variable in /etc/rc.conf ? -- Mathieu Arnold ___ 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: BIND REPLACE_BASE option
Thank you Matt. It is refreshing to hear an actual business case for the reasons REPLACE_BASE was created. Thank you also for the pointers to a way of avoid dulpicate binaries. Do you know of more detailed documentation on how to prevent installworld and freebsd-update from installing these binaries in the first place? That leaves the issue of cross-platform compatibility, which is still broken without REPLACE_BASE. What about those of us who support environments that aren't BSD monocultures? Roger Marquis Well, like I said, REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. It should have been a very small minor change. If people didn't want to have two versions installed then the solution would have been to use WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so that those files were deleted or not installed in the first place. I do exactly this for NTPd, OpenSSH, and Unbound all of which I use the port versions for so don't need them in the base system. ___ 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: BIND REPLACE_BASE option
On Tue, Jan 13, 2015 at 08:33:13AM -0800, Roger Marquis wrote: ... Poudriere is a self-contained build system that can be used to bulk build any number of packages that can be used on any number of other systems. This is very useful if you need different features or options than the packages provided by the FreeBSD project. make package will build a single package of one port from the system it is run from. The packages built by make package can also be used on any number of other systems, like those built by Poudriere. That means that the port, and all of its dependencies, will be installed on the host. Depending on your needs, this can be a good or a bad thing. They're two completely different beasts and neither can replace the other. So one difference then would be that Poudriere determines which dependencies are run-time vs build-time and creates packages for those by default, is that correct? I can see how that might be convenient for packages with a large number of dependencies (like sssd) but it also seems like a lot of additional infrastructure simply to build binaries on one host to be used by many. Roger ___ 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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 22:50:09 -0800 Chris H bsd-li...@bsdforge.com wrote On Tue, 13 Jan 2015 18:34:45 -0800 Chris H bsd-li...@bsdforge.com wrote On Tue, 13 Jan 2015 13:54:56 -0700 John Hein john.h...@microsemi.com wrote Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Thanks for the offer, and reply, John. So far I've squashed ~20 errors. I'm now at the IPv6 specific ones. Willing to hand it over if someone wants it. Thanks, John. I might just take you up on that. :) Thanks again, John. OK. All the errors have been chased, and crushed. But it's now late. So I won't be submitting the pr(1) until tomorrow. OK killed all the errors, rolled up a release, and submitted an svn diff. Please see the pr(1): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196746 The build still emits a fair amount of warnings. but none are show stoppers. The source wants an earlier GCC, and really isn't well suited for clang. This was all built, tested on 11-CURRENT. I'll eliminate all the warnings, for the next version. All the best. --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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-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: BIND REPLACE_BASE option
Matthew Seaman wrote: Yes, poudriere does a lot of stuff, but if you didn't use a central builder, you'ld end up replicating all of that stuff onto every machine you wanted to manage. What stuff would you end up replicating? I ask because our make package host don't replicate anything other than the required binaries, libraries and configs. Roger ___ 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: net-mgmt/rancid and cisco ssh kexagorhitms
On 2015-01-14 15:35, Marko Cupać wrote: Hi, as of FreeBSD 9.3, it is not possible to ssh into some cisco routers (namely 1921 and 3925 in my case), unless option -o KexAlgorithms= diffie-hellman-group14-sha1 is specified. Probably, as a consequence, rancid stopped working for these routers since I upgraded OS on which it is installed to 9.3. How can I make this work again? Thank you in advance, I had the same issue but there is a simple solution: $ cat ~rancid/.ssh/config host host1 host2 host3 IP1 IP2 ... KexAlgorithms diffie-hellman-group14-sha1 -- HTH, olli ___ 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: BIND REPLACE_BASE option
Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Honestly. Need I remind you, this is FreeBSD, *not* Linux? In all honesty, I am *not* pleased with the current efforts to turn the FreeBSD motto The Power to Serve into FreeBSD, it's the new Linux. But I [begrudgingly] understand the inclination to do so. Amen to that. I also think a lot of people expect that emulating Linux' binary package systems will stop our favorite OS' declining market share. Unfortunately, there's a lot more to it. FreeBSD has had binary packages for years and they haven't had the desired effect. What's missing is perhaps an understanding of what Linux differences account for its success over FreeBSD. Clearly the topic of this thread, deprecating REPLACE_BASE, isn't going to help in this regards. Portsng and pkgng aren't helping yet either though their improvements have laid the foundation for easier coding of new features (like better dependency tracking, a non-cli menu, ad-hoc queries, ...). That said. While I understand your inclination to think FreeBSD must somehow be broken, when it doesn't operate as you're accustomed with Linux. Not my inclination :-) Please take care with those attributes. This is FreeBSD, after all, and as hard as everyone works to eliminate the element of surprise, this is still FreeBSD. So celebrate the difference. Don't curse it, or more importantly; it's hard working developers. :) I trust we are _all_ grateful to the developers who are doing a good job, at least when not deprecating popular features and responding to the resulting end-user frustration with statements like REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. The hard work that goes into so many ports _is_ BSD's primary advantage over Linux backed-up by ZFS, jails, security and the BSD license. Personally I believe that a lot of this differential is due to the GPL which doesn't allow Linux deltas to propagate back to BSD but nobody seems to be discussing way of addressing this (like a CDDL BSD perhaps). But getting back to the meta-topic i.e., where BSDs are at a disadvantage, has anyone here used kickstart, satellite, sssd, IPA, gparted, synaptic, a live desktop DVD or the Ubuntu GUI installer? Roger Marquis ___ 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: BIND REPLACE_BASE option
On 2015/01/14 15:34, Roger Marquis wrote: So one difference then would be that Poudriere determines which dependencies are run-time vs build-time and creates packages for those by default, is that correct? I can see how that might be convenient for packages with a large number of dependencies (like sssd) but it also seems like a lot of additional infrastructure simply to build binaries on one host to be used by many. Poudriere by definition will create packages for all of the build- and run-depends, as it needs the build-depends packages itself in order to build everything. It builds everything in temporary jails which it installs all the needed dependencies to, and then destroys after that package has been built. However, when you go to install a package from the repo, pkg(8) will only pull down the run-time dependencies of whatever you choose to install. That means there are a good chunk of packages you simply don't need to have on your production servers any more. Yes, poudriere does a lot of stuff, but if you didn't use a central builder, you'ld end up replicating all of that stuff onto every machine you wanted to manage. Poudriere itself can run on a fairly modest machine -- it depends on how many packages you need to build and how quickly you want them. It's quite feasible to use poudriere for a small-ish repo on a machine at night, when it is otherwise quiet, and then use the same machine for something else during the day. Cheers, Matthew ___ 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: BIND REPLACE_BASE option
Mathieu Arnold wrote: | That leaves the issue of cross-platform compatibility, which is still | broken without REPLACE_BASE. What about those of us who support | environments that aren't BSD monocultures? By using the named_conf variable in /etc/rc.conf ? That enables configuration compatibility but doesn't address binaries or their PATHs. Named perhaps isn't the best example of a port with cross-platform issues. Postfix, OTOH, is a different animal. I spent countless hours trying to accommodate the default BSD PREFIX, usually just installing from source without using ports, before paying Doug to write a patch for postfix' INST_BASE option. That investment has paid of manyfold over the years. Even more effort was put into porting freepbx but that effort failed specifically due to cross-platform (PREFIX) issues, resulting in several RH servers in an otherwise BSD shop. Roger ___ 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: BIND REPLACE_BASE option
On Wed, 14 Jan 2015 08:11:39 -0800 (PST) Roger Marquis marq...@roble.com wrote Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Honestly. Need I remind you, this is FreeBSD, *not* Linux? In all honesty, I am *not* pleased with the current efforts to turn the FreeBSD motto The Power to Serve into FreeBSD, it's the new Linux. But I [begrudgingly] understand the inclination to do so. Amen to that. I also think a lot of people expect that emulating Linux' binary package systems will stop our favorite OS' declining market share. Unfortunately, there's a lot more to it. FreeBSD has had binary packages for years and they haven't had the desired effect. What's missing is perhaps an understanding of what Linux differences account for its success over FreeBSD. Clearly the topic of this thread, deprecating REPLACE_BASE, isn't going to help in this regards. Portsng and pkgng aren't helping yet either though their improvements have laid the foundation for easier coding of new features (like better dependency tracking, a non-cli menu, ad-hoc queries, ...). That said. While I understand your inclination to think FreeBSD must somehow be broken, when it doesn't operate as you're accustomed with Linux. Not my inclination :-) Please take care with those attributes. Fair enough. My entire reply was *intended* to be light hearted. But like you, I *too* have some issues with some of the decisions made. I'm afraid I let that influence my reply. Sorry. This is FreeBSD, after all, and as hard as everyone works to eliminate the element of surprise, this is still FreeBSD. So celebrate the difference. Don't curse it, or more importantly; it's hard working developers. :) I trust we are _all_ grateful to the developers who are doing a good job, at least when not deprecating popular features and responding to the resulting end-user frustration with statements like REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. The hard work that goes into so many ports _is_ BSD's primary advantage over Linux backed-up by ZFS, jails, security and the BSD license. Personally I believe that a lot of this differential is due to the GPL which doesn't allow Linux deltas to propagate back to BSD but nobody seems to be discussing way of addressing this (like a CDDL BSD perhaps). IMHO it's still too early to tell whether all the big changes made during 2014 will, or have had, the positive, or desired affect intended. But for sure, it's been a *wild* ride for many of us. But getting back to the meta-topic i.e., where BSDs are at a disadvantage, has anyone here used kickstart, satellite, sssd, IPA, gparted, synaptic, a live desktop DVD or the Ubuntu GUI installer? Thanks for your *thoughtful* reply, Roger. --Chris Roger Marquis ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org --- ___ freebsd-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: net-mgmt/rancid and cisco ssh kexagorhitms
On Wed, Jan 14, 2015 at 6:35 AM, Marko Cupać marko.cu...@mimar.rs wrote: Hi, as of FreeBSD 9.3, it is not possible to ssh into some cisco routers (namely 1921 and 3925 in my case), unless option -o KexAlgorithms= diffie-hellman-group14-sha1 is specified. Probably, as a consequence, rancid stopped working for these routers since I upgraded OS on which it is installed to 9.3. How can I make this work again? Thank you in advance, -- Marko Cupać https://www.mimar.rs This looks like an issue that should go to the RANCiD developers upstream. It's a rather trivial thing to adjust the expect script for clogin to deal with this, though it probably should be more than just adding the option to the ssh command to make it specific to the routers that actually require it. I suspect that OpenSSH portable has removed this key exchange mechanism as a default due to concerns with SHA1, but that is just a guess as I have not been following either RANCiD or OpenSSH since I retired. I do suspect that adding this option to clogin is all that is required to get it working for you, though. Just look through clogin for 'ssh' to find the commands. (Note that there are probably at least two cases and you probably want to change all of them. -- R. Kevin Oberman, Network Engineer, Retired E-mail: 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: BIND REPLACE_BASE option
On 14/01/2015 16:34, Roger Marquis wrote: Matthew Seaman wrote: Yes, poudriere does a lot of stuff, but if you didn't use a central builder, you'ld end up replicating all of that stuff onto every machine you wanted to manage. What stuff would you end up replicating? I ask because our make package host don't replicate anything other than the required binaries, libraries and configs. This implies you are already using a central build host? Matthew's reply was talking about replicating build-depends packages if you build on each host separately. The advantage for me for using poudriere has been I use one machine to build 8.x 9.x and 10.x packages with a few flavours of each, its in a nice easy to use form and builds the repos (which I serve via nginx) and it handles all the jails/updating etc for me. Nothing I couldnt do manually sure but saves me time and effort. I just need to remember to check for new ports options from time to time. Vince Roger ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-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: BIND REPLACE_BASE option
On Wed, 14 Jan 2015 04:27:42 -0800 Jeffrey Bouquet via freebsd-ports freebsd-ports@freebsd.org wrote On 01/13/15 07:55, Kurt Jaeger wrote: Hi! customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. poudriere allows you to manage several seperate pkg trees with different options, so you can: - build a default tree (and pkg repo), provide it to all generic hosts - build a seperate tree (and pkg repo) with modified options, and provide it to the special hosts It helps to keep the poudriere build tree on fast flash/SSD drives 8-} This all works and is very, very good! Thanks for the work! As I probably won't ever know enough from experience, if one wants a local lan build tool is there any flowchart with use cases 1... foo foo bar use case tinderbox 2... foo foo bar use case build jail 3... foo foo bar use case bhyve 4... foo foo bar use case poudriere 5... foo foo bar use case csbd OR qjail OR ezjail OR man jail OR bastille script 6... foo foo bar use case server on lan serving packages And where they may overlap, which takes the least setup time, which takes the least maintenance time, which can be most easily migrated version version ... Excellent observation. These look like prime install candidates. A sort of meta-install, much like a Server, or Desktop install is already. Maybe someone with good install-foo could easily cobble up appropriate scripts to accommodate such a thing. Thanks for bringing it up, Jeffrey! --Chris Not to mention the wiki, but if that information was [some term ] use cases like virtualization or multi-machine or... on the freebsd.org page prominently, it may result in a larger userbase... more coders onboard. Recognizing that a lot of this is emerging technology. Apologies. I've a slight interest in reading any such document, having read an hour or so yesterday not a few htm explaining jails, (10 pages of threads linked from a search 'ezjail' in the forums, for example) to know that acquiring the expertise of a quickstart group of terms to focus on in any particular scenario is something I don't easily expect to acquire. On the other hand, to include the wiki... vs links from it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-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: BIND REPLACE_BASE option
On Wed, 14 Jan 2015 16:18:07 + Matthew Seaman matt...@freebsd.org wrote On 2015/01/14 15:34, Roger Marquis wrote: So one difference then would be that Poudriere determines which dependencies are run-time vs build-time and creates packages for those by default, is that correct? I can see how that might be convenient for packages with a large number of dependencies (like sssd) but it also seems like a lot of additional infrastructure simply to build binaries on one host to be used by many. Poudriere by definition will create packages for all of the build- and run-depends, as it needs the build-depends packages itself in order to build everything. It builds everything in temporary jails which it installs all the needed dependencies to, and then destroys after that package has been built. However, when you go to install a package from the repo, pkg(8) will only pull down the run-time dependencies of whatever you choose to install. That means there are a good chunk of packages you simply don't need to have on your production servers any more. Yes, poudriere does a lot of stuff, but if you didn't use a central builder, you'ld end up replicating all of that stuff onto every machine you wanted to manage. Poudriere itself can run on a fairly modest machine -- it depends on how many packages you need to build and how quickly you want them. It's quite feasible to use poudriere for a small-ish repo on a machine at night, when it is otherwise quiet, and then use the same machine for something else during the day. This might be a good place to put some links to how-to's for common use-cases for poudriere. I see questions like this quite often on the lists, and in the forums. Anyone have one? --Chris Cheers, Matthew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-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: games/wesnoth: How to cope with invalid DSO for symbol `_ZN5boost6system15system_categoryEv'
On Wed, 14 Jan 2015 09:34:11 +0100 Torsten Zuehlsdorff mailingli...@toco-domains.de wrote: On 13.01.2015 22:04, Bryan Drewery wrote: On 1/9/2015 5:18 AM, Torsten Zuehlsdorff wrote: [ 3%] mo-update [wesnoth-dw-ar]: Creating mo file. /usr/bin/ld: g: invalid DSO for symbol `_ZN5boost6system15system_categoryEv' definition /usr/local/lib/libboost_system.so.1.55.0: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) --- cutter --- Usually this means -lboost_system is missing from the linker line. Recent binutils in recent FreeBSD head has been patched to be more clear about it. As you can see from the output of pkg info i have the most recent binutils installed. At an FreeBSD 10.1 - also the most recent released version. Therefore i don't understand your comment. Can you explain it further? Whats your advice? Remove this line because it should work? Or keep the line for compatibility reasons? Basically it comes down to this (too lazy to search for a better source/explanation): http://fedoraproject.org/wiki/UnderstandingDSOLinkChange -- Michael Gmelin ___ 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: BIND REPLACE_BASE option
On Tue, Jan 13, 2015 at 08:33:13AM -0800, Roger Marquis wrote: One question while we're on the topic of deprecations, has 'make pkg || make package' been deprecated in favor of poudriere? No, they serve to completely different purposes, though there is some overlap. Poudriere is a self-contained build system that can be used to bulk build any number of packages that can be used on any number of other systems. This is very useful if you need different features or options than the packages provided by the FreeBSD project. make package will build a single package of one port from the system it is run from. That means that the port, and all of its dependencies, will be installed on the host. Depending on your needs, this can be a good or a bad thing. They're two completely different beasts and neither can replace the other. Erwin -- Erwin Lansinghttp://droso.dk er...@freebsd.orghttp:// www.FreeBSD.org pgpeD1nmt8Wy7.pgp Description: PGP signature
Re: games/wesnoth: How to cope with invalid DSO for symbol `_ZN5boost6system15system_categoryEv'
On 13.01.2015 22:04, Bryan Drewery wrote: On 1/9/2015 5:18 AM, Torsten Zuehlsdorff wrote: [ 3%] mo-update [wesnoth-dw-ar]: Creating mo file. /usr/bin/ld: g: invalid DSO for symbol `_ZN5boost6system15system_categoryEv' definition /usr/local/lib/libboost_system.so.1.55.0: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) --- cutter --- Usually this means -lboost_system is missing from the linker line. Recent binutils in recent FreeBSD head has been patched to be more clear about it. As you can see from the output of pkg info i have the most recent binutils installed. At an FreeBSD 10.1 - also the most recent released version. Therefore i don't understand your comment. Can you explain it further? Whats your advice? Remove this line because it should work? Or keep the line for compatibility reasons? Greetings, Torsten ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ lang/execline | 1.08| 2.0.1.1 +-+ mail/mpop | 1.2.0 | 1.2.2 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: BIND REPLACE_BASE option
Matt Smith wrote: On Jan 14 13:30, Michelle Sullivan wrote: Matt Smith wrote: Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. Was this ever documented? (I've been using bind in base for servers for many years and this is the first time I've heard of it - and it is unlikely I'm the only one.) I'm not sure if it was documented anywhere in particular. I've just seen it mentioned lots of times on these mailing lists in the past. Specifically around the time he was experimenting with slaving the root and arpa zones and there were a few configuration changes to named.conf at that time. The main reasoning is that the versions of things in the base system are usually old and rarely get updated. They occasionally get patches if there's a serious security vulnerability but for minor bugs it's unlikely you'll see any patch. And to patch it you quite often need to do a full O/S upgrade which is very time consuming and probably needs a reboot. The port versions are updated straight away, even for minor bugs and because you've not also updated half the O/S in the process you don't need to do anything other than restart named. And that is precisely the reason I used the 'REPLACE_BASE' option... BTW, what happens if you /usr/local/etc/rc.d/named start and /etc/rc.d/named start now (particularly the latter) ? ... I'm assuming some thought of this and removed /etc/rc.d/named as part of a freebsd-update ...? (note: some of use cannot 'freebsd-update' the 'delete-old' stuff because some expletive deleted got it also to delete the pkg_* tools - which some of us have to use currently - despite that same expletive deleted attempting to force production systems into untested configurations... even when patching exploits. Regards, -- Michelle Sullivan http://www.mhix.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: BIND REPLACE_BASE option
+--On 13 janvier 2015 19:11:50 -0800 Roger Marquis marq...@roble.com wrote: | The dialog option you talk about says: | [ ] REPLACE_BASEEOL, no longer supported | I'm quite sure the end-user you're talking about can get a clue from it, | and if he either already had selected it before, or he just selected it, | he will get: | === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. | The end-user can then get another clue and maybe unselect it. | | Maybe you're right but, to perhaps better illustrate the point, you would | never see something like this in Ubuntu, Debian, Redhat, or SuSE. Well, like I said, REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. -- Mathieu Arnold ___ 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: mypaint
On 2015-01-12 20:16, Jan Beich wrote:
I think the following are relevant patches from bugzilla.
Index: Mk/Uses/scons.mk
===
--- Mk/Uses/scons.mk(revision 376385)
+++ Mk/Uses/scons.mk(working copy)
@@ -17,6 +17,8 @@ IGNORE= Incorrect 'USES+= scons:${scons_ARGS}' sco
MAKEFILE= #
MAKE_FLAGS= #
ALL_TARGET= #
+CCFLAGS?= ${CFLAGS}
+LINKFLAGS?=${LDFLAGS}
LIBPATH?= ${LOCALBASE}/lib
CPPPATH?= ${LOCALBASE}/include
SCONS=${LOCALBASE}/bin/scons
Index: graphics/mypaint/Makefile
===
--- graphics/mypaint/Makefile (revision 376385)
+++ graphics/mypaint/Makefile (working copy)
@@ -22,7 +22,7 @@ BUILD_DEPENDS:= ${RUN_DEPENDS} \
USE_GNOME=glib20 pygtk2
MAKE_ARGS=prefix=${PREFIX}
-USES= gettext pkgconfig scons tar:bzip2 python
+USES= compiler:gcc-c++11-lib gettext pkgconfig scons tar:bzip2 python
INSTALLS_ICONS= yes
SUB_FILES=pkg-install
-
Yup, this fixes the problem. 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
Re: BIND REPLACE_BASE option
On 01/13/15 07:55, Kurt Jaeger wrote: Hi! customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. poudriere allows you to manage several seperate pkg trees with different options, so you can: - build a default tree (and pkg repo), provide it to all generic hosts - build a seperate tree (and pkg repo) with modified options, and provide it to the special hosts It helps to keep the poudriere build tree on fast flash/SSD drives 8-} This all works and is very, very good! Thanks for the work! As I probably won't ever know enough from experience, if one wants a local lan build tool is there any flowchart with use cases 1... foo foo bar use case tinderbox 2... foo foo bar use case build jail 3... foo foo bar use case bhyve 4... foo foo bar use case poudriere 5... foo foo bar use case csbd OR qjail OR ezjail OR man jail OR bastille script 6... foo foo bar use case server on lan serving packages And where they may overlap, which takes the least setup time, which takes the least maintenance time, which can be most easily migrated version version ... Not to mention the wiki, but if that information was [some term ] use cases like virtualization or multi-machine or... on the freebsd.org page prominently, it may result in a larger userbase... more coders onboard. Recognizing that a lot of this is emerging technology. Apologies. I've a slight interest in reading any such document, having read an hour or so yesterday not a few htm explaining jails, (10 pages of threads linked from a search 'ezjail' in the forums, for example) to know that acquiring the expertise of a quickstart group of terms to focus on in any particular scenario is something I don't easily expect to acquire. On the other hand, to include the wiki... vs links from it. ___ 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: BIND REPLACE_BASE option
Matt Smith wrote: On Jan 14 12:15, Mathieu Arnold wrote: Well, like I said, REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. Was this ever documented? (I've been using bind in base for servers for many years and this is the first time I've heard of it - and it is unlikely I'm the only one.) It should have been a very small minor change. If people didn't want to have two versions installed then the solution would have been to use WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so that those files were deleted or not installed in the first place. I do exactly this for NTPd, OpenSSH, and Unbound all of which I use the port versions for so don't need them in the base system. ..and for those using freebsd-update? Oh and on setting up named after installing from ports it gets chrooted and it has 'problems' seems the chroot mechanism chroots/links in /etc/namedb rather than /usr/local/etc/namedb ... haven't fully gotten to the bottom of it yet, but currently on all machines after freebsd-update (and possibly new installs of 9.3) I ended up creating links between /var/named/usr/local/etc/namedb/named.conf and /usr/local/etc/namedb/named.conf and /etc/namedb/named.conf to get it working.. so something is 'odd' in the mean time my deployment script has been modified to create all the links to get it working so stopped looking at it for the moment. Michelle -- Michelle Sullivan http://www.mhix.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: BIND REPLACE_BASE option
On Jan 14 12:15, Mathieu Arnold wrote: Well, like I said, REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. It should have been a very small minor change. If people didn't want to have two versions installed then the solution would have been to use WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so that those files were deleted or not installed in the first place. I do exactly this for NTPd, OpenSSH, and Unbound all of which I use the port versions for so don't need them in the base system. -- Matt ___ 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: BIND REPLACE_BASE option
On Jan 14 13:30, Michelle Sullivan wrote: Matt Smith wrote: Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. Was this ever documented? (I've been using bind in base for servers for many years and this is the first time I've heard of it - and it is unlikely I'm the only one.) I'm not sure if it was documented anywhere in particular. I've just seen it mentioned lots of times on these mailing lists in the past. Specifically around the time he was experimenting with slaving the root and arpa zones and there were a few configuration changes to named.conf at that time. The main reasoning is that the versions of things in the base system are usually old and rarely get updated. They occasionally get patches if there's a serious security vulnerability but for minor bugs it's unlikely you'll see any patch. And to patch it you quite often need to do a full O/S upgrade which is very time consuming and probably needs a reboot. The port versions are updated straight away, even for minor bugs and because you've not also updated half the O/S in the process you don't need to do anything other than restart named. -- Matt ___ 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
