Re: why was XFree86 dropped for ports?
On Wed, 2009-04-01 at 16:14 -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Noland wrote: On Tue, 2009-03-31 at 22:36 -0400, Chuck Robey wrote: I recently got kde4.2 working on my home box, and all the neat eye candy things that are added, I'll have to see, maybe you're right, XFree86 might not work with KDE, but saying that XFree86 hasn't had an update since December makes no sense to me, versus the fact that I *think* git allows no release tags, so I think one could argue that there are no Xorg releases at all. That, or I don't know git well enough, either is possible. If there are tags in git, I will go back and reread the git docs until I find them. git has tags and branches, all of which can be checked out from fd.o. AFAIK, things aren't tagged for Xorg releases, but all of the packages carry tags and some have release branches. I was hoping I would get an answer on this. It is indeed a feature of git, or has it been grafted on by convention? If git's got it, I'll drop this particular topic, and try to find the command I must have missed. If those features are done by convention, I guessed I was relying on the git man pages, and just didn't look hard enough at the web pages for Xorg to spot the info. I've been a bit critical of git in my mind, and need to get myself either justified or corrected. GIT-TAG(1) git has a lot of nice features... It also has it's weak points in my mind. Generally the biggest advantage and disadvantage is the distributed nature of git. It is very convenient to make local commits and rebase and keep local branches, but I think it leads to chaos if it isn't controlled. Everyone has a master repo. I pretty regularly use cvs, svn and git these days, covering all my different corners of hell... robert. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknTyzgACgkQz62J6PPcoOlfrgCfc9/ZsGKtJOhb4xqUecVLfrhy NDoAnRcfOJdQH1OsxVBTtjlbxlN1jyLG =uHG+ -END PGP SIGNATURE- -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
xfce4-cpugraph-plugin
Hi, is anyone able to run sysutils/xfce4-cpugraph-plugin in xfce4.6 on a 64-bit computer? The current version in the ports (0.3.0) runs fine on my i386 laptop running 8.0-CURRENT, but it fails on my amd64 laptop running 7.1-RELEASE. In the latter case it builds alright, but it crashes when loading it into the panel (in a loop which looks fine). It might be wrong option in one of its dependencies, but I didn't notice anything obvious in its immediate dependencies. Can someone confirm if it works and optionally post the options the dependencies were built with? I will also poke the upstream developers for a BSD version of 0.4.0 (the current version, which has multi-core support). Thanks, Rene ___ 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: xfce4-cpugraph-plugin
It doesn't work on my setup with 7.1-STABLE and xfce4.6 on amd64 as well. I have 3 computers with the same exact issue. On Thu, Apr 2, 2009 at 5:20 AM, Rene Ladan r...@freebsd.org wrote: Hi, is anyone able to run sysutils/xfce4-cpugraph-plugin in xfce4.6 on a 64-bit computer? The current version in the ports (0.3.0) runs fine on my i386 laptop running 8.0-CURRENT, but it fails on my amd64 laptop running 7.1-RELEASE. In the latter case it builds alright, but it crashes when loading it into the panel (in a loop which looks fine). It might be wrong option in one of its dependencies, but I didn't notice anything obvious in its immediate dependencies. Can someone confirm if it works and optionally post the options the dependencies were built with? I will also poke the upstream developers for a BSD version of 0.4.0 (the current version, which has multi-core support). Thanks, Rene ___ 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: Status of devel/boost upgrade
2009/4/1 Dmitry Marakasov amd...@amdmi3.ru: * Jeremy Messenger (me...@cox.net) wrote: No need bsd.boost.mk over that small stuff. How about resolve conflict for real by split boost and boost-python by have boost only install non-python stuff and boost-python install only python stuff? That of course would be harder and more interesting, maybe I gotta dig into it. Hi folks! I've already did it about a month ago. Currently I'm testing the solution. There are two ideas about splitting boost: 1) Split it into bjam, source-libs, shared-libs, python-libs and docs. This is what was actually done by me. 2) Split it into bjam, docs and a separate port for each library. This needs discussion. If you are interested, you may download sample ports from http://alexanderchuranov.com/boost-port/ The most recent tarball contains a set of alternative non-conflicting versioned ports for boost. They may be installed in addition to existing devel/boost. The 'source-libs' are header-only libraries that do not need compilation. For now I've found a single flaw in the latest set of these ports: devel/boost-python-libs-1.38 conflicts with devel/boost, because they install Pyste in the same place. Please, note that the flaw is only about the conflict of versioned port and non-versioned, if we would break non-versioned, system-layout boost as we currently have into parts, then there is no flaw at all. I didn't started a mailing thread on this topic, because there are tasks related to devel/boost that are not yet completed: updating to 1.37 and then to 1.38. Splitting boost into parts have following benefits: 1) Shorter time of installation/updates from packages. 2) Fine-grained selection of what's really necessary. 3) Simplified dependency tracking for other ports that depend on boost. 4) No more issues like conflict of devel/boost and devel/boost-python There are also drawbacks: 1) Time to build complete boost from ports is increased, because boost.org provides a single source package and it gets decompressed several times. 2) The number of ports is increased. The questions are: 1) Should we break boost into parts? 2) Should we break boost into jam', 'source-libs', 'shared-libs', 'python-libs' and 'docs' or into one port per library? If folks agree on splitting boost into parts, I'll be glad to finish it. Sincerely, Alexander Churanov, maintainer of devel/boost ___ 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: Status of devel/boost upgrade
* Alexander Churanov (alexanderchura...@gmail.com) wrote: I've already did it about a month ago. Currently I'm testing the solution. There are two ideas about splitting boost: Woo, this is great! 1) Split it into bjam, source-libs, shared-libs, python-libs and docs. This is what was actually done by me. 2) Split it into bjam, docs and a separate port for each library. This needs discussion. Not sure if splitting it into many small libraries is a good idea. How many are there, btw? Is it a port per libboost_*so, or per include/boost/* ? Also splitting shared libs and source libs is a strange idea - there will be confusion on which port does specific library belong and it seems very likely that most boost-using ports will depend on both ports. Boost-python is a must to be split into separate port because it has an extra dependency, docs too, because not many people need them, bjam, well, because it's a build tool, and everything else may be left in a single port. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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
