watching changelogs easily
Hi, Is there any centralized way to see what changes were made in the new version of whatever the port is for? I know of freshports.org, but it only lists the port's own changes, not the app's. Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ruby18, -pthreads, deep recursion
On Fri, 02 Nov 2007 18:30:13 -0500, Jeremy Messenger <[EMAIL PROTECTED]> wrote: On Fri, 02 Nov 2007 11:37:07 -0500, Marcin Wisnicki <[EMAIL PROTECTED]> wrote: On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html If it's any consolation, I've emailed the ruby maintainer a few times about why disabling threads in the port's menu doesn't *really* disable threads and have never gotten a reply. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. I must be behind with -pthread stuff for FreeBSD 7.x/-CURRENT. If it's doesn't need -pthread any longer, then it's awsome. We can add a new check of if system is below than 7.x then force add -pthread in ruby port. It will need a lot of test first before maintainer or someone to commit this change. I don't mind to test on ruby-gtk2/ruby-gnome2 in RELENG_7 by remove -pthread from ruby port. Yep, ruby-gtk2/ruby-gnome2 work great with ruby compiled without -pthread on RELENG_7. Nice! My suggest of add a new check should make everybody more happy. % ldd /usr/local/bin/ruby /usr/local/bin/ruby: libruby18.so.18 => /usr/local/lib/libruby18.so.18 (0x2807d000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) libm.so.5 => /lib/libm.so.5 (0x2816d000) libc.so.7 => /lib/libc.so.7 (0x28182000) % ruby /usr/local/share/examples/ruby18/gtk2/misc/filechooser.rb [...no crash...] % ruby /usr/local/share/examples/ruby18/gtk2/misc/fileselection.rb [...no crash...] Cheers, Mezz Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GraphicsMagick build error on RELENG_7
Sources from an hour ago: == Making all in magick `./magick_config.h.in' is up to date. `../config.status' is up to date. `./magick_config_api.h.in' is up to date. `../config.status' is up to date. Making all in wand make: don't know how to make ../magick/libGraphicsMagick.la. Stop *** Error code 1 1 error *** Error code 2 Stop in /usr/ports/graphics/GraphicsMagick. *** Error code 1 == after which I did: cd work/GraphicsMagick-1.1.10/magick/ make cd /usr/ports/graphics/GraphicsMagick/ make make test (all fine) make deinstall make reinstall --per ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ruby18, -pthreads, deep recursion
On Fri, 02 Nov 2007 11:37:07 -0500, Marcin Wisnicki <[EMAIL PROTECTED]> wrote: On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html If it's any consolation, I've emailed the ruby maintainer a few times about why disabling threads in the port's menu doesn't *really* disable threads and have never gotten a reply. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. I must be behind with -pthread stuff for FreeBSD 7.x/-CURRENT. If it's doesn't need -pthread any longer, then it's awsome. We can add a new check of if system is below than 7.x then force add -pthread in ruby port. It will need a lot of test first before maintainer or someone to commit this change. I don't mind to test on ruby-gtk2/ruby-gnome2 in RELENG_7 by remove -pthread from ruby port. Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ruby18, -pthreads, deep recursion
On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: > On Thursday 01 November 2007 04:04:35 pm lemon wrote: >> [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html >> http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html >> > If it's any consolation, I've emailed the ruby maintainer a few times > about why disabling threads in the port's menu doesn't *really* disable > threads and have never gotten a reply. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diablo on 7.0-BETA
On Tue, Oct 30, 2007 at 02:30:33PM -0400, Peter Thoenen wrote: > Anybody got Diablo working? If so, you do anything special (my jar's > won't run). If not: > > 1) Anybody know when a Diablo support 7.0 is coming out? > 2) Until then, can we mark Diablo as broken on 7.0 Can you please include the error you get when you try to run an application? It should work if you have compat6x installed and the port already pulls in compat6x on 7.x. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diablo on 7.0-BETA
On Thu, Nov 01, 2007 at 10:21:23AM +0100, [LoN]Kamikaze wrote: > Peter Thoenen wrote: > > The Java JDK binary put out by the FBSD Foundation. While only 5.x and > > 6.x binaries are out, either they should work on 7.0 or it should be > > marked broken on 7.0 in the port tree (instead of letting me install it > > via ports). > > > > NOT the game > > I'd rather add a dependency to COMPAT6x There already is one. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Diablo on 7.0-BETA
On Wed, 31 Oct 2007 20:54:52 -0400
Peter Thoenen <[EMAIL PROTECTED]> wrote:
> The Java JDK binary put out by the FBSD Foundation. While only 5.x and
> 6.x binaries are out, either they should work on 7.0 or it should be
> marked broken on 7.0 in the port tree (instead of letting me install it
> via ports).
Peter, works fine here.
$ uname -sr
FreeBSD 7.0-BETA1
diablo-jdk-1.5.0.07.01_7 (from a package that I had built in 6.2 before I
ugpraded)
compat6x-i386-6.2.602110.200706 << u'll need this!
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01)
Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode)
I'll be upgrading to jdk1.6 anyway...
_
{Beto|Norberto|Numard} Meijome
When you just want a system that works, you choose Unix;
When you want a system that just works, you choose Microsoft.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ruby18, -pthreads, deep recursion
On Thursday 01 November 2007 04:04:35 pm lemon wrote: > Hi, > > I've been struggling with FreeBSD's ruby18 port and threads. I realise > there's previous discussion[0] about this and I feel I'm blundering > somewhat, but here goes. > > On both 7.x and 6.x boxes I've built ruby18 with the pthreads knob > deliberately turned off (the default). The resultant ruby has problems > with deep recursion, shown by this script[1] but less pathologically in > production in a busy RoR site too. > > $ ruby -e 'def d(x); p x; d x+1; end; d 0' > > This bombs with SIGILL[2]. > > I note that, as per the conversations linked above, this build uses the > GCC option -pthread and links against libthr[3]. > > If I build the port without -pthread (and related config.h #define), > install the library alongside the from-port one, and employ the > resultant binary with some libmap.conf guidance I get a ruby which > behaves far nicer[4]. I can recurse way deeper and receive a graceful > SystemStackError exception when things hit the wall[5]. > > What's the score here? Clearly there's motive for building like it does, > but the hacked ruby works better for me in everyday life. Any ideas? > > I hope this is on-topic for freebsd-ports. I mailed the maintainer first > but got no response. > > Regards, l. > > [0] > http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019352.html > http://lists.freebsd.org/pipermail/freebsd-ports/2006-March/030691.html > > [1] Google found me this, I forget where! > > [2] $ ruby -e 'def d(x); p x; d x+1; end; d 0' | head > 0 > 1 > 2 > ... > 2138 > 2139 > Illegal instruction: 4 > > [3] $ ldd `which ruby` > /usr/local/bin/ruby: > libruby18.so.18 => /usr/local/lib/libruby18.so.18 (0x2807d000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) > libm.so.5 => /lib/libm.so.5 (0x2816d000) > libthr.so.3 => /lib/libthr.so.3 (0x28182000) > libc.so.7 => /lib/libc.so.7 (0x28195000) > > [4] $ ldd ~/tmp/ruby18 > /home/lemon/tmp/ruby18: > libruby18.so.18 => /usr/local/lib/libruby18-nothread.so.18 > (0x2807d000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) > libm.so.5 => /lib/libm.so.5 (0x2816d000) > libc.so.7 => /lib/libc.so.7 (0x28182000) > > [5] $ ~/tmp/ruby18 -e 'def d(x); p x; d x+1; end; d 0' > 0 > 1 > 2 > ... > 67705 > 67706 > -e:1:in `inspect': stack level too deep (SystemStackError) > from -e:1:in `p' > from -e:1:in `d' > from -e:1:in `d' > from -e:1 If it's any consolation, I've emailed the ruby maintainer a few times about why disabling threads in the port's menu doesn't *really* disable threads and have never gotten a reply. In my case though the damage from the 'sort of threaded' ruby that the port builds with the threads option turned off is far more insiduous. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
