Re: linux-opera start script
Hey Andriy, please add my email in CC in the next time. I am maintaining
this port and I near have miss this thread.
On Thu, 22 Jun 2006 08:24:24 -0500, Boris Samorodov <[EMAIL PROTECTED]> wrote:
On Thu, 22 Jun 2006 12:49:33 +0300 Andriy Gapon wrote:
I am getting the following message, probably completely harmless, when
I start linux-opera:
$ linux-opera
sh: error while loading shared libraries:
/usr/local/lib/compat/libtermcap.so.2: ELF file ABI version invalid
I see the following lines in linux-opera script:
# Make sure the compat libraries are found
test -d /usr/local/lib/compat/ &&
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib/compat/"
I am not sure why linux-opera would need /usr/local/lib/compat/, but
this is how LD_LIBRARY_PATH gets spammed.
Seems I understand what is going on.
It is a side effect of installing linux programms with FreeBSD
environment. Install.sh script of linux-opera port has function
guess_os() with:
-
os=`uname -s` || error 'uname'
case $os in
FreeBSD|NetBSD) os=AnyBSD;;
SunOS*) os=SunOS;;
esac
-
Sure it's the FreeBSD. And later at this script has:
-
case "${os}" in
AnyBSD|OpenBSD)
wrapper_contain="${wrapper_contain}
# Make sure the compat libraries are found
test -d /usr/local/lib/compat/ &&
LD_LIBRARY_PATH=\"\${LD_LIBRARY_PATH}:/usr/loc
al/lib/compat/\"
"
;;
-
All is OK when Opera is installed as a native package/port. But not
while installing it as a linux port. Upstream developers shouldn't be
bothered by determining the TARGET_OS. ;-)
Thanks for check and report, I will create and commit a fix in linux-opera.
Cheers,
Mezz
WBR
--
[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: pkgconfig/pkg-config
On Wed, 28 Jun 2006 12:35:47 -0500, david coder <[EMAIL PROTECTED]> wrote: since pkgconfig was moved to pkg-config, a number of portupgrade paths appear to be broken, certainly all that i've tried that depend on it, in particular glib20, acroread7, etc. what to do? i'm running 6.x & my ports tree is fresh. Run 'pkgdb -Ff'. Always recommend to run 'pkgdb -Ff' before touch portupgrade. Cheers, Mezz thx. David Coder Network Engineer Emeritus, Verio/NTT Telluride, CO & Washington, DC -- [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]"
Anyone still using x11-wm/fluxbox?
Hello folks, Fluxbox is now at 1.0rc2, so it is near ready to move from fluxbox-devel to fluxbox. I am wondering if there is any users that still are using x11-wm/fluxbox (0.1.14)? If yes, then I am happy to move from fluxbox to something like fluxbox-old (got any better name?) but I will not maintain it as I shall drop it to [EMAIL PROTECTED] If I get no reply until Fluxbox released at 1.0 then the 0.1.14 version will be gone for good. 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: new port of bonfire
On Thu, 06 Jul 2006 14:21:03 -0500, Lars Engels <[EMAIL PROTECTED]> wrote: On Thu, Jul 06, 2006 at 04:16:05PM -0300, Sergio Lenzi wrote: Hello all.. I have made a port of bonfire http://perso.orange.fr/bonfire/ and would like to publish it in the ports collection After reading the ports documentation I found nothing abou publishing it in the ports collection Can someone, please, give me a direction on how o publish the port? or submit it to a commiter Hi Sergio! You have to send it with 'send-pr'. It's described here: http://www.freebsd.org/doc/en/books/porters-handbook/porting-submitting.html We already have bonfire in MC ports. http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/ports/sysutils/bonfire/ The reason why we didn't put it in FreeBSD ports tree is that there is no HAL port, which it exists in MC ports. You will have to talk with ahze about it. I personal have no idea if it required HAL support or whatever. Cheers, Mezz Lars -- [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: new port of bonfire
On Thu, 06 Jul 2006 14:35:11 -0500, michael johnson <[EMAIL PROTECTED]> wrote: On 7/6/06, michael johnson <[EMAIL PROTECTED]> wrote: On 7/6/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote: > > On Thu, 06 Jul 2006 14:21:03 -0500, Lars Engels <[EMAIL PROTECTED]> > wrote: > > > On Thu, Jul 06, 2006 at 04:16:05PM -0300, Sergio Lenzi wrote: > >> Hello all.. > >> > >> I have made a port of bonfire http://perso.orange.fr/bonfire/ > >> and would like to publish it in the ports collection > >> > >> After reading the ports documentation I > >> found nothing abou publishing it in the ports collection > >> > >> Can someone, please, give me a direction on > >> how o publish the port? or submit it to a commiter > > > > Hi Sergio! > > > > You have to send it with 'send-pr'. It's described here: > > http://www.freebsd.org/doc/en/books/porters-handbook/porting-submitting.html > > > We already have bonfire in MC ports. > > http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/ports/sysutils/bonfire/ > > The reason why we didn't put it in FreeBSD ports tree is that there is > no > HAL port, which it exists in MC ports. You will have to talk with ahze > about it. I personal have no idea if it required HAL support or > whatever. I haven't looked but I don't think the newest version of bonfire uses hal. 2006: Bonfire-0.3.90 Lots of small and big fixes/changes to improve the overall UI and usability of B onfire (See Changelog). Three deps were removed (HAL, DBus, GDL). I know many of you (including me) like d GDL but it is not enough maintained to be fully usable. User can now choose image type when copying a disc to hard drive. Three new translations: Italian, and Brazilian Portugue Thanks! Now, you guys can make an agreement for who want to maintain it. ;-) Cheers, Mezz Michael Cheers, > Mezz > > > Lars -- [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: Anyone still using x11-wm/fluxbox?
On Sat, 08 Jul 2006 07:07:11 -0500, Randy Pratt <[EMAIL PROTECTED]> wrote: On Mon, 3 Jul 2006 19:18:26 -0400 Randy Pratt <[EMAIL PROTECTED]> wrote: On Mon, 03 Jul 2006 13:42:20 -0500 "Jeremy Messenger" <[EMAIL PROTECTED]> wrote: > Hello folks, > > Fluxbox is now at 1.0rc2, so it is near ready to move from fluxbox-devel > to fluxbox. I am wondering if there is any users that still are using > x11-wm/fluxbox (0.1.14)? If yes, then I am happy to move from fluxbox to > something like fluxbox-old (got any better name?) but I will not maintain > it as I shall drop it to [EMAIL PROTECTED] If I get no reply until > Fluxbox released at 1.0 then the 0.1.14 version will be gone for good. I'm using the older fluxbox and also know of a few others who are also dragging their feet. I've actually had my attention elsewhere and wasn't following the fluxbox-devel but I'll give it a whirl on a test box in the next few days. I doubt I'd request that the old version remain in the tree in any event since I'd keep it along with a few other local ports if I really wanted to stick with the old version. Thanks for the notice though so I can start paying attention :-) Just a follow-up to my previous comments. I switched to the fluxbox-devel-1.0rc2_1 version yesterday and have not seen any problems. I left my old ~/.fluxbox directory and configs and there didn't seem to be any problems. No reason that I can see to keep the old version around. Thanks for check. There only will be a small issue related with the rename of bsetroot to fbsetroot that might causing some old theme not work any longer. I will copying some of pkg-message (ATTENTION part) in /usr/ports/UPDATING when fluxbox-devel merges into fluxbox. Cheers, Mezz Randy -- [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: RFC: Merging X11BASE to LOCALBASE
On Fri, 14 Jul 2006 09:09:27 -0500, <[EMAIL PROTECTED]> wrote:
Hello;
--- Dejan Lesjak <[EMAIL PROTECTED]> ha scritto:
On Friday 14 July 2006 01:59, [EMAIL PROTECTED] wrote:
> Hi;
>
> Just here mumbling...
>
> It would be interesting to set
>
> X11BASE=/usr/X11 when using XFree86 and
> X11BASE=${LOCALBASE} when using XOrg.
>
> Not only due to historical consistency (/usr/X11 is the path
recommended in
> XFree86 manpages), but as a way to be able to use XFree86 and keep the
> system somewhat cleaner.
Well, I was planing XFree86 would move to LOCALBASE as well - if it
doesn't,
ports depending on X11 would have to special case XFree86 libraries and
includes and such, which would make system a bit less clean. Why do you
think
Hmm.. there should be no need to have special cases for ports that
properly
respect X11BASE. Ports that don't respect X11BASE (those that have
/usr/X11R6
hard coded) should be cleaned/fixed anyways.
using /usr/X11 would make things cleaner?
I haven't checked lately but XFree86 and XOrg are currently in conflict
aren't
they? One has to deinstall and rebuild all the packages built with XOrg
and
start a fresh build to use XFree86. Having XFree86 on it's own prefix
would
avoid the problem of having packages built with the wrong version of X
and it
also make an eventual clean up easier.
Nobody should install both xorg and xfree86 at the same time. It's pretty
pointless and it would cause more messy when you try to build other ports
that depend on either of it. Move everything in LOCALBASE, nothing more
and nothing less, is much cleaner.
Cheers,
Mezz
I think the user perceived default wouldn't change, with most people
using XOrg
in LOCALBASE, and some people using XFree86 in X11BASE. Of course if
eventually
X11BASE disappears is another matter, but at least for backwards
compatibility
(4.x?) it's good to have it for a while.
just my 0.02$
Pedro.
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
--
[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: graphics/png - CC
On Fri, 28 Jul 2006 18:35:14 -0500, Andrey Chernov <[EMAIL PROTECTED]> wrote: On Fri, Jul 28, 2006 at 11:40:10AM +0200, [LoN]Kamikaze wrote: The port graphics/png does not honour the CC Variable. I can't reproduce that, it honors CC for me. I can, CC=gcc will not change the CC when it compiles. 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: graphics/png - CC
On Sat, 29 Jul 2006 13:27:08 -0500, [LoN]Kamikaze <[EMAIL PROTECTED]>
wrote:
Andrey Chernov wrote:
On Sat, Jul 29, 2006 at 01:16:47PM -0500, Jeremy Messenger wrote:
On Fri, 28 Jul 2006 18:35:14 -0500, Andrey Chernov <[EMAIL PROTECTED]>
wrote:
On Fri, Jul 28, 2006 at 11:40:10AM +0200, [LoN]Kamikaze wrote:
The port graphics/png does not honour the CC Variable.
I can't reproduce that, it honors CC for me.
I can, CC=gcc will not change the CC when it compiles.
It is hard to imagine how it is ever possible. There is standard BSD
makefile.freebsd which not owervrites CC as you can see in the file.
No idea, I don't know png's build system so that cc must be come from
somewhere.
Is it possible that make.conf is read again?
I think, add "CC=${CC}" in graphics/png/Makefile's MAKE_ENV at 31 line
should do.
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: graphics/png - CC
On Sat, 29 Jul 2006 15:20:02 -0500, Andrey Chernov <[EMAIL PROTECTED]>
wrote:
On Sat, Jul 29, 2006 at 02:59:19PM -0500, Jeremy Messenger wrote:
On Sat, 29 Jul 2006 13:27:08 -0500, [LoN]Kamikaze <[EMAIL PROTECTED]>
wrote:
>Andrey Chernov wrote:
>>On Sat, Jul 29, 2006 at 01:16:47PM -0500, Jeremy Messenger wrote:
>>>On Fri, 28 Jul 2006 18:35:14 -0500, Andrey Chernov <[EMAIL PROTECTED]>
>>>wrote:
>>>
>>>>On Fri, Jul 28, 2006 at 11:40:10AM +0200, [LoN]Kamikaze wrote:
>>>>>The port graphics/png does not honour the CC Variable.
>>>>I can't reproduce that, it honors CC for me.
>>>I can, CC=gcc will not change the CC when it compiles.
>>
>>It is hard to imagine how it is ever possible. There is standard BSD
>>makefile.freebsd which not owervrites CC as you can see in the file.
No idea, I don't know png's build system so that cc must be come from
somewhere.
>Is it possible that make.conf is read again?
I think, add "CC=${CC}" in graphics/png/Makefile's MAKE_ENV at 31 line
should do.
It will be hack for reason unknown, I prefer to avoid that.
It is not a hack and it is known reason that you need to honor CC.
I normally set CC to anything and it honors.
How did you set? The graphics/png doesn't honor it when you add CC=foobar
in make.conf or graphics/png/Makefile.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-cc.html
I never heard from somebody other than you about that problem.
I don't tweak CC, so it's why I never have seen it until LoN_Kamikaze
report it. Not many people do that, but it's good to honor CC for icc,
choice versions of gcc and other compilers.
You should inspect your build path step by step to find real reason of
that bag, only after that we can find the real fix.
I already have gave you a solution. If you don't like it then it's your
job to figure another solution as you are maintaining for this 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: graphics/png - CC
On Sat, 29 Jul 2006 16:07:40 -0500, Gábor Kövesdán <[EMAIL PROTECTED]> wrote: Andrey Chernov wrote: On Sat, Jul 29, 2006 at 03:54:44PM -0500, Jeremy Messenger wrote: It will be hack for reason unknown, I prefer to avoid that. It is not a hack and it is known reason that you need to honor CC. It is not a reason, it is a goal. The reason is the bug true nature discovered. I normally set CC to anything and it honors. How did you set? The graphics/png doesn't honor it when you add CC=foobar in make.conf or graphics/png/Makefile. /usr/ports/graphics/png ttyp2 73_# setenv CC "gcc -g" /usr/ports/graphics/png ttyp2 74_# make ===> Extracting for png-1.2.12_1 => MD5 Checksum OK for libpng-1.2.12.tar.bz2. => SHA256 Checksum OK for libpng-1.2.12.tar.bz2. ===> Patching for png-1.2.12_1 ===> Applying FreeBSD patches for png-1.2.12_1 ===> Configuring for png-1.2.12_1 ===> Building for png-1.2.12_1 gcc -g -O2 -fno-strict-aliasing -pipe -march=pentium4 -march=pentium4 -c png.c ^^ gcc -g -O2 -fno-strict-aliasing -pipe -march=pentium4 -march=pentium4 -c pngset.c gcc -g -O2 -fno-strict-aliasing -pipe -march=pentium4 -march=pentium4 -c pngget.c gcc -g -O2 -fno-strict-aliasing -pipe -march=pentium4 -march=pentium4 -c pngrutil.c ^C You should inspect your build path step by step to find real reason of that bag, only after that we can find the real fix. I already have gave you a solution. If you don't like it then it's your job to figure another solution as you are maintaining for this port. Solution for what? You don't describe where the bug is exactly. Since I can't reproduce this situation on my machine, I can only relay upon your inspecting to maintain this port in this matter. I can't reproduce it either. Forgive me, guys. I mixed up with between my system and jail make.conf. Now I can't reproduce it. # cat /etc/make.conf | grep CC CC=gcc # pwd /usr/ports/graphics/png # make ===> Extracting for png-1.2.12_1 => MD5 Checksum OK for libpng-1.2.12.tar.bz2. => SHA256 Checksum OK for libpng-1.2.12.tar.bz2. ===> Patching for png-1.2.12_1 ===> Applying FreeBSD patches for png-1.2.12_1 ===> Configuring for png-1.2.12_1 ===> Building for png-1.2.12_1 gcc -O2 -fno-strict-aliasing -pipe -g -c png.c [...] Cheers, Mezz [EMAIL PROTECTED] /home/tux/wrk/ports/graphics/png]# cat /etc/make.conf | head -n 6 PERL_VER=5.8.8 PERL_VERSION=5.8.8 # Kernel & Userland CC=/usr/local/bin/gcc42 [EMAIL PROTECTED] /home/tux/wrk/ports/graphics/png]# make ===> Extracting for png-1.2.8_3 => MD5 Checksum OK for libpng-1.2.8.tar.bz2. => SHA256 Checksum OK for libpng-1.2.8.tar.bz2. ===> Patching for png-1.2.8_3 ===> Applying FreeBSD patches for png-1.2.8_3 ===> Configuring for png-1.2.8_3 ===> Building for png-1.2.8_3 /usr/local/bin/gcc42 -O -pipe -I. -DPNG_USE_PNGGCCRD -DPNG_NO_ASSEMBLER_CODE -c png.c /usr/local/bin/gcc42 -O -pipe -I. -DPNG_USE_PNGGCCRD -DPNG_NO_ASSEMBLER_CODE -c pngset.c /usr/local/bin/gcc42 -O -pipe -I. -DPNG_USE_PNGGCCRD -DPNG_NO_ASSEMBLER_CODE -c pngget.c /usr/local/bin/gcc42 -O -pipe -I. -DPNG_USE_PNGGCCRD -DPNG_NO_ASSEMBLER_CODE -c pngrutil.c [...snip...] -- [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: portmaster, bison, java/jdk15
On Tue, 01 Aug 2006 22:50:30 -0500, Jiawei Ye <[EMAIL PROTECTED]> wrote: I am running into 2 problems. 1. Some ports want devel/bison as dependancy, I installed devel/bison2 and it works too. But when the bison1 depending port gets upgraded by portmaster, portmaster will insist on bringing in devel/bison, instead of devel/bison2. Not sure what the correct solution is. 2. I just made a java/jdk15 yesterday, and the port gets updated today, resulting in portmaster wanting to upgrade the port, but portmaster will also try to install linux-sun-jdk15 as a dependancy on JDK15. The normal situation is that when there is a native JDK/Diablo present in the system, JDK15 port shouldn't depend on linux-sun-jdk for bootstrapping. I am not sure if this is a problem with the jdk15 port itself or not. doing "make clean" in java/jdk15 does list linux-sun-jdk as a dependancy, but simple 'make install' will not pull it in, is this contradictory? It is a known issue, I have reported to Doug a while back. I have a workaround for it by hack in portmaster, but it is not a right solution. Someone will have to figure a good solution. However, here's what I hacked in portmaster. while getopts 'CDFGabdfghilm:nop:r:suv' COMMAND_LINE_ARGUMENT ; do [...] F) ONLY_ME=yes; ARGS="-F $ARGS" ;; [...] cd $pd/$portdir if [ -n "$ONLY_ME" ]; then make depends else dependency_check fi I just run -F on specific port that needs it. As for solution, right now I am thinking about check on each port's conflict. Like for example: - Check on if devel/bison has any of CONFLICT. - CONFLICTS is devel/bison2, then check if devel/bison2 exists. - devel/bison2 does exist, then remove the devel/bison out of dependency check list. - Check if devel/bison2 needs to update. - [...goes on as normal...] I don't know if it's good idea. Looks like create a database is a better solution? Cheers, Mezz Jiawei Ye -- [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: portmaster, bison, java/jdk15
On Tue, 01 Aug 2006 23:33:02 -0500, Scot Hetzel <[EMAIL PROTECTED]> wrote: On 8/1/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote: On Tue, 01 Aug 2006 22:50:30 -0500, Jiawei Ye <[EMAIL PROTECTED]> wrote: > I am running into 2 problems. > > 1. Some ports want devel/bison as dependancy, I installed devel/bison2 > and it works too. But when the bison1 depending port gets upgraded by > portmaster, portmaster will insist on bringing in devel/bison, instead > of devel/bison2. Not sure what the correct solution is. > It is a known issue, I have reported to Doug a while back. I have a workaround for it by hack in portmaster, but it is not a right solution. Someone will have to figure a good solution. However, here's what I hacked in portmaster. : As for solution, right now I am thinking about check on each port's conflict. Like for example: - Check on if devel/bison has any of CONFLICT. - CONFLICTS is devel/bison2, then check if devel/bison2 exists. - devel/bison2 does exist, then remove the devel/bison out of dependency check list. - Check if devel/bison2 needs to update. - [...goes on as normal...] I don't know if it's good idea. Looks like create a database is a better solution? How about changing the ports that depend on bison to use something like: It will working for bison, but portmaster still need to be fix as there are some of ports other than just bison. For example, pcre vs pcre-utf8, cdrtools vs cdrtools-devel, ffmpeg vs ffmpeg-devel and goes on Add more USE_* for those too? :-) Cheers, Mezz USE_BISON= 1+ Then either submit a Mk/bsd.bison.mk file, or patch bsd.port.mk so that it will automatically detect which version of bison is installed (see USE_[MYSQL, POSTGRESQL, BDB] in Mk/bsd.databases.mk for an example) and added it as a BUILD_DEPENDS. Note: If a port also needs bison as a RUN_DEPENDS, you could use USE_BISON_RUN= 1+, and it would automatically set both a build, and run dependancy. Scot -- [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: portmaster, bison, java/jdk15
On Wed, 02 Aug 2006 01:09:00 -0500, Doug Barton <[EMAIL PROTECTED]> wrote: Jeremy Messenger wrote: It is a known issue, I have reported to Doug a while back. *nod* As for solution, right now I am thinking about check on each port's conflict. Like for example: - Check on if devel/bison has any of CONFLICT. - CONFLICTS is devel/bison2, then check if devel/bison2 exists. - devel/bison2 does exist, then remove the devel/bison out of dependency check list. - Check if devel/bison2 needs to update. - [...goes on as normal...] I don't know if it's good idea. That is a good idea, thanks for suggesting it. I will look at some code to do that, although I might not get it into the current version, as I'm almost done with some serious performance optimizations that I'd like to get out the door. Sweet, look forward for it. :-) Cheers, Mezz Looks like create a database is a better solution? Heh, no. Doug -- [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: devel/boost: what's proper shared library version?
On Wed, 13 May 2009 11:26:56 -0500, Alexander Churanov wrote: Hi folks! I'm currently working on boost-1.39 port. The wiki http://wiki.freebsd.org/BoostPortingProject reflects most recent project status. And there is a question: what is the proper value for shared libraries installed by boost? As I can see from CVS, devel/boost started setting shared library version explicitly since 1.32. It was 2 for 1.32, then 3 for 1.33, then remained 3 till 1.35. When updating to 1.37 I've changed it to 4, just made +1. Now It's not clear what version should be used for 1.39. Boost.org provides no binary compatibility between versions of their libraries. It seems the best solution is to modify shared libraries version on each version update from boost. The choices are: 1) Just increment number further. It would be 5 for 1.39 This is a correct choice. But you only need to bump it if newer version break the ABI. If the binary of library is compatibility, then do not bump it. 2) Use what's boost installer provides (currently so.1.39.0) You can try ltverhack (must have USE_AUTOTOOLS=libtool:15 with it) in bsd.gnome.mk, it's what near all GNOME and a some outside ports use to get same .so.N as Linux. Like our glib2/gtk2 has .so.0 just like Linux. If the ltverhack doesn't work then stick with manual. By the way, ltverhack fix libtool bug for FreeBSD to get correct .so.N. 3) Use own numbering system, linked to version of boost. For example: so.1390 No. This is very ugly, because its force all ports to rebuild at the each time when boost update. It's not need to bump if ABI is compatibility. I don't like option (1), because *so version is not related to version of libraries. The library version is unrelated with release version. It's merely an ABI version, so it bumps when ABI break in the next update. For the (2) I've heard that on FreeBSD version must be a single number. I've never seen versions like 1390, as suggested in option (3). What approach to follow? Sincerely, Alexander Churanov, maintainer of devel/boost -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/boost: what's proper shared library version?
On Thu, 14 May 2009 13:14:26 -0500, Alexander Churanov wrote: Jeremy, There is no binary compatibility for boost libraries at all. To be precise, they say "this may work for some cases", but boost folks are intentionally not examining if such a compatibility exists between releases. Of course, they provide no warranty of any kind. I've just dropped a message to boost and they confirmed that there is no compatibility between releases. So then, my question was not about binary compatibility. I was sure it does not exist. And yes, we need to rebuild all ports that depend on boost each time the libraries are updated. The question is: "how correctly assign versions to shared libraries from boost?" I suggest using boost release version, because this is most clear and obvious way. It's supported by boost out-of-box. The only concern is whether library names like libboost_date_time.so.1.39.0 are acceptable for FreeBSD. It's highly unlike they will break the ABI in the minor release. We haven't bump boost when minor version was released and no issue. What number or blah, I don't care as long as you do not bump it for no reason when the ABI isn't broke. Cheers, Mezz Alexander Churanov, maintainer of devel/boost -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
Why not use normal CONFLICTS in lang/gcc43 instead of custom?
Hello Gerald, I am trying to install x11/gnome2 last night and the build has gotten stop at lang/gcc43, because of conflict with lang/gcc295. But wait, I don't have lang/gcc295 install. I only have ccache installed that has put 'gcc295' in /usr/local/libexec/ccache/ and this path is in the front of my PATH. It caused lang/gcc43 to find it by mistake. --- # ls -l /usr/local/libexec/ccache/ | grep 295 lrwxr-xr-x 1 root wheel 21 June 12 14:36 g++295@ -> /usr/local/bin/ccache lrwxr-xr-x 1 root wheel 21 June 12 14:36 gcc295@ -> /usr/local/bin/ccache # echo $PATH /usr/local/libexec/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin --- --- pre-extract: @# Building libgcj with lang/gcc295 installed is causing a failure @# about "hidden symbol `__eprintf'" in libgcc.a(_eprintf.o). @if type gcc295 >/dev/null ; then \ echo "This port will not build in the presence of lang/gcc295."; \ exit 1; \ fi --- Puzzled me for you to not use the CONFLICTS, so why not use it? If you really can't use CONFLICTS, then can you use the full path of gcc295? Thanks. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Stop in /usr/ports/lang/gcc43
On Sun, 14 Jun 2009 14:05:10 -0500, Dan Allen wrote: On 13 Jun 2009, at 10:55 PM, b. f. wrote: Some care is taken to avoid introducing circular dependencies in Ports, so this shouldn't happen. It sounds to me as if you have mistakenly introduced a USE_FORTRAN=yes into your build environment somehow. I DO have USE_FORTRAN=yes in /etc/make.conf. I will try things without that. The #1 rule is to never put the USE_* in make.conf. Cheers, Mezz Stay tuned... Thanks! Dan -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Why not use normal CONFLICTS in lang/gcc43 instead of custom?
On Tue, 16 Jun 2009 03:54:18 -0500, Alex Dupre wrote:
Using the full path will not work too well either with different
LOCALBASEs
though I guess one could check /usr/local, $PREFIX, and $LOCALBASE and
consider that good enough.
I think ${LOCALBASE}/bin/gcc295 would be enough. As you say, gcc295 is
dying, while ccache is actively used. It's quite annoying to remove such
check from the Makefile, while I doubt anyone is still going to compile
gcc43 with gcc295 installed in a non-standard location.
Yes, I agree about that ${LOCALBASE}. Either put full path or remove
gcc295 sound good to me.
Cheers,
Mezz
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: devel/boost-python
On Tue, 16 Jun 2009 19:34:43 -0500, Scot Hetzel wrote: 2009/6/16 martinko : Hallo, I've installed graphics/gimp which installed devel/boost. Now I'm trying to install x11/kdebase4* that want devel/boost-python which is in conflict with devel/boost. I don't think I've modified any port options, therefore I'm wondering why the ports fail to install. :-/ What should I do to remedy the situation pls ? Either uninstall graphics/gimp and devel/boost. First install devel/boost-python then graphics/gimp. You don't need to uninstall gimp. All you have to do is reinstall boost with python option. The fix is on way from boost maintainer and being test. Cheers, Mezz Or use either portupgrade or pormaster to replace devel/boost with devel/boost-python: If using portupgrade: # portupgrade -o devel/boost-python devel/boost If using portmaster: # portmaster -o ldevel/boost-python devel/boost Scot -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Temporary patch to fix USB in kdebase4
On Thu, 02 Jul 2009 09:52:49 -0500, Lawrence Stewart wrote: Hans Petter Selasky wrote: See attachment. --HPS Any chance you (or someone with the right clue) could update this patch to work with more recent 8-CURRENT? I get the following output when trying to compile kdebase4 (which applies your original patch as extra-patch-libusb20) on r195046 world/kernel: There is no usb_revision.h in recently -CURRENT. I have nothing of it in my system, I always run make delete-old and delete-old-libs. However, I am able to installed both kdebase3 and kdebase4 by tweak in extra-patch-libusb20. All I have to do like this: Change from: +#include To: +/*#include */ As for the kdebase3, I just took a patch from ports/135860 then tweak a bit. I am planning to follow up in its PR. But, I haven't run those in runtime yet thought. Cheers, Mezz Scanning dependencies of target kcm_usb [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o In file included from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevices.h:20, from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/kcmusb.cpp:27: /usr/include/dev/usb/usb_revision.h:33: error: multiple definition of 'enum usb_dev_speed' /usr/include/dev/usb/usb.h:686: error: previous definition here /usr/include/dev/usb/usb_revision.h:34: error: conflicting declaration 'USB_SPEED_VARIABLE' /usr/include/dev/usb/usb.h:687: error: 'USB_SPEED_VARIABLE' has a previous declaration as 'usb_dev_speed USB_SPEED_VARIABLE' /usr/include/dev/usb/usb_revision.h:35: error: conflicting declaration 'USB_SPEED_LOW' /usr/include/dev/usb/usb.h:688: error: 'USB_SPEED_LOW' has a previous declaration as 'usb_dev_speed USB_SPEED_LOW' /usr/include/dev/usb/usb_revision.h:36: error: conflicting declaration 'USB_SPEED_FULL' /usr/include/dev/usb/usb.h:689: error: 'USB_SPEED_FULL' has a previous declaration as 'usb_dev_speed USB_SPEED_FULL' /usr/include/dev/usb/usb_revision.h:37: error: conflicting declaration 'USB_SPEED_HIGH' /usr/include/dev/usb/usb.h:690: error: 'USB_SPEED_HIGH' has a previous declaration as 'usb_dev_speed USB_SPEED_HIGH' /usr/include/dev/usb/usb_revision.h:38: error: conflicting declaration 'USB_SPEED_SUPER' /usr/include/dev/usb/usb.h:691: error: 'USB_SPEED_SUPER' has a previous declaration as 'usb_dev_speed USB_SPEED_SUPER' /usr/include/dev/usb/usb_revision.h:45: error: multiple definition of 'enum usb_revision' /usr/include/dev/usb/usb.h:698: error: previous definition here /usr/include/dev/usb/usb_revision.h:46: error: conflicting declaration 'USB_REV_UNKNOWN' /usr/include/dev/usb/usb.h:699: error: 'USB_REV_UNKNOWN' has a previous declaration as 'usb_revision USB_REV_UNKNOWN' /usr/include/dev/usb/usb_revision.h:47: error: conflicting declaration 'USB_REV_PRE_1_0' /usr/include/dev/usb/usb.h:700: error: 'USB_REV_PRE_1_0' has a previous declaration as 'usb_revision USB_REV_PRE_1_0' /usr/include/dev/usb/usb_revision.h:48: error: conflicting declaration 'USB_REV_1_0' /usr/include/dev/usb/usb.h:701: error: 'USB_REV_1_0' has a previous declaration as 'usb_revision USB_REV_1_0' /usr/include/dev/usb/usb_revision.h:49: error: conflicting declaration 'USB_REV_1_1' /usr/include/dev/usb/usb.h:702: error: 'USB_REV_1_1' has a previous declaration as 'usb_revision USB_REV_1_1' /usr/include/dev/usb/usb_revision.h:50: error: conflicting declaration 'USB_REV_2_0' /usr/include/dev/usb/usb.h:703: error: 'USB_REV_2_0' has a previous declaration as 'usb_revision USB_REV_2_0' /usr/include/dev/usb/usb_revision.h:51: error: conflicting declaration 'USB_REV_2_5' /usr/include/dev/usb/usb.h:704: error: 'USB_REV_2_5' has a previous declaration as 'usb_revision USB_REV_2_5' /usr/include/dev/usb/usb_revision.h:52: error: conflicting declaration 'USB_REV_3_0' /usr/include/dev/usb/usb.h:705: error: 'USB_REV_3_0' has a previous declaration as 'usb_revision USB_REV_3_0' /usr/include/dev/usb/usb_revision.h:59: error: multiple definition of 'enum usb_hc_mode' /usr/include/dev/usb/usb.h:712: error: previous definition here /usr/include/dev/usb/usb_revision.h:60: error: conflicting declaration 'USB_MODE_HOST' /usr/include/dev/usb/usb.h:713: error: 'USB_MODE_HOST' has a previous declaration as 'usb_hc_mode USB_MODE_HOST' /usr/include/dev/usb/usb_revision.h:61: error: conflicting declaration 'USB_MODE_DEVICE' /usr/include/dev/usb/usb.h:714: error: 'USB_MODE_DEVICE' has a previous declaration as 'usb_hc_mode USB_MODE_DEVICE' /usr/include/dev/usb/usb_revision.h:62: error: conflicting declaration 'USB_MODE_DUAL' /usr/include/dev/usb/usb.h:715: error: 'USB_MODE_DUAL' has a previous declaration as 'usb_hc_mode USB_MODE_DUAL' /usr/include/dev/usb/usb_revision.h:69: error: multiple definition of 'enum usb_dev_s
May I commit kvirc(-devel)? Fix the path of ltmain.sh.
Hello, May I commit kvirc(-devel) to fix the path/hardcore of ltmain.sh? -- % ls -l /usr/local/share/libtool15/ltmain.sh ls: /usr/local/share/libtool15/ltmain.sh: No such file or directory % grep ltmain /usr/ports/devel/libtool15/pkg-plist share/libtool/libltdl/ltmain.sh share/libtool/ltmain.sh -- Here are the patches to fix those: http://people.freebsd.org/~mezz/diff/both_kvric.diff Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
May I commit your ports to fix the hardcore?
Hello, May I commit your ports to fix the hardcore of ltmain.sh and libtool? Here are the patches: kde@: http://people.freebsd.org/~mezz/diff/kdeutils3.diff anatoly.borodin@: http://people.freebsd.org/~mezz/diff/directfb.diff alecn2002@: http://people.freebsd.org/~mezz/diff/kmymoney2.diff Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: May I commit your ports to fix the hardcore?
On Thu, 02 Jul 2009 14:56:31 -0500, Thomas Abthorpe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 2, 2009 03:30:46 pm Jeremy Messenger wrote: May I commit your ports to fix the hardcore of ltmain.sh and libtool? Here are the patches: kde@: http://people.freebsd.org/~mezz/diff/kdeutils3.diff Hi Jeremey Feel free to commit the patch. - + Now I can view it in my browser. ;-) Committed! Thank you and miwi too. Cheers, Mezz :) Thomas - -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpNEPAACgkQ5Gm/jNBp8qCxHQCeIPfcfgQvgWfufaA5mYtodXKB CjEAn3/PjPsis/Gy1kCWRZnNHnxlh2Fs =amc/ -END PGP SIGNATURE- -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: www/firefox35 coredumps every time at startup
On Thu, 09 Jul 2009 14:21:16 -0500, Heino Tiedemann wrote: Heino Tiedemann wrote: Martin Wilke wrote: On Wed, Jul 08, 2009 at 09:21:31AM +0200, Heino Tiedemann wrote: > Heino Tiedemann wrote: > > I installed the port www/firefox35. After installation I tried to > > start it > > It core dumps 'every time' (100% reproducable). > > Did you load sem(4)? To quote UPDATING: > > If your Firefox crashes with the following message while viewing a > HTML5 page: "Bad system call (core dumped)" you need to load the sem > module (kldload sem). > > To load sem on every boot put the following into your > /boot/loader.conf: sem_load="YES" Hi Johan, no, I did not, because 1) my message was different then that one in UPDATING 2) it crahses on startup, not while viewing a HTML5 document (as mentioned in UPDATING) Should I try sem_load="YES" also for that Problem? Yes, after the install/update start firefox the FF3.5 welcome site with a html5 video, so it's crash with a video. does not work: [x] /boot/loader.conf: sem_load="YES" [x] reboot $ firefox3 Fatal error 'Recurse on a private mutex.' at line 986 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 2) Abort trap (core dumped) Seems to be another problem then mentioned in UPDATE. Any Ideas? Is somewone working on it? It looks like firefox35 or somewhere has missed to compile with -pthread. What can I Do? Upgrade to FreeBSD 7.x or above. I am not kidding. FreeBSD 7.x and above are heck a lot better than 6.x. Those don't have any problem, which FreeBSD 6.x has some bugs or missing feature that force some stuff to compile with -pthread when it's not need. Cheers, Mezz Heino -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: www/firefox35 coredumps every time at startup
On Thu, 09 Jul 2009 15:26:39 -0500, Heino Tiedemann wrote: "Jeremy Messenger" wrote: On Thu, 09 Jul 2009 14:21:16 -0500, Heino Tiedemann wrote: Heino Tiedemann wrote: Martin Wilke wrote: On Wed, Jul 08, 2009 at 09:21:31AM +0200, Heino Tiedemann wrote: > Heino Tiedemann wrote: > > I installed the port www/firefox35. After installation I tried to > > start it > > It core dumps 'every time' (100% reproducable). > > Did you load sem(4)? To quote UPDATING: > > If your Firefox crashes with the following message while viewing a > HTML5 page: "Bad system call (core dumped)" you need to load the sem > module (kldload sem). > > To load sem on every boot put the following into your > /boot/loader.conf: sem_load="YES" Hi Johan, no, I did not, because 1) my message was different then that one in UPDATING 2) it crahses on startup, not while viewing a HTML5 document (as mentioned in UPDATING) Should I try sem_load="YES" also for that Problem? Yes, after the install/update start firefox the FF3.5 welcome site with a html5 video, so it's crash with a video. does not work: [x] /boot/loader.conf: sem_load="YES" [x] reboot $ firefox3 Fatal error 'Recurse on a private mutex.' at line 986 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 2) Abort trap (core dumped) Seems to be another problem then mentioned in UPDATE. Any Ideas? Is somewone working on it? It looks like firefox35 or somewhere has missed to compile with -pthread. What is this "-pthread" Can I change that? Disable the option? What can I Do? Upgrade to FreeBSD 7.x or above. I am not kidding. FreeBSD 7.x and above are heck a lot better than 6.x. Those don't have any problem, which FreeBSD 6.x has some bugs or missing feature that force some stuff to compile with -pthread when it's not need. Not yet. First I have to buy new hardware.. so - how can I change the "-pthread" option? You will have to wait until someone figure where is the right place to add the -pthread. Cheers, Mezz greets Heino -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [HEADSUP]: Ports freeze schedule for 8.0-RELEASE
Hello all, It will be great if I can get more people to help test with libtool/libltdl 2.2 before the freeze. It already has been tested in pointyhat-exp last week, we have fixed almost all of error logs. Only three ports have been marked as BROKEN is x11-wm/ion-2, audio/ccaudio and lang/ccscript. If anyone want to fix those, feel free to or those will be remove if nobody fix it in a few months. I have sent an email to pav for request another run in pointyhat-exp. However, to test libtool/libltdl, you will need to checkout ports-stable module from MarcusCom CVS. 1) See document: http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/ ... 2) Checkout ports tree by cvsup, csup, or whatever by your choice. 3) fetch http://www.marcuscom.com/downloads/marcusmerge script, then run 'sh marcusmerge -m ports-stable' and the password is 'anoncvs'. 4) You must run devel/libtool22/files/libtool22_hack.sh first before you try to install anything in ports tree. The libtool22_hack.sh will edit all ports/*/*/Makefile* to change libtool:15 -> libtool:22, devel/libtool15 -> devel/libtool22 and etc. If you need to create INDEX then you need to edit devel/Makefile by change lib*15 -> lib*22. 5) Reinstall everything that depend on libltdl due to shared library version bump, do this (untest): portmaster -o devel/libtool22 libtool-1.5\* portmaster -o devel/libltdl22 libltdl-1.5\* portmaster -r libltdl\* I believe that it's same way for portupgrade. If there is anything that behave change after this upgrade, let me know and I will try to fix it. Thanks! Cheers, Mezz On Fri, 17 Jul 2009 04:05:30 -0500, Erwin Lansing wrote: Below is the tentative schedule for the ports freeze in preparation for 8.0-RELEASE. If any major delays occur in the overall release schedule, the dates may be postponed, but please start preparing to have your changed committed to the tree before August 17 to ensure they are included in the release. Also, portmgr kindly asks anyone who has anything major lined up to already from today start mailing portmgr about these so we know what to expect and not be surprised by any major fallout that might extend the short freeze we have planned. August 17: ports tree is frozen and package build begin August 24: ports tree is thawed and final package builds begin August 31: FreeBSD 8.0-RELEASE is released and ports tree is unfrozen -erwin -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [HEADSUP]: Ports freeze schedule for 8.0-RELEASE
On Fri, 17 Jul 2009 15:40:43 -0500, Jeremy Messenger wrote: Hello all, It will be great if I can get more people to help test with libtool/libltdl 2.2 before the freeze. It already has been tested in By the way, the test is what I meant by runtime not build. I have tested it with GNOME 2.26 and 2.27, KDE 3, KDE 4, XFCE 4 and many other WMs before I put in MC CVS ports-stable. Also, a few other applications. All of those work fine. But... I prefer different people to do the test that they might ran into problem that I haven't catch. It would be great if someone can test www/apache20 and www/apache22. Maybe there is no issue, since all patches are similar in and take from apache SVN. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [HEADSUP]: Ports freeze schedule for 8.0-RELEASE
On Sat, 18 Jul 2009 01:36:16 -0500, Philip M. Gollucci wrote: Jeremy Messenger wrote: Hello all, It will be great if I can get more people to help test with libtool/libltdl 2.2 before the freeze. It already has been tested in pointyhat-exp last week, we have fixed almost all of error logs. Only three ports have been marked as BROKEN is x11-wm/ion-2, audio/ccaudio and lang/ccscript. If anyone want to fix those, feel free to or those will be remove if nobody fix it in a few months. I have sent an email to pav for request another run in pointyhat-exp. However, to test libtool/libltdl, you will need to checkout ports-stable module from MarcusCom CVS. sysutils/lsof DOES NOT COMPILE with libtool22. Actually, sysutils/lsof does not use libtool and has no dependency require (well, only require /usr/src/sys/*). The sysutils/lsof is very common to get break when someone make the changes in -CURRENT. If you update your -CURRENT, I am sure that it will build as pointyhat(-exp), marcus and others can get it builds. http://tb.p6m7g8.net live with libtool22, as far as I can tell the complete set below is fine -- Thanks for test! Cheers, Mezz HTH -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: ports/*/jpeg "Thanks a lot guys"
On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg "Great real great" Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. Yes, but how can you tell if there is newer version? The pkg_version and pkgversion don't tell you that it's PORTREVISION or actually newer version. What about when we run 'port* -a'? Took about two weeks to get PORTREVISION bump isn't right at all. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: apr-gdbm-db42 upgrade conflicting with libtool
On Mon, 03 Aug 2009 11:39:33 -0500, David Southwell wrote: In message <20090803125519.ga60...@twisted.net>, Troy (t...@twisted.net) wrote: > I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran > into the following error. My libtool was just upgraded to libtool-2.2.6a > so there may be a conflict there. Anyone have ideas? > > > checking minix/config.h usability... no > checking minix/config.h presence... no > checking for minix/config.h... no > checking whether it is safe to define __EXTENSIONS__... yes > checking for library containing strerror... none required > checking whether system uses EBCDIC... no > performing libtool configuration... > ./configure: 9753: Syntax error: word unexpected (expecting ")") > *** Error code 2 > > Stop in /usr/ports/devel/apr. > *** Error code 1 > > Stop in /usr/ports/devel/apr. I am also having problems updating devel/apr. In my case it gets past the configure stage and fails during the compile stage: % ===> Building for apr-gdbm-db43-1.3.7.1.3.8 -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include -o passwd/apr_getpass.lo -c passwd/apr_getpass.c && touch passwd/apr_getpass.lo /libtool: Can't open /libtool: No such file or directory *** Error code 2 Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. *** Error code 1 Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. *** Error code 1 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. % I have not had time to try to figure out what is going wrong, but I may have time tomorrow. Cheers, Nick. I also have problems: uname -a FreeBSD dns1.vizion2000.net 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Built on Intel quad Core lt_cv_sys_max_cmd_len=262144 /bin/sh ./buildconf buildconf: checking installation... buildconf: python not found. You need python installed to build APR from SVN. *** Error code 1 Stop in /usr/ports/devel/apr. *** Error code 1 I can't reproduce it. Pav has ran pointyhat-exp a few times and devel/apr has never came up, which it always passed build. Did all of you follow the /usr/ports/UPDATING? Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/glib install is not correct.
On Thu, 06 Aug 2009 01:35:32 -0500, khsing wrote: I have found the reason. because libtool15 have been mv to libtool22. It is documented in /usr/ports/UPDATING. so upgrade libtool from 15 to 22 will resolve this problem. portmaster -Btuw libtool On Thu, Aug 6, 2009 at 12:36 PM, 葉佳威 Jiawei Ye wrote: On Thu, Aug 6, 2009 at 12:10 PM, khsing wrote: When I deinstall devel/glib20 ports. I got this message ===> Deinstalling for devel/glib20 ===> Deinstalling glib-2.20.4 pkg_delete: file '/usr/local/lib/libgio-2.0.so.0' doesn't exist pkg_delete: file '/usr/local/lib/libglib-2.0.so.0' doesn't exist pkg_delete: file '/usr/local/lib/libgmodule-2.0.so.0' doesn't exist pkg_delete: file '/usr/local/lib/libgobject-2.0.so.0' doesn't exist pkg_delete: file '/usr/local/lib/libgthread-2.0.so.0' doesn't exist pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) On Thu, Aug 6, 2009 at 12:07 PM, khsing wrote: > When I install graphics/p5-Image-Magick-Iterator, I have got some > message below. > > I think the devel/glib install is not correct, so made this error. > > gmake[4]: Leaving directory > `/usr/ports/devel/glib20/work/glib-2.20.4/docs' > gmake[3]: Leaving directory > `/usr/ports/devel/glib20/work/glib-2.20.4/docs' > gmake[2]: Leaving directory > `/usr/ports/devel/glib20/work/glib-2.20.4/docs' > gmake[1]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.20.4' > ===> Running ldconfig > /sbin/ldconfig -m /usr/local/lib > ===> Registering installation for glib-2.20.4 > ===> Returning to build of liblqr-1-0.4.1 > Error: shared library "glib-2.0.0" does not exist > *** Error code 1 > > Stop in /usr/ports/graphics/liblqr-1. > *** Error code 1 > > Stop in /usr/ports/graphics/ImageMagick. > *** Error code 1 > > Stop in /usr/ports/graphics/ImageMagick. > *** Error code 1 > > Stop in /usr/ports/graphics/p5-Image-Magick-Iterator. > > > -- > A man live in jail and want to break. > http://blog.khsing.net > I had the same issue with my new 4-core AMD64 -current system too. I suspect it's the new libtool and MAKE_JOBS_NUMBER>1. If I use MAKE_JOBS_NUMBERS>1 + libtool 2.2, both glib and atk are built with very strange lib version. glib is 2.0.200, atk is 1.2.6092 (or something like that, I don't have the exact error message anymore). To work around, set MAKE_JOB_NUMBERS=1 in make.conf and rebuild glib. that should make the problem go away for the moment. Cheers, Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: slib-guile
On Fri, 07 Aug 2009 12:31:35 -0500, Jason J. Hellenthal wrote: # Date created:3 November 2003 # Whom:Kimura Fuyuki # # $FreeBSD: ports/lang/slib-guile/Makefile,v 1.8 2008/06/06 13:41:14 edwin Exp $ #$MCom: ports/lang/slib-guile/Makefile,v 1.3 2006/10/13 02:32:48 marcus Exp $ PORTNAME= slib PORTVERSION=3a4 # Keep this in sync with lang/slib PORTREVISION= 2 CATEGORIES= lang scheme MASTER_SITES= # empty PKGNAMESUFFIX= -guile DISTFILES= # empty This is not in sync with lang/slib is this port used anymore or should I just disregard this to /dev/trash ? --- % gports Makefile lang/slib-guile /usr/ports/devel/g-wrap/Makefile /usr/ports/finance/gnucash/Makefile --- You can't remove this port. It's best to update slib-guile or leave it alone. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: ports/137843: Cannot compile devel/apr (version 1.3.8.1.3.9) on AMD64
On Fri, 21 Aug 2009 07:16:57 -0500, Matthias Andree
wrote:
Same for me, on i386. Removing the listed leftover libtool15/libltdl15
files/directories let the devel/apr build succeed, where it would fail
before.
Given that the devel/libtool15 port is gone:
1. Can we have a pkg-install script that purges the obsolete libtool15
stuff (as listed, but substituting ${PKG_PREFIX} for /usr/local) post a
successful libtool22 install? Apparently the older pkg-plist were
incomplete, so that libtool15 didn't get completely removed on
uninstall, and a libtool22/libltdl22 post-installation cleanup of
libtool15 seems the natural way to solve.
No need to, the /usr/local/bin/libtool15 wasn't in libtool15 for over
three yeaers. It looks like you use FORCE_PKG_REGISTER that force
overwrite and that libtool15 was never remove correct.
2. Alternatively, please mention in /usr/ports/UPDATING that
libtool15/libltdl15 cruft needs to be purged manually (file list as
above).
It's more like user's fault or something.
Cheers,
Mezz
Thank you.
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: WITH_GECKO for system with firefox3(5)?
On Fri, 21 Aug 2009 09:00:13 -0500, Lowell Gilbert wrote: Lowell Gilbert writes: Andriy Gapon writes: It seems that WITH_GECKO=firefox implies firefox2 and there is no firefox3 option. So what should I use here? libxul? The Makefile implies that USE_GECKO= firefox3<->firefox may be what you want. But that doesn't work. There seems to be work in progress, but I don't know more. Mozilla folks want all third-party application to use libxul. The Firefox 3+ do not install library and etc, so no stuff can be build with it. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: webkit-gtk2 vs libtool-2.2.6a
On Sat, 22 Aug 2009 04:57:04 -0500, Fabian Keil wrote: Andriy Gapon wrote: webkit-gtk2 fails to build after libtool-2.2.6a update. Auto tools provide some helpful self diagnostics: ===> Configuring for webkit-gtk2-1.0.1_8 In related news, is anyone currently working on a webkit update? Neither uzbl nor the latest Liferea release are satisfied with the version in the ports and I assume this list is incomplete. It will be in when GNOME 2.28 released. You can grab it from marcuscom.com CVS if you can't wait. Cheers, Mezz Fabian -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, 22 Aug 2009 13:38:45 -0500, matt donovan wrote: On Sat, Aug 22, 2009 at 2:22 PM, Martin Wilke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy Guys, The FreeBSD Gecko Team will let you know what the plans for the future are and on what we are currently working. Goals: * Removal of mozilla, nvu, xulrunner and firefox2. * www/firefox35 should be moved to www/firefox. * The options USE_GECKO mozilla nvu xulrunner and firefox will be also removed. Background: We have a lot of old stuff on the portstree and it's time to cleanup old stuff. * www/mozilla is 5 year old now, no longer supported by upstream, and has many many vulnerabilities. We can use www/seamonkey. * www/nvu last official release was in 2005, no longer supported, and also some vulnerabilities. We have www/kompozer which also need an update to get this unbroken. * www/xulrunner is old and was replaced by www/libxul. We should not hold any old Gecko stuff. Also it's not longer supported by upstream: https://wiki.mozilla.org/XULRunner:Roadmap Problems which we have to solve: Some Gnome ports need www/firefox to build and work, but unfortunately firefox2 isn't longer supported by the Mozilla Foundation. Also www/firefox has a lot of vulnerabilities. We should www/firefox mark FORBIDDEN at this time gives no fixes for the latest securtiy reports. We see here 2 ways: 1) The Gnome Team (not the FreeBSD Gnome Team) take time and move all his stuff to libxul. I believe that all of our ports have libxul support. You can go ahead remove those. If we happen to miss one, we will find it. :-) 2) or we the FreeBSD Team have to remove all these ports. We know that's really hard but we should not hold vulnerabilities stuff. We hope to get here a bit help from the FreeBSD Gnome Team to make it possible to get some stuff to work with the current libxul version. Current Status: We working currently on Firefox 3.6 (alpha1) [2], Thunderbird 3.0 (beta3) [1], new libxul 1.9.1.2. All 3 are already committed to our repo. [1] a screenshot from tb3 under FreeBSD http://tmp.chruetertee.ch/tb3.0b3.png [2] a screenshot from ff36 under FreeBSD http://tmp.chruetertee.ch/ff36.png A current status can you find here: https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO So that's all at the moment, Feedback, Comments are welcome. - - Martin for the FreeBSD Gecko Team - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkqQN08ACgkQdLJIhLHm/OlZ7wCgk6xG3ymevRMf1D/0e9LpEqZ4 vF8An200XdohvNq3nptL4NCBIom+vgPN =SlKU -END PGP SIGNATURE- ___ freebsd-gn...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-gnome To unsubscribe, send any mail to "freebsd-gnome-unsubscr...@freebsd.org" I just have one question when has xulrunner been unsupported upstream considering that xulrunner 1.9.1 was released when firefox 3.5.2 was teh last release of xulrunner 1.9.x alpha was august 22end yes it's development but it's still supported. upstream The libxul is xulrunner 1.9x. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, 22 Aug 2009 15:52:43 -0500, wrote: Martin Wilke wrote: Background: We have a lot of old stuff on the portstree and it's time to cleanup old stuff. ... * www/nvu last official release was in 2005, no longer supported, and also some vulnerabilities. We have www/kompozer which also need an update to get this unbroken. ... Problems which we have to solve: Some Gnome ports need www/firefox to build and work, but unfortunately firefox2 isn't longer supported by the Mozilla Foundation. So, if I am understanding this correctly, it's proposed to replace nvu with an updated kompozer, which to judge from the name is part of KDE. Thus Gnome acquires a dependency on KDE by way of firefox/gecko? This does not seem like a Good Thing (TM). Why don't you check what kompozer is first? ;-) Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: libtool & pthread & ilmbase
On Fri, 28 Aug 2009 21:18:24 -0500, Dmitry Marakasov
wrote:
Hi!
I've asked about this issue before, but though Daniel Eischen nicely
explained me some stuff regarding threads, I was haven't had a clear
idea how to fix this. Now I've ran into this again, so I'll raise this
once more. The problem:
graphics/ilmbase is built with thread support by default (see port).
However, while libs are linked with -pthread as they should:
Search for 'nostdlib pthread' in google and you will see many results.
Linux even has the same problem.
libtool: link: c++ -shared -nostdlib /usr/lib/crti.o
/usr/lib/crtbeginS.o .libs/IlmThreadPool.o .libs/IlmThread.o
.libs/IlmThreadSemaphore.o .libs/IlmThreadMutex.o .libs/IlmThreadPosix.o
.libs/IlmThreadSemaphorePosix.o .libs/IlmThreadSemaphorePosixCompat.o
.libs/IlmThreadMutexPosix.o -Wl,-rpath
-Wl,/usr/home/amdmi3/projects/freebsd/ports/graphics/ilmbase/work/ilmbase-1.0.1/Iex/.libs
-Wl,-rpath
-Wl,/usr/home/amdmi3/projects/freebsd/ports/graphics/ilmbase/prefix/lib
../Iex/.libs/libIex.so -pthread -L/usr/lib -lstdc++ -lm -lc -lgcc_s
/usr/lib/crtendS.o /usr/lib/crtn.o -march=prescott -pthread -pthread
-pthread -pthread -Wl,-soname -Wl,libIlmThread.so.6 -o
.libs/libIlmThread.so.6
the resulting libraries have no dependency on real threading lib (-lthr):
% ldd /usr/local/lib/libIlmThread.so
/usr/local/lib/libIlmThread.so:
libIex.so.6 => /usr/local/lib/libIex.so.6 (0x281b)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2830)
libm.so.5 => /lib/libm.so.5 (0x281c1000)
libc.so.7 => /lib/libc.so.7 (0x2808f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281da000)
thus, I won't be able to link with this library directly:
% gcc 1.c -lIlmThread -L/usr/local/lib
/usr/local/lib/libIlmThread.so: undefined reference to `pthread_create'
unless I specify -pthread.
While this may be expected for libIlm_Thread_, there are other
(essentially thread-unaware) libs that depend on it.
OpenEXR:
% gcc 1.c -lIlmImf -L/usr/local/lib
/usr/local/lib/libIlmThread.so.6: undefined reference to `pthread_create'
nvidia-texture-tools (depends on OpenEXR):
% gcc 1.c -lnvimage -L/usr/local/lib
/usr/local/lib/libIlmThread.so.6: undefined reference to `pthread_create'
DevIL (conditionally depends on nvidia-texture-tools):
% gcc 1.c -lIL -L/usr/local/lib
/usr/local/lib/libIlmThread.so.6: undefined reference to `pthread_create'
Now, when I build CEGUI (which depends on devil), it won't really build
DevIL plugin, as configure check for link with DevIL will fail.
Finally, because of that, secretmaryochronicles segfault on startup.
This took some time to unwind, and I want this to be fixed once and
forever.
The solutions:
1) Add -pthread to linker flags in ALL dependent ports.
I think this is a no-go, as we'll then be forcing threads in too
many ports, which are essentially thread-unaware. Also, we'll be forcing
threads regardless of whether ilmbase is built threaded or not, also
regardless of whether we actually depend in ilmbase or not.
2) Fix it in ilmbase. I believe, like this:
.if ${OSVERSION} < 700041
PTHREAD_LIBS+= -lpthread
.else
PTHREAD_LIBS+= -lthr
.endif
Best to copy GECKO_PTHREAD's way of get library. Grep for
GECKO_PTHREAD_LIBS in ports/Mk/bsd.gecko.mk.
# cd /usr/ports/www/firefox3
# make -V GECKO_PTHREAD_LIBS
-lpthread
Cheers,
Mezz
this may not be so good, as only libIlmThread should be linked to
threads actually. So another solution:
3) Fix it in OpenEXR.
The same way as above, as just CONFIGURE_ARGS="${PTHREAD_LIBS}"
doesn't seem to have any effect.
I'm for #3. I've submitted a PR for this in April ([1]), but
nork@ didn't respond, so I'd like to commit this after some tinderboxing
if no one sees any additionak caveats.
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/133291
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: transmission-daemon-1.73
On Mon, 31 Aug 2009 03:25:20 -0500, Alexey Markov wrote: Hello! First of all, excuse my English. ;-) I want to ask, is there any plans to update /net-p2p/transmission/ port to the latest 1.74 version? Or may i do it myself, by patch? I have been testing it for a few days (almost a week), because I don't trust Transmission's release quaility anymore. Anyway, I have committed 1.74 update recently. Cheers, Mezz Thanks in advance! -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
Testers: Here's a patch to update linux-opera to 10.00.
Hello all,
Here is a patch to update linux-opera to 10.00. It works great with old
~/.linux-opera so far, I haven't seen any problem. I will be out of town
for a few days. I need someone to test it more and report any bug if there
is any. When I commit it, I am planning to note in the UPDATING about make
the back up of ~/.linux-opera and turn the auto-update off. Also, I am
planning to make a request to the Opera developer for allow us to tweak
the path of /etc instead of hardcore that way I can put
operaprefs_fixed.ini and put in ${PREFIX}/etc/ to force disable
auto-update.
Patch: http://people.freebsd.org/~mezz/diff/linux-opera.diff
Couldn't have done without bsam. He has created linux-nas-lib for all
linux_base*. The linux-opera (well, it's QT libraries that came in its
tarball) needs it, so be sure to have your ports tree and installed ports
up to date.
Cheers,
Mezz
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: Testers: Here's a patch to update linux-opera to 10.00.
On Wed, 02 Sep 2009 04:07:49 -0500, Gary Jennejohn wrote: On Tue, 01 Sep 2009 21:49:20 -0500 "Jeremy Messenger" wrote: Here is a patch to update linux-opera to 10.00. It works great with old ~/.linux-opera so far, I haven't seen any problem. I will be out of town for a few days. I need someone to test it more and report any bug if there is any. Works extremely well so far, even flash works without any complications. I'm using linux_base-f10-10_1. uname -a (sanitized): FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #35: Sat Aug 29 18:30:32 CEST 2009 amd64 Thanks for test it, I have committed it. I didn't add anything UPDATING since it seems run very stable with old ~/.linux-opera. Cheers, Mezz --- Gary Jennejohn -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: x11-fm/xfe dependencies
On Tue, 08 Sep 2009 10:20:47 -0500, Jim Brooks wrote: Hi, xfe doesn't depend on GNOME. I tested removing this line from Makefile and compiled/ran successfully without GNOME: No... To have USE_GNOME does NOT means that it depends on GNOME. Explain us why you think so? Cheers, Mezz < USE_GNOME= gnomehack gnometarget -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: skype problem with fc10 and worldofgoo-demo
On Tue, 15 Sep 2009 09:03:52 -0500, Boris Samorodov wrote: Alexey Dokuchaev writes: Typically, there are two major providers of libGL (both native and Linux flavors): linux-*-dri ports *or* nvidia-driver, depending on what gfx card you have). Now the problem here that linux-*-dri ports install *both* It's not a problem. It's a feature. ;-) libGL and libGLU, while nvidia-driver installs just libGL (which is perfectly fine, since only libGL must directly interact with hardware via kernel module, for example). Recently bsam@ committed linux-f10-libGLU port with allowed me to port WorldOfGoo; previously, it was impossible without ugly hacks, since I use nVidia card + drivers, which conflict with linux-*-dri (the latter was the only provider of libGL for f10 until recently). Ideally, any port that needs libGL and/or libGLU should depend on libGLU *and* either libGL *or* nvidia-driver. Ports that depend on linux-*-dri to get these libs are very likely to drag conflicts sooner or later (this is especially true for nVidia cards owners). Perhaps Boris can shed more light on the subject. I've just emailed a patch for games/linux-worldofgoo-demo. Many other ports which need linux libGL/libGLU (either for nvidia or not) use those checks. It seems to work fine for other ports and should fix the case here. All conflicts seems to be dealt by that check either. Am I missing something? Isn't it better to fix in Mk/bsd.linux*.mk rather than try to fix all other ports? Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: skype problem with fc10 and worldofgoo-demo
On Wed, 16 Sep 2009 01:35:39 -0500, Boris Samorodov wrote: Boris Samorodov writes: "Jeremy Messenger" writes: On Tue, 15 Sep 2009 09:03:52 -0500, Boris Samorodov wrote: I've just emailed a patch for games/linux-worldofgoo-demo. Many other ports which need linux libGL/libGLU (either for nvidia or not) use those checks. It seems to work fine for other ports and should fix the case here. All conflicts seems to be dealt by that check either. Am I missing something? Isn't it better to fix in Mk/bsd.linux*.mk rather than try to fix all other ports? I thought about it. May be it'a way to go but not just before 8.0-RELEASE. Or may be even better to deal with the case at bsd.nvidia.mk? The bsd.linux*.mk would be more correct place, because it controls the USE_LINUX stuff. Cheers, Mezz Can anyone provide a patch or a proof of concept? -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: glib/webkit update?
On Wed, 07 Oct 2009 10:30:59 -0500, Dmitry Marakasov wrote: Hi! I need a new version of webkit, because the one that is currently in the ports tree doesn't work with Yahoo maps, and I need that for astro/josm. I've tried to update webkit port locally to r49078, but it requires newer glib: Requested 'glib-2.0 >= 2.21.3' but version of GLib is 2.20.5 Updating glib may require more effort and may break some of my installed apps, so I ask here - is there official update planned anytime soon, and/or is there some work in progress available to test? GNOME 2.28 was released during our ports tree freeze time, so we weren't able to put into ports tree. If you can't wait, grab those in MarcusCom CVS[1]. [1] http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/ Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: transmission port
On Tue, 26 Jan 2010 08:19:20 -0600, Christopher Fabritius wrote: Hello I was wondering wether you are considering updating the port for the transmission bittorrent client to the 1.80 release? Important stuff like magnet link support has been added, so it would be much appreciated :) Since I am getting many emails, so I am CC'ing to po...@. No, I will not commit it right away the release day or even a week. At the every release, it always have bugs. They released 1.80 to 1.82 in less than 4 or 5 days. For Transmission, I always test least a week on the major release before I commit it. If you can't wait, feel free do it by yourself in your system. Cheers, Mezz thanks Christopher -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: posix_fallocate
On Tue, 02 Feb 2010 01:10:39 -0600, Doug Barton wrote:
I'm working on the port of the 0.15 version of rblibtorrent
(http://sourceforge.net/projects/qbittorrent/files/qbittorrent-unstable/libtorrent-rasterbar-0.15.svn.r4203.tar.gz/download?use_mirror=heanet)
and ran into a snag with the following:
int ret = posix_fallocate(m_fd, 0, s);
The only reference in /usr/include is:
/usr/include/fcntl.h: * XXX missing posix_fadvise() and
posix_fallocate(), and POSIX_FADV_* macros.
/usr/include/sys/fcntl.h: * XXX missing posix_fadvise() and
posix_fallocate(), and POSIX_FADV_* macros.
No references at all in /usr/local/include.
There is another block of code that could be a solution, but it doesn't
look promising either:
#ifdef F_PREALLOCATE
fstore_t f = {F_ALLOCATECONTIG, F_PEOFPOSMODE, 0, s, 0};
if (fcntl(m_fd, F_PREALLOCATE, &f) < 0)
{
ec = error_code(errno, get_posix_category());
return false;
}
So, any suggestions? :)
I did request for anyone to create posix_fallocate() for FreeBSD long time
ago. You maybe can follow Transmission's same idea for return as nothing.
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026590.html
Cheers,
Mezz
Doug
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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-p2p/transmission] Partial new version 1.83
On Tue, 02 Feb 2010 03:03:31 -0600, Spil Oss wrote: Hi All, Created a partial port of the new 1.83 version of Transmission BT (including Magnet support). This works for me as net-p2p/transmission-daemon and www/transmission-web and has NOT been tested or even tried with any of the GUI ports or even the -cli interface. transmission-remote and transmission-daemon are in working order, as is the web interface. Changes net-p2p/transmission-cli * change version from 1.76 to 1.83 * remove files/disable-web (target was empty in the new Makefile.in) * make makesum (obviously) www/transmission * New pkg-plist file created using http://www.freebsd.org/doc/en/books/porters-handbook/plist-autoplist.html and removing the Makefile entries The `diff -ruN` output for both ports is attached Hope this is usefull to anyone! I don't have a GUI on my FreeBSD machine to test the GUI slave ports and am not a very good porter but am willing to lear. Comments are very welcome. Do not use this patch. The plist is broke. I will commit 1.83 this week. Cheers, Mezz Kind regards, Spil. -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Recent massive port update.
On Fri, 05 Feb 2010 21:42:09 -0600, jhell wrote: On Fri, 5 Feb 2010 17:50, ertr1013@ wrote: On Fri, Feb 05, 2010 at 06:25:42PM +0300, cvs-...@yandex.ru wrote: Hi there. I see some massive port update in past hours, but not see what the reason of it (nor on freebsd-ports@, nor on freshports.org). Can anybody shed the light what was changed? The graphics/jpeg port was updated such that the version number of libjpeg.so was increased. This necessitated a revision bump in all the ports that depend on graphics/jpeg. There are *many* such ports. Thanks. [r...@smeshariki2 ~]# portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Fri Feb 5 06:44:34 MSK 2010 to Fri Feb 5 15:57:40 MSK 2010. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 4282 patches. I could have swore that I recently heard an announcement that barred this type of activity until after 7.3-RELEASE was made Read this: http://lists.freebsd.org/pipermail/freebsd-ports/2010-January/059241.html Guess that doesn't stand for everything. Stick to package if you can't handle it. Was there some type of security concern that caused this bump of jpeg in the first place or was it just a creeping featurism? -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: gir-repository-atk-0.6.5_3 build error
On Tue, 16 Feb 2010 08:30:26 -0600, Janos Dohanics wrote: While building gnome2-2.28.2_1, I get this error: Making all in gir gmake[2]: Entering directory `/usr/ports/accessibility/gir-repository-atk/work/gir-repository-0.6.5/gir' /usr/local/bin/g-ir-scanner -v --namespace Atk --nsversion=1.0 \ --add-include-path=. --add-include-path=. \ --include=GObject-2.0 \ --library=atk-1.0 \ --libtool="/bin/sh ../libtool" \ --output Atk-1.0.gir \ --pkg gobject-2.0 \ --pkg atk \ -I`pkg-config --variable=includedir atk`/atk-1.0 \ `pkg-config --variable=includedir atk`/atk-1.0/atk/*.h /usr/local/bin/g-ir-scanner: not found gmake[2]: *** [Atk-1.0.gir] Error 127 gmake[2]: Leaving directory `/usr/ports/accessibility/gir-repository-atk/work/gir-repository-0.6.5/gir' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/accessibility/gir-repository-atk/work/gir-repository-0.6.5' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/accessibility/gir-repository-atk. *** Error code 1 Stop in /usr/ports/x11-toolkits/gir-repository-gtk20. *** Error code 1 Stop in /usr/ports/x11-toolkits/unique. *** Error code 1 Stop in /usr/ports/audio/gnome-media. *** Error code 1 Stop in /usr/ports/x11/gnome2. *** Error code 1 Stop in /usr/ports/x11/gnome2. However: # ls -al /usr/local/bin/g-ir-scanner -r-xr-xr-x 1 root wheel 1385 Feb 12 15:50 /usr/local/bin/g-ir-scanner Looks like you did the Python upgrade? 'grep python /usr/local/bin/g-ir-scanner' and see what it returns. ...and gnomelogalyzer.sh was no help. How do I fix this problem? Have you follow the UPDATING for Python upgrade if it is this problem? In general, when do the major upgrade of Python/Perl/etc. I usually rebuild everything that depend on Python/Perl/etc. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Checksum mismatch for ports/finance/homebank-4.2
On Fri, 26 Feb 2010 00:29:05 -0600, Doug Barton wrote: On Fri, 26 Feb 2010, Ruslan Mahmatkhanov wrote: I've removed all the conversations from homebank author after patch from this PR was commited ). But he is released the new version (4.2.1) after i ask him if distfile was rerolled. Latter he is addmitted that reroll was the bad idea. There is only 4.2.1 and 4.0.2 and past versions: http://homebank.free.fr/public/ Original 4.2 distfile was removed. Since you're in contact with the author, perhaps he could provide a copy of the distfile that matches what's currently in ports? You need to relax... :-) He is author. Therefore, it makes no difference if he released new version or rerolled the tarball. If he said that he rerolled to fix the bug(s) then it's good enough. Same idea with new release version. Cheers, Mezz Doug -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
Why do ports tree have two neon ports?
Why do the ports tree have two neon ports? The neon 0.29 is API and ABI backwards-compatible with 0.28.x and 0.27.x. Have two in the ports tree create a problems when one port want neon28 and another want 0.29 with no reason. Add more than one same libraries in the ports tree is a serious problem for us. I am requesting you to remove neon28 and have all ports to depend on neon29 after the freeze. Thanks, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [freebsd-ports] Pilot error or bash dependencies broken?
On Thu, 18 Mar 2010 09:08:04 -0600, Mike Winter wrote: The problem seems v bad if there is possibility of infinite recursion Show us your make.conf. Cheers, Mezz ===> xorg-vfbserver-1.6.0,1 depends on executable: Xvfb - not found ===>Verifying install for Xvfb in /usr/ports/x11-servers/xorg-vfbserver make: Max recursion level (500) exceeded.: Resource temporarily unavailable *** Error code 2 On Mar 17, 2010, at 1:07 PM, Gary Jennejohn wrote: On Wed, 17 Mar 2010 10:20:37 -0700 Mike Winter wrote: In spirit of a beginner's first question to 'freebsd-ports' please tell me why bash depends on x11? in /etc/make.conf I had WITHOUT_X11=yes and I ended up needing Xvfb. This is confusing to me. I get into a nasty loop of failed dependencies: [snip list of X ports] This is very weird. The only thing which occurs to me is to try making it with WITHOUT_NLS=1 in the command line. --- Gary Jennejohn -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [Call for Testing] X.org 7.5 for FreeBSD
On Thu, 11 Mar 2010 07:44:14 -0600, Martin Wilke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Call for Testing Xorg 7.5 Howdy! We're happy to announce that Xorg 7.5 is ready for public testing. The ATI and Intel drivers were patched to work with the new server, please report any problems to us! The drivers for Vesa, NV and NVIDIA have been tested thoroughfully and seem to work fine. Works very well with GNOME 2.29.x, x11/nvidia-driver and 8-STABLE (i386) so far. It was a clean installation. A note to FreeBSD 6.X users: Unfortunately you'll have to compile gcc 4.2+ first because the X.org Team doesn't support gcc 3.X longer, We're strongly recommand you to update your System to 7.X or above. Please take a look on our Wikipage. There you can find the svn repo to checkout X.org ports. http://wiki.freebsd.org/ModularXorg/7.5 A small merge script to merge the svn checkout into the real portstree could be found here: http://people.freebsd.org/~miwi/xorg/xorgmerge The script is a modified version of the kdemerge script. Please set the KDEDIR variable to the path of your X.org ports. I didn't use this script, which I use marcusmerge. That way I can use the unmerge option. # svn co http://trillian.chruetertee.ch/svn/ports/branches/xorg-dev # find xorg-dev -name .svn | xargs rm -rf (I can edit in marcusmerge for .svn later by copy your script) # sh marcusmerge.sh -m xorg-dev Cheers, Mezz After merging please try portupgrade -af \* portmaster -af Please report any problems and issus to x11 (at) FreeBSD.org. Thanks to beat@, rnoland@, fluffy@ for their help. Happy Updating! - - Martin - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuY860ACgkQdLJIhLHm/OkENgCeOb5NbYlQaYc50Rh+EmWcdhH8 WKgAoJEsl+YcvdTa2KKpiOFuENuW6S6I =HVVi -END PGP SIGNATURE- -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [Call for Testing] X.org 7.5 for FreeBSD
On Sat, 20 Mar 2010 11:47:22 -0600, Torfinn Ingolfsen wrote: Update On Sat, Mar 20, 2010 at 1:26 PM, Gary Jennejohn wrote: Well, I don't know whether this is really relevant, but I noticed that xfce4-session actually depends on dbus-glib and not dbus. It might be necessary to reinstall dbus-glib with DBUS_DISABLE_CHECKS set. This is easily done by modifying devel/dbus-glib/Makefile to set --enable-checks=no at line 320. Ok, I tried that too. Sadly, it had no effect. xfce4-session core dumps as before with this option set for dbus-glib. Yes, I restarted dbus after reinstalling this port. Of course, this is just a hack and doesn't fix the real problem and we're probably all getting tired of this thread :) Possibly, but I'm willing to try a few suggestions more. It would be nice if it worked. Looks like it's a known issue in the Linux world too. http://bugzilla.xfce.org/show_bug.cgi?id=5966 Try to change the theme to default. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: commit PR ports/146582: [PATCH]textproc/libxml2
On Wed, 23 Jun 2010 02:11:49 -0500, Alexander Kriventsov wrote: On 22.06.2010 19:11, Chris Rees wrote: On 22 June 2010 15:21, Alexander Kriventsov wrote: Hello! Can anybody commit this http://www.freebsd.org/cgi/query-pr.cgi?pr=146582? You need to ask the Gnome team to approve it first. How can I do this? They didn't send any replay from May 14. Is it possible to commit with reason like 'maintainer timeout'? This PR is only add option that allow to configure libxml without threads which is enable by default. The PORTREVISION is not need. I will check w/ your PR later. Cheers, Mezz Chris -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: transmission 1.93 update
On Fri, 25 Jun 2010 16:12:54 -0500, Anonymous wrote: "Dutchman01" writes: Hi, Any plans to upgrade transmission 1.93 to 2.0 version in the freebsd tree? When it's ready. Better ask mezz@, I'm not the maintainer. If you're that impatient try my patch below. Thanks for patch. I have 2.0 ready available in my machine since the first day. I am not commit it until after FreeBSD 8.1 released. I might want to wait until 2.1 as I can see a few noticeable bugs that are fixed in SVN, but I don't know. I will see. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: transmission 1.93 update
On Sat, 26 Jun 2010 15:45:35 -0500, Sam Fourman Jr. wrote: On Sat, Jun 26, 2010 at 6:25 PM, Jeremy Messenger wrote: On Fri, 25 Jun 2010 16:12:54 -0500, Anonymous wrote: "Dutchman01" writes: Hi, Any plans to upgrade transmission 1.93 to 2.0 version in the freebsd tree? When it's ready. Better ask mezz@, I'm not the maintainer. If you're that impatient try my patch below. Thanks for patch. I have 2.0 ready available in my machine since the first day. I am not commit it until after FreeBSD 8.1 released. I might want to wait until 2.1 as I can see a few noticeable bugs that are fixed in SVN, but I don't know. I will see. Cheers, Mezz I would like to run transmission 2.0, would you mind posting a patch? Sure, here: http://people.freebsd.org/~mezz/diff/transmission201.diff Cheers, Mezz Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: -- SPAM -- Re: transmission 1.93 update
On Sun, 27 Jun 2010 05:16:15 -0500, Anonymous wrote: "Jeremy Messenger" writes: On Sat, 26 Jun 2010 15:45:35 -0500, Sam Fourman Jr. wrote: I would like to run transmission 2.0, would you mind posting a patch? Sure, here: http://people.freebsd.org/~mezz/diff/transmission201.diff How about switching to USE_XZ? It decompresses faster on slow machines. Sure, I have changed it to xz in my machine. Cheers, Mezz bzip2 -dc /b/dist/transmission-2.01.tar.bz2 > /dev/null 5.12s user 0.13s system 86% cpu 6.057 total xz -dc /b/dist/transmission-2.01.tar.xz > /dev/null 0.99s user 0.16s system 86% cpu 1.330 total -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: gimp-2.6.9,2
On Wed, 07 Jul 2010 22:01:18 -0500, Frank A. Greco wrote: HI, I'm running 8.0-RELEASE, amd64. The port installs fine as a package but when I try to run gimp I get an error message that gegl 0.1.2 needs to be updated to gegl 0.0.18. The description of the port says that gegl 0.1.2 is required, so I suspect that the problem is that app/sanity.c didn't get updated. Whether that's the problem or not, any help would be appreciated. Thanks. I can't reproduce your problem. Do you have more than one gegl installed? Maybe somehow old gegl files are still left in your system? Show us the outputs of this: # pkg_info -IX gegl # ldconfig -r | grep gegl # find /usr/local/lib -name \*gegl\* Cheers, Mezz Frank Greco -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
www/linux-opera 10.60 patch...
Hello all, A few of you have asked me about patch of linux-opera update to 10.60. Here: http://people.freebsd.org/~mezz/diff/linux-opera1060.diff The flash plugin 10.1 has an issue of sometimes the mouse click does not work. I am not sure if it's Opera 10.60 or flash plugin 10.1 issue as I haven't dig deeper in it yet. Anyone is welcome to figure on this bug if you don't want to wait. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
Changed mezz's email address..
Hello all, Just let every one know about that I have changed my email address from me...@cox.net to mezz.free...@gmail.com. Be sure to update your contact/address book list. If you have m...@freebsd.org then you don't have to do anything as it will go straight to my new address. The reason is to use IMAP for free from gmail. Easier for me to check my email in anywhere such as my cell phone (android) and etc. Also, Cox's email gets down too many times compare to other email services. As for the old address, I will keep it for a week or so before I kill it. My me...@cox.net is down for two days by now, so be patient and I will reply back when it's up again. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: www/linux-opera 10.60 patch...
On Thu, 15 Jul 2010 02:46:11 -0500, Gary Jennejohn
wrote:
On Wed, 14 Jul 2010 17:10:57 -0500
"Jeremy Messenger" wrote:
Hello all,
A few of you have asked me about patch of linux-opera update to 10.60.
Here: http://people.freebsd.org/~mezz/diff/linux-opera1060.diff
The flash plugin 10.1 has an issue of sometimes the mouse click does not
work. I am not sure if it's Opera 10.60 or flash plugin 10.1 issue as I
haven't dig deeper in it yet. Anyone is welcome to figure on this bug if
you don't want to wait.
I installed 10.60 last week directly from the tarball.
Things I've noticed
1) linux: pid 2334 (opera): ioctl fd=5, cmd=0x8910 ('‰',16) is not
implemented - haven't checked just exacly what this ioctl does
Yeah, I get that too. A more line:
ioctl fd=17, cmd=0x8b01 ('',1) is not implemented
The 0x8910 is SIOCGIFNAME and 0x8b01 is SIOCGIWNAME in Linux's ioctl. I
don't think FreeBSD has those. Someone in emulation@ (add in CC) might
knows more about it. Even if someone want to create patch for it.
2) operapluginwrapper dumps core quite frequently, but that also happened
with the older linux-opera too
Known issue for very long time. Don't know why and don't know how to do
backtraces with linux binary in FreeBSD.
I haven't noticed any problems with flash.
No click issue? in Hulu? I only tested flash in hulu.com.
Cheers,
Mezz
--
Gary Jennejohn
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: transmission-daemon-2.04_1
2010/10/21 Вадим Петряев : > Hello! > > > > Transmission was two times released after version 2.04 > https://trac.transmissionbt.com/roadmap?show=completed > > 10 October released 2.10 and 17 October released 2.11 > > May be you need some help for port maintenance? > > As I understand, this port require only one patch changes - because patched > libtransmission/fdlimit.c changed. I am not commit the update yet. Transmission have a bad history of release version that isn't stable enough as you can see they already have 2.11 in a very short peroid. I am able to reproduce a few of problems in 2.10 and 2.11. The 2.12 might be released sometimes soon (just a guess), so I will see how it goes. Cheers, Mezz > Good luck, Vadim -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: transmission-daemon-2.04_1
On Sun, Oct 24, 2010 at 12:51 AM, Anonymous wrote: > Jeremy Messenger writes: > >> 2010/10/21 Вадим Петряев : >>> Transmission was two times released after version 2.04 >>> https://trac.transmissionbt.com/roadmap?show=completed >>> >>> 10 October released 2.10 and 17 October released 2.11 >>> >>> May be you need some help for port maintenance? >>> >>> As I understand, this port require only one patch changes - because patched >>> libtransmission/fdlimit.c changed. >> >> I am not commit the update yet. Transmission have a bad history of >> release version that isn't stable enough as you can see they already >> have 2.11 in a very short peroid. I am able to reproduce a few of >> problems in 2.10 and 2.11. The 2.12 might be released sometimes soon >> (just a guess), so I will see how it goes. > > FYI, 2.04 is not bug-free either > > $ transmission-remote myhost -a http://foo/bar.torrent > myhost:9091 responded: "http error 0: No Response" A very minor and acceptable bug. > By waiting you're just trading one bunch of bugs for another. ;\ Trade to version one that crash? I don't think so. ;-) The 2.12 in SVN seems to have fixed all crashes. The 2.10 was worst compared to 2.11 though. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
security/ocaml-cryptokit: Move back in ${LOCALBASE}/lib/ocaml/.
Can you move security/ocaml-cryptokit's files from lib/ocaml/site-lib/ back to lib/ocaml/? It's what default in the original Makefile. /work/cryptokit-1.3/Makefile: --- [...] # Where to install the library. By default: OCaml's standard library directory. INSTALLDIR=`$(OCAMLC) -where` [...] OCAMLC=ocamlc -g [...] install: cp cryptokit.cmi cryptokit.cma cryptokit.mli $(INSTALLDIR) cp libcryptokit.a $(INSTALLDIR) [...] --- # ocamlc -g -where /usr/local/lib/ocaml The reason why I am requesting you is that I had to hack a many files and I have two binaries (can't access to its source codes). Any of ports need to follow the original as much as possible or the rest of other libraries/applications have to be created many patches because of our port is lacking follow upstream. I can create a patch if you want me to. Thanks, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
graphics/ocaml-images: Fix the path in the ld.conf (OCAML_LDCONFIG).
When I build a few of ocaml ports and I always noticed that I get this warning:
ocamlfind: [WARNING] Cannot read directory
/usr/local/lib/ocaml/site-lib/images which is mentioned in ld.conf
Decided to dig it in and found a problem.
# grep site-lib/images /var/db/pkg/ocaml-images-3.0.2_7,2/+CONTENTS
@exec echo %D/lib/ocaml/site-lib/images >> %D/lib/ocaml/ld.conf
@unexec /usr/bin/sed -i "" -e '/lib\/ocaml\/site-lib\/images/d'
%D/lib/ocaml/ld.conf
# ls /usr/local/lib/ocaml/site-lib/ | grep images
camlimages/
There is no /usr/local/lib/ocaml/site-lib/images and the correct path
is /usr/local/lib/ocaml/site-lib/camlimages. A simple fix is to add
OCAML_LDLIBS=${OCAML_SITELIBDIR}/${OCAML_PKGDIRS} under the
OCAML_PKGDIRS. Now the result is correct and I don't get any of
warning.
# grep ld\.conf /var/db/pkg/ocaml-images-3.0.2_7,2/+CONTENTS
@exec echo %D/lib/ocaml/site-lib/camlimages >> %D/lib/ocaml/ld.conf
@unexec /usr/bin/sed -i "" -e '/lib\/ocaml\/site-lib\/camlimages/d'
%D/lib/ocaml/ld.conf
May I commit it to add the
OCAML_LDLIBS=${OCAML_SITELIBDIR}/${OCAML_PKGDIRS} and bump the
PORTREVISION?
Thanks,
Mezz
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: libtool question again
On Wed, Mar 7, 2012 at 3:42 AM, Alex Dupre wrote: > Roman Bogorodskiy wrote: >>> USE_AUTOTOOLS= libtool >>> USE_GNOME= ltverhack >>> >>> to avoid bumping. >> >> I'm using it and it doesn't help: libgnutls.so.47 becomes >> libgnutls.so.48 (where 48 is 'current'). > > Probably you have not set LIBTOOLFILES to include all the 'configure' > scripts. Yep, that's correct. The gnutls has more than one configure, so its Makefile will need to set it to this: LIBTOOLFILES= configure lib/configure libextra/configure Cheers, Mezz > In any case, a bump will be necessary, because the shared version number > will decrease, but at least it won't be necessary next times. > > -- > Alex Dupre -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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"
lang/lua: It does need gmake.
I get a build failure on amd64: - /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value *** Error code 1 - I got it fixed by add USE_GMAKE=yes in the Makefile and now I can get it built ok. If you compare the build log between make and gmake. You will see it has different output. This http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/162279 has broken it. May I commit it by add USE_GMAKE=yes back in? Thanks, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: lang/lua: It does need gmake.
On Thu, Mar 15, 2012 at 4:14 PM, Niclas Zeising wrote: > On 2012-03-15 20:50, Jeremy Messenger wrote: >> I get a build failure on amd64: >> >> - >> /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' >> can not be used when making a shared object; recompile with -fPIC >> lapi.o: could not read symbols: Bad value >> *** Error code 1 >> - >> >> I got it fixed by add USE_GMAKE=yes in the Makefile and now I can get >> it built ok. If you compare the build log between make and gmake. You >> will see it has different output. This >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/162279 has broken it. >> >> May I commit it by add USE_GMAKE=yes back in? >> >> Thanks, >> Mezz >> >> > > Hi! > I can't reproduce the error. I just tried and succeeded in compiling and > linking lua on a x86_64 virtual machine. Figured out. Add custom CFLAGS in the make.conf and you will get a build failure with make but not gmake. Here's what I have in my make.conf: CFLAGS= -O2 -fno-strict-aliasing -pipe -g STRIP= Cheers, Mezz > The md5 sum of liblua-5.1.so.1 is also the same, regardless of using > make or gmake. > Regards! > -- > Niclas -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: lang/lua: It does need gmake.
On Thu, Mar 15, 2012 at 6:23 PM, Chuck Swiger wrote: > On Mar 15, 2012, at 4:18 PM, Jeremy Messenger wrote: >> Figured out. Add custom CFLAGS in the make.conf and you will get a >> build failure with make but not gmake. Here's what I have in my >> make.conf: >> >> CFLAGS= -O2 -fno-strict-aliasing -pipe -g >> STRIP= > > Does it work properly if you use "CFLAGS+=" instead? It will, but you do not need to put '+' in make.conf. I have same CFLAGS for years and years, btw. Cheers, Mezz > Regards, > -- > -Chuck -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: lang/lua: It does need gmake.
On Fri, Mar 16, 2012 at 5:49 AM, b. f. wrote: > Jeremy Messenger wrote: >> On Thu, Mar 15, 2012 at 6:23 PM, Chuck Swiger wrote: >> > On Mar 15, 2012, at 4:18 PM, Jeremy Messenger wrote: >> >> Figured out. Add custom CFLAGS in the make.conf and you will get a >> >> build failure with make but not gmake. Here's what I have in my >> >> make.conf: >> >> >> >> CFLAGS= -O2 -fno-strict-aliasing -pipe -g >> >> STRIP= >> > >> > Does it work properly if you use "CFLAGS+=" instead? >> >> It will, but you do not need to put '+' in make.conf. I have same >> CFLAGS for years and years, btw. > > If you have been making these assignments unconditionally, then for > years and years you have been in danger of breaking or damaging the > builds for many ports that explicitly invoke make(1) more than once > (and thus read make.conf more than once), by clobbering prior changes > to CFLAGS or STRIP that are made in port makefiles. Despite the > misleading examples in the base-system example make.conf, this kind of > customization is not supported for Ports, and not encouraged. You > should take steps to ensure that your custom values are set only once, > before any top-level port Makefile is parsed. You can define them > conditionally, or move them to another makefile that is included only > once, or disable multiple inclusions of make.conf for Ports by using > something like "__MAKE_CONF=/dev/null" in the right place. Any ports have to respect the CFLAGS, see the porter handbook. If it fails to do then it needs to be fixed. Add '+' in the make.conf is not right way to do it as it's merely add in exists CFLAGS. mandree, thanks for took care of it! Cheers, Mezz > b. -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: new port request
On Mon, Mar 26, 2012 at 1:56 PM, AN wrote: > I would like to request the following app be added to the ports tree. I am > not a developer or I would try to do it myself. > > Packet Tracer Version 5.3.3 > > > It is a Cisco application that is very helpful for learning networking, and > studying for Cisco exams. It would be a useful tool to have on FreeBSD. > Thanks in advance to anyone who may work on this. http://www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html "The Packet Tracer software is available free of charge ONLY to Networking Academy instructors, students, alumni, and administrators that are registered Academy Connection users. To Download Packet Tracer: •Log in to Academy Connection (you must be a registered Networking Academy student, alumni, instructor, or administrator)" -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: port dependencies with port options
On Fri, Apr 20, 2012 at 5:29 AM, Vitaly Magerya wrote: > Chris Inacio wrote: >> I wanted to add an option to multiple ports - that is easy. But, those >> ports have a dependency relationship, and I only want the last node in the >> port dependency graph to build with that option if the requisite ports have >> too. >> >> In real terms: >> >> net/spread <- net/libfixbuf <- net-mgmt/yaf >> >> I added a SPREAD option to net/libfixbuf & to net-mgmt/yaf. net-mgmt/yaf >> can only build a Spread version if libfixbuf was built with a Spread >> version. >> >> Question 1) How do you construct such that if a user goes into >> net-mgmt/yaf chooses Spread and fixbuf isn't already installed, it builds >> fixbuf with the spread option? >> >> Question 2) How do you ensure that if fixbuf is already installed, it has >> the Spread option enabled, or disallow/error the Yaf Spread option? > > One way to do this is to create a separate port net/libfixbuf-spread > that either installs separate libfixbuf-spread.so or just conflicts with > net/libfixbuf, and then make net-mgmt/yaf depend on that if SPREAD > option is on. Please do not create a split port that will end up conflict with the each others. It creates more problems rather than solve. Either split port without have conflict to the each others or enable SPREAD by default. If enable by default then add a check error if libfixbuf-spread.so does not exist then give user a head up to enable SPREAD back on. Split port without conflict is always best opinion, but if it's complicate to do it then do the enable SPREAD by default instead. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: port dependencies with port options
On Fri, Apr 20, 2012 at 10:52 AM, Chris Inacio wrote: > > > On Fri, Apr 20, 2012 at 11:36 AM, Jeremy Messenger > wrote: >> >> On Fri, Apr 20, 2012 at 5:29 AM, Vitaly Magerya >> wrote: >> > Chris Inacio wrote: >> >> I wanted to add an option to multiple ports - that is easy. But, those >> >> ports have a dependency relationship, and I only want the last node in >> >> the >> >> port dependency graph to build with that option if the requisite ports >> >> have >> >> too. >> >> >> >> In real terms: >> >> >> >> net/spread <- net/libfixbuf <- net-mgmt/yaf >> >> >> >> I added a SPREAD option to net/libfixbuf & to net-mgmt/yaf. >> >> net-mgmt/yaf >> >> can only build a Spread version if libfixbuf was built with a Spread >> >> version. >> >> >> >> Question 1) How do you construct such that if a user goes into >> >> net-mgmt/yaf chooses Spread and fixbuf isn't already installed, it >> >> builds >> >> fixbuf with the spread option? >> >> >> >> Question 2) How do you ensure that if fixbuf is already installed, it >> >> has >> >> the Spread option enabled, or disallow/error the Yaf Spread option? >> > >> > One way to do this is to create a separate port net/libfixbuf-spread >> > that either installs separate libfixbuf-spread.so or just conflicts with >> > net/libfixbuf, and then make net-mgmt/yaf depend on that if SPREAD >> > option is on. >> >> Please do not create a split port that will end up conflict with the >> each others. It creates more problems rather than solve. >> >> Either split port without have conflict to the each others or enable >> SPREAD by default. If enable by default then add a check error if >> libfixbuf-spread.so does not exist then give user a head up to enable >> SPREAD back on. >> >> Split port without conflict is always best opinion, but if it's >> complicate to do it then do the enable SPREAD by default instead. >> >> Cheers, >> Mezz >> >> > > So let me see if I understand the conversation so far correctly: > > (*) If I want to detect it, then I would need something like a new library > name output from from fixbuf based on the build. (This currently doesn't > exist.) I don't have access to FreeBSD and CVS too due to firewall at work, but if it doesn't has seperate library. I do not recommend to rename the library and go with enable option by default instead. If the spread is very small and doesn't has tons of dependency, you can even have libfixbuf depends on spread by default without provide option to turn off/on. Simple. Cheers, Mezz > (*) I could do some split port, but (even being a noob) sounds pretty bad. > > (*) There isn't a current method that directly queries build options from > one port to another. > > Am I capturing current state? > > 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: FreeBSD Port: transmission-daemon-2.04_1
I will update it to 2.12 in this week. Cheers, Mezz On Oct 22, 2010 8:15 PM, "Jeremy Messenger" wrote: > 2010/10/21 Вадим Петряев : >> Hello! >> >> >> >> Transmission was two times released after version 2.04 >> https://trac.transmissionbt.com/roadmap?show=completed >> >> 10 October released 2.10 and 17 October released 2.11 >> >> May be you need some help for port maintenance? >> >> As I understand, this port require only one patch changes - because patched >> libtransmission/fdlimit.c changed. > > I am not commit the update yet. Transmission have a bad history of > release version that isn't stable enough as you can see they already > have 2.11 in a very short peroid. I am able to reproduce a few of > problems in 2.10 and 2.11. The 2.12 might be released sometimes soon > (just a guess), so I will see how it goes. > > Cheers, > Mezz > >> Good luck, Vadim > > > -- > mezz.free...@gmail.com - m...@freebsd.org > FreeBSD GNOME Team > http://www.FreeBSD.org/gnome/ - gn...@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: libksba update broken
On Thu, Dec 16, 2010 at 10:07 AM, Greg Larkin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > David Demelier wrote: >> On 16/12/2010 16:44, Greg Larkin wrote: >> David Demelier wrote: > Hello, > > gnupg and libksba are not installed : > > ===> Verifying install for ksba.17 in /usr/ports/security/libksba > ===> Returning to build of gnupg-2.0.16_3 > Error: shared library "ksba.17" does not exist > *** Error code 1 > > Stop in /usr/ports/security/gnupg. > *** Error code 1 > > Stop in /usr/ports/security/gnupg. > >> >> Hi David, >> >> Please update your ports tree and try it again. I committed the fix an >> hour or so ago, so it's possible that portsnap will take a little while >> to create its update package. >> >> Thank you, >> Greg >>> > >> Oh you were faster than me! ignore my patch and thanks for the work :-) > >> Best regards, > >> David. > > Hi David, > > Thank you for your help, and I also committed a new entry to UPDATING to > assist everyone with the port upgrading process: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/UPDATING.diff?r1=1.1010;r2=1.1011 In the next version or next shared library bump, can you following add this? USE_AUTOTOOLS= libtool USE_GNOME= ltverhack It will fix libtool bug and that way it won't bump the shared library version with no reason. There is no ABI break between 1.0.8 and 1.1.0. With the add of two lines, looks like this: 1.0.8: --- @@ -3,5 +3,5 @@ lib/libksba.a lib/libksba.la lib/libksba.so -lib/libksba.so.17 +lib/libksba.so.8 share/aclocal/ksba.m4 --- 1.1.0: --- @@ -3,5 +3,5 @@ lib/libksba.a lib/libksba.la lib/libksba.so -lib/libksba.so.18 +lib/libksba.so.8 share/aclocal/ksba.m4 --- Cheers, Mezz > Thank you, > Greg > - -- > Greg Larkin > > http://www.FreeBSD.org/ - The Power To Serve > http://www.sourcehosting.net/ - Ready. Set. Code. > http://twitter.com/sourcehosting/ - Follow me, follow you > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFNCjk30sRouByUApARAvE/AJ9tIF6VfmOcGteVJI0wmNKvDKA2NwCeO4Km > +yifSf77kOSO7rnmeUgl9Cs= > =UU+N > -END PGP SIGNATURE- -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: libksba update broken
On Mon, Dec 20, 2010 at 4:40 PM, Greg Larkin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jeremy Messenger wrote: >>> In the next version or next shared library bump, can you following add this? >> >>> USE_AUTOTOOLS= libtool >>> USE_GNOME= ltverhack >> >>> It will fix libtool bug and that way it won't bump the shared library >>> version with no reason. There is no ABI break between 1.0.8 and 1.1.0. >>> With the add of two lines, looks like this: >> >>> 1.0.8: >>> --- >>> @@ -3,5 +3,5 @@ >>> lib/libksba.a >>> lib/libksba.la >>> lib/libksba.so >>> -lib/libksba.so.17 >>> +lib/libksba.so.8 >>> share/aclocal/ksba.m4 >>> --- >> >>> 1.1.0: >>> --- >>> @@ -3,5 +3,5 @@ >>> lib/libksba.a >>> lib/libksba.la >>> lib/libksba.so >>> -lib/libksba.so.18 >>> +lib/libksba.so.8 >>> share/aclocal/ksba.m4 >>> --- >> >>> Cheers, >>> Mezz >> > > Hi Mezz, > > Thanks very much for that tip, and I'll make a note of it for the next > release. I wasn't aware of ltverhack, but it looks like a great idea > for this port! No problem. For anyone that want to learn more about libtool issue. jylefort (left FreeBSD) has discovered an issue with libtool. Here's his comments in IRC back in Aug 2005: it might be that libtool is incorrectly numbering libraries, on FreeBSD freebsd-elf) major=".$current" linux) major=.`expr $current - $age` this means that on FreeBSD, the library major number will be increased even if the ABI is preserved I wonder why they thought FreeBSD would be different. i wonder, too i'll do some calculations using gtk20 as reference LT_VERSION_INFO = 600:9:600 that's what gtk+ 2.6.9 passes as -version-info on linux, it results in 600 - 600 = gtk-2.0.so.0 on FreeBSD, it results as 600 = gtk-2.0.so.600 this makes me think that ltmain.sh should be fixed I agree. we might want to change ltverhack to fix ltmain.sh Cheers, Mezz > Thank you, > Greg > - -- > Greg Larkin > > http://www.FreeBSD.org/ - The Power To Serve > http://www.sourcehosting.net/ - Ready. Set. Code. > http://twitter.com/sourcehosting/ - Follow me, follow you > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFND9t20sRouByUApARAqmDAJ97jFiTFqPSglTYsQC2VNJ+qLhukACfUOi4 > H2mHHrP6KQ72eDFv/x8sFOI= > =exg8 > -END PGP SIGNATURE- -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: transmission-2.22
On Sun, Mar 6, 2011 at 6:22 AM, Grzegorz Blach wrote: > On 03/06/2011 12:55, David Demelier wrote: >> On 06/03/2011 07:21, Ruslan Mahmatkhanov wrote: >>> 06.03.2011 05:18, Alex V. Petrov пишет: FreeBSD alex.super 8.2-STABLE FreeBSD 8.2-STABLE #116: Thu Mar 3 21:55:50 KRAT 2011 alex@alex.super:/usr/obj/usr/src/sys/ALEX amd64 transmission-2.13< needs updating (port has 2.22) transmission-cli-2.13< needs updating (port has 2.22) transmission-daemon-2.13< needs updating (port has 2.22) transmission-gtk2-2.13< needs updating (port has 2.22) #portmaster -aD [skip] ../libtransmission/libtransmission.a(handshake.o) (.text+0x16d9):/usr/ports/net-p2p/transmission- cli/work/transmission-2.22/libtransmission/handshake.c:610: undefined reference to `evbuffer_get_length' ../libtransmission/libtransmission.a(handshake.o) (.text+0x1714):/usr/ports/net-p2p/transmission- cli/work/transmission-2.22/libtransmission/handshake.c:759: more undefined references to `evbuffer_get_length' follow gmake[1]: *** [transmission-create] Ошибка 1 gmake[1]: Leaving directory `/usr/ports/net-p2p/transmission- cli/work/transmission-2.22/utils' gmake: *** [all-recursive] Ошибка 1 *** Error code 1 Stop in /usr/ports/net-p2p/transmission-cli. ===>>> make failed for net-p2p/transmission-cli ===>>> Aborting update ===>>> Update for net-p2p/transmission-cli failed ===>>> Aborting update - Alex V. Petrov >>> >>> You should deinstall libevent first. >>> >> >> Why this is not in ports/UPDATING then? :-( >> > > Because, probably it's not a good solution. Correct. There is bug in libevent2's libevent*.pc. I have submitted a patch in PR to fix it. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155315 Cheers, Mezz > I'm useing memcached witch need libevent to work. > So removing libevent, will broke memcached :-( -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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-p2p/transmission-gtk2 fails to build
On Sat, Mar 5, 2011 at 10:03 AM, Ruslan Mahmatkhanov wrote:
> 05.03.2011 17:29, Anonymous пишет:
>>
>> Ruslan Mahmatkhanov writes:
>>
>>> Hi!
>>>
>>> I'm trying to update transmission 2.13 -> 2.22 on 8-stable.
>>>
>>> Errors like this:
>>> ../libtransmission/libtransmission.a(handshake.o)(.text+0x167d): In
>>> function `canRead':
>>>
>>> /usr/ports/net-p2p/transmission-gtk2/work/transmission-2.22/libtransmission/handshake.c:789:
>>> undefined reference to `evbuffer_search'
>>>
>>> ../libtransmission/libtransmission.a(handshake.o)(.text+0x16d4):/usr/ports/net-p2p/transmission-gtk2/work/transmission-2.22/libtransmission/handshake.c:761:
>>> undefined reference to `evbuffer_get_length'
>>>
>>> Full build log is here:
>>> http://pastebin.com/k0ZWLj3J
>>
>> Probably a remnant from before libevent used PKG_CHECK_MODULES().
>> -L${LOCALBASE}/lib precedes -L${LOCALBASE}/lib/event2 during linking,
>> build with V=1 or -Wl,--verbose to see.
>>
>> %%
>> Index: net-p2p/transmission-cli/Makefile
>> ===
>> RCS file: /a/.cvsup/ports/net-p2p/transmission-cli/Makefile,v
>> retrieving revision 1.74
>> diff -u -p -r1.74 Makefile
>> --- net-p2p/transmission-cli/Makefile 5 Mar 2011 04:17:28 -
>> 1.74
>> +++ net-p2p/transmission-cli/Makefile 5 Mar 2011 14:09:06 -
>> @@ -28,8 +28,6 @@ USE_GMAKE= yes
>> USE_GNOME?= pkgconfig
>> USE_OPENSSL= yes
>> GNU_CONFIGURE= yes
>> -CPPFLAGS= -I${LOCALBASE}/include
>> -LDFLAGS= -L${LOCALBASE}/lib
>> CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}"
>> CONFIGURE_ARGS=--with-zlib=/usr \
>> --disable-libappindicator \
>> %%
>
> No, this patch doesn't help. But removing libevent-1.4.14b_2 does, while
> keeping libevent2-2.0.10.
There is bug in libevent2's libevent*.pc. I have submitted a patch in
PR to fix it.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155315
Cheers,
Mezz
> There is also discussion about that in gnome@. Thanks.
>
> --
> Regards,
> Ruslan
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: [HEADS UP] GNU make 3.82
On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are
> a number of rather unfortunate backwards incompatibility issues between this
> and 3.81 which makes a simple replacement unworkable.
>
> A new port, devel/gmake381 has just been committed to the tree which is a
> heavily stripped down 3.81 version (just the binary, installed as
> ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked
> IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly
> in any way, shape or form.
>
> The next steps are as follows:
>
> 1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching
> devel/gmake381 to the build, and extending the USE_GMAKE variable so that a
> value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use
> the older 3.81
>
> 2. -exp runs will be iterated over to determine which ports break building
> with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue
> to build. A list of such ports will be maintained and posted.
>
> 3. devel/gmake381 will then be marked DEPRECATED with a suitable
> EXPIRATION_DATE (at least 6 months), at which point it will be removed, and
> the USE_GMAKE=381 logic also reverted, so that everything will go back to
> using devel/gmake. Note: it will not be necessary to edit individual port
> Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to
> see if the variable is defined. This will provide for ease of use (grep -R
> USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact
> that they'll most likely be broken in weird and interesting ways.
>
> A followup posting will occur as and when steps (1) and (2) have been
> completed.
You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
fixed those ports to build with gmake 3.82.
Cheers,
Mezz
> -aDe
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: [HEADS UP] GNU make 3.82
On Sat, Mar 12, 2011 at 11:48 AM, Jeremy Messenger
wrote:
> On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett wrote:
>> Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are
>> a number of rather unfortunate backwards incompatibility issues between this
>> and 3.81 which makes a simple replacement unworkable.
>>
>> A new port, devel/gmake381 has just been committed to the tree which is a
>> heavily stripped down 3.81 version (just the binary, installed as
>> ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked
>> IGNORE and is NOT attached to devel/Makefile. Please do NOT use it
>> directly in any way, shape or form.
>>
>> The next steps are as follows:
>>
>> 1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching
>> devel/gmake381 to the build, and extending the USE_GMAKE variable so that a
>> value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will
>> use the older 3.81
>>
>> 2. -exp runs will be iterated over to determine which ports break building
>> with 3.82, and they will be marked as USE_GMAKE=381 to allow them to
>> continue to build. A list of such ports will be maintained and posted.
>>
>> 3. devel/gmake381 will then be marked DEPRECATED with a suitable
>> EXPIRATION_DATE (at least 6 months), at which point it will be removed, and
>> the USE_GMAKE=381 logic also reverted, so that everything will go back to
>> using devel/gmake. Note: it will not be necessary to edit individual port
>> Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to
>> see if the variable is defined. This will provide for ease of use (grep -R
>> USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact
>> that they'll most likely be broken in weird and interesting ways.
>>
>> A followup posting will occur as and when steps (1) and (2) have been
>> completed.
>
> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.
...and audio/portaudio .
> Cheers,
> Mezz
>
>> -aDe
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: prelminary analysis of the gmake3.82 -exp run
On Thu, Mar 10, 2011 at 8:16 PM, Mark Linimon wrote: > I recent did a first-pass experimental ports run with gmake3.82. The > results from that were pretty bad: 38 confirmed errors (5 more possible), > with ~1100 ports as collateral damage, mostly from audio/portaudio and > devel/p5-Module-Build. Don't know anything about Perl ports stuff, so I have skipped it. Committed a fix in audio/portaudio and two other ports below. > After a brief discussion among the portmgrs, we decided to make another > run with some patches (see http://www.freebsd.org/cgi/query-pr.cgi?pr=155215) > to try to narrow down the collateral damage, before notifying individual > maintainers. However, here's the information for those that want to get > a head start on doing the work. > > Note that the new 'gmake' error classification has been added to the results; > OTOH, many regressions will be classified as 'makefile'. It depends on how, > exactly, the build failure occurred. > > mcl > > - Forwarded message from Mark Linimon - > > Date: Sat, 5 Mar 2011 20:49:28 -0600 > From: Mark Linimon > To: a...@freebsd.org > Cc: port...@freebsd.org > Subject: prelminary analysis of gmake -exp run > User-Agent: Mutt/1.5.20 (2009-06-14) > > http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.20110304064411.pointyhat-west/index-category.html > > definitely gmake: > > audio/portaudio > devel/ORBit > irc/xchat-gnome Done with three ports here. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Fwd: prelminary analysis of the gmake3.82 -exp run
On Sun, Mar 13, 2011 at 6:06 AM, Mark Linimon wrote:
> On Sun, Mar 13, 2011 at 11:39:26AM +0100, Ulrich Spörlein wrote:
>> Augmented with a crude estimate of ports affected by these breakages
>> (via grepping INDEX, basically).
>
> With a little detective work, you can get that from pointyhat. e.g.
> the "Aff." ("Affects") column in
>
> http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-8-exp-latest/
>
>> I couldn't find a link to the actual gmake-3.82 update patch. How do
>> people actually test their changes?
>
> It's in the PR, ports/155215:
>
> http://tinderbox.lovett.com/patches/gmake-20110310.diff
Or see here: http://lists.freebsd.org/pipermail/cvs-ports/2011-March/213529.html
I know that my steps was incorrect on 'cp' part, but I am sure that
everyone can figure it out. ;-)
Cheers,
Mezz
> mcl
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: webkit-gtk2-1.2.7 doesn't upgrade after changing python to 2.7
On Mon, Mar 14, 2011 at 11:26 AM, Gritsuk Anton wrote: > HI! > > Now i'm using FreeBSD 8.2 (r219048): > # uname -srm > FreeBSD 8.2-STABLE i386 > > I upgraded and replaced my Python 2.6 to 2.7 and all packages is related of > this. I use instruction from /usr/ports/UPDATING: > # portupgrade -o lang/python27 lang/python26 > # cd /usr/ports/lang/python && make upgrade-site-packages > > After this update, installation/upgading of webkit-gtk2 is failed. > > Let's see: > > # portupgrade webkit-gtk2-1.2.7 > ... > CCLD Programs/unittests/testhttpbackend > CCLD Programs/unittests/testloading > CCLD Programs/unittests/testglobals > CCLD Programs/unittests/testmimehandling > CCLD Programs/unittests/testnetworkrequest > CCLD Programs/unittests/testnetworkresponse > CCLD Programs/unittests/testwebframe > CCLD Programs/unittests/testwebbackforwardlist > CCLD Programs/unittests/testwebhistoryitem > CCLD Programs/unittests/testwindow > CCLD Programs/unittests/testdownload > CCLD Programs/unittests/testatk > CCLD Programs/unittests/testhittestresult > CCLD Programs/unittests/testwebsettings > CCLD Programs/unittests/testwebresource > CCLD Programs/unittests/testwebdatasource > CCLD Programs/unittests/testwebview > CCLD Programs/unittests/testkeyevents > GEN WebKit-1.0.gir > /usr/local/bin/g-ir-scanner: not found > gmake[1]:*** [WebKit-1.0.gir] ??127 > gmake[1]:*** ?? ???... > gmake[1]: Leaving directory `/usr/ports/www/webkit-gtk2/work/webkit-1.2.7' > gmake:*** [all] ??2 > ** Command failed[exit code 1]: /usr/bin/script -qa > /tmp/portupgrade20110313-72168-1mkl71b-0 env UPGRADE_TOOL=portupgrade > UPGRADE_PORT=webkit-gtk2-1.2.7 UPGRADE_PORT_VER=1.2.7 make > ** Fix the problem and try again. > ** Listing the failed packages (-:ignored/ *:skipped/ !:failed) > ! www/webkit-gtk2 (webkit-gtk2-1.2.7) (unknown build error) > > > If I replace first string in /usr/local/bin/g-ir-scanner: > #!/usr/local/bin/python2.6 to #!/usr/local/bin/python2.7 Reinstall gobject-introspection is a best solution. I don't follow the UPDATING complete about Python upgrade, which I just follow on -o part then did the portmaster -r python27-2.7.1_1. I did it because I know that it will work a lot better than upgrade-site-packages by 99%. The shortcut usually bite. Cheers, Mezz > my upgrade finish successful. > > Please, investigate this problem. > > -- > > best regards, > Anton -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: tracking lib dependencies
On Wed, Mar 16, 2011 at 10:56 AM, Robert Huff wrote:
>
> When trying to rebuild avahi after the recent upgrade, I get:
>
> signals-marshal.c:186: warning: ISO C forbids conversion of object pointer to
> function pointer type
>
> CC libavahi_gobject_la-ga-client-enumtypes.lo
>
> CC libavahi_gobject_la-ga-entry-group-enumtypes.lo
>
> CC libavahi_gobject_la-ga-enums-enumtypes.lo
>
> CCLD libavahi-gobject.la
>
> GISCAN Avahi-0.6.gir
>
> g-ir-scanner: warning: Option --strip-prefix has been deprecated;
>
> see --identifier-prefix and --symbol-prefix.
>
> /usr/include/machine/endian.h:123: syntax error, unexpected '{' in ' return
> (__extension__ ({ register __uint64_t __X = (_x); __asm ("bswap %0" : "+r"
> (__X)); __X; }));' at '{'
>
> /usr/include/machine/endian.h:123: syntax error, unexpected ';' in ' return
> (__extension__ ({ register __uint64_t __X = (_x); __asm ("bswap %0" : "+r"
> (__X)); __X; }));' at ';'
>
> /usr/include/machine/endian.h:130: syntax error, unexpected '{' in ' return
> (__extension__ ({ register __uint32_t __X = (_x); __asm ("bswap %0" : "+r"
> (__X)); __X; }));' at '{'
>
> /usr/include/machine/endian.h:130: syntax error, unexpected ';' in ' return
> (__extension__ ({ register __uint32_t __X = (_x); __asm ("bswap %0" : "+r"
> (__X)); __X; }));' at ';'
>
> /libexec/ld-elf.so.1: Shared object "libicui18n.so.38" not found, required by
> "libavahi-glib.so.1"
>
> Command
> '['/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/Avahi-0.6',
>
> '--introspect-dump=/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/types.txt,/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/dump.xml']'
> returned non-zero exit status 1
>
> gmake[3]: *** [Avahi-0.6.gir] Error 1
>
> gmake[3]: Leaving directory
> `/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject'
>
> gmake[2]: *** [all] Error 2
>
>
> (full build log is appended)
>
> libicui18n.so.38? The current version of icu is 4.6
> (re-installed this morning). Where is this picking up the
> dependency on 3.8?
You need to follow icu update in the /usr/ports/UPDATING.
Cheers,
Mezz
> Respectfully,
>
>
> Robert Huff
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: tracking lib dependencies
On Wed, Mar 16, 2011 at 5:47 PM, Robert Huff wrote: > > Jeremy Messenger writes: > >> > /libexec/ld-elf.so.1: Shared object "libicui18n.so.38" not found, >> required by "libavahi-glib.so.1" >> > >> > Command >> '['/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/Avahi-0.6', >> >> '--introspect-dump=/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/types.txt,/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/dump.xml']' >> returned non-zero exit status 1 >> > >> > gmake[3]: *** [Avahi-0.6.gir] Error 1 >> >> You need to follow icu update in the /usr/ports/UPDATING. > > Ok, did that: > > portupgrade -fr devel/icu > > I got a long list of successful rebuilds, plus avahi failing to > build with the exact same error. Do you have libicui18n.so.38 in your system? Or like two icu ports installed? Or maybe portupgrade doesn't do upgrade in the right order, so try to use portmaster instead. Cheers, Mezz > Robert Huff -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Help with first port Makefile
On Mon, Mar 28, 2011 at 9:28 PM, Raphael Kubo da Costa wrote:
> Rod Person writes:
>
>> If I put:
>> USE_GNOME= yes
>> in the Makefile everything builds great, but it checks for dependencies
>> that aren't needed by Fotoxx. All I want to check is to make sure gtk20
>> is installed. I have tried the following, but all of these fail to find
>> gtk20, even though it is installed on my system.
>>
>> LIB_DEPENDS= gtk20:${PORTSDIR}/x11-toolkits/gtk20
>>
>> and
>>
>> LIB_DEPENDS= libgtk-x11-2.0.so:${PORTSDIR}/x11-toolkits/gtk20
>
> I suggest taking a look at section 5.7.1 of the porter's handbook, which
> describes the format for LIB_DEPENDS entries. You almost got it right on
> the second try -- by taking a quick glance at
> /usr/ports/Mk/bsd.gnome.mk, you can see this in line 281:
>
> gtk20_LIB_DEPENDS= gtk-x11-2.0.0:${PORTSDIR}/x11-toolkits/gtk20
>
> By the way, taking a look at the comments in the beginning of
> bsd.gnome.mk is also a good idea, as it shows you can use something like
>
> USE_GNOME=gtk20
>
> and be done with it.
And... Visit here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/
(Click on 'Using GNOME')
Cheers,
Mezz
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: transmission-daemon-2.22
On Sat, Apr 16, 2011 at 4:13 PM, MaamuT wrote:
> Hi,
>
> Sorry for my funny english, but i'm french and i don't speak very well… (thx
> google trad ;) )
>
> I found a litle bug in transmission-daemon web interface in fresh install by
> the ports on freebsd.
>
> The tab_backgrounds_highlight.png is not installed by the port install, but i
> have copy manualy the .png and it's ok now.
Umm, it does install for me. See here:
# cd /usr/ports/www/transmission-web/
# make install clean
===> License check disabled, port has not defined LICENSE
===> Extracting for transmission-web-2.22
=> SHA256 Checksum OK for transmission-2.22.tar.xz.
===> Patching for transmission-web-2.22
===> Applying FreeBSD patches for transmission-web-2.22
===> Configuring for transmission-web-2.22
===> Installing for transmission-web-2.22
===> Generating temporary packing list
===> Checking if www/transmission-web already installed
===> Registering installation for transmission-web-2.22
===> Cleaning for transmission-web-2.22
# find /usr/local/share -name tab_backgrounds_highlight.png
/usr/local/share/transmission/web/images/buttons/tab_backgrounds_highlight.png
Is it in the right place? Where did you copy your
tab_backgrounds_highlight.png to?
> I'm sorry if my explaination is so funny, I hope that will help you
> nevertheless.
It's ok, I understand your email just fine. :-)
Cheers,
Mezz
> I am available for any other information.
>
> Yours faithfully,
>
> --
> MaamuT,
> (\_ _/) ID-CLIK.COM
> (='.'=) maa...@id-clik.com
> (")_(") http://www.id-clik.com/
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: saving a few ports from death
On Mon, Apr 25, 2011 at 7:48 PM, Doug Barton wrote: > On 04/25/2011 17:28, martinko wrote: >> >> Ok, >> I skimmed through the list of deprecated ports and I identifed the >> following that I may be using or at least used in past and I could take >> over their maintenance to save them from death: > > Generally by the time that a port has deteriorated to the point where the > distfiles are gone, and it has no maintainer, it's usually a pretty good > sign that it's time to move on. This isn't just because of the distfile > issue. Every port in the tree consumes resources, whether it's for pointyhat > runs, space on the package sites (including the mirrors), etc. They also > consume time to deal with when they get broken by changes in the OS, etc. > What we're trying to do here is to eliminate ports that are no longer > useful. > > You might want to consider whether or not some of these can be replaced by > different alternatives. > >> misc/wmweather > > Give misc/wmweather+ a try. It's actively developed and maintained. > >> sysutils/wmmemmon > > There are a million other dockapps that do similar jobs, and this one does > not seem that special. :) > > As for the gimp thing that you mentioned, I don't know anything about it, http://registry.gimp.org/node/137 "GREYCstoration has been discontinued, and is now replaced by the G'MIC project, which contains all the former GREYCstoration features, but also much much much more !" http://gmic.sourceforge.net/gimp.shtml (G'MIC project) Cheers, Mezz > but if you wish to become its maintainer the polite thing to do would be to > provide resources to host its distfile(s). > > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.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" > -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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 ${HAVE_GNOME:xxx} and dependencies
On Wed, Jun 29, 2011 at 3:23 AM, David Demelier
wrote:
> On 27/06/2011 13:42, David Demelier wrote:
>>
>> Hello there,
>>
>> There is something I don't understand well. I installed eclipse a long
>> time ago because I needed it for a java project. As you may know eclipse
>> use a lot of gnome dependencies and I usually install ports that don't
>> require them.
>>
>> Now I deinstalled eclipse, and I realized that these libs such as
>> gconf2, libgnome, libgnomeui are needed by a lot of application that had
>> never required them before ! see :
>>
>> Information for gconf2-2.32.0_2:
>>
>> Required by:
>> gnome-vfs-2.24.4
>> libcanberra-0.26
>> libgnome-2.32.0
>> libbonoboui-2.24.4
>> libgnome-keyring-2.32.0
>> libsoup-gnome-2.32.2
>> gnome-keyring-2.32.1
>> policykit-gnome-0.9.2_5
>> gnome-mount-0.8_7
>> gvfs-1.6.6_1
>> libgnomeui-2.24.4
>> firefox-4.0.1,1
>> gimp-app-2.6.11_2,1
>> gimp-2.6.11,2
>> thunderbird-3.1.10
>> inkscape-0.48.1_1
>> wxgtk2-common-2.8.12
>> wxgtk2-unicode-2.8.12
>> audacity-devel-1.3.13_1
>> libpurple-2.8.0
>> pidgin-2.8.0
>> pidgin-pidgimpd-1.1.1_5
>>
>> I can see for example in the graphics/gimp-app/Makefile :
>>
>> .if defined(WITH_GVFS) || ${HAVE_GNOME:Mgvfs}!=""
>> LIB_DEPENDS+= gnome-keyring.0:${PORTSDIR}/security/gnome-keyring
>> USE_GNOME+= gvfs
>> . if ${HAVE_GNOME:Mlibgnomeui}!=""
>> USE_GNOME+= libgnomeui
>> . endif
>> .endif
>>
>> Then, if I disable the option WITH_GVFS (which is already done) but I
>> have gnome-vfs installed it will pull the gnome-vfs dependency when I'll
>> rebuild the port? I think this is what happened. I have probably rebuild
>> this port and that's why it requires the new dependency.
>>
>> The user hasn't the power on this option if the gnome-vfs is installed
>> then?
>>
>> Cheers.
>>
>
> Ignore, I've just seen there is WITHOUT_GNOME that is checked before
With the ${HAVE_GNOME:xxx}, you can either do WITHOUT_GNOME=yes or
WITHOUT_GNOME=xxx.
> HAVE_GNOME and it was not used by portconf now everything is fixed.
Umm... Probably not a real fixed, because your gimp might be still
linked with gvfs. Because there was no --without-gvfs. It's clearly
that it's bug. I have fixed it. It doesn't has ${HAVE_GNOME:gvfs}
anymore as it's pointless when it's enable by default. All you have to
do is WITHOUT_GVFS and it will depends on libcurl instead if you
prefer.
Cheers,
Mezz
> --
> David Demelier
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: Call for testers -- CONF_FILES variable
On Wed, Jun 29, 2011 at 3:24 PM, Chris Rees wrote: > Dear all, > > I've rewritten the CONF_FILES handling after talking to bapt@, and > I've done away with the > colon-separated tuples -- they're overcomplicated. > > The result is something like MAN and PORTDOCS (indeed most of the code > is stolen from PORTDOCS). > > This means that shell globs, filenames and directories are specified > in CONF_FILES, but the sample file is installed in the Makefile as > .pkgconf. I like the rest, but I do not like the name of .pkgconf. I think, the 'pkgconf' is best define for something related with FreeBSD rather than third-party product. The .sample or .default is best name and less confuse for the users, because the word said it all what it is. Cheers, Mezz > Examples for MailScanner [1] show how it can replace huge trees of > config files, and for portscout [2] shows how it is used for just one > file. > > Look at how much has been removed from the MailScanner plist and > pkg-*install.in files -- there are three screens of unused functions > that could also be chopped out now too! > > I'm asking people to (if they want) try out the new variable, and let > me know what they like and don't like about it. > > Since bapt@ is sort of sponsoring this and isn't back for ~ two weeks > it won't make it in before then at least, but some testing and > feedback would be fantastic! > > http://people.freebsd.org/~crees/patches/bsd-port-mk-conf-files-plist-only-pkgconf.diff > > Chris > > [1] http://people.freebsd.org/~crees/patches/mailscanner-conf-files.diff > [2] http://people.freebsd.org/~crees/patches/portscout-conf-files.diff > > P.S. Before people complain about the pkgconf suffix, that is for > compatibility with pkgng, and no, .sample files are not going to be > supported -- they'll need to be installed as .pkgconf. Sorry. -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: sqlite3 3.7.7 and svn
On Thu, Jun 30, 2011 at 10:12 AM, Kostik Belousov wrote: > It seems that update from sqlite3 3.7.6.3 to 3.7.7 breaks svn, It has been fixed in 3.7.7.1, you can try to update (not in ports yet) and see if it works. http://svn.haxx.se/dev/archive-2011-06/index.shtml#858 http://svn.haxx.se/dev/archive-2011-06/index.shtml#872 Cheers, Mezz > at least the svnsync does not work for me anymore. I am afraid > to touch local checkouts since I have a useful work sitting in them. > > An attempt to svnsync sync results in not quite useful message > svnsync: Error while replaying commit > > Ktracing svnsync shown the text like > ( failure ( ( 200029 38:Couldn't perform atomic initialization 31:subv\ > ersion/libsvn_subr/atomic.c 55 ) ( 200030 27:database schema has chang\ > ed 31:subversion/libsvn_subr/sqlite.c 99 ) ) ) > passed near /dev/null, that gave me a hint. > > Indeed, downgrade of the sqlite3 port to 3.7.6.3 allowed svnsync to process. > > This is amd64 stable/8 machine with subversion-freebsd-1.6.17_2. -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: www/transmission-web: make patch fails
On Thu, Jun 30, 2011 at 12:56 PM, Barbara wrote: > # make patch > ===> License check disabled, port has not defined LICENSE > ===> Extracting for transmission-web-2.32 > => SHA256 Checksum OK for transmission-2.32.tar.xz. > ===> Patching for transmission-web-2.32 > ===> Applying FreeBSD patches for transmission-web-2.32 > 1 out of 1 hunks failed--saving rejects to gtk/tr-prefs.c.rej > => Patch patch-gtk_tr-prefs.c failed to apply cleanly. > => Patch(es) patch-fix_without_ipv6 applied cleanly. > *** Error code 1 > > Stop in /usr/ports/www/transmission-web. Forgot to remove a patch, committed it. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: ruby18, -pthreads, deep recursion
On Thu, 01 Nov 2007 16:04:35 -0500, lemon <[EMAIL PROTECTED]> 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. People did a lot of test for lofi and me. You can see http://freebsd.rambler.ru/bsdmail/cvs-all_2005/msg08680.html ... Have ruby compiles without -pthread breaks more stuff than with -pthread. But we can't enable thread option because it also break more stuff than disable thread support. Weird? As for your problem of ruby with -pthread. I have known about that problem and there used to have a PR of it, but I can't find that PR. It was only a problem that ruby with -pthread is causing. I am not going to work on ruby all over again, so don't ask me. :-) I am hoping that someone can bring 100% solution, but we haven't get Mr. Right for ruby yet. Maybe Ruby 1.9 or 2.x with new VM/thread will solve this problem or not. Cheers, Mezz Regards, l. -- [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 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 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]"
Re: [PATCH] portmaster with SU_CMD
On Sun, 11 Nov 2007 16:59:50 -0600, Doug Barton <[EMAIL PROTECTED]> wrote: This is very interesting stuff, but I don't see how it would be useful to a very wide audience. My feeling is that the vast majority of our users build and/or install ports as root, and I don't see any good reason for that not to be the default practice. I'll review your patch more thoroughly when time allows (since we are in a freeze I can't add new features right now anyway) but I'm not inclined to add this unless there is a fairly substantial clamor for it. In fact I think I've passed a tipping point for portmaster where the complexity of the code, and the number of options (and thus, optional code paths) make adding new stuff very hard to do without introducing more bugs, and because there are so many different combinations of options it's hard to regression test improvements to existing features, never mind new ones. I'm not saying I'll never add a new feature, just that there needs to be a really good reason to do so. I agree, because you can't build any ports in /usr/ports as in normal user anyway. I don't see any good reason to do it either. Cheers, Mezz Doug -- [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: [PATCH] portmaster with SU_CMD
On Mon, 12 Nov 2007 11:31:42 -0600, Ricardo Nabinger Sanchez <[EMAIL PROTECTED]> wrote: On Mon, 12 Nov 2007 10:33:55 -0600 "Jeremy Messenger" <[EMAIL PROTECTED]> wrote: I agree, because you can't build any ports in /usr/ports as in normal user anyway. I don't see any good reason to do it either. Yes you can. No, not by default and I have pointed 'in /usr/ports'. You just need to set WRKDIRPREFIX in your /etc/make.conf, to "/tmp" for instance. I've been doing that happily for some years now. Doug said, 'I'm not saying I'll never add a new feature, just that there needs to be a really good reason to do so.' Do anyone has any? I personal still don't see any good reason to do it. 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]"
