LUA fails upgrade on 7.2/amd64
---> Upgrading 'lua-5.1.4' to 'lua-5.1.4_1' (lang/lua) ---> Building '/usr/ports/lang/lua' ===> Cleaning for lua-5.1.4_1 ===> License check disabled, port has not defined LICENSE ===> Extracting for lua-5.1.4_1 => MD5 Checksum OK for lua-5.1.4.tar.gz. => SHA256 Checksum OK for lua-5.1.4.tar.gz. ===> Patching for lua-5.1.4_1 ===> Applying FreeBSD patches for lua-5.1.4_1 ===> lua-5.1.4_1 depends on executable: pkg-config - found ===> Configuring for lua-5.1.4_1 ===> Building for lua-5.1.4_1 cd src && make freebsd make all MYCFLAGS="-DLUA_USE_LINUX" MYLIBS="-Wl,-E -lreadline" cc -pipe -O -Wall -DLUA_USE_LINUX -c lapi.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lcode.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ldebug.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ldo.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ldump.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lfunc.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lgc.c cc -pipe -O -Wall -DLUA_USE_LINUX -c llex.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lmem.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lobject.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lopcodes.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lparser.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lstate.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lstring.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ltable.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ltm.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lundump.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lvm.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lzio.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lauxlib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lbaselib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ldblib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c liolib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lmathlib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c loslib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c ltablib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lstrlib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c loadlib.c cc -pipe -O -Wall -DLUA_USE_LINUX -c linit.c cc -pipe -O -Wall -DLUA_USE_LINUX -c lua.c cc -pipe -O -Wall -DLUA_USE_LINUX -c luac.c cc -pipe -O -Wall -DLUA_USE_LINUX -c print.c cc -o liblua.so -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o /usr/bin/ld: lapi.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/lang/lua. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20100907-97247-142gdn1-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=lua-5.1.4 UPGRADE_PORT_VER=5.1.4 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! lang/lua (lua-5.1.4) (unknown build error) Any hint? 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"
multimedia/gstreamer-plugins-ugly compile failure distinfo bad
Hi Thanks in advance for fixing dns1# cd /usr/ports/multimedia/gstreamer-plugins-ugly dns1# make clean ===> Cleaning for gstreamer-plugins-ugly-0.10.16,3 dns1# make ===> License check disabled, port has not defined LICENSE => gst-plugins-ugly-0.10.16.tar.bz2 is not in /usr/ports/multimedia/gstreamer- plugins-ugly/../../multimedia/gstreamer-plugins/distinfo. => Either /usr/ports/multimedia/gstreamer-plugins- ugly/../../multimedia/gstreamer-plugins/distinfo is out of date, or => gst-plugins-ugly-0.10.16.tar.bz2 is spelled incorrectly. *** Error code 1 Stop in /usr/ports/multimedia/gstreamer-plugins-ugly. David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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: LUA fails upgrade on 7.2/amd64
Andrea Venturoli writes: > ---> Upgrading 'lua-5.1.4' to 'lua-5.1.4_1' (lang/lua) > ---> Building '/usr/ports/lang/lua' > ===> Cleaning for lua-5.1.4_1 > ===> License check disabled, port has not defined LICENSE > ===> Extracting for lua-5.1.4_1 > => MD5 Checksum OK for lua-5.1.4.tar.gz. > => SHA256 Checksum OK for lua-5.1.4.tar.gz. > ===> Patching for lua-5.1.4_1 > ===> Applying FreeBSD patches for lua-5.1.4_1 > ===> lua-5.1.4_1 depends on executable: pkg-config - found > ===> Configuring for lua-5.1.4_1 > ===> Building for lua-5.1.4_1 > cd src && make freebsd > make all MYCFLAGS="-DLUA_USE_LINUX" MYLIBS="-Wl,-E -lreadline" > cc -pipe -O -Wall -DLUA_USE_LINUX -c lapi.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lcode.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ldebug.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ldo.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ldump.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lfunc.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lgc.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c llex.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lmem.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lobject.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lopcodes.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lparser.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lstate.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lstring.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ltable.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ltm.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lundump.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lvm.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lzio.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lauxlib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lbaselib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ldblib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c liolib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lmathlib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c loslib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c ltablib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lstrlib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c loadlib.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c linit.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c lua.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c luac.c > cc -pipe -O -Wall -DLUA_USE_LINUX -c print.c > cc -o liblua.so -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o > ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o > lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o > lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o > ltablib.o lstrlib.o loadlib.o linit.o > /usr/bin/ld: lapi.o: relocation R_X86_64_32 can not be used when > making a shared object; recompile with -fPIC > lapi.o: could not read symbols: Bad value > > Any hint? It's expected becasue you're overriding -fPIC in port's Makefile from your make.conf (CFLAGS=...). If you still want to *reduce* optimization then append CFLAGS by using `+=' instead of `='. ___ 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: spamassassin port/package
On 9/6/10 10:07 PM, Brian W. wrote: Any chance this could by default do a sa-update? I have this happen twice now where portupgrade -ap got me a new spamassassin, but spamd wouldn't start until I ran sa-update. patches welcome, but consider automated ports builds, and portmaster and binary packages on systems without any internet access. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 > *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: x11/stumpwm and ports/149397
Hi, On Sat, Sep 04, 2010 at 10:00:06PM +0400, Anonymous wrote: > Since the PR was handed over to you by p...@[1] I haven't seen any activity > for around a month. Do you even have an interest in the lisp port? If not or I'm sorry for what happened, but the only reason I didn't do my work here is the lack of time. I'm replying you late for that too. Anyway I saw that Gabor has solved the problem in the best way. Sorry again for the problem that I raised. JM --- http://www.jaculamodyun.net http://people.freebsd.org/~jacula/ pgpib9RyBY3Mw.pgp Description: PGP signature
Re: multimedia/gstreamer-plugins-ugly compile failure distinfo bad
> Hi > Thanks in advance for fixing > dns1# cd /usr/ports/multimedia/gstreamer-plugins-ugly > dns1# make clean > ===> Cleaning for gstreamer-plugins-ugly-0.10.16,3 > dns1# make > ===> License check disabled, port has not defined LICENSE > => gst-plugins-ugly-0.10.16.tar.bz2 is not in > /usr/ports/multimedia/gstreamer- > plugins-ugly/../../multimedia/gstreamer-plugins/distinfo. > => Either /usr/ports/multimedia/gstreamer-plugins- > ugly/../../multimedia/gstreamer-plugins/distinfo is out of date, or > => gst-plugins-ugly-0.10.16.tar.bz2 is spelled incorrectly. > *** Error code 1 > > Stop in /usr/ports/multimedia/gstreamer-plugins-ugly. > > David I posted this immediately after updating ports. Whilst scribing the ports was updated!! gstreamer-plugins-ugly is now compiling Thanks David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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"
libthr and libc
Hello. I found out interesting thing yesterday. I use 8.0-stable and observed the same behavior on 8.1-release. I tried to create ecpg (embedded SQL) program for PostgreSQL. The program linked but gave strange error (sqlca structure wasn't passed correctly to user program). I found out that the reason was in threads behavior - each time we called pthread_once (inside ecpglib) it didn't work. Program linked to libc.so and called some stubs from it. When I realised it, I linked program with libthr, and it started work correctly. Can someone explain why this stubs are in libc? Why didn't linker just throw a linking error? -- С уважением, Александр Пыхалов, системный администратор ЮГИНФО ЮФУ. ___ 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: libthr and libc
Alexander Pyhalov ha scritto: > Can someone explain why this stubs are in libc? Why didn't linker just > throw a linking error? Simple explanation: the stubs are there because you can create a thread-safe library and use it in a single-threaded or multi-threaded program. Once linked to a multi-threaded program (with -pthread) the library gets access to the real libthr implementations of the pthread_* functions, while in the single-threaded program the library will use the libc stubs without affecting performance. If you encounter errors probably your program/libraries dynamically loads shared libraries that link with libthr and so you eventually call some pthread_* functions from libc and others from libthr. -- Alex Dupre ___ 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: libthr and libc
Thanks for explanation. Alex Dupre wrote: Simple explanation: the stubs are there because you can create a thread-safe library and use it in a single-threaded or multi-threaded program. Once linked to a multi-threaded program (with -pthread) the library gets access to the real libthr implementations of the pthread_* functions, while in the single-threaded program the library will use the libc stubs without affecting performance. If you encounter errors probably your program/libraries dynamically loads shared libraries that link with libthr and so you eventually call some pthread_* functions from libc and others from libthr. Yes, it was the case. And it was not rather simple to find out this :) And one more interesting thing. I have a sample threaded application. On one system it was implicitly linked to libthr (on 8.0-stable), and on other system (8.1-RELEASE) it had to be explicitly stated "-lpthr"... -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University ___ 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: libthr and libc
Alexander Pyhalov ha scritto: > Yes, it was the case. And it was not rather simple to find out this :) Did I win anything? ;-) > And one more interesting thing. I have a sample threaded application. On > one system it was implicitly linked to libthr (on 8.0-stable), and on > other system (8.1-RELEASE) it had to be explicitly stated "-lpthr"... Hmmm, too few details to answer. What changed (not related to this point) from 8.0 and 8.1 is that if you unload (dlclose) a shared library that was linked with libthr, the libthr library will not be unloaded (previously bad things were happening, since pthread_* functions pointers were wrong after unload). -- Alex Dupre ___ 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: libthr and libc
Alex Dupre wrote: Alexander Pyhalov ha scritto: Yes, it was the case. And it was not rather simple to find out this :) Did I win anything? ;-) Yes. My gratitude. It would be more if I had gotten this answer two dayas ago before sitting with gdb for a working day :) -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University ___ 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: libthr and libc
On Tue, Sep 07, 2010 at 02:18:02PM +0400, Alexander Pyhalov wrote: > Thanks for explanation. > > Alex Dupre wrote: > >Simple explanation: the stubs are there because you can create a > >thread-safe library and use it in a single-threaded or multi-threaded > >program. Once linked to a multi-threaded program (with -pthread) the > >library gets access to the real libthr implementations of the pthread_* > >functions, while in the single-threaded program the library will use the > >libc stubs without affecting performance. > >If you encounter errors probably your program/libraries dynamically > >loads shared libraries that link with libthr and so you eventually call > >some pthread_* functions from libc and others from libthr. > Yes, it was the case. And it was not rather simple to find out this :) > And one more interesting thing. I have a sample threaded application. On > one system it was implicitly linked to libthr (on 8.0-stable), and on > other system (8.1-RELEASE) it had to be explicitly stated "-lpthr"... Once I marked libthr as not loadable. It caused so much crying on the lists that it had to be reverted. Apparently, people prefer to live with the silent bugs instead of explicit reports. pgpr1xB0LCIYz.pgp Description: PGP signature
Problem with textproc/py-lucene port on 8.1-RELEASE
Hi All, I've just spent over 3 hours at the pc watching over a py-lucene install, accepting licenses, running off to other download sites to fetch stuff, that sort of fun. So I was not happy to be getting a stop error after 3 hours like I have got below. any ideas how to proceed please? Gav... /usr/local/bin/python2.6 -m jcc.__main__ --jar lucene-java-3.0.2/build/lucene-core-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/snowball/lucene-snowball-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/analyzers/common/lucene-analyzers-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/regex/lucene-regex-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/memory/lucene-memory-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/highlighter/lucene-highlighter-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/queries/lucene-queries-3.0.2.jar --jar build/jar/extensions.jar --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream --exclude org.apache.lucene.queryParser.Token --exclude org.apache.lucene.queryParser.TokenMgrError --exclude org.apache.lucene.queryParser.QueryParserTokenManager --exclude org.apache.lucene.queryParser.ParseException --exclude org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --rename org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer --version 3.0.2 --module python/collections.py --files 2 --build Exception in thread "main" java.lang.NoSuchMethodException: java.lang.Object.hasNext() at java.lang.Class.getMethod(Class.java:1605) Traceback (most recent call last): File "/usr/local/lib/python2.6/runpy.py", line 122, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/local/lib/python2.6/runpy.py", line 34, in _run_code exec code in run_globals File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2-amd64. egg/jcc/__main__.py", line 102, in cpp.jcc(sys.argv) File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2-amd64. egg/jcc/cpp.py", line 565, in jcc declares, typeset) File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2-amd64. egg/jcc/cpp.py", line 1014, in code superMethod = find_method(superCls, methodName, params) File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2-amd64. egg/jcc/cpp.py", line 218, in find_method if (e.getJavaException().getClass().getName() == 'java.lang.NoSuchMethodException'): File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2-amd64. egg/jcc/cpp.py", line 51, in getJavaException return self.args[0] IndexError: tuple index out of range gmake: *** [compile] Error 255 *** Error code 1 Stop in /usr/ports/textproc/py-lucene. ___ 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: fox-1.6.40 failure file size mismatch/ not available
> Size mismatch for file from www.fox-toolkit.org/ftp > File not available from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ > > dns1# make > ===> License check disabled, port has not defined LICENSE > ===> Found saved configuration for fox-1.6.37_3 > => fox-1.6.40.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > => Attempting to fetch from http://www.fox-toolkit.org/ftp/. > fetch: http://www.fox-toolkit.org/ftp/fox-1.6.40.tar.gz: size mismatch: > expected 4355091, actual 4353981 > => Attempting to fetch from ftp://ftp.fox-toolkit.org/pub/. > fetch: ftp://ftp.fox-toolkit.org/pub/fox-1.6.40.tar.gz: size mismatch: > expected 4355091, actual 4353981 > => Attempting to fetch from http://fresh.t-systems-sfr.com/unix/src/misc/. > fetch: http://fresh.t-systems-sfr.com/unix/src/misc/fox-1.6.40.tar.gz: Not > Found > => Attempting to fetch from http://freebsd.unixfreunde.de/sources/. > fetch: http://freebsd.unixfreunde.de/sources/fox-1.6.40.tar.gz: Not Found > => Attempting to fetch from > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. > fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/fox-1.6.40.tar.gz: > File unavailable (e.g., file not found, no access) > => Couldn't fetch it - please try to retrieve this > => port manually into /usr/ports/distfiles/ and try again. > *** Error code 1 > > Stop in /usr/ports/x11-toolkits/fox16. > *** Error code 1 > > Stop in /usr/ports/x11-toolkits/fox16. Attempt to fetch from ftp.freebsd.org/distfiles showed: > mget fox-1.0.53.tar.gz [anpqy?]? n > mget fox-1.2.16.tar.gz [anpqy?]? n > mget fox-1.2.18.tar.gz [anpqy?]? n > mget fox-1.4.32.tar.gz [anpqy?]? n > mget fox-1.4.35.tar.gz [anpqy?]? n > mget fox-1.4.6.tar.gz [anpqy?]? n > mget fox-1.4.7.tar.gz [anpqy?]? n > mget fox-1.6.1.tar.gz [anpqy?]? n > mget fox-1.6.14.tar.gz [anpqy?]? n > mget fox-1.6.16.tar.gz [anpqy?]? n > mget fox-1.6.25.tar.gz [anpqy?]? n > mget fox-1.6.26.tar.gz [anpqy?]? n > mget fox-1.6.28.tar.gz [anpqy?]? n > mget fox-1.6.29.tar.gz [anpqy?]? n > mget fox-1.6.30.tar.gz [anpqy?]? n > mget fox-1.6.31.tar.gz [anpqy?]? n > mget fox-1.6.33.tar.gz [anpqy?]? n > mget fox-1.6.34.tar.gz [anpqy?]? n > mget fox-1.6.35.tar.gz [anpqy?]? n > mget fox-1.6.36.tar.gz [anpqy?]? n > mget fox-1.6.37.tar.gz [anpqy?]? n > mget fox-1.7.21.tar.gz [anpqy?]? n > No response Any chance of a fix?? David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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: fox-1.6.40 failure file size mismatch- solution here -
> > Size mismatch for file from www.fox-toolkit.org/ftp > > File not available from > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ > > > > dns1# make > > ===> License check disabled, port has not defined LICENSE > > ===> Found saved configuration for fox-1.6.37_3 > > => fox-1.6.40.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > > => Attempting to fetch from http://www.fox-toolkit.org/ftp/. > > fetch: http://www.fox-toolkit.org/ftp/fox-1.6.40.tar.gz: size mismatch: > > expected 4355091, actual 4353981 > > => Attempting to fetch from ftp://ftp.fox-toolkit.org/pub/. > > fetch: ftp://ftp.fox-toolkit.org/pub/fox-1.6.40.tar.gz: size mismatch: > > expected 4355091, actual 4353981 > > => Attempting to fetch from > > http://fresh.t-systems-sfr.com/unix/src/misc/. fetch: > > http://fresh.t-systems-sfr.com/unix/src/misc/fox-1.6.40.tar.gz: Not > > Found > > => Attempting to fetch from http://freebsd.unixfreunde.de/sources/. > > fetch: http://freebsd.unixfreunde.de/sources/fox-1.6.40.tar.gz: Not Found > > => Attempting to fetch from > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. > > fetch: > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/fox-1.6.40.tar.gz: > > File unavailable (e.g., file not found, no access) > > => Couldn't fetch it - please try to retrieve this > > => port manually into /usr/ports/distfiles/ and try again. > > *** Error code 1 > > > > Stop in /usr/ports/x11-toolkits/fox16. > > *** Error code 1 > > > > Stop in /usr/ports/x11-toolkits/fox16. > > Attempt to fetch from ftp.freebsd.org/distfiles showed: > > mget fox-1.0.53.tar.gz [anpqy?]? n > > mget fox-1.2.16.tar.gz [anpqy?]? n > > mget fox-1.2.18.tar.gz [anpqy?]? n > > mget fox-1.4.32.tar.gz [anpqy?]? n > > mget fox-1.4.35.tar.gz [anpqy?]? n > > mget fox-1.4.6.tar.gz [anpqy?]? n > > mget fox-1.4.7.tar.gz [anpqy?]? n > > mget fox-1.6.1.tar.gz [anpqy?]? n > > mget fox-1.6.14.tar.gz [anpqy?]? n > > mget fox-1.6.16.tar.gz [anpqy?]? n > > mget fox-1.6.25.tar.gz [anpqy?]? n > > mget fox-1.6.26.tar.gz [anpqy?]? n > > mget fox-1.6.28.tar.gz [anpqy?]? n > > mget fox-1.6.29.tar.gz [anpqy?]? n > > mget fox-1.6.30.tar.gz [anpqy?]? n > > mget fox-1.6.31.tar.gz [anpqy?]? n > > mget fox-1.6.33.tar.gz [anpqy?]? n > > mget fox-1.6.34.tar.gz [anpqy?]? n > > mget fox-1.6.35.tar.gz [anpqy?]? n > > mget fox-1.6.36.tar.gz [anpqy?]? n > > mget fox-1.6.37.tar.gz [anpqy?]? n > > mget fox-1.7.21.tar.gz [anpqy?]? n > > No response > Any chance of a fix?? > > David As a test I downloaded the file via http from http://www.fox- toolkit.org/fox.html and then ran # make makesum and then tried #make and received the following errors: configure: WARNING: unrecognized options: --enable-threadsafe, --enable-cups ===> Building for fox-1.6.40 Making all in utils c++ -DPACKAGE_NAME=\"fox\" -DPACKAGE_TARNAME=\"fox\" - DPACKAGE_VERSION=\"1.6.40\" -DPACKAGE_STRING=\"fox\ 1.6.40\" - DPACKAGE_BUGREPORT=\"jer...@fox-toolkit.com\" -DPACKAGE_URL=\"\" - DPACKAGE=\"fox\" -DVERSION=\"1.6.40\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 - DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" - DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIBRT=1 - DHAVE_LIBPTHREAD=1 -DHAVE_VSSCANF=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOLL=1 - DHAVE_STRTOULL=1 -I.-I/usr/local/include -I/usr/local/include/freetype2 - I/usr/local/include -Wall -Wextra -Wformat -Woverloaded-virtual -Wshadow -O2 -fno-strict-aliasing -pipe -march=nocona -O2 -Wuninitialized -ffast-math - finline-functions -fexpensive-optimizations -DNDEBUG -Wuninitialized -ffast- math -fstrict-aliasing -finline-functions -fomit-frame-pointer -fexpensive- optimizations -pg -DHAVE_XFT_H=1 -I/usr/include/freetype2 -DNO_XIM - I/usr/local/include -MT reswrap.o -MD -MP -MF .deps/reswrap.Tpo -c -o reswrap.o reswrap.cpp c++: -pg and -fomit-frame-pointer are incompatible *** Error code 1 Stop in /usr/ports/x11-toolkits/fox16/work/fox-1.6.40/utils. *** Error code 1 Stop in /usr/ports/x11-toolkits/fox16/work/fox-1.6.40. *** Error code 1 Stop in /usr/ports/x11-toolkits/fox16. *** Error code 1 Stop in /usr/ports/x11-toolkits/fox16. After unchecking "Build with Profiling support" fox compiled. The correct contents of distfile are shown as follows: dns1# cat distinfo MD5 (fox-1.6.40.tar.gz) = 1253617ca2ef5652b865e35dc2ddb65c SHA256 (fox-1.6.40.tar.gz) = 19bcdb56f3985ef359adc1cf3a392d11cad0d097c646dd73c8ef1349faa1ba6f SIZE (fox-1.6.40.tar.gz) = 4353981 Any chance someone could check and commit? Thanks David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network _
Re: fox-1.6.40 failure file size mismatch- solution here -
On Tue, Sep 07, 2010 at 02:31:38PM +0100, David Southwell wrote:
>
> As a test I downloaded the file via http from http://www.fox-
> toolkit.org/fox.html and then ran
> # make makesum
> and then tried
> #make
> and received the following errors:
>
> configure: WARNING: unrecognized options: --enable-threadsafe, --enable-cups
> ===> Building for fox-1.6.40
> Making all in utils
> c++ -DPACKAGE_NAME=\"fox\" -DPACKAGE_TARNAME=\"fox\" -
> DPACKAGE_VERSION=\"1.6.40\" -DPACKAGE_STRING=\"fox\ 1.6.40\" -
> DPACKAGE_BUGREPORT=\"jer...@fox-toolkit.com\" -DPACKAGE_URL=\"\" -
> DPACKAGE=\"fox\" -DVERSION=\"1.6.40\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
> DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
> DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -
> D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
> -D_POSIX_PTHREAD_SEMANTICS=1
> -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -
> DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIBRT=1 -
> DHAVE_LIBPTHREAD=1 -DHAVE_VSSCANF=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOLL=1 -
> DHAVE_STRTOULL=1 -I.-I/usr/local/include -I/usr/local/include/freetype2 -
> I/usr/local/include -Wall -Wextra -Wformat -Woverloaded-virtual -Wshadow -O2
> -fno-strict-aliasing -pipe -march=nocona -O2 -Wuninitialized -ffast-math -
> finline-functions -fexpensive-optimizations -DNDEBUG -Wuninitialized -ffast-
> math -fstrict-aliasing -finline-functions -fomit-frame-pointer -fexpensive-
> optimizations -pg -DHAVE_XFT_H=1 -I/usr/include/freetype2 -DNO_XIM -
> I/usr/local/include -MT reswrap.o -MD -MP -MF .deps/reswrap.Tpo -c -o
> reswrap.o reswrap.cpp
> c++: -pg and -fomit-frame-pointer are incompatible
> *** Error code 1
>
> Stop in /usr/ports/x11-toolkits/fox16/work/fox-1.6.40/utils.
> *** Error code 1
>
> Stop in /usr/ports/x11-toolkits/fox16/work/fox-1.6.40.
> *** Error code 1
>
> Stop in /usr/ports/x11-toolkits/fox16.
> *** Error code 1
>
> Stop in /usr/ports/x11-toolkits/fox16.
>
> After unchecking "Build with Profiling support" fox compiled.
>
> The correct contents of distfile are shown as follows:
>
> dns1# cat distinfo
> MD5 (fox-1.6.40.tar.gz) = 1253617ca2ef5652b865e35dc2ddb65c
> SHA256 (fox-1.6.40.tar.gz) =
> 19bcdb56f3985ef359adc1cf3a392d11cad0d097c646dd73c8ef1349faa1ba6f
> SIZE (fox-1.6.40.tar.gz) = 4353981
>
> Any chance someone could check and commit?
>
I found a copy of the old distfile floating around. The change is
innocuous (diff attached). If gahr doesn't respond within the customary
timeout period, I'll commit a fix.
Shaun
--
Shaun Amott // PGP: 0x6B387A9A
"A foolish consistency is the hobgoblin
of little minds." - Ralph Waldo Emerson
diff -urN fox-1.6.40.orig/fox.pc.in fox-1.6.40/fox.pc.in
--- fox-1.6.40.orig/fox.pc.in 2009-03-13 05:45:10.0 +
+++ fox-1.6.40/fox.pc.in 2010-09-02 02:01:28.0 +0100
@@ -1,10 +1,18 @@
-pref...@prefix@
-exec_pref...@exec_prefix@
-libd...@libdir@
-included...@includedir@
+prefix="@prefix@"
+exec_prefix="@exec_prefix@"
+libdir="@libdir@"
+includedir="@includedir@/f...@fox_major_version@@fox_minor_version@"
+LIBS="@LIBS@"
+X_LIBS="@X_LIBS@"
+X_BASE_LIBS="@X_BASE_LIBS@"
+X_EXTRA_LIBS="@X_EXTRA_LIBS@"
+GL_LIBS="@GL_LIBS@"
+fox_libs=-lf...@fox_major_version@@fox_minor_version@
Name: FOX
-Description: FOX is a C++ based Toolkit for developing Graphical User Interfaces
+Description: The FOX Toolkit
+URL: www.fox-toolkit.org
Version: @fox_major_vers...@.@fox_minor_vers...@.@FOX_PATCH_LEVEL@
-Libs: -L${libdir} -lf...@fox_major_version@@fox_minor_version@ @X_LIBS@ @X_BASE_LIBS@ @X_EXTRA_LIBS@ @GL_LIBS@ @LIBS@
-Cflags: -I${includedir}/f...@fox_major_version@@fox_minor_version@
+Libs: ${FOX_LIBS}
+Libs.private: ${X_LIBS} ${X_BASE_LIBS} ${X_EXTRA_LIBS} ${GL_LIBS} ${LIBS}
+Cflags: -I${includedir}
pgplvw5qRysID.pgp
Description: PGP signature
Re: fox-1.6.40 failure file size mismatch- solution here -
> On Tue, Sep 07, 2010 at 02:31:38PM +0100, David Southwell wrote: > > As a test I downloaded the file via http from http://www.fox- > > toolkit.org/fox.html and then ran > > # make makesum > > and then tried > > #make > > and received the following errors: > > > > configure: WARNING: unrecognized options: --enable-threadsafe, > > --enable-cups ===> Building for fox-1.6.40 > > Making all in utils > > c++ -DPACKAGE_NAME=\"fox\" -DPACKAGE_TARNAME=\"fox\" - > > DPACKAGE_VERSION=\"1.6.40\" -DPACKAGE_STRING=\"fox\ 1.6.40\" - > > DPACKAGE_BUGREPORT=\"jer...@fox-toolkit.com\" -DPACKAGE_URL=\"\" - > > DPACKAGE=\"fox\" -DVERSION=\"1.6.40\" -DSTDC_HEADERS=1 > > -DHAVE_SYS_TYPES_H=1 - DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 > > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 > > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - > > D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 > > -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 > > -DLT_OBJDIR=\".libs/\" - > > DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_DIRENT_H=1 > > -DHAVE_LIBRT=1 - DHAVE_LIBPTHREAD=1 -DHAVE_VSSCANF=1 -DHAVE_VSNPRINTF=1 > > -DHAVE_STRTOLL=1 - DHAVE_STRTOULL=1 -I.-I/usr/local/include > > -I/usr/local/include/freetype2 - I/usr/local/include -Wall -Wextra > > -Wformat -Woverloaded-virtual -Wshadow -O2 -fno-strict-aliasing -pipe > > -march=nocona -O2 -Wuninitialized -ffast-math - finline-functions > > -fexpensive-optimizations -DNDEBUG -Wuninitialized -ffast- math > > -fstrict-aliasing -finline-functions -fomit-frame-pointer -fexpensive- > > optimizations -pg -DHAVE_XFT_H=1 -I/usr/include/freetype2 -DNO_XIM - > > I/usr/local/include -MT reswrap.o -MD -MP -MF .deps/reswrap.Tpo -c -o > > reswrap.o reswrap.cpp > > c++: -pg and -fomit-frame-pointer are incompatible > > *** Error code 1 > > > > Stop in /usr/ports/x11-toolkits/fox16/work/fox-1.6.40/utils. > > *** Error code 1 > > > > Stop in /usr/ports/x11-toolkits/fox16/work/fox-1.6.40. > > *** Error code 1 > > > > Stop in /usr/ports/x11-toolkits/fox16. > > *** Error code 1 > > > > Stop in /usr/ports/x11-toolkits/fox16. > > > > After unchecking "Build with Profiling support" fox compiled. > > > > The correct contents of distfile are shown as follows: > > > > dns1# cat distinfo > > MD5 (fox-1.6.40.tar.gz) = 1253617ca2ef5652b865e35dc2ddb65c > > SHA256 (fox-1.6.40.tar.gz) = > > 19bcdb56f3985ef359adc1cf3a392d11cad0d097c646dd73c8ef1349faa1ba6f > > SIZE (fox-1.6.40.tar.gz) = 4353981 > > > > Any chance someone could check and commit? > > I found a copy of the old distfile floating around. The change is > innocuous (diff attached). If gahr doesn't respond within the customary > timeout period, I'll commit a fix. > > Shaun Thanks for undertaking that task. there is one other thing I have realised. Downloads via ftp from fox- toolkit.org do not always work unless -p option is used. I think this is the reason why the file could not be found. I forgot to mention that. I downloaded fox-1.6.40.tar.gz via http.If file is not found then users could be advised to download manually from http://www.fox-toolkit.org/fox.html David Photographic Artist Permanent Installations & Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography & Official Portraiture Combined darkroom & digital creations & Systems Adminstrator for the vizion2000.net network ___ 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-mgmt/tinderbox: fix i386 jail on amd64 host on 9-CURRENT
Hello!
I've recently bumped into the issue which was already discussed
on current@:
http://lists.freebsd.org/pipermail/freebsd-current/2010-July/018638.html
In short, in the ports' tinderbox, i386 jail fails on the amd64 host
during "make distribution" step. This configuration, while
not strictly supported, is rather usefull.
It looks like it hasn't been fixed in the repository or in ports.
I can confirm that the proposed patch:
http://lists.freebsd.org/pipermail/freebsd-current/2010-July/018676.html
fixes the build of i386 jail on amd64 host.
Attached is an updated patch-lib-tc_command.sh.new which could be
dropped into the files directory of ports-mgmt/tinderbox port
instead of the current file.
Could interested people (cc-ed) check it on other releases and
propagate it upstream?
Thanks,
Alexey.
--- lib/tc_command.sh.orig 2009-11-27 18:32:31.0 +0100
+++ lib/tc_command.sh 2010-09-07 16:50:24.0 +0200
@@ -223,7 +223,7 @@
#---
Setup () {
-MAN_PREREQS="lang/perl5.[81]"
+MAN_PREREQS="lang/perl5.[81]*"
OPT_PREREQS="lang/php[45] databases/pear-MDB2 www/php[45]-session"
PREF_FILES="tinderbox.ph"
README="$(tinderLoc scripts README)"
@@ -774,10 +774,10 @@
# determine if we're cross-building world
crossEnv=""
if [ "${jailArch}" != "${myArch}" ]; then
- crossEnv="TARGET_ARCH=${jailArch} MACHINE_ARCH=${jailArch}
MAKEOBJDIRPREFIX=${J_OBJDIR}/${jailArch} MACHINE=${jailArch}"
+ crossEnv="TARGET_ARCH=${jailArch}"
fi
-cd ${SRCBASE}/etc && env DESTDIR=${J_TMPDIR} ${crossEnv} \
- make -m ${J_TMPDIR}/usr/share/mk distribution >
${jailBase}/distribution.tmp 2>&1
+cd ${SRCBASE} && env DESTDIR=${J_TMPDIR} ${crossEnv} \
+ make distribution > ${jailBase}/distribution.tmp 2>&1
if [ $? -ne 0 ]; then
echo "ERROR: distribution failed - see ${jailBase}/distribution.tmp"
buildJailCleanup 1 ${jailName} ${J_SRCDIR}
___
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"
XPI infrastructure needs some love
Dear port committers, I understand that infofarmer@ and miwi@ have no more enough free time to be hyper-active about those and other ports (and btw, thanks very much for the huge work you did in the past!), but is out there anyone else out there with both a commit bit and some time on hand to give a bit of love to the XPI ports? Maybe it's just my impression, but it seems they've got some bitrot, and I feel a little pity for them, both as an user and a maintainer. ;) For those which might be interested, a quick list of the ones that need some attention (that I own or I could find as open with PR queries): Date Number Description 2008/08/27 126876 Makefile.xpi's xpi-gen gets the wrong id sometimes 2010/05/23 146854 Update port: www/xpi-gbutts update & rename 2010/07/01 148282 [PATCH] www/xpi-tabmixplus: fix XPI_ID 2010/08/26 149987 [NEW PORT] mail/xpi-dispmua: Displays icon of MUA 2010/08/02 149211 [PATCH] www/xpi-vimperator: update to 2.3.1 2010/09/06 150327 [PATCH] Makefile.xpi: do not install XPI metadata 2010/09/06 150328 [MAINTAINER] www/xpi-stumbleupon: update to 3.73 126876 and 150327 are my proposals to enhance the Makefile.xpi infrastructure, the rest is mostly updates. yours truly, -- Lapo Luchini - http://lapo.it/ "Beware of bugs in the above code; I have only proved it correct, not tried it." (Donald Knuth, 1977-03-22) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/asterisk16
2010/8/23 Mark Linimon : > I sent mail to sobomax on the 17th and he responded. I'm willing to > wait a few more days to see what action he takes but that's it. > > mcl Have you heard from sobo...@? Thanks in advance. -- TAKATSU Tomonari ___ 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: XPI infrastructure needs some love
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/10 16:39, Lapo Luchini wrote: > Dear port committers, > I understand that infofarmer@ and miwi@ have no more enough free > time to be hyper-active about those and other ports (and btw, thanks > very much for the huge work you did in the past!), but is out there > anyone else out there with both a commit bit and some time on hand to > give a bit of love to the XPI ports? > > Maybe it's just my impression, but it seems they've got some bitrot, and > I feel a little pity for them, both as an user and a maintainer. ;) > > For those which might be interested, a quick list of the ones that need > some attention (that I own or I could find as open with PR queries): > > Date Number Description > 2008/08/27 126876 Makefile.xpi's xpi-gen gets the wrong id sometimes > 2010/05/23 146854 Update port: www/xpi-gbutts update & rename > 2010/07/01 148282 [PATCH] www/xpi-tabmixplus: fix XPI_ID > 2010/08/26 149987 [NEW PORT] mail/xpi-dispmua: Displays icon of MUA > 2010/08/02 149211 [PATCH] www/xpi-vimperator: update to 2.3.1 > 2010/09/06 150327 [PATCH] Makefile.xpi: do not install XPI metadata > 2010/09/06 150328 [MAINTAINER] www/xpi-stumbleupon: update to 3.73 > > 126876 and 150327 are my proposals to enhance the Makefile.xpi > infrastructure, the rest is mostly updates. I will take a look in the next few minutes at these. The next thing that should happen is the auto assigner should not touch xpi related ports until someone else steps up; however, thats not me, I'm over committed already. > > yours truly, > - -- - 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFMhnWbdbiP+9ubjBwRAkZ2AJ49V1Pfw/XJLEdAr99BF0KNCbbqUACggnkf y+ReohWBkg0ve2dSOam3nL8= =nXnp -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: XPI infrastructure needs some love
Quoth Lapo Luchini on Tuesday, 07 September 2010: > Dear port committers, > I understand that infofarmer@ and miwi@ have no more enough free > time to be hyper-active about those and other ports (and btw, thanks > very much for the huge work you did in the past!), but is out there > anyone else out there with both a commit bit and some time on hand to > give a bit of love to the XPI ports? > > Maybe it's just my impression, but it seems they've got some bitrot, and > I feel a little pity for them, both as an user and a maintainer. ;) > > For those which might be interested, a quick list of the ones that need > some attention (that I own or I could find as open with PR queries): > > Date Number Description > 2008/08/27 126876 Makefile.xpi's xpi-gen gets the wrong id sometimes > 2010/05/23 146854 Update port: www/xpi-gbutts update & rename > 2010/07/01 148282 [PATCH] www/xpi-tabmixplus: fix XPI_ID > 2010/08/26 149987 [NEW PORT] mail/xpi-dispmua: Displays icon of MUA > 2010/08/02 149211 [PATCH] www/xpi-vimperator: update to 2.3.1 > 2010/09/06 150327 [PATCH] Makefile.xpi: do not install XPI metadata > 2010/09/06 150328 [MAINTAINER] www/xpi-stumbleupon: update to 3.73 > > 126876 and 150327 are my proposals to enhance the Makefile.xpi > infrastructure, the rest is mostly updates. > > yours truly, > > -- > Lapo Luchini - http://lapo.it/ > > "Beware of bugs in the above code; I have only proved it correct, not > tried it." (Donald Knuth, 1977-03-22) > ___ > 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" I applied 149211 to my own development system running 8.1-STABLE, and I've been using it daily since the bugathon. Someone could just commit that. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpF7IKUNkOd9.pgp Description: PGP signature
Re: XPI infrastructure needs some love
--- Original message --- From: Lapo Luchini To: po...@freebsd.org Cc: infofar...@freebsd.org, m...@freebsd.org, s...@freebsd.org Sent: 7.9.'10, 20:39 Dear port committers, I understand that infofarmer@ and miwi@ have no more enough free time to be hyper-active about those and other ports (and btw, thanks very much for the huge work you did in the past!), but is out there anyone else out there with both a commit bit and some time on hand to give a bit of love to the XPI ports? Hey Lapo and all, nice to hear from you! XPI stuff is one of those things that's crying to get 95% automated (along with CPAN, pypy, etc, but *not* along with generic ports). I would estimate it is about a week of work for a reasonably seasoned ports committer. At the moment, I could provide input for anyone with enough time to undertake it, but can not implement it myself. ___ 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: XPI infrastructure needs some love
On 09/07/2010 09:39 AM, Lapo Luchini wrote: Dear port committers, I understand that infofarmer@ and miwi@ have no more enough free time to be hyper-active about those and other ports (and btw, thanks very much for the huge work you did in the past!), but is out there anyone else out there with both a commit bit and some time on hand to give a bit of love to the XPI ports? This might be a good time to re-evaluate how we handle those ports in the first place. How many of them involve actual C or C++ code that needs to be compiled to run, vs. simply re-packaging javascript bits? (That's a serious question btw, not a troll.) For those that we are simply repackaging, what's the value in doing that, vs. simply allowing users to download them from mozilla's site? I use quite a few addons for both firefox and thunderbird and the only FreeBSD version I use is enigmail, which (AFAIK) actually does require compilation. Everything else I download, and have never had a problem. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LUA fails upgrade on 7.2/amd64
Il 09/07/10 10:40, Anonymous ha scritto: It's expected becasue you're overriding -fPIC in port's Makefile from your make.conf (CFLAGS=...). If you still want to *reduce* optimization then append CFLAGS by using `+=' instead of `='. Thanks, this was the problem. So, I've had the following in /etc/make.conf since eons: CFLAGS=-O -pipe COPTFLAGS=-O -pipe Genrally speaking (meaning for any port), is this still useful? Are the above flags deprecated? Will I get optimized code without them? bye & Thanks 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: LUA fails upgrade on 7.2/amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/10 19:33, Andrea Venturoli wrote: > Il 09/07/10 10:40, Anonymous ha scritto: > >> It's expected becasue you're overriding -fPIC in port's Makefile from >> your make.conf (CFLAGS=...). If you still want to *reduce* optimization >> then append CFLAGS by using `+=' instead of `='. > > Thanks, this was the problem. > > So, I've had the following in /etc/make.conf since eons: > CFLAGS=-O -pipe > COPTFLAGS=-O -pipe > > > Genrally speaking (meaning for any port), is this still useful? > Are the above flags deprecated? > Will I get optimized code without them? $ make -V CFLAGS -V COPTFLAGS - -O2 -pipe - -O2 -pipe are the defaults for 'eons' now for both /usr/src userland and kernel and ports. - -- - 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFMhpRXdbiP+9ubjBwRAuamAJ95iWViYnMD+ujHsWptsiTCKgTUVgCfX260 eLJxd7dgEXQo1uiVeYKZ0BA= =loY7 -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: [CFT] GNU gdb(1) 7.2 Shell Archive - devel/gdb7
On 09/07/2010 12:39, FreeBSD Ports wrote: > 06.09.2010 19:53, jhell написав(ла): >> I have just created a gdb7 port from the existing devel/gdb6. > > Sir, if your port follows my example of having the Insight (GUI-front > end for GDB) as an option, you have my blessing. Back in the day I had > to manually rip-out the Insight-bits out of the giant tarball the > developers had for download (they included the entire gdb, Tcl, Tk, > iTcl, and iTk with it!). > > If your port has the same kind of granularity, I'll gladly add your port > and can also make you a maintainer of devel/gdb6. Yours, > > -mi Alright, I wasnt looking into it too far but I can flip those back into the port. The current port of gdb6 already does not work for Insight if you have any other version of Tcl installed other than 8.4 so I guess I have some work to do in order to get that into shape. The main part that I am worried about ATM is functionality before experimental changes and I can add or work on putting the Insight support back into gdb7 while we get to this stage. Also the TUI support for some reason seems borked in XTerm, not sure about others so I am looking into that too. All-in-all its looking up besides one report on FreBSD-CURRENT that that does not recognize powerpc-unknown-9.0 but that seems to be a simple slight of hand fix. Personally I am not really looking to be the or a maintainer of any port but am willing to step up and submit patches and whatever is needed given free time is available so please do not misunderstand my intentions with the previous email as I am only looking to get these on an updated schedule so they flow with the rest of ports usage. Also still having ports in CVS adds some unnecessary overhead on my end that I am not prepared to deal with permanently at this point. But can if need be for a short time step in to help out. Later today Ill be putting the gdb7 port that I constructed into a Mercurial repo on GoogleCode so if people want to contribute they can easily by cloning and making their changes locally. Regards, -- jhell,v ___ 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: XPI infrastructure needs some love
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/10 17:25, Philip M. Gollucci wrote: > On 09/07/10 16:39, Lapo Luchini wrote: >> Date Number Description >> 2008/08/27 126876 Makefile.xpi's xpi-gen gets the wrong id sometimes This looks fine to me. Tests fine in tb. make gen-xpi doesn't change XPI_ID for any ports either except for www/xpi-tambixplus below. >> 2010/05/23 146854 Update port: www/xpi-gbutts update & rename Sent to portmgr@ for repo-copy request. >> 2010/07/01 148282 [PATCH] www/xpi-tabmixplus: fix XPI_ID Looks fine as well., Tests fine in tb >> 2010/08/02 149211 [PATCH] www/xpi-vimperator: update to 2.3.1 Looks fine, tests in tb fine, loads fine in ff on my desktop; however, stas@ will/wants to handle this one. >> 2010/09/06 150327 [PATCH] Makefile.xpi: do not install XPI metadata Looks fine, but: 1) breaks PLIST for 8 other ports. The fix is of course trivial -- www/xpi-adblock_plus www/xpi-flashgot www/xpi-foxmarks www/xpi-google-notebook www/xpi-joga www/xpi-noscript www/xpi-pdf_download www/xpi-togglewordwrap 2) I'm not sure what to do about this one -- ../xpi-adblock/Makefile.xpi", line 192: warning: duplicate script for target "post-extract" ignored www/xpi-downthemall www/xpi-foxyproxy www/xpi-jsview www/xpi-mousegestures www/xpi-statusbarclock www/xpi-unplug >> 2010/09/06 150328 [MAINTAINER] www/xpi-stumbleupon: update to 3.73 Also looks fine., tests fine tin tb. >> 2010/08/26 149987 [NEW PORT] mail/xpi-dispmua: Displays icon of MUA ignoring for now. - -- - 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFMhqO+dbiP+9ubjBwRAk0UAJ9eMzCjuNETVwMf9ol+mDXLtezUiQCeJCqW f2wGXFWbOPPJPYlTmRWM9WE= =+FIk -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: XPI infrastructure needs some love
Doug Barton wrote: > This might be a good time to re-evaluate how we handle those ports in > the first place. How many of them involve actual C or C++ code that > needs to be compiled to run, vs. simply re-packaging javascript bits? Only enigmail comes to my mind. (but it is even a bit more evil, it requires the original sources and can't be directly installed) > For those that we are simply > repackaging, what's the value in doing that, vs. simply allowing > users to download them from mozilla's site? Well, in vastly multi-user places there might of course be good reasons to have a single centralized package instead of one-for-each-user-account, but OTOH... places like that are not much more used in this a-few-PCs-per-household world we currently live in. Still, I feel that as a *somewhat cleaner* choice and go to the extent of creating a port for every extension I do use (on my single-user machines), but I'm not quite sure I'd be able to justify that with real arguments other than a warm fuzzy feeling. ;) -- Lapo Luchini - http://lapo.it/ "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." (Weinberg's Second Law) ___ 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: XPI infrastructure needs some love
Philip M. Gollucci wrote: > On 09/07/10 17:25, Philip M. Gollucci wrote: >> On 09/07/10 16:39, Lapo Luchini wrote: >>> Date Number Description >>> 2008/08/27 126876 Makefile.xpi's xpi-gen gets the wrong id sometimes > This looks fine to me. Tests fine in tb. make gen-xpi doesn't change > XPI_ID for any ports either except for www/xpi-tambixplus below. Right: I couple of my ports need that patch in order for xpi-gen to generate the correct value, but I was manually changing the value before port submit, so it doesn't change any actual committed data except that one. >>> 2010/09/06 150327 [PATCH] Makefile.xpi: do not install XPI metadata > Looks fine, but: > > 1) breaks PLIST for 8 other ports. The fix is of course trivial Yes, it avoids installing digital signature, so META-INF should be in plist no more using that patch... OTOH as you correctly notice that patch is using 'post-extract' target and some ports (that I didn't notice) have one themselves; I'm not sure what's the correct approach to have a default value in the include that doesn't conflict. -- Lapo Luchini - http://lapo.it/ “C is quirky, flawed, and an enormous success.” (Dennis M. Ritchie) ___ 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: LUA fails upgrade on 7.2/amd64
>> So, I've had the following in /etc/make.conf since eons: >> CFLAGS=-O -pipe >> COPTFLAGS=-O -pipe >> >> >> Genrally speaking (meaning for any port), is this still useful? >> Are the above flags deprecated? >> Will I get optimized code without them? > >$ make -V CFLAGS -V COPTFLAGS >- -O2 -pipe >- -O2 -pipe > >are the defaults for 'eons' now for both /usr/src userland and kernel >and ports. This is not quite the whole story -- apart from warnings, and changes due to debugging or profiling, these flags may also depend on the architecture, the compiler, and the version of FreeBSD. Some of the architectures drop the optimization level in the CFLAGS to -O (arm, mips), even though they may not do it for COPTFLAGS. amd64 appends -frename-registers to COPTFLAGS. Fortran flags (no longer used by the base system) are still set at -O. Some flags are trimmed from CFLAGS to form CXXFLAGS. By default, ports append -fno-strict-aliasing in bsd.port.mk, as does the base system for FreeBSD < 8, but not FreeBSD >= 8. And there are still overrides present for icc, which, seemingly, almost no one uses anymore. The details are in /usr/src/sys/conf/kern.pre.mk, the makefiles in /usr/src/share/mk or /usr/share/mk, and bsd.port.mk. It seems to be a common mistake, that people do not realize that make.conf is often parsed a second time for do-build and other ports targets, after port Makefiles, so that *FLAGS= ... assignments in make.conf may override the *FLAGS settings from port Makefiles in MAKE_ENV. Given the examples in /usr/share/examples/etc/make.conf, which seem designed for the base system, perhaps we ought to add a comment explicitly warning people about this. Also, I am not sure about the test for the addition of -fPIC in the lang/lua Makefile -- I wonder if the test should be against ARCH, as requested in bsd.port.mk, rather than MACHINE_ARCH. Furthermore, this port links the shared library with only an empty MYLDFLAGS -- this may break builds with certain CFLAGS, or with compilers from ports. The following is more appropriate: --- old.patch-src-Makefile 2010-09-05 08:59:47.0 -0400 +++ patch-src-Makefile 2010-09-05 09:02:10.0 -0400 @@ -30,7 +30,7 @@ a:$(ALL_A) +$(LUA_SO):$(CORE_O) $(LIB_O) -+ $(CC) -o $@ $(MYLDFLAGS) -shared -Wl,-soname=$(LUA_SONAME) $? ++ $(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(MYLDFLAGS) -shared -Wl,-soname=$(LUA_SONAME) $? + $(LUA_A): $(CORE_O) $(LIB_O) - $(AR) $@ $? ___ 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: XPI infrastructure needs some love
On 09/07/2010 01:20 PM, Lapo Luchini wrote: Doug Barton wrote: For those that we are simply repackaging, what's the value in doing that, vs. simply allowing users to download them from mozilla's site? Well, in vastly multi-user places there might of course be good reasons to have a single centralized package instead of one-for-each-user-account, but OTOH... places like that are not much more used in this a-few-PCs-per-household world we currently live in. I maintain my own archive for my personal platforms (multibooting different OS', re-installing not-infrequently) because it makes it easier to keep things consistent, amongst other reasons. For the purpose you describe FreeBSD packages are neither useful nor desirable since the individual user still has to install the thing. Still, I feel that as a *somewhat cleaner* choice and go to the extent of creating a port for every extension I do use (on my single-user machines), but I'm not quite sure I'd be able to justify that with real arguments other than a warm fuzzy feeling. ;) My concern with this for some time is that there is little to no actual benefit for the vast majority of these ports, however they do consume resources. Admittedly not an overwhelming number of resources, but given the fact that ports/package resources are stretched thin, and we'd like to expand support for packages going forward, I think we need to carefully evaluate these choices, especially given that we're losing maintainers. As a quick overview I did a find for ports with xpi in the name and there are well over 100. That doesn't include other ports with different naming conventions. My suggestion is that we simply eliminate these ports altogether, but I realize that's not likely to happen. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: XPI infrastructure needs some love
On Tue, Sep 7, 2010 at 19:39, Doug Barton wrote: > > My concern with this for some time is that there is little to no actual > benefit for the vast majority of these ports, however they do consume > resources. Admittedly not an overwhelming number of resources, but given the > fact that ports/package resources are stretched thin, and we'd like to > expand support for packages going forward, I think we need to carefully > evaluate these choices, especially given that we're losing maintainers. As a > quick overview I did a find for ports with xpi in the name and there are > well over 100. That doesn't include other ports with different naming > conventions. > > My suggestion is that we simply eliminate these ports altogether, but I > realize that's not likely to happen. :) Around 6 months ago, a similar thing was proposed for a number of eclipse plugins - they can all be installed and updated via the builtin update manager and nothing is built for FreeBSD - they are just Java stuff that can be binary downloaded and run anywhere. People wanted them kept because in a corporate environment the admin can provide a consistent version to all users and update them using whatever methods they already use for other ports. -- Rob Farmer ___ 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: XPI infrastructure needs some love
On 09/07/2010 09:09 PM, Rob Farmer wrote: Around 6 months ago, a similar thing was proposed for a number of eclipse plugins - they can all be installed and updated via the builtin update manager and nothing is built for FreeBSD - they are just Java stuff that can be binary downloaded and run anywhere. Are these eclipse plugins similar to mozilla plugins in that the user has to take an additional step after the FreeBSD package is added, or if the package is on the system then it's available to all the users immediately? If the latter, then I can understand why having FreeBSD packages of them would be valuable. If they are similar to mozilla plugins then I'm curious what the value-add is. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: XPI infrastructure needs some love
Doug Barton wrote: > Are these eclipse plugins similar to mozilla plugins in that the user > has to take an additional step after the FreeBSD package is added, or if > the package is on the system then it's available to all the users > immediately? If the latter, then I can understand why having FreeBSD > packages of them would be valuable. If they are similar to mozilla > plugins then I'm curious what the value-add is. Uh? But the XPI plugins *are* immediately available to all the Firefox/SeaMonkey/ThunderBird of all the users, immediately after install. I think you're thinking about Enigmail, which only creates a local XPI that must then be installed by every and each user that desires to do, but enigmail's unique in that approach, all the other XPI ports are immediately available. (ok, sometimes a "make relink-all" is needed if a browser is updated after the plugins, but most of the times nothing needs to be done and that's a centralized one-run-per-system command anyways) -- Lapo Luchini - http://lapo.it/ “There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.” (Jeremy S. Anderson) ___ 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: XPI infrastructure needs some love
On 09/07/2010 09:36 PM, Lapo Luchini wrote: Doug Barton wrote: Are these eclipse plugins similar to mozilla plugins in that the user has to take an additional step after the FreeBSD package is added, or if the package is on the system then it's available to all the users immediately? If the latter, then I can understand why having FreeBSD packages of them would be valuable. If they are similar to mozilla plugins then I'm curious what the value-add is. Uh? But the XPI plugins *are* immediately available to all the Firefox/SeaMonkey/ThunderBird of all the users, immediately after install. Well if that's true then I'm prepared to be a tiny bit embarrassed, but that's why I wanted to discuss it. I'm not afraid to learn something new, thanks! :) I think you're thinking about Enigmail, which only creates a local XPI that must then be installed by every and each user that desires to do, but enigmail's unique in that approach, all the other XPI ports are immediately available. Interesting. I am going to assume that's true (can't test it at the moment) but even so it doesn't really change how I feel about the situation. If we have maintainers who are willing to keep these things up to date and people agree that this is an acceptable use of scarce resources, well, Ok then. But if either of those premises are not true, IMO they need to go. I'm particularly concerned about the situation where we have them in the tree but they are not up to date. That's not only a waste of resources it makes us look bad. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: XPI infrastructure needs some love
On Tue, Sep 7, 2010 at 21:32, Doug Barton wrote: > On 09/07/2010 09:09 PM, Rob Farmer wrote: >> >> Around 6 months ago, a similar thing was proposed for a number of >> eclipse plugins - they can all be installed and updated via the >> builtin update manager and nothing is built for FreeBSD - they are >> just Java stuff that can be binary downloaded and run anywhere. > > Are these eclipse plugins similar to mozilla plugins in that the user has to > take an additional step after the FreeBSD package is added, or if the > package is on the system then it's available to all the users immediately? > If the latter, then I can understand why having FreeBSD packages of them > would be valuable. If they are similar to mozilla plugins then I'm curious > what the value-add is. I'm not quite sure what you mean by "take an additional step after the FreeBSD package is added." I've never used either the xpi ports or the eclipse plugins. Do users have to run some command to import the plugins into their ~/.mozilla profiles after root installs them or is it automatic? Skimming a couple makefiles, neither the xpi nor eclipse plugin ports indicate this type of thing in a pkg-message or similar that I can see. I don't really have much of an opinion on this - I can see the pros (easier administration) and cons (more ports to be maintained, possiblity of lagging behind what's available upstream) to having the ports. I just recall the discussion and mentioned it because I thought it might be relevant if there was already some precedent for this type of thing (it seems the eclispe ports were kept). -- Rob Farmer > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: XPI infrastructure needs some love
Rob Farmer wrote: > Do users have to run some command to import the plugins into their > ~/.mozilla profiles after root installs them or is it automatic? Homedir of the iser isn't really involved, Firefox/Thunderbird/SeaMonkey expect the system to have system-wide packages available in system directories, then each user has them by default (but can selectively disable some of them if they want, though they still show up in his list). System-available packages show up in the "Addons manager" in a slightly different way, e.g. they can't be upgraded or deleted, only disabled. -- Lapo Luchini - http://lapo.it/ “Gentlemen do not read each others mail.” (Henry Lewis Stimson) ___ 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: XPI infrastructure needs some love
Doug Barton wrote: > If we have maintainers who are willing to keep these things > up to date and people agree that this is an acceptable [way] Well, I'm not so sure about the ones I don't use, but the ones I do use are usualyl well maintained (either that or they get a PR form me), but there's also the fact that updating them is usually a no-brainer (in most cases it could well be automated, as Andrew Pantyukhin has suggested); it seems to me that a maintainer is not the most scarce resource in updating an XPI port, committer time seems to be a scarcer resource to me (but that's of course the point of view of a maintainer). > I'm particularly concerned about the situation where we have them in the > tree but they are not up to date. That's not only a waste of resources > it makes us look bad. Especially so because system-wide packages are then more difficult to update for the single user; I don't remember at the moment if a stale system package can be Disabled *and* installed locally by the user or not (as I usually update the port first without trying to update as user), but that (if it is the case that it's impossible) would be a strong additional reason to be sure to have latest version in the ports. But I'm not really sure about this, I will double check next time an extension I do use is outdated (before updating the port). -- Lapo Luchini - http://lapo.it/ “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” (Edsger W. Dijkstra) ___ 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"
