Re: Instafix for FreeBSD ports brokenness on 10.0?
On Thu, 29 Sep 2011 16:12:40 -0700
Stanislav Sedov wrote:
> So now tell me how
> .if ${OSVERION} > SOMETHING
> do something
> .endif
>
> in bsd.port.mk
>
> is more risky then that particular commit which can potentially break
> devel/ for all OSVERSIONs.
>
+1.
I can't understand why I (and other HEAD users) should wait 9.0-RELEASE
or 'patch' bsd.port.mk after every ports tree update ?
Also, not so long time ago was commits with LICENSE= x11, Eitan, have
you tried to compile it BEFORE commit ? Why now I talking about
multiple exp-runs and risk?
--
wbr, tiger
___
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"
INDEX now builds successfully on 7.x
___ 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: PHP segmentation faults
On 29/09/2011 20:54, johan Hendriks wrote: Op 29-09-11 19:29, Moggie schreef: Hi, Unfortunately, for some time now, PHP scripts have been producing segmentation faults when executed on one of our systems :( Various posts found via google suggested reinstalling all the PHP ports and/or using a script to re-order the PHP extension modules, but all so far without success. The output of php -m is as follows: [PHP Modules] apc bz2 Core ctype date dom ereg filter gd hash iconv json libxml mbstring mcrypt mhash mysql mysqli mysqlnd openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML snmp sockets SPL sqlite3 standard tokenizer xml zip zlib I'm using this simple test to reproduce the problem: /tmp/test.php /usr/local/bin/php /tmp/test.php Hello, World!Segmentation fault (core dumped) All this makes me sad, especially since my Cacti graphs aren't being updated any more :( Any help or advise on how I might go about resolving this please would be very much appreciated. Thank you in advance for your time and consideration. Kind regards, moggie try to disable some modules you do not use for cacti for example. then try to enable some modules one at the time to see which is faulty. Also try to shuffle with the order in which they load. I had the same with zabbix, and finally found an order in which my maps did not crash the server any more. This is the order in my /usr/local/etc/php/extensions.ini extension=zlib.so extension=mysql.so extension=gettext.so extension=xml.so extension=gd.so extension=ctype.so extension=session.so extension=iconv.so extension=pdo.so extension=pdo_pgsql.so extension=pgsql.so extension=apc.so extension=pdf.so extension=bcmath.so extension=bz2.so extension=curl.so extension=dom.so extension=mbstring.so extension=mysqli.so extension=pdo_sqlite.so extension=sqlite.so extension=sqlite3.so extension=json.so extension=tokenizer.so extension=filter.so extension=hash.so extension=posix.so extension=simplexml.so extension=xmlreader.so extension=xmlwriter.so extension=ldap.so extension=mcrypt.so extension=openssl.so extension=snmp.so extension=sockets.so extension=zip.so I do not have all the extensions you have, but maybe this helps you. regards, Johan Hendriks Hi Johan, Thank you for the reply. Unfortunately there is other stuff running on this box as well. However, if I don't get any joy from playing with the ordering some more, I will have no choice but to try removing modules and making things worse before they get better :] Thanks again, moggie ___ 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: PHP segmentation faults
On 30/09/2011 00:58, Jase Thew wrote: On 29/09/2011 18:29, Moggie wrote: Hi, Unfortunately, for some time now, PHP scripts have been producing segmentation faults when executed on one of our systems :( Various posts found via google suggested reinstalling all the PHP ports and/or using a script to re-order the PHP extension modules, but all so far without success. Can you provide a copy of your /usr/local/etc/php/extensions.ini. Also, what version of PHP are you referring to? Regards, Jase. Hi, Sure can (pasted below) and thanks for the reply. Using PHP version php5-5.3.8. I've not had chance to try out the things people have suggested in other responses yet, but I will. Thanks again to everyone who has responded :) Kind regards, moggie --- extensions.ini begins --- extension=session.so extension=simplexml.so extension=ctype.so extension=apc.so extension=mbstring.so extension=tokenizer.so extension=filter.so extension=mcrypt.so extension=gd.so extension=iconv.so extension=zlib.so extension=bz2.so extension=openssl.so extension=dom.so extension=hash.so extension=pdo.so extension=pdo_mysql.so extension=pdo_sqlite.so extension=mysqli.so extension=mysql.so extension=sockets.so extension=xml.so ; additional extension(s) not known by fixphpextorder.sh extension=sqlite3.so extension=zip.so extension=json.so extension=posix.so extension=snmp.so --- extensions.ini ends --- ___ 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: PHP segmentation faults
On 29/09/2011 18:29, Moggie wrote: Hi, Unfortunately, for some time now, PHP scripts have been producing segmentation faults when executed on one of our systems :( Various posts found via google suggested reinstalling all the PHP ports and/or using a script to re-order the PHP extension modules, but all so far without success. Can you provide a copy of your /usr/local/etc/php/extensions.ini. Also, what version of PHP are you referring to? Regards, Jase. ___ 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: Instafix for FreeBSD ports brokenness on 10.0?
On Thu, 29 Sep 2011 17:40:36 -0400
Eitan Adler mentioned:
> The ports tree can be very fickle and touching a large class of ports
> requires multiple exp-runs. Attempting these types of changes
> just prior to release adds a degree of risk which no one wants to accept.
>
Who don't want to accept this?
Who is making this decision for everyone?
> Affecting *every single port* is not a negligible risk.
I can easily commit whatever I want to bsd.ruby.mk right now
affecting all the ports (and nobody will say a word), but we can't
do a conditional fix in bsd.port.mk? I'd say the first one poses
much a higher risk (and I never did a single exp-run for that).
Seriously, just look at the commits happening right now. Here's
one example (the most recent commit, not picking up anything):
15:22 < CIA-28> [ports] glarkin * devel/Makefile: - Hook py-zope.interface to
the build
So now tell me how
.if ${OSVERION} > SOMETHING
do something
.endif
in bsd.port.mk
is more risky then that particular commit which can potentially break
devel/ for all OSVERSIONs.
--
Stanislav Sedov
ST4096-RIPE
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
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"
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: py27-zope.component-3.11.0: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.component-3.11.0: no entry for /usr/ports/devel/py-zope.interface make_index: kojoney-0.0.4.1_3: no entry for /usr/ports/devel/py-zope.interface make_index: py27-pyramid-1.2_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-pyramid-1.2_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.proxy-3.6.1_3: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.proxy-3.6.1_3: no entry for /usr/ports/devel/py-zope.interface make_index: py27-twistedCore-11.0.0_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-twistedCore-11.0.0_1: no entry for /usr/ports/devel/py-zope.interface make_index: pitivi-0.13.4.2_2: no entry for /usr/ports/devel/py-zope.interface make_index: py27-transaction-1.1.1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-transaction-1.1.1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-repoze.what-pylons-1.0_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-repoze.what-pylons-1.0_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.schema-3.8.1_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.schema-3.8.1_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-dosage-1.6.0_1: no entry for /usr/ports/devel/py-zope.interface make_index: freevo-1.9.0_5: no entry for /usr/ports/devel/py-zope.interface make_index: zodb-py27-3.10.3_3: no entry for /usr/ports/devel/py-zope.interface make_index: zodb-py27-3.10.3_3: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.configuration-3.7.4_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.configuration-3.7.4_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-repoze.who-1.0.19_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-repoze.who-1.0.19_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.i18n-3.7.4_1: no entry for /usr/ports/devel/py-zope.interface make_index: py27-zope.testing-3.10.2: no entry for /usr/ports/devel/py-zopeInterface make_index: py27-zope.testing-3.10.2: no entry for /usr/ports/devel/py-zopeInterface make_index: py27-zope.exceptions-3.6.1_1: no entry for /usr/ports/devel/py-zope.interface Committers on the hook: beat dhn glarkin lme pav Most recent CVS update was: U audio/osdmixer/Makefile U comms/ncid/Makefile U comms/ncid/distinfo U comms/ncid/pkg-plist U databases/zodb3/Makefile U deskutils/lightning/Makefile U deskutils/py-dosage/Makefile U devel/Makefile U devel/py-repoze.what-pylons/Makefile U devel/py-repoze.who/Makefile U devel/py-transaction/Makefile U devel/py-twistedCore/Makefile U devel/py-zope.component/Makefile U devel/py-zope.component/distinfo U devel/py-zope.component/pkg-descr U devel/py-zope.configuration/Makefile U devel/py-zope.exceptions/Makefile U devel/py-zope.i18n/Makefile U devel/py-zope.interface/Makefile U devel/py-zope.interface/distinfo U devel/py-zope.interface/pkg-descr U devel/py-zope.interface/pkg-plist U devel/py-zope.schema/Makefile U multimedia/freevo/Makefile U multimedia/pitivi/Makefile U net/kojoney/Makefile U net/py-zope.proxy/Makefile U net-im/pymsn/Makefile U net-mgmt/aircrack-ng/Makefile U net-mgmt/aircrack-ng/files/patch-src_osdep_freebsd.c U sysutils/nbosd/Makefile U www/py-pyramid/Makefile U x11-toolkits/py-kiwi/Makefile ___ 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: PHP segmentation faults
W dniu 2011-09-29 19:29, Moggie pisze: > mhash Are you using apache-worker? Try to disable that module. -- best regards, Lukasz Wasikowski ___ 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: PHP segmentation faults
Try using xdebug (another php module) it will produce a stack trace when it segfaults. On 09/29/2011 10:29 AM, Moggie wrote: > Hi, > > Unfortunately, for some time now, PHP scripts have been producing > segmentation faults when executed on one of our systems :( > > Various posts found via google suggested reinstalling all the PHP ports > and/or using a script to re-order the PHP extension modules, but all so > far without success. > > The output of php -m is as follows: > > [PHP Modules] > apc > bz2 > Core > ctype > date > dom > ereg > filter > gd > hash > iconv > json > libxml > mbstring > mcrypt > mhash > mysql > mysqli > mysqlnd > openssl > pcre > PDO > pdo_mysql > pdo_sqlite > posix > Reflection > session > SimpleXML > snmp > sockets > SPL > sqlite3 > standard > tokenizer > xml > zip > zlib > > > I'm using this simple test to reproduce the problem: > > /tmp/test.php > Print "Hello, World!"; > ?> > > > /usr/local/bin/php /tmp/test.php > Hello, World!Segmentation fault (core dumped) > > > All this makes me sad, especially since my Cacti graphs aren't being > updated any more :( Any help or advise on how I might go about resolving > this please would be very much appreciated. Thank you in advance for > your time and consideration. > > Kind regards, > moggie > ___ > 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" -- Mark D. Foster http://mark.foster.cc/ ___ 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: Thunderbird 6.0.2/7.0: Crashing when using with OpenLDAP backend
On 09/29/11 18:31, Andrea Venturoli wrote: > On 09/28/11 14:29, O. Hartmann wrote: >> I run in a problem on FreeBSD 9.0-BETA3/10.0-CURRENT using OpenLDAP >> (Cyrus SASL2 aktivated) and OpenLDAP backend (most recent client and >> server). Thunderbird 6.0.2 and 7.0 coredumps with signal 11. I hadn't >> any chance to check whether this also happens on 8.2-STABLE, but I'll >> check this as soon as possible, since I run the same OpenLDAP backend >> and configuration (also the Cyrus SASL2 libs, most recent from ports). >> >> The boxes in question do have FreeBSD 9.0-BETA3/10.0-CUR compiled with >> CLANG and Thunderbird is also compiled with CLANG. >> >> >> Does anyone else experience these issues? > > You mean this? >> http://freebsd.1045724.n5.nabble.com/TB-5-0-crashing-with-nss-ldap-td4575944.html >> > > bye > av. I think, the gdb output looked like yours. I have to check this when I'm back in the bureau/lab. But I remember that tha las line of the gdb-output before the backtrace refered to libldap60.so. Regards, Oliver Hartmann ___ 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: Instafix for FreeBSD ports brokenness on 10.0?
The ports tree can be very fickle and touching a large class of ports requires multiple exp-runs. Attempting these types of changes just prior to release adds a degree of risk which no one wants to accept. > The question is why we're not going to fiddle with auto* given other > stuff which is being committed to the ports tree right now, which is > unrelated to release as well? Because these commits don't possibly break a large portion of ports. > The fix can be added unconditionaly, > thus having a very low (I'd say negligible) risk of breaking anything. Affecting *every single port* is not a negligible risk. > In the meantime, if we don't fix this we're making it impossible for > any HEAD users to do any kind of productive work in ports. We will fix it, once 9-RELEASE is out the door. In the meantime please see UPDATING 20110928. -- Eitan Adler ___ 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: Linuxulator X11 broken?
On Thu, Sep 29, 2011 at 1:50 PM, Andrew wrote:
> I'm seeing broken flash plugin, skype and citrix client all reporting
> in one way or other that they can't open display. This is all on
> 8.2-STABLE FreeBSD 8.2-STABLE #8: Thu Sep 29 10:11:04 BST 2011 built
> this morning on amd64.
> e.g.
>
> (npviewer.bin:2790): Gtk-WARNING **: cannot open display: :0
> *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC
> client connection
>
> part of ktrace of skype failing to launch:
>
> 64328 skype CALL linux_socketcall(0x1,0xca00)
> 64328 skype RET linux_socketcall 7
> 64328 skype CALL linux_socketcall(0x3,0xca00)
> 64328 skype STRU struct sockaddr { AF_LOCAL, invalid }
> 64328 skype RET linux_socketcall -1 errno 2 No such file or directory
> 64328 skype CALL close(0x7)
> 64328 skype RET close 0
> 64328 skype CALL linux_socketcall(0x1,0xca00)
> 64328 skype RET linux_socketcall 7
> 64328 skype CALL linux_socketcall(0x3,0xca00)
> 64328 skype STRU struct sockaddr { AF_LOCAL, /tmp/.X11-unix/X0 }
> 64328 skype RET linux_socketcall -1 errno 22 Invalid argument
> 64328 skype CALL close(0x7)
> 64328 skype RET close 0
> 64328 skype CALL write(0x6,0x9700e01,0x1)
> 64328 skype GIO fd 6 wrote 1 byte
> "@"
> 64328 skype RET write 1
> 64328 skype CALL close(0x6)
> 64328 skype RET close 0
> 64328 skype CALL close(0x5)
> 64328 skype RET close 0
> 64328 skype CALL linux_rt_sigaction(0x11,0xca28,0xc99c,0x8)
> 64328 skype RET linux_rt_sigaction 0
> 64328 skype CALL linux_exit_group(0x1)
>
>
> I've reinstalled linux-f10* ports to see if anything changed, but to no avail.
>
> Thanks,
> Andrew
To me it seems as if the socket kernel patch is involved in this issue.
ktrace of firefox trying to play flash via npviewer(nsplugin wrapper)
shows this:
31900 initial thread RET nanosleep 0
31900 initial thread CALL connect(0x15,0x809241d18,0x42)
31900 initial thread STRU struct sockaddr { AF_LOCAL, invalid }
31900 initial thread NAMI
"/tmp/_org_wrapper_NSPlugins_libflashplayer.so_31900-2_1804289383"
31900 initial thread RET connect -1 errno 2 No such file or directory
31900 initial thread CALL nanosleep(0x7fffca30,0x7fffca40)
31900 initial thread RET nanosleep 0
31900 initial thread CALL connect(0x15,0x809241d18,0x42)
31900 initial thread STRU struct sockaddr { AF_LOCAL, invalid }
31900 initial thread NAMI
"/tmp/_org_wrapper_NSPlugins_libflashplayer.so_31900-2_1804289383"
31900 initial thread RET connect -1 errno 2 No such file or directory
31900 initial thread CALL nanosleep(0x7fffca30,0x7fffca40)
31900 initial thread RET nanosleep 0
31900 initial thread CALL unlink(0x8093cd150)
31900 initial thread NAMI
"/tmp/_org_wrapper_NSPlugins_libflashplayer.so_31900-2_1804289383"
31900 initial thread RET unlink -1 errno 2 No such file or directory
31900 initial thread CALL close(0x15)
31900 initial thread RET close 0
31900 initial thread CALL write(0x2,0x7fffc2d0,0x19)
31900 initial thread GIO fd 2 wrote 25 bytes
"*** NSPlugin Wrapper *** "
31900 initial thread RET write 25/0x19
31900 initial thread CALL write(0x2,0x7fffc3b0,0x3e)
31900 initial thread GIO fd 2 wrote 62 bytes
"ERROR: failed to initialize plugin-side RPC client connection
"
best regards,
kaltheat
___
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: Linuxulator X11 broken?
Hello, this mail is from Japan. My name is Hiroshi Saeki, a hobby user of FreeBSD. Only a few hours before, I upgraded my FreeBSD/amd64 8.2-RELEASE-p2 to 8.2-RELEASE-p3. The same problem occured. linux-firefox-devel-3.5.19 linux-opera-11.50 ja-acroread8-8.1.7_3 cannot be started. They can't open display. I reverted the kernel to it of 8.2-RELEASE-p2, and they work fine. RELENG_8_2 src/sys/kern/uipc_usrreq.c 1.233.2.2.2.2 RELENG_8 src/sys/kern/uipc_usrreq.c 1.233.2.6 must be problematic. I am going to send-pr about uipc_userreq.c. Perhaps, you too should revert kernel to privious version. I wish this will be of your help. With warm regards. On Thu, 29 Sep 2011 12:50:55 +0100 Andrew wrote: > I'm seeing broken flash plugin, skype and citrix client all reporting > in one way or other that they can't open display. This is all on > 8.2-STABLE FreeBSD 8.2-STABLE #8: Thu Sep 29 10:11:04 BST 2011 built > this morning on amd64. ___ 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: Instafix for FreeBSD ports brokenness on 10.0?
On Thu, 29 Sep 2011 11:47:33 +0200 Erwin Lansing mentioned: > On Thu, Sep 29, 2011 at 10:47:25AM +0200, Ed Schouten wrote: > > Hi folks, > > > > Why can't we simply fix the entire ports tree at once by doing something > > like this? > > > If we're not going to fiddle with auto* so close to a release date, we > certainly are not going to fiddle with the whole ports infrastructure > that affects even more ports, especially not for a workaround that only > affects CURRENT users. Ports on CURRENT is only provided on a best > effort basis and its users are expected to be techically savvy enough to > work around these kinds of issues themselves. > > We can always use more eyes on 9.0-BETA3 and as HEAD hasn't diverged > that much, it would be nice if people installed the beta and reported > any bugs found there. > The question is why we're not going to fiddle with auto* given other stuff which is being committed to the ports tree right now, which is unrelated to release as well? The fix can be added unconditionaly, thus having a very low (I'd say negligible) risk of breaking anything. In the meantime, if we don't fix this we're making it impossible for any HEAD users to do any kind of productive work in ports. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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: Instafix for FreeBSD ports brokenness on 10.0?
On Thu, 29 Sep 2011 11:18:59 +0200 Ed Schouten mentioned: > * Ed Schouten , 20110929 11:07: > > I meant simply adding this line to bsd.port.mk, to be executed after > > pre-configure and before configure. > > More specifically, see the attached patch. > I think this is a good idea. I recommend sending this to re@ and/or core@ for consideration. Personally, I'd love to see this committed ASAP, as I'm unable to do any ports work right now. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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/161004: version update
hi please commit port update On Sun, Sep 25, 2011 at 08:30:10AM +, freebsd-gnats-sub...@freebsd.org wrote: > Thank you very much for your problem report. > It has the internal identification `ports/161004'. > The individual assigned to look at your > report is: freebsd-ports-bugs. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=161004 > > >Category: ports > >Responsible:freebsd-ports-bugs > >Synopsis: version update > >Arrival-Date: Sun Sep 25 08:30:10 UTC 2011 -- --- Vasiliy P. MelnikVPM-UANIC ___ 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: PHP segmentation faults
Op 29-09-11 19:29, Moggie schreef: Hi, Unfortunately, for some time now, PHP scripts have been producing segmentation faults when executed on one of our systems :( Various posts found via google suggested reinstalling all the PHP ports and/or using a script to re-order the PHP extension modules, but all so far without success. The output of php -m is as follows: [PHP Modules] apc bz2 Core ctype date dom ereg filter gd hash iconv json libxml mbstring mcrypt mhash mysql mysqli mysqlnd openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML snmp sockets SPL sqlite3 standard tokenizer xml zip zlib I'm using this simple test to reproduce the problem: /tmp/test.php /usr/local/bin/php /tmp/test.php Hello, World!Segmentation fault (core dumped) All this makes me sad, especially since my Cacti graphs aren't being updated any more :( Any help or advise on how I might go about resolving this please would be very much appreciated. Thank you in advance for your time and consideration. Kind regards, moggie try to disable some modules you do not use for cacti for example. then try to enable some modules one at the time to see which is faulty. Also try to shuffle with the order in which they load. I had the same with zabbix, and finally found an order in which my maps did not crash the server any more. This is the order in my /usr/local/etc/php/extensions.ini extension=zlib.so extension=mysql.so extension=gettext.so extension=xml.so extension=gd.so extension=ctype.so extension=session.so extension=iconv.so extension=pdo.so extension=pdo_pgsql.so extension=pgsql.so extension=apc.so extension=pdf.so extension=bcmath.so extension=bz2.so extension=curl.so extension=dom.so extension=mbstring.so extension=mysqli.so extension=pdo_sqlite.so extension=sqlite.so extension=sqlite3.so extension=json.so extension=tokenizer.so extension=filter.so extension=hash.so extension=posix.so extension=simplexml.so extension=xmlreader.so extension=xmlwriter.so extension=ldap.so extension=mcrypt.so extension=openssl.so extension=snmp.so extension=sockets.so extension=zip.so I do not have all the extensions you have, but maybe this helps you. regards, Johan Hendriks ___ 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: Options for emulators/wine?
On 28 September 2011 10:49, Thomas Mueller wrote: > from Chris Rees : > >> Some rather strange printers will be recognised by umass before ugen >> recognises them; you have to plug it in before umass is loaded or it >> becomes a mass storage device. > >> I'm not sure that the Windows printer stack is included in Wine, why >> would you rather do that than use CUPS? The gutenprint drivers are >> often of a higher quality than the manufacturer's provided ones, and >> they install less trash. > > I need umass, otherwise USB sticks and other USB disks are inaccessible. I think you've misunderstood me. Power on (without umass), plug in printer, watch console for ulpt0 and THEN kldload umass. > Should the printer be plugged in and powered on at boot time? Yes. See above :) > I am already trying unsuccessfully to build hplip to access the printer in > the Unix way, without wine. > > With wine, I might want to try another way, using MS-Windows drivers if > possible. > > Building hplip failed due to a broken dependency, py-reportlab2 > > BROKEN= does not package > (quoting from the Makefile) > > I seriously doubt you'll have any luck with hp drivers under wine :) Unless HP differs seriously from the Epsons I've always used, you can just use vanilla CUPS with them. Bear in mind, I'm no expert on HP printers; I'm only replying because no-one else has jumped in :) 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"
PHP segmentation faults
Hi, Unfortunately, for some time now, PHP scripts have been producing segmentation faults when executed on one of our systems :( Various posts found via google suggested reinstalling all the PHP ports and/or using a script to re-order the PHP extension modules, but all so far without success. The output of php -m is as follows: [PHP Modules] apc bz2 Core ctype date dom ereg filter gd hash iconv json libxml mbstring mcrypt mhash mysql mysqli mysqlnd openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML snmp sockets SPL sqlite3 standard tokenizer xml zip zlib I'm using this simple test to reproduce the problem: /tmp/test.php /usr/local/bin/php /tmp/test.php Hello, World!Segmentation fault (core dumped) All this makes me sad, especially since my Cacti graphs aren't being updated any more :( Any help or advise on how I might go about resolving this please would be very much appreciated. Thank you in advance for your time and consideration. Kind regards, moggie ___ 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: Thunderbird 6.0.2/7.0: Crashing when using with OpenLDAP backend
On 09/28/11 14:29, O. Hartmann wrote: I run in a problem on FreeBSD 9.0-BETA3/10.0-CURRENT using OpenLDAP (Cyrus SASL2 aktivated) and OpenLDAP backend (most recent client and server). Thunderbird 6.0.2 and 7.0 coredumps with signal 11. I hadn't any chance to check whether this also happens on 8.2-STABLE, but I'll check this as soon as possible, since I run the same OpenLDAP backend and configuration (also the Cyrus SASL2 libs, most recent from ports). The boxes in question do have FreeBSD 9.0-BETA3/10.0-CUR compiled with CLANG and Thunderbird is also compiled with CLANG. Does anyone else experience these issues? You mean this? http://freebsd.1045724.n5.nabble.com/TB-5-0-crashing-with-nss-ldap-td4575944.html bye av. ___ 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: Re-starting daemons across upgrades?
W dniu 2011-09-28 23:12, Matthias Andree pisze: > So basically, we need a lever the operator can flip, and that typical > ports running daemons, respect - that can state whether ports > auto-restart deamons previously running (which would entail complaining > the if needs manual intervention, like chasing configuration language > changes, or other), or whether not to and just collect their names and > list them so the operator can do it at a convenient time -- assuming the > daemons are up to that task (continue running). That solution would satisfy most of the use cases. -- best regards, Lukasz Wasikowski ___ 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"
Linuxulator X11 broken?
I'm seeing broken flash plugin, skype and citrix client all reporting
in one way or other that they can't open display. This is all on
8.2-STABLE FreeBSD 8.2-STABLE #8: Thu Sep 29 10:11:04 BST 2011 built
this morning on amd64.
e.g.
(npviewer.bin:2790): Gtk-WARNING **: cannot open display: :0
*** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC
client connection
part of ktrace of skype failing to launch:
64328 skypeCALL linux_socketcall(0x1,0xca00)
64328 skypeRET linux_socketcall 7
64328 skypeCALL linux_socketcall(0x3,0xca00)
64328 skypeSTRU struct sockaddr { AF_LOCAL, invalid }
64328 skypeRET linux_socketcall -1 errno 2 No such file or directory
64328 skypeCALL close(0x7)
64328 skypeRET close 0
64328 skypeCALL linux_socketcall(0x1,0xca00)
64328 skypeRET linux_socketcall 7
64328 skypeCALL linux_socketcall(0x3,0xca00)
64328 skypeSTRU struct sockaddr { AF_LOCAL, /tmp/.X11-unix/X0 }
64328 skypeRET linux_socketcall -1 errno 22 Invalid argument
64328 skypeCALL close(0x7)
64328 skypeRET close 0
64328 skypeCALL write(0x6,0x9700e01,0x1)
64328 skypeGIO fd 6 wrote 1 byte
"@"
64328 skypeRET write 1
64328 skypeCALL close(0x6)
64328 skypeRET close 0
64328 skypeCALL close(0x5)
64328 skypeRET close 0
64328 skypeCALL linux_rt_sigaction(0x11,0xca28,0xc99c,0x8)
64328 skypeRET linux_rt_sigaction 0
64328 skypeCALL linux_exit_group(0x1)
I've reinstalled linux-f10* ports to see if anything changed, but to no avail.
Thanks,
Andrew
___
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 9-Beta3 and FlashPlayer
I also have problems with flash after upgrade to FF7 on 8.2 -p3 RELEASE. I posted this to the ports list yesterday. (process:20370): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20370): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20389): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20389): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20408): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20408): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20427): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20427): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20446): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20446): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down I'v tried nspluginwrapper -r [FILE] and I'v tried nspluginwrapper -i [FILE] with no luck. Any suggestions on how to resolve the problem? Thanks /Leslie I have under opera (when i open flash page): [cr4sh@x300 ~]$ opera (process:64180): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (operapluginwrapper.linux:64180): Gtk-WARNING **: cannot open display: :0 Opera Plugin Proxy: Could not start up plugin ___ 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: Instafix for FreeBSD ports brokenness on 10.0?
On Thu, Sep 29, 2011 at 1:47 AM, Ed Schouten wrote:
> Hi folks,
>
> Why can't we simply fix the entire ports tree at once by doing something
> like this?
>
> find ${WRKSRC} -type f \( -name config.libpath -o \
> -name config.rpath -o -name configure -o -name libtool.m4 \) \
> -exec sed -i 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
>
> Just to be safe, we can only execute this when OSVERSION is 10.0.
This is not sufficient since some places it's freebsd[123],
freebsd[[123]], etc...
Cheers,
--
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
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: Instafix for FreeBSD ports brokenness on 10.0?
* Xin LI , 20110929 12:08: > This is not sufficient since some places it's freebsd[123], > freebsd[[123]], etc... Yes, but the patch I propose already fixes a large class of compilation issues. It is by no means a silver bullet. -- Ed Schouten WWW: http://80386.nl/ pgpnUhQiJ8vUz.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
On Thu, Sep 29, 2011 at 10:47:25AM +0200, Ed Schouten wrote: > Hi folks, > > Why can't we simply fix the entire ports tree at once by doing something > like this? > If we're not going to fiddle with auto* so close to a release date, we certainly are not going to fiddle with the whole ports infrastructure that affects even more ports, especially not for a workaround that only affects CURRENT users. Ports on CURRENT is only provided on a best effort basis and its users are expected to be techically savvy enough to work around these kinds of issues themselves. We can always use more eyes on 9.0-BETA3 and as HEAD hasn't diverged that much, it would be nice if people installed the beta and reported any bugs found there. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@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: clang and configure checking for equivalent simple type
Hi, > Alternatively, you can turn off only a specific -Werror, e.g. > > CFLAGS += -Wno-error=unused > > it's ignored by gcc in base while gcc46 wants -Wno-error=unused-value that's a very good point. Thanks a lot! Best, Klaus ___ 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: clang and configure checking for equivalent simple type
Hi, > Are you sure that you don't have -Werror being set somehow? well, fortunately I have! Note that it is a feature in this context that a similar programs don't compile if the types are incompatible. Compare the following. -Wno-unused -Werror is indeed the correct choice of flags. Best, Klaus /usr/ports/net/socat>make configure CC=gcc ... checking for equivalent simple type of size_t... 6 /* unsigned long */ checking for equivalent simple type of mode_t... 2 /* unsigned short */ checking for equivalent simple type of pid_t... 3 /* int */ checking for equivalent simple type of uid_t... 4 /* unsigned int */ checking for equivalent simple type of gid_t... 4 /* unsigned int */ checking for equivalent simple type of time_t... 5 /* long */ checking for equivalent simple type of socklen_t... 4 /* unsigned int */ checking for equivalent simple type of off_t... 5 /* long */ checking for equivalent simple type of off64_t... 0 /* unknown, taking default */ checking for basic type of struct stat.st_dev... 4 /* unsigned int */ checking for basic type of struct stat.st_ino... 4 /* unsigned int */ checking for basic type of struct stat.st_nlink... 2 /* unsigned short */ checking for basic type of struct stat.st_size... 5 /* long */ checking for basic type of struct stat.st_blksize... 4 /* unsigned int */ checking for basic type of struct stat.st_blocks... 5 /* long */ checking for basic type of struct timeval.tv_usec... 5 /* long */ checking for basic type of struct rlimit.rlim_max... 5 /* long */ ... /usr/ports/net/socat>make configure CC=clang CFLAGS=-Wno-error ... checking for equivalent simple type of size_t... 1 /* short */ checking for equivalent simple type of mode_t... 1 /* short */ checking for equivalent simple type of pid_t... 1 /* short */ checking for equivalent simple type of uid_t... 1 /* short */ checking for equivalent simple type of gid_t... 1 /* short */ checking for equivalent simple type of time_t... 1 /* short */ checking for equivalent simple type of socklen_t... 1 /* short */ checking for equivalent simple type of off_t... 1 /* short */ checking for equivalent simple type of off64_t... 0 /* unknown, taking default */ checking for basic type of struct stat.st_dev... 1 /* short */ checking for basic type of struct stat.st_ino... 1 /* short */ checking for basic type of struct stat.st_nlink... 1 /* short */ checking for basic type of struct stat.st_size... 1 /* short */ checking for basic type of struct stat.st_blksize... 1 /* short */ checking for basic type of struct stat.st_blocks... 1 /* short */ checking for basic type of struct timeval.tv_usec... 1 /* short */ checking for basic type of struct rlimit.rlim_max... 1 /* short */ ... /usr/ports/net/socat>make configure CC=clang CFLAGS=-Wno-unused ... checking for equivalent simple type of size_t... 6 /* unsigned long */ checking for equivalent simple type of mode_t... 2 /* unsigned short */ checking for equivalent simple type of pid_t... 3 /* int */ checking for equivalent simple type of uid_t... 4 /* unsigned int */ checking for equivalent simple type of gid_t... 4 /* unsigned int */ checking for equivalent simple type of time_t... 5 /* long */ checking for equivalent simple type of socklen_t... 4 /* unsigned int */ checking for equivalent simple type of off_t... 5 /* long */ checking for equivalent simple type of off64_t... 0 /* unknown, taking default */ checking for basic type of struct stat.st_dev... 4 /* unsigned int */ checking for basic type of struct stat.st_ino... 4 /* unsigned int */ checking for basic type of struct stat.st_nlink... 2 /* unsigned short */ checking for basic type of struct stat.st_size... 5 /* long */ checking for basic type of struct stat.st_blksize... 4 /* unsigned int */ checking for basic type of struct stat.st_blocks... 5 /* long */ checking for basic type of struct timeval.tv_usec... 5 /* long */ checking for basic type of struct rlimit.rlim_max... 5 /* long */ ... /usr/ports/net/socat>make configure CC=clang CFLAGS= ... checking for equivalent simple type of size_t... 0 /* unknown, taking default */ checking for equivalent simple type of mode_t... 0 /* unknown, taking default */ checking for equivalent simple type of pid_t... 0 /* unknown, taking default */ checking for equivalent simple type of uid_t... 0 /* unknown, taking default */ checking for equivalent simple type of gid_t... 0 /* unknown, taking default */ checking for equivalent simple type of time_t... 0 /* unknown, taking default */ checking for equivalent simple type of socklen_t... 0 /* unknown, taking default */ checking for equivalent simple type of off_t... 0 /* unknown, taking default */ checking for equivalent simple type of off64_t... 0 /* unknown, taking default */ checking for basic type of struct stat.st_dev... 0 /* unknown, taking default */ checking for basic type of struct stat.st_ino... 0 /* unknown, taking default */ checking for basic type of struct stat.st_nlink... 0 /* unknown, taking default */ checking for basic
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Ed Schouten , 20110929 11:07:
> I meant simply adding this line to bsd.port.mk, to be executed after
> pre-configure and before configure.
More specifically, see the attached patch.
--
Ed Schouten
WWW: http://80386.nl/
--- Mk/bsd.port.mk
+++ Mk/bsd.port.mk
@@ -3667,6 +3667,16 @@
@${DO_NADA}
.endif
+# Work around an issue where FreeBSD 10.0 is detected as FreeBSD 1.x.
+run-autotools-fixup:
+.if ${OSVERSION} >= 100
+ @find ${WRKSRC} -type f \( -name config.libpath -o \
+ -name config.rpath -o -name configure -o -name libtool.m4 \) \
+ -exec sed -i '' 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
+.else
+ @${DO_NADA}
+.endif
+
# Configure
.if !target(do-configure)
@@ -4266,7 +4276,7 @@
_CONFIGURE_DEP= patch
_CONFIGURE_SEQ= build-depends lib-depends configure-message \
configure-autotools pre-configure pre-configure-script \
-run-autotools do-configure post-configure post-configure-script
+run-autotools run-autotools-fixup do-configure post-configure post-configure-script
_BUILD_DEP= configure
_BUILD_SEQ= build-message pre-build pre-build-script do-build \
post-build post-build-script
pgpU7Tmu2JJOq.pgp
Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Matthew Seaman , 20110929 11:01: > Because that's a change to the upstream distfiles downloaded from the > net. So this change would have to be implemented by adding patch files > to every port that needed it, or by adding a new make target in the > various Makefiles. I meant simply adding this line to bsd.port.mk, to be executed after pre-configure and before configure. -- Ed Schouten WWW: http://80386.nl/ pgpBq7UqfhcJ4.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
On 29/09/2011 09:47, Ed Schouten wrote:
> Hi folks,
>
> Why can't we simply fix the entire ports tree at once by doing something
> like this?
>
> find ${WRKSRC} -type f \( -name config.libpath -o \
> -name config.rpath -o -name configure -o -name libtool.m4 \) \
> -exec sed -i 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
>
> Just to be safe, we can only execute this when OSVERSION is 10.0.
>
Because that's a change to the upstream distfiles downloaded from the
net. So this change would have to be implemented by adding patch files
to every port that needed it, or by adding a new make target in the
various Makefiles.
However, this is going to be a huge amount of churn and disruption in
the ports, and if you hadn't noticed, we're right in the middle of the
process of generating 9.0-RELEASE. Meaning that now is not the time to
implement widespread changes that will throw the ports tree into disarray.
So people that run -CURRENT -- people that, mind you, are expected to be
pretty competent Unix developers capable of dealing with the much worse
systemic problems that tend to pop up when running bleeding edge code --
those people are being asked to put up with ports brokenness for a few
weeks. Work-arounds have been published, and I'm sure there's quite a
lot of work going on behind the scenes to make the eventual fix pretty
seamless.
If that doesn't work for you, then try 9.0-BETA3 for a while. There's
virtually no difference to -CURRENT at the moment, and it doesn't tickle
this particular bug.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Ed Schouten , 20110929 10:47:
> -exec sed -i 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
Whoops. Don't forget to add '' after the -i.
--
Ed Schouten
WWW: http://80386.nl/
pgpeXx31sf2gD.pgp
Description: PGP signature
Instafix for FreeBSD ports brokenness on 10.0?
Hi folks,
Why can't we simply fix the entire ports tree at once by doing something
like this?
find ${WRKSRC} -type f \( -name config.libpath -o \
-name config.rpath -o -name configure -o -name libtool.m4 \) \
-exec sed -i 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
Just to be safe, we can only execute this when OSVERSION is 10.0.
--
Ed Schouten
WWW: http://80386.nl/
pgpbCNHmqdKNT.pgp
Description: PGP signature
Re: FreeBSD 9-Beta3 and FlashPlayer
2011-09-29 09:45, crsnet.pl skrev: Hello. I make update yesterday with csup. And i have build new firefox 7 from src. And today i see my flashplayer dont work (under Opera/Firefox). Opera about:plugins Opis: Shockwave Flash 10.3 r183 /usr/local/lib/npapi/symlinks/linux-opera/libflashplayer.soapplication/futuresplash FutureSplash Player spl application/x-shockwave-flash Shockwave Flash swf,swt,null,flash Firefox about:plugins File: npwrapper.libflashplayer.so Version: Shockwave Flash 10.3 r183 MIME Type Description Suffixes application/x-shockwave-flash Shockwave Flash swf application/futuresplash FutureSplash Player spl [cr4sh@x300 ~]$ pkg_info | grep flash linux-f10-flashplugin-10.3r183.10 Adobe Flash Player NPAPI Plugin [cr4sh@x300 ~]$ pkg_info | grep nsplugi nspluginwrapper-1.4.4 A compatibility plugin for Mozilla NPAPI plugins [cr4sh@x300 ~]$ nspluginwrapper -v -i $( find / -name libflashplayer.so ) Install plugin /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-firefox/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-firefox-devel/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-flock/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-flock-devel/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-mozilla/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-netscape-messenger/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-netscape-navigator/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-nvu/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-opera/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-opera-devel/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-seamonkey/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-seamonkey-devel/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-sunbird/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/npapi/symlinks/linux-sunbird-devel/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/local/lib/browser_plugins/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/ports/www/linux-f10-flashplugin10/work/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so Install plugin /usr/home/cr4sh/.mozilla/plugins/libflashplayer.so into /home/cr4sh/.mozilla/plugins/npwrapper.libflashplayer.so When i try to play youtube movie i get only black rectangle. I try to pkg_delete && pkg_add -r nspluginwrapper, opera-linuxplugins and make linux-f10-flashplugin. But this doesn't work ;/ Regards. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" I also have problems with flash after upgrade to FF7 on 8.2 -p3 RELEASE. I posted this to the ports list yesterday. (process:20370): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20370): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20389): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20389): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20408): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (npviewer.bin:20408): Gtk-WARNING **: cannot open display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection NOTE: child process received `Goodbye', closing down (process:20427): Gtk-WARNING **: Locale not supported by C librar
Re: HEADS UP: ports/ and 10.0-CURRENT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.09.2011 21:32, Hartmann, O. wrote: > floating like a dead man in the water. I suspect the > conversters/libiconv broke something, since it claims it has > installed libiconv.so.3, but there is never such a shared object > installed! Here's what I did to recover: 1. Deinstall lang/gawk This is necessary so that ports don't try to use it. 2. Reinstall devel/libtool with UNAME_r=9.0-RELEASE Ports using autotools call libtool to know if they should build shared libraries. But libtool disables shared libraries for freebsd1*. You can check what libtool will tell to other ports by doing: libtool --config | grep build_libtool_libs To have shared libraries, this variable must be set to "yes". 3. Reinstall converters/libiconv Now, libiconv.so.3 is back. At this point, my installed ports were running fine. I never reinstalled gettext so it never broke; you may have to. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EIE8ACgkQa+xGJsFYOlNqXQCfVaINbK4Wi+wuyazRLT9aa95o 4dgAoIlecAMgWti/SQhOf4UrVusiNGK0 =G2Bo -END PGP SIGNATURE- ___ 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"
