Re: ports that break using clang
Mark Linimon writes: > >I've found "wiki.freebsd.org/PortsAndClang" where the most > > recent list is from October. > >I know the build cluster is having problems, but is there a > > more recent list somewhere? > > There are no more recent builds, sorry. Drat. Thanks, Robert Huff ___ 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 that break using clang
On Sat, Jan 19, 2013 at 12:43:37AM -0500, Robert Huff wrote: > I've found "wiki.freebsd.org/PortsAndClang" where the most > recent list is from October. > I know the build cluster is having problems, but is there a > more recent list somewhere? There are no more recent builds, sorry. mcl ___ 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"
ports that break using clang
I've found "wiki.freebsd.org/PortsAndClang" where the most recent list is from October. I know the build cluster is having problems, but is there a more recent list somewhere? Robert Huff ___ 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"
Setting up tinderbox-devel on a pkgng system
Hi,
I'm in the process of setting up tinderbox and have encountered some troubles.
Looking at the code, tinderbox uses `pkg info -qgO` but passes package names
when, according to pkg-info(8) """-O Search is done by the
origin.""". So, no need for different checks per requirement.
Another issue with the above approach is that it fails to match against perl-
threaded-5.14. [1]
I've attached a patch that fixes those issues for me.
Another issue is that, by default, the port installs databases/p5-DBD-mysql
which is not a recognised port. The attached patch fixes that [2].
Regards,
[1] I think pkgng is partially broken as it will succeed in matching pkg names
when using `-O`. Not sure what the expected behaviour is though.
[2] I assumed that databases/p5-DBD-mysqlXY needs to correspond to
databases/mysqlXY-client (no idea if that is a correct assumption).
Only in scripts: ds.ph
diff -ur /usr/local/tinderbox/scripts/lib/db-mysql.sh scripts/lib/db-mysql.sh
--- /usr/local/tinderbox/scripts/lib/db-mysql.sh 2013-01-17 17:56:19.0 +0200
+++ scripts/lib/db-mysql.sh 2013-01-18 07:42:32.0 +0200
@@ -24,8 +24,8 @@
#
# $MCom: portstools/tinderbox/lib/db-mysql.sh,v 1.8 2012/10/27 17:38:49 marcus Exp $
#
-export DB_MAN_PREREQS="databases/p5-DBD-mysql[456][0145]@p5-DBD-mysql[456][0145]-* databases/mysql[456][0145]-client@mysql[456][0145]-client-*"
-export DB_OPT_PREREQS="databases/php5-mysql@php5-mysql-* databases/php5-pdo_mysql@php5-pdo_mysql-*"
+export DB_MAN_PREREQS="databases/p5-DBD-mysql[456][0145] databases/mysql[456][0145]-client"
+export DB_OPT_PREREQS="databases/php5-mysql databases/php5-pdo_mysql"
if [ -n "${db_admin_pass}" ]; then
export DB_PROMPT='true'
diff -ur /usr/local/tinderbox/scripts/lib/db-pgsql.sh scripts/lib/db-pgsql.sh
--- /usr/local/tinderbox/scripts/lib/db-pgsql.sh 2013-01-17 17:56:19.0 +0200
+++ scripts/lib/db-pgsql.sh 2013-01-18 07:43:07.0 +0200
@@ -24,8 +24,8 @@
#
# $MCom: portstools/tinderbox/lib/db-pgsql.sh,v 1.9 2012/10/27 17:38:49 marcus Exp $
#
-export DB_MAN_PREREQS="databases/p5-DBD-Pg@p5-DBD-Pg-* databases/postgresql*-client@postgresql*-client-*"
-export DB_OPT_PREREQS="databases/php5-pgsql@php5-pgsql-* databases/php5-pdo_pgsql@php5-pdo_pgsql-*"
+export DB_MAN_PREREQS="databases/p5-DBD-Pg databases/postgresql*-client"
+export DB_OPT_PREREQS="databases/php5-pgsql databases/php5-pdo_pgsql"
if [ -n "${db_admin_pass}" ]; then
export PGPASSWORD=${db_admin_pass}
diff -ur /usr/local/tinderbox/scripts/lib/db-sqlite.sh scripts/lib/db-sqlite.sh
--- /usr/local/tinderbox/scripts/lib/db-sqlite.sh 2013-01-17 17:56:19.0 +0200
+++ scripts/lib/db-sqlite.sh 2013-01-18 07:41:45.0 +0200
@@ -1,5 +1,5 @@
-export DB_MAN_PREREQS="databases/sqlite3@sqlite3-* databases/p5-DBD-SQLite@p5-DBD-SQLite-*"
-export DB_OPT_PREREQS="databases/php5-pdo_sqlite@php5-pdo_sqlite-*"
+export DB_MAN_PREREQS="databases/sqlite3 databases/p5-DBD-SQLite"
+export DB_OPT_PREREQS="databases/php5-pdo_sqlite"
export DB_PROMPT=''
export DB_SCHEMA_LOAD='/usr/local/bin/sqlite3 -batch ${db_name} < "${schema_file}"'
diff -ur /usr/local/tinderbox/scripts/lib/tc_command.sh scripts/lib/tc_command.sh
--- /usr/local/tinderbox/scripts/lib/tc_command.sh 2013-01-17 17:56:19.0 +0200
+++ scripts/lib/tc_command.sh 2013-01-18 07:40:58.0 +0200
@@ -296,8 +296,8 @@
#---
Setup () {
-MAN_PREREQS="lang/perl5.[81]*@perl-5.[81]*"
-OPT_PREREQS="lang/php[45]@php[45]-* www/php[45]-session@php[45]-session* archivers/p5-Compress-Bzip2@p5-Compress-Bzip2-*"
+MAN_PREREQS="lang/perl5.[81]*"
+OPT_PREREQS="lang/php[45] www/php[45]-session archivers/p5-Compress-Bzip2"
PREF_FILES="tinderbox.ph"
README="$(tinderLoc scripts README)"
TINDERBOX_URL="http://tinderbox.marcuscom.com/";
diff -ur /usr/local/tinderbox/scripts/lib/tinderlib.sh scripts/lib/tinderlib.sh
--- /usr/local/tinderbox/scripts/lib/tinderlib.sh 2013-01-17 17:56:19.0 +0200
+++ scripts/lib/tinderlib.sh 2013-01-18 07:39:29.0 +0200
@@ -690,16 +690,14 @@
use_pkgng=$(make -f /usr/ports/Mk/bsd.port.mk -VWITH_PKGNG)
for r in ${reqs} ; do
- png_r=${r##*@}
- p_r=${r%%@*}
if [ -n "${use_pkgng}" ]; then
-if [ -z "$(pkg info -qgO ${png_r})" ]; then
-missing="${missing} ${png_r}"
+if [ -z "$(pkg info -qgO ${r})" ]; then
+missing="${missing} ${r}"
error=1
fi
else
-if [ -z "$(pkg_info -Q -O ${p_r})" ]; then
-missing="${missing} ${p_r}"
+if [ -z "$(pkg_info -Q -O ${r})" ]; then
+missing="${missing} ${r}"
error=1
fi
fi
Only in scripts: tinderbox
Only in scripts: tinderbox.ph
Only in scripts: tinderbox.ph.bak
--- Makefile.orig 2013-01-18 07:49:57.0 +0200
+++ Makefile 2013-01-18 07:50:17.0
Ports, bsd.lib.mk and NOPROFILE
I just tried to build a system with -CURRENT from scratch, and it fell over in graphics/gd because NOPROFILE is now named NO_PROFILE in bsd.lib.mk grep(1) tells me that a number of other ports will also have this problem It may be appropriate with a bandaid in bsd.lib.mk, which emits a noisy warning, until all these ports are fixed. A good grep strategy is to look for files containing "NOPROFILE" and "bsd.lib.mk" but they need not be on the same line. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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/opera ISSUE Java Plugin missing
On 01/18/13 13:19, awarecons wrote: Are you saying the handbook instructions for enabling java in Opera do not work, then? Seems to be so in the case. You're doing something wrong, than. Opera 12.12 on my system catches java/icedtea-web I just installed Opera, launched it, and checked the plugin list[0,1]. I've installed the same vers. of plugin: icedtea-web-1.3.1 A free Java plug-in and Java Web Start for OpenJDK And, as it was mentioned above, IcedTeaPlugin.so is caught by FireFox, SeaMonkey, Chromium and Epiphany even)) except Opera. Obvious diff. is in arch (i386) and osvers. (9.0-REL-p5), but it would be strange if it really matters in the case... I don't think it would, but I only installed Opera to prove on my system whether or not Opera was catching the plugin. I think it's one of the worst browsers in existence (next to IE). May there be such dependence that java/icedtea-web needs to be installed _strictly_ after browser(s) installation, not before? I installed the icetea-web plugin after I installed Firefox and haven't touched it since then except for updates. I absolutely didn't issue a single command except to launch Opera after I installed it. So when I say I just installed Opera, that is all I literally did. Check ~/.opera/pluginpath.ini this is what mine looks like [Paths] /usr/local/lib/browser_plugins/symlinks/opera=1 /usr/local/lib/npapi/symlinks/opera=1 /usr/local/lib/npapi/symlinks/linux-opera=1 I have no idea if Opera catches any of these paths, these are the defaults upon install. -- Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.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: graphics/hugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/18/13 1:34 PM, Rainer Hurling wrote: > On 18.01.2013 18:48 (UTC+2), Greg Larkin wrote: >> On 1/18/13 12:00 PM, Rainer Hurling wrote: >>> On 18.01.2013 08:37 (UTC+2), Vasil Dimov wrote: On Thu, Jan 17, 2013 at 16:34:59 -0600, ajtiM wrote: > My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue > Dec 4 06:55:39 UTC 2012 > r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 > > clang -v: FreeBSD clang version 3.1 (branches/release_31 > 156863) 20120523 Target: i386-unknown-freebsd9.0 Thread > model: posix > > I try to update hugin (Chase OpenEXR lib update) with clang > but I got an error: > > > In file included from > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/vanilla/SimpleAtomicCount.cxx:26: > > >> > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:117:9: >> > error: void function 'createScope' should not return a > value [-Wreturn-type] return false; ^ ~ > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:121:5: > > error: void function 'createScope' should not return a value > [-Wreturn-type] return true; ^ 2 errors > generated. *** > [src/foreign/zthread/src/CMakeFiles/ZThread.dir/AtomicCount.cxx.o] > > Error code 1 [...] Hello, Do you have CC=clang CXX=clang++ CPP=clang-cpp in your environment, e.g. /etc/make.conf ? hugin does not seem to compile with clang. I fixed the above error but a set of another ones spills out. Can you try the attached patch which should force it to compile with gcc and confirm whether it fixes the problem for you? >> >>> Hi Vasil, >> >>> thanks for the patch for Makefile and >>> src/foreign/flann/util/logger.h. Both works nice for me on >>> recent 10.0-CURRENT amd64. >> >>> With USE_GCC=yes the patch uses lang/gcc46. Isn't USE_GCC=any >>> also sufficient, so we can use systems compiler gcc-4.2.1, if >>> present? >> >>> Rainer >> The clang compilation issues would better be addressed with the hugin authors. >> >> >> >> Hi all, > > hi Greg, > >> The build with clang dies inside of the zthread code included in >> the hugin distro, and I wonder if it would be fixed with the same >> patch that I committed to the devel/zthread port this week? > > very nice idea and problably the right one. > >> Here is the patch file for zthread's Guard.h file: >> >> http://svnweb.freebsd.org/ports/head/devel/zthread/files/patch-include__zthread__Guard.h?revision=310556&view=co > >> > I just tried your patch on hugin (my patch attached) with clang and > it builds and installs fine. A quick test using hugin also seems to > be ok. > > I did not use your fourth item in patching Guard.h, because it is > different from yours and should already ok for clang: > > in zthreads Guard.h:l.494 -if(!isDisabled()) + > if(!this->isDisabled()) LockingPolicy::destroyScope(*this); > > in hugins Guard.h:l.494 if(!LockHolder::isDisabled()) > LockingPolicy::destroyScope(*this); > > This should be ok within hugins Guard.h. What do you think about > it? > > Many thanks, Rainer > >> >> Hope that helps, Greg Hi Rainer, Yes, your patch for Guard.h looks fine, and I think it should be committed to the hugin port. Cheers, Greg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD5tvUACgkQ0sRouByUApC2cgCdGEfO2U8SZi+CHUzy/zyLCS98 xQsAoLWNRDRZPShsHwJuRFYKHBA7JQ3h =6Z87 -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"
Re: Using bidirectional authentication in pkgng
On 18/01/2013 02:57, Michael Gmelin wrote: > a. I understand that my use case is not necessarily pkgng's top >priority. Ultimately requirement 2 is pretty nonsensical for >distributing open source packages Well, yes. I must admit that ssh based transport authenticated with keys is not top of the list. Not that we have any objection to implementing all sorts of transport schemes, but the libfetch provided targets are the easiest and most popular use cases. If you really want this, please open an issue at GitHub. It will get dealt with eventually. Sooner if anyone wants to send a pull-request. > b. It still would be great if sftp could somehow be supported in the >future - or at least some syntax that allows external tools to be >called to accomplish the task. That way people could use sftp, curl >or what not to fetch packages. Hmmm... it may be possible to implement this sort of thing via a suitable modification of the plugin architecture. Incorporating new transport schemes is OK, so long as the code to do it is BSD licensed (or something compatible like the MIT or Apache licenses) and it doesn't add run-time dependencies to pkgng. (ie. we have to be able to compile it into the binaries so the pkg package can be installed standalone.) > c. libfetch really needs to get fixed to allow certificate verification >in its fetchX* and fetchHTTP* functions when using HTTPS. fetch(3) >is based on it and there is no indication anywhere whatsoever that >no checks are done at all (none of the libfetch or fetch utility man >pages mention it). This would be useful functionality to add to libfetch. However, support for DANE (RFC 6698) would be even better, IMHO. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: www/opera ISSUE Java Plugin missing
>Are you saying the handbook instructions for enabling java in Opera do not >work, then? Seems to be so in the case. >You're doing something wrong, than. Opera 12.12 on my system catches >java/icedtea-web I just installed Opera, launched it, and checked the plugin >list[0,1]. I've installed the same vers. of plugin: icedtea-web-1.3.1 A free Java plug-in and Java Web Start for OpenJDK And, as it was mentioned above, IcedTeaPlugin.so is caught by FireFox, SeaMonkey, Chromium and Epiphany even)) except Opera. List of plugins caught: Refresh plug-ins Disable Shockwave Flash Description: Shockwave Flash 11.2 r202 Architecture: non-native /usr/local/lib/npapi/symlinks/opera/libflashplayer.soapplication/futuresplash spl Disable VLC Multimedia Plugin (compatible Totem 2.32.0) Description: The Totem 2.32.0 plugin handles video and audio streams. Architecture: native /usr/local/lib/npapi/symlinks/opera/libtotem-cone-plugin.soaudio/midi midi,mid Disable Windows Media Player Plug-in 10 (compatible; Totem) Description: The Totem 2.32.0 plugin handles video and audio streams. Architecture: native /usr/local/lib/npapi/symlinks/opera/libtotem-gmp-plugin.sovideo/x-msvideo avi,asf,wmv Disable DivX® Web Player Description: DivX Web Player version 1.4.0.233 Architecture: native /usr/local/lib/npapi/symlinks/opera/libtotem-mully-plugin.sovideo/divx divx Disable QuickTime Plug-in 7.6.6 Description: The Totem 2.32.0 plugin handles video and audio streams. Architecture: native /usr/local/lib/npapi/symlinks/opera/libtotem-narrowspace-plugin.sovideo/mp4 mp4,mpg4 Disable DjView-4.9 Description: This is the DjView-4.9 version of the DjVu plugin. See DjVuLibre. Architecture: native /usr/local/lib/npapi/symlinks/opera/nsdejavu.soimage/x-djvu djvu,djv Enable Java(TM) Plug-in 1.6.0_38 Description: The next generation Java plug-in for Mozilla browsers. Architecture: non-native /usr/local/lib/npapi/symlinks/opera/libnpjp2.soapplication/x-java-vm Enable Adobe Reader 9.5 Description: The Adobe Reader plugin is used to enable viewing of PDF and FDF files from within the browser. Architecture: non-native /usr/local/lib/browser_plugins/nppdf.soapplication/pdf pdf Disable Adobe Reader 9.5 Description: The Adobe Reader plugin is used to enable viewing of PDF and FDF files from within the browser. Architecture: native /usr/local/lib/browser_plugins/npwrapper.nppdf.so Obvious diff. is in arch (i386) and osvers. (9.0-REL-p5), but it would be strange if it really matters in the case... May there be such dependence that java/icedtea-web needs to be installed _strictly_ after browser(s) installation, not before? 2013/1/18 Joseph A. Nagy, Jr : > On 01/18/13 09:06, awarecons wrote: >> >> As it was mentioned above: since Opera 10.50 it doesn't use Java >> directly, hence it looks for a special Java plugin file libnpjp2.so >> and ONLY! >> >> The problem is that the file libnpjp2.so residues in >> linux-sun-jre1[67] only, not in openjdk nor diablo nor jdk16 editions, >> though available is non-native only. > > > Are you saying the handbook instructions for enabling java in Opera do not > work, then? > > >> Cut from opera:plugins (java/linux-sun-jre16): >> Java(TM) Plug-in 1.6.0_38 >> Description: The next generation Java plug-in for Mozilla browsers. >> Architecture: non-native >> /usr/local/lib/npapi/symlinks/opera/libnpjp2.so >> >> Of course it fails to start properly and crashes after is called. >> >> A try to nspluginwrapper it fails: >> >> nspluginwrapper -v -i /usr/local/linux-sun-jre1.6.0/lib/i386/libnpjp2.so >> *** NSPlugin Viewer *** ERROR: libnpjp2.so: cannot open shared object >> file: No such file or directory >> *** NSPlugin Viewer *** ERROR: libnpjp2.so: cannot open shared object >> file: No such file or directory >> nspluginwrapper: no appropriate viewer found for libnpjp2.so >> >> Opera 12.12 rejects classic plugin file javaplugin-oji.so and >> IcedTeaPlugin.so (tested). >> >> It would be keen to update the Handbook part 7.2.5 Opera of >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html, >> that it doesn't support java/icedtea-web anymore? >> >> All the steps from Handbook had been taken, and IcedTeaPlugin.so is >> caught by FireFox, SeaMonkey, Chromium... but Opera 12.12 > > > You're doing something wrong, than. Opera 12.12 on my system catches > java/icedtea-web I just installed Opera, launched it, and checked the plugin > list[0,1]. > > >> . >> Additional Notes from Oracle >> >> (http://www.oracle.com/technetwork/java/javase/manual-plugin-install-linux-136395.html): >> >> The classic plugin file was located here: >> >> /plugin/i386/javaplugin-oji.so >> >> >> __This file should no longer be used and all symbolic links to it >> removed__. >> >> >> Thank you. > > > [0]: http://www.joseph-a-nagy-jr.us/images/problems/opera-version.png > [1]: http://www.joseph-a-nagy-jr.us/images/problems/opera-plugins.png > > -- > Yours in Christ, > > Joseph A Nagy Jr > "Whoever loves instruction loves kn
Re: FreeBSD Port: graphics/hugin
On 18.01.2013 18:48 (UTC+2), Greg Larkin wrote:
> On 1/18/13 12:00 PM, Rainer Hurling wrote:
>> On 18.01.2013 08:37 (UTC+2), Vasil Dimov wrote:
>>> On Thu, Jan 17, 2013 at 16:34:59 -0600, ajtiM wrote:
My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec
4 06:55:39 UTC 2012
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
clang -v: FreeBSD clang version 3.1 (branches/release_31
156863) 20120523 Target: i386-unknown-freebsd9.0 Thread model:
posix
I try to update hugin (Chase OpenEXR lib update) with clang but
I got an error:
In file included from
/usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/vanilla/SimpleAtomicCount.cxx:26:
> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:117:9:
>
error: void function 'createScope' should not return a value
[-Wreturn-type] return false; ^ ~
/usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:121:5:
error: void function 'createScope' should not return a value
[-Wreturn-type] return true; ^ 2 errors generated.
***
[src/foreign/zthread/src/CMakeFiles/ZThread.dir/AtomicCount.cxx.o]
Error code 1
>>> [...]
>>>
>>> Hello,
>>>
>>> Do you have
>>>
>>> CC=clang CXX=clang++ CPP=clang-cpp
>>>
>>> in your environment, e.g. /etc/make.conf ?
>>>
>>> hugin does not seem to compile with clang. I fixed the above
>>> error but a set of another ones spills out.
>>>
>>> Can you try the attached patch which should force it to compile
>>> with gcc and confirm whether it fixes the problem for you?
>
>> Hi Vasil,
>
>> thanks for the patch for Makefile and
>> src/foreign/flann/util/logger.h. Both works nice for me on recent
>> 10.0-CURRENT amd64.
>
>> With USE_GCC=yes the patch uses lang/gcc46. Isn't USE_GCC=any also
>> sufficient, so we can use systems compiler gcc-4.2.1, if present?
>
>> Rainer
>
>>> The clang compilation issues would better be addressed with the
>>> hugin authors.
>>>
>
>
>
> Hi all,
hi Greg,
> The build with clang dies inside of the zthread code included in the
> hugin distro, and I wonder if it would be fixed with the same patch
> that I committed to the devel/zthread port this week?
very nice idea and problably the right one.
> Here is the patch file for zthread's Guard.h file:
>
> http://svnweb.freebsd.org/ports/head/devel/zthread/files/patch-include__zthread__Guard.h?revision=310556&view=co
I just tried your patch on hugin (my patch attached) with clang and it
builds and installs fine. A quick test using hugin also seems to be ok.
I did not use your fourth item in patching Guard.h, because it is
different from yours and should already ok for clang:
in zthreads Guard.h:l.494
-if(!isDisabled())
+if(!this->isDisabled())
LockingPolicy::destroyScope(*this);
in hugins Guard.h:l.494
if(!LockHolder::isDisabled())
LockingPolicy::destroyScope(*this);
This should be ok within hugins Guard.h. What do you think about it?
Many thanks,
Rainer
>
> Hope that helps,
> Greg
diff -Naur hugin.orig/files/patch-src__foreign__flann__util__logger.h
hugin/files/patch-src__foreign__flann__util__logger.h
--- hugin.orig/files/patch-src__foreign__flann__util__logger.h 1970-01-01
01:00:00.0 +0100
+++ hugin/files/patch-src__foreign__flann__util__logger.h 2013-01-18
19:05:12.0 +0100
@@ -0,0 +1,10 @@
+--- src/foreign/flann/util/logger.h.orig 2011-12-02 18:02:36.925022000
+0100
src/foreign/flann/util/logger.h2013-01-18 19:04:18.0 +0100
+@@ -32,6 +32,7 @@
+ #define LOGGER_H
+
+ #include
++#include
+ #include "flann/general.h"
+
+
diff -Naur
hugin.orig/files/patch-src__foreign__zthread__include__zthread__Guard.h
hugin/files/patch-src__foreign__zthread__include__zthread__Guard.h
--- hugin.orig/files/patch-src__foreign__zthread__include__zthread__Guard.h
1970-01-01 01:00:00.0 +0100
+++ hugin/files/patch-src__foreign__zthread__include__zthread__Guard.h
2013-01-18 19:10:18.0 +0100
@@ -0,0 +1,31 @@
+--- src/foreign/zthread/include/zthread/Guard.h.orig 2011-12-02
18:02:37.253022000 +0100
src/foreign/zthread/include/zthread/Guard.h2013-01-18
19:08:14.0 +0100
+@@ -108,7 +108,7 @@
+ }
+
+ template
+- static void createScope(LockHolder& l, unsigned long ms) {
++ static bool createScope(LockHolder& l, unsigned long ms) {
+
+ if(Scope1::createScope(l, ms))
+ if(!Scope2::createScope(l, ms)) {
+@@ -428,8 +428,8 @@
+ template
+ Guard(Guard& g) : LockHolder(g) {
+
+-LockingPolicy::shareScope(*this, extract(g));
+-
++LockingPolicy::shareScope(*this, this->extract(g));
++
+ }
+
+ /**
+@@ -458,7 +458,7 @@
+ template
+ Guard(Guard& g, LockType& lock) : LockHolder(lock) {
+
+-LockingPolicy::transferScope(*this, extract(g));
++LockingPolicy::trans
Re: www/firefox [18.0,1] compilation error
Looks a bit variative (after patches of January, 11th?):
g++46 -o Debugger.o -c -I./../../dist/system_wrappers_js -include
/usr/ports/www/firefox/work/mozilla-release/js/src/config/gcc_hidden.h
-DENABLE_TYPEDARRAY_MOVE -DENABLE_YARR_JIT=1 -DMOZ_GLUE_IN_PROGRAM
-DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\"
-DDLL_SUFFIX=\".so\" -DNO_NSPR_10_SUPPORT -DUSE_ZLIB
-I/usr/local/lib/libffi-3.0.9/include -I.
-I/usr/ports/www/firefox/work/mozilla-release/js/src/../../mfbt/double-conversion
-I/usr/ports/www/firefox/work/mozilla-release/js/src -I.
-I./../../dist/include -I/usr/local/include/nspr
-I/usr/ports/www/firefox/work/mozilla-release/js/src
-I/usr/ports/www/firefox/work/mozilla-release/js/src/assembler
-I/usr/ports/www/firefox/work/mozilla-release/js/src/yarr -fPIC -O2
-pipe -march=pentium4 -mtune=pentium4 -Wno-error -w
-isystem/usr/local/include -I/usr/local/include -Wall -Wpointer-arith
-Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body
-Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings
-Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -O2 -pipe
-march=pentium4 -mtune=pentium4 -Wl,-rpath=/usr/local/lib/gcc46
-fno-strict-aliasing -O2 -pipe -march=pentium4 -mtune=pentium4
-Wno-error -w -Wl,-rpath=/usr/local/lib/gcc46 -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -pipe -DNDEBUG
-DTRIMMED -fprofile-use -fprofile-correction -Wcoverage-mismatch -O2
-fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1
-DENABLE_JIT=1 -O2 -pipe -march=pentium4 -mtune=pentium4 -Wno-error
-w -isystem/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT
-include ./js-confdefs.h -MD -MF .deps/Debugger.o.pp
/usr/ports/www/firefox/work/mozilla-release/js/src/vm/Debugger.cpp
/usr/ports/www/firefox/work/mozilla-release/js/src/vm/Debugger.cpp: In
static member function 'static JSTrapStatus
js::Debugger::onSingleStep(JSContext*, JS::Value*)':
/usr/ports/www/firefox/work/mozilla-release/js/src/vm/Debugger.cpp:1170:14:
error: 'frame' was not declared in this scope
gmake[5]: *** [Debugger.o] Error 1
2013/1/13 awarecons :
> gmake[6]: Entering directory
> `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd9.0/layout/style'
> g++46 -o nsCSSRuleProcessor.i_o -c -I../../dist/stl_wrappers
> -I../../dist/system_wrappers -include
> /usr/ports/www/firefox/work/mozilla-release/config/gcc_hidden.h
> -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
> -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET
> -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API
> -DEXCLUDE_SKIA_DEPENDENCIES -DOS_POSIX=1 -DOS_FREEBSD=1 -DOS_BSD=1
> -D_IMPL_NS_LAYOUT
> -I/usr/ports/www/firefox/work/mozilla-release/ipc/chromium/src
> -I/usr/ports/www/firefox/work/mozilla-release/ipc/glue
> -I../../ipc/ipdl/_ipdlheaders
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../base
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../generic
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../xul/base/src
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../../content/base/src
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../../content/html/content/src
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../../content/xbl/src
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style/../../content/xul/document/src
> -I/usr/ports/www/firefox/work/mozilla-release/layout/style -I.
> -I../../dist/include -I/usr/local/include/nspr
> -I/usr/local/include/nss -I/usr/local/include/nss/nss
> -I/usr/local/include -I/usr/local/include-fPIC -O2 -pipe
> -march=pentium4 -mtune=pentium4 -Wno-error -w
> -isystem/usr/local/include -I/usr/local/include -Wall -Wpointer-arith
> -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body
> -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings
> -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -O2 -pipe
> -march=pentium4 -mtune=pentium4 -Wl,-rpath=/usr/local/lib/gcc46
> -fno-strict-aliasing -O2 -pipe -march=pentium4 -mtune=pentium4
> -Wno-error -w -Wl,-rpath=/usr/local/lib/gcc46 -fno-exceptions
> -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections
> -fno-exceptions -std=gnu++0x -pipe -DNDEBUG -DTRIMMED
> -fprofile-generate -O2 -fomit-frame-pointer -O2 -pipe -march=pentium4
> -mtune=pentium4 -Wno-error -w -isystem/usr/local/include
> -I/usr/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h
> -MD -MF .deps/nsCSSRuleProcessor.i_o.pp
> /usr/ports/www/firefox/work/mozilla-release/layout/style/nsCSSRuleProcessor.cpp
> /usr/ports/www/firefox/work/mozilla-release/layout/style/nsCSSRuleProcessor.cpp:
> In function 'bool SelectorMatches(mozilla::dom::Element*,
> nsCSSSelector*, NodeMatchContext&, TreeMatchContext&, bool*)':
> /usr/ports/www/firefox/work/mozilla-release/layout/style/nsCSSRuleProcessor.cpp:1790:9:
> error: expected ';' before '{' token
> /usr/ports/www/firefox/work/moz
Re: FreeBSD Port: graphics/hugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/18/13 12:00 PM, Rainer Hurling wrote: > On 18.01.2013 08:37 (UTC+2), Vasil Dimov wrote: >> On Thu, Jan 17, 2013 at 16:34:59 -0600, ajtiM wrote: >>> My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec >>> 4 06:55:39 UTC 2012 >>> r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> clang -v: FreeBSD clang version 3.1 (branches/release_31 >>> 156863) 20120523 Target: i386-unknown-freebsd9.0 Thread model: >>> posix >>> >>> I try to update hugin (Chase OpenEXR lib update) with clang but >>> I got an error: >>> >>> >>> In file included from >>> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/vanilla/SimpleAtomicCount.cxx:26: >>> >>> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:117:9: >>> error: void function 'createScope' should not return a value >>> [-Wreturn-type] return false; ^ ~ >>> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:121:5: >>> error: void function 'createScope' should not return a value >>> [-Wreturn-type] return true; ^ 2 errors generated. >>> *** >>> [src/foreign/zthread/src/CMakeFiles/ZThread.dir/AtomicCount.cxx.o] >>> Error code 1 >> [...] >> >> Hello, >> >> Do you have >> >> CC=clang CXX=clang++ CPP=clang-cpp >> >> in your environment, e.g. /etc/make.conf ? >> >> hugin does not seem to compile with clang. I fixed the above >> error but a set of another ones spills out. >> >> Can you try the attached patch which should force it to compile >> with gcc and confirm whether it fixes the problem for you? > > Hi Vasil, > > thanks for the patch for Makefile and > src/foreign/flann/util/logger.h. Both works nice for me on recent > 10.0-CURRENT amd64. > > With USE_GCC=yes the patch uses lang/gcc46. Isn't USE_GCC=any also > sufficient, so we can use systems compiler gcc-4.2.1, if present? > > Rainer > >> The clang compilation issues would better be addressed with the >> hugin authors. >> > > Hi all, The build with clang dies inside of the zthread code included in the hugin distro, and I wonder if it would be fixed with the same patch that I committed to the devel/zthread port this week? Here is the patch file for zthread's Guard.h file: http://svnweb.freebsd.org/ports/head/devel/zthread/files/patch-include__zthread__Guard.h?revision=310556&view=co Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD5iuMACgkQ0sRouByUApBLDACcC//v9Eh1FarE5hquSOXCJTCW dkQAn28D/1xJ+FytgzRrRgUN3lDiIA6g =mvIm -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"
Re: FreeBSD Port: graphics/hugin
On 18.01.2013 08:37 (UTC+2), Vasil Dimov wrote: > On Thu, Jan 17, 2013 at 16:34:59 -0600, ajtiM wrote: >> My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 >> UTC >> 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> clang -v: FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 >> Target: i386-unknown-freebsd9.0 >> Thread model: posix >> >> I try to update hugin (Chase OpenEXR lib update) with clang but I got an >> error: >> >> >> In file included from >> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/vanilla/SimpleAtomicCount.cxx:26: >> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:117:9: >> >> error: >> void function 'createScope' should not return a value [-Wreturn-type] >> return false; >> ^ ~ >> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:121:5: >> >> error: >> void function 'createScope' should not return a value [-Wreturn-type] >> return true; >> ^ >> 2 errors generated. >> *** [src/foreign/zthread/src/CMakeFiles/ZThread.dir/AtomicCount.cxx.o] Error >> code 1 > [...] > > Hello, > > Do you have > > CC=clang > CXX=clang++ > CPP=clang-cpp > > in your environment, e.g. /etc/make.conf ? > > hugin does not seem to compile with clang. I fixed the above error but a > set of another ones spills out. > > Can you try the attached patch which should force it to compile with gcc > and confirm whether it fixes the problem for you? Hi Vasil, thanks for the patch for Makefile and src/foreign/flann/util/logger.h. Both works nice for me on recent 10.0-CURRENT amd64. With USE_GCC=yes the patch uses lang/gcc46. Isn't USE_GCC=any also sufficient, so we can use systems compiler gcc-4.2.1, if present? Rainer > The clang compilation issues would better be addressed with the hugin > authors. > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/p5-Devel-LexAlias | 0.04| 0.05 +-+ lang/bigloo | 3.8c| 4.0a +-+ sysutils/fusefs-smbnetfs| 0.5.3a | 0.5.3 +-+ www/py-webware | 1.1 | 1.1.1 +-+ www/xist| 3.25| 4.9.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/opera ISSUE Java Plugin missing
On 01/18/13 09:06, awarecons wrote: As it was mentioned above: since Opera 10.50 it doesn't use Java directly, hence it looks for a special Java plugin file libnpjp2.so and ONLY! The problem is that the file libnpjp2.so residues in linux-sun-jre1[67] only, not in openjdk nor diablo nor jdk16 editions, though available is non-native only. Are you saying the handbook instructions for enabling java in Opera do not work, then? Cut from opera:plugins (java/linux-sun-jre16): Java(TM) Plug-in 1.6.0_38 Description: The next generation Java plug-in for Mozilla browsers. Architecture: non-native /usr/local/lib/npapi/symlinks/opera/libnpjp2.so Of course it fails to start properly and crashes after is called. A try to nspluginwrapper it fails: nspluginwrapper -v -i /usr/local/linux-sun-jre1.6.0/lib/i386/libnpjp2.so *** NSPlugin Viewer *** ERROR: libnpjp2.so: cannot open shared object file: No such file or directory *** NSPlugin Viewer *** ERROR: libnpjp2.so: cannot open shared object file: No such file or directory nspluginwrapper: no appropriate viewer found for libnpjp2.so Opera 12.12 rejects classic plugin file javaplugin-oji.so and IcedTeaPlugin.so (tested). It would be keen to update the Handbook part 7.2.5 Opera of http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html, that it doesn't support java/icedtea-web anymore? All the steps from Handbook had been taken, and IcedTeaPlugin.so is caught by FireFox, SeaMonkey, Chromium... but Opera 12.12 You're doing something wrong, than. Opera 12.12 on my system catches java/icedtea-web I just installed Opera, launched it, and checked the plugin list[0,1]. . Additional Notes from Oracle (http://www.oracle.com/technetwork/java/javase/manual-plugin-install-linux-136395.html): The classic plugin file was located here: /plugin/i386/javaplugin-oji.so __This file should no longer be used and all symbolic links to it removed__. Thank you. [0]: http://www.joseph-a-nagy-jr.us/images/problems/opera-version.png [1]: http://www.joseph-a-nagy-jr.us/images/problems/opera-plugins.png -- Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.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"
Freeglut not installing on 9.1?
Hi all -- Just a quick question... Is it just me or is anyone else having issues with freeglut not building (and, as a consequence, a whole bunch of stuff that relies on graphics)? I've searched, but couldn't find out if there's a general problem here, FreeBSD-realted, or if it's an upstream issue. TIA, Hank ___ 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/opera ISSUE Java Plugin missing
As it was mentioned above: since Opera 10.50 it doesn't use Java directly, hence it looks for a special Java plugin file libnpjp2.so and ONLY! The problem is that the file libnpjp2.so residues in linux-sun-jre1[67] only, not in openjdk nor diablo nor jdk16 editions, though available is non-native only. Cut from opera:plugins (java/linux-sun-jre16): Java(TM) Plug-in 1.6.0_38 Description: The next generation Java plug-in for Mozilla browsers. Architecture: non-native /usr/local/lib/npapi/symlinks/opera/libnpjp2.so Of course it fails to start properly and crashes after is called. A try to nspluginwrapper it fails: nspluginwrapper -v -i /usr/local/linux-sun-jre1.6.0/lib/i386/libnpjp2.so *** NSPlugin Viewer *** ERROR: libnpjp2.so: cannot open shared object file: No such file or directory *** NSPlugin Viewer *** ERROR: libnpjp2.so: cannot open shared object file: No such file or directory nspluginwrapper: no appropriate viewer found for libnpjp2.so Opera 12.12 rejects classic plugin file javaplugin-oji.so and IcedTeaPlugin.so (tested). It would be keen to update the Handbook part 7.2.5 Opera of http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html, that it doesn't support java/icedtea-web anymore? All the steps from Handbook had been taken, and IcedTeaPlugin.so is caught by FireFox, SeaMonkey, Chromium... but Opera 12.12 . Additional Notes from Oracle (http://www.oracle.com/technetwork/java/javase/manual-plugin-install-linux-136395.html): The classic plugin file was located here: /plugin/i386/javaplugin-oji.so __This file should no longer be used and all symbolic links to it removed__. Thank you. 2013/1/18 Joseph A. Nagy, Jr : > On 01/17/13 13:47, awarecons wrote: >> As of official http://www.opera.com/docs/linux/plugins/install/#java >> >> Java plug-in (Sun/Oracle) >> >> As of Opera 10.50, Opera uses the Java plug-in. Previously Opera used >> the Java Runtime Environment (JRE) directly. > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html > > > 7.2.5 Opera > > Opera is a full-featured and standards-compliant browser. It also comes > with a built-in mail and news reader, an IRC client, an RSS/Atom feeds > reader and much more. Despite this, Opera is relatively lightweight and > very fast. It comes in two flavors: a “native” FreeBSD version and a > version that runs under Linux emulation. > > To browse the Web with the FreeBSD version of Opera, install the package: > > # pkg_add -r opera > > Some FTP sites do not have all the packages, but Opera can still be > obtained through the Ports Collection by typing: > > # cd /usr/ports/www/opera > # make install clean > > To install the Linux version of Opera, substitute linux-opera in place > of opera in the example above. > > The Adobe Flash plugin is not available for FreeBSD. However, a Linux® > version of the plugin exists. To install this version, the > www/linux-f10-flashplugin11 port has to be installed, then install the > port www/opera-linuxplugins: > > # cd /usr/ports/www/linux-f10-flashplugin11 > # make install clean > # cd /usr/ports/www/opera-linuxplugins > # make install clean > > You can check the presence of the plugin: start your browser, enter > opera:plugins in the location bar and press Enter. A list should appear > with all the currently available plugins. > > To add the Java plugin, follow the instructions for Firefox[0]. > > [0]: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html#moz-java-plugin > -- > Yours in Christ, > > Joseph A Nagy Jr > "Whoever loves instruction loves knowledge, But he who hates correction > is stupid." -- Proverbs 12:1 > Emails are not formal business letters, whatever businesses may want. > Original content CopyFree (F) under the OWL http://owl.apotheon.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/opera ISSUE Java Plugin missing
On 01/18/13 05:55, Jakub Lach wrote: You are missing my point. Opera couldn't just outright stop 'supporting' Java plug-ins (more like Java content, believe it or not, but using plug-in or JRE is secondary here), but they are not ones responsible for this environment deployment. No, I don't think I did miss your point. The Opera developers didn't, from the OP, they switched from JRE to plug-ins. The Opera developers can be the only ones because they are the only ones developing Opera. Certainly Oracle isn't forcing anyone to use the plug-in over the run-time environment. I know FreeBSD as a project should document to the it's best ability all possible use cases one could be forced into (including using Java plug-in). I think it does good job mostly. I think they do an excellent job. That doesn't stop me from a little rant on the side, though... And hopefully it goes my way: http://w3techs.com/technologies/details/cp-javaruntime/all/all But that doesn't stop people from installing plug-in en masse, which starts to defy reason: http://www.statowl.com/plugin_overview.php To be honest, I'm not interested in plug-in-vs.-run-time-environment arguments. Having been knee-deep in the browser wars and having advocated Linux (and more recently, FreeBSD) over any other operating system, I just couldn't give a rip about any such arguments over anything else (including OS and browser preference) anymore. I'm more in the "best tool for the job, with a favoring of copyfree licensing over any other all else being equal" camp now-a-days. If something stops supporting something I felt critical, if there is a better (or technically equal but better licensed) alternative, I'll just switch to it. It just happens to be the OP wanted Jave RE for Opera instead of the plug-in model and may have found a hackity-hack way of doing so despite the Opera people moving to the plug-in model. Given your view of plugins, if you don't want to extend the functionality of your browser through them, that's fine. You may even have a point about their awful security. I have no such concerns. Not because I have no concerns about security, but because I take other steps to mitigate my exposure to malicious web sites. Also, I'm partially insulted by your logic that somehow installing a plug-in of any sort "defies reason." There are many reasons people will install the Java plugin. I happen to want to be able to play Runescape (a very popular browser-based MMO). That and the fact some other websites (like, last time I visited, the Small Business Administration website along with a few others) do use Java, I would like to be able to view them (it's the same reason I use Flash, not because I like it, but because it's necessary for my being able to visit various websites). -- Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.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: graphics/gd fails to install
(maintainer is CCed)
17.01.2013 21:35, John-Mark Gurney пишет:
> Looks like some fall out from the removal of old no underscore options..
>
> Does anyone mind if I commit this patch:
> Index: graphics/gd/files/Makefile.bsd
> ===
> --- graphics/gd/files/Makefile.bsd(revision 310554)
> +++ graphics/gd/files/Makefile.bsd(working copy)
> @@ -40,7 +40,7 @@
>
> install:
> mkdir -p ${PREFIX}/include
> - ${MAKE} LIB=${LIB} LIBDIR=${PREFIX}/lib NOPROFILE=true \
> + ${MAKE} LIB=${LIB} LIBDIR=${PREFIX}/lib NO_PROFILE=true \
> SHLIB_MAJOR=${SHLIB_MAJOR} SHLIB_MINOR=${SHLIB_MINOR} \
> -f ${MAKEDIR}/bsd.lib.mk install
> cd ${.CURDIR} && ${BSD_INSTALL_DATA} ${INCS} ${PREFIX}/include
>
> w/o it on a recent HEAD it tries to install libgd_p.a which isn't built...
Hereby confirm the bug and the fix at:
-
% uname -a
FreeBSD BB051.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r245551: Thu
Jan 17 18:07:59 SAMT 2013
b...@bb051.wart.ru:/usr/obj/usr/src/sys/BB64X amd64
-
Thanks!
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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/opera ISSUE Java Plugin missing
You are missing my point. Opera couldn't just outright stop 'supporting' Java plug-ins (more like Java content, believe it or not, but using plug-in or JRE is secondary here), but they are not ones responsible for this environment deployment. I know FreeBSD as a project should document to the it's best ability all possible use cases one could be forced into (including using Java plug-in). I think it does good job mostly. That doesn't stop me from a little rant on the side, though... And hopefully it goes my way: http://w3techs.com/technologies/details/cp-javaruntime/all/all But that doesn't stop people from installing plug-in en masse, which starts to defy reason: http://www.statowl.com/plugin_overview.php -- View this message in context: http://freebsd.1045724.n5.nabble.com/www-opera-ISSUE-Java-Plugin-missing-tp5778625p5778824.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: graphics/hugin
On Friday 18 January 2013 01:37:15 Vasil Dimov wrote: > On Thu, Jan 17, 2013 at 16:34:59 -0600, ajtiM wrote: > > My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 > > 06:55:39 UTC 2012 > > r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > > > clang -v: FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 > > Target: i386-unknown-freebsd9.0 > > Thread model: posix > > > > I try to update hugin (Chase OpenEXR lib update) with clang but I got an > > error: > > > > > > In file included from > > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/van > > illa/SimpleAtomicCount.cxx:26: > > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/.. > > /include/zthread/Guard.h:117:9: > > > > error: > > void function 'createScope' should not return a value > > [-Wreturn-type] > > > > return false; > > ^ ~ > > > > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../ > > include/zthread/Guard.h:121:5: > > > > error: > > void function 'createScope' should not return a value > > [-Wreturn-type] > > > > return true; > > ^ > > > > 2 errors generated. > > *** [src/foreign/zthread/src/CMakeFiles/ZThread.dir/AtomicCount.cxx.o] > > Error code 1 > > [...] > > Hello, > > Do you have > > CC=clang > CXX=clang++ > CPP=clang-cpp > > in your environment, e.g. /etc/make.conf ? > > hugin does not seem to compile with clang. I fixed the above error but a > set of another ones spills out. > > Can you try the attached patch which should force it to compile with gcc > and confirm whether it fixes the problem for you? > > The clang compilation issues would better be addressed with the hugin > authors. Yes, I have CC=clang...in /etc/make.conf. I will use gcc. Thank you. Mitja http://www.redbubble.com/people/lumiwa ___ 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: [RFC] update of Tcl/Tk to 8.6.0
On 18 January 2013 08:41, Pietro Cerutti wrote:
> Hello again,
>
> here [1] is an updated patch, also including other Tcl/Tk -related
> ports, which pertains to the following actions:
>
> - update Tcl/Tk to 8.6.0. I'm still not convinced that bundled packages
> (itcl, sqlite3, tdbc, thread) should be installed, as ports exist for
> all of them.
>
> - enable (OPTIONally) threads on Tcl/Tk 8.4, 8.5, and 8.6. Remove -thread
> slave ports.
>
> - enable (OPTIONally) bundled modules on Tcl 8.5 and 8.6. Modules are
> installed in version-specific locations, so the two versions do not
> interfere with one other. Remove tcl-modules slave port.
>
> - fix man pages conflicts among ports (thanks bf@ for the discussion).
> This is handled by adding a ${LATEST_LINK} suffix to all the man
> pages names, e.g.,
> wish(1) --> 'man wish.tk86' or 'man wish.tk85'
> string(n) --> 'man string.tcl86' or 'man string.tcl85'
>
> [1] http://people.freebsd.org/~gahr/tcltk-patch.diff
>
> If nothing serious comes up, I plan to get this comitted next week.
>
> Thanks for your time,
I would also add CONFLICTS_INSTALL on the old tcl-modules ports; this
will force people to deinstall it *before* they install the new tcl
ports, and thus avoid them breaking stuff by deinstalling it later.
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: java/jdk16 ISSUE outdated info in Makefile
On Thu, Jan 17, 2013 at 11:15:08PM +0400, awarecons wrote: > 1. Patchset download fails: > http://www.eyesbeyond.com/freebsddom/java/jdk16.html fails > (temporary?) to give any of 1-4 or current patchsets > (bsd-jdk16-patches-4.tar.bz2) > > working: > http://www.filewatcher.com/m/bsd-jdk16-patches-4.tar.bz2.960930-0.html > > 2. tzupdater-1_3_42-2011k.zip is outdated, current is: > > http://download.oracle.com/otn-pub/java/tzupdater/1.3.53/tzupdater-1_3_53-2012j.zip > > so ports/java/jdk16/Makefile should be changed to > > TZUPDATE_VERSION=<->1_3_53 > TZUPDATE_TZVERSION=<--->2012j > > and ../distinfo respectively. > > And again, as in java/openjdk6 and may be other java ports, - silent > usage of -march=586 overriding system-wide march/mtune. The jdk16 port has been removed from the ports tree for some time now. Please use openjdk6 instead. -- Greg Lewis Email : gle...@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : gle...@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"
