Re: Add mips64* to lang/gcc/4.8
On Tue, 17 Jun 2014 16:28:47 -0400, Brian Callahan wrote:
>
> On 06/17/14 16:16, Pascal Stumpf wrote:
> > On Tue, 17 Jun 2014 13:42:28 -0400, Brian Callahan wrote:
> >> Hi ports --
> >>
> >> And earlier version of the attached diff was passed around but I think
> >> it's time now to get it in (thanks jasper for the prodding).
> >> This will get gcc-4.8 built on mips64el (I'm assuming mips64 as
> >> well...). This gcc was able to build working llvm binaries on mips64el
> >> from their HEAD from about 3 weeks ago (did not build clang because
> >> clang doesn't support mips3 yet).
> > Well, the important question is: Does it help the gcc4 users in the
> > ports tree on mips64* or do they run into similar binutils issues?
> >
>
> The big test from my perspective would be webkit. But I don't have the
> time to test that on mips64el. I'm hoping someone on here does.
I also just re-read the relevant config.gcc parts and noticed that
PIE_DEFAULT=1 is missing from tm_defines. Can someone test if that
works?
> >> OK?
> >>
> >> ~Brian
> >>
> >>
> >> Index: Makefile
> >> ===
> >> RCS file: /cvs/ports/lang/gcc/4.8/Makefile,v
> >> retrieving revision 1.36
> >> diff -u -p -r1.36 Makefile
> >> --- Makefile 8 Jun 2014 18:55:36 - 1.36
> >> +++ Makefile 17 Jun 2014 17:36:31 -
> >> @@ -1,8 +1,5 @@
> >> # $OpenBSD: Makefile,v 1.36 2014/06/08 18:55:36 brad Exp $
> >>
> >> -BROKEN-mips64 = ld: not enough GOT space for local GOT entries
> >> -BROKEN-mips64el = ld: not enough GOT space for local GOT entries
> >> -
> >> ONLY_FOR_ARCHS = alpha amd64 i386 powerpc sparc64 mips64 mips64el
> >> DPB_PROPERTIES = parallel
> >>
> >> @@ -59,6 +56,7 @@ FLAVOR ?=
> >>
> >> ONLY_FOR_ARCHS-ada = amd64 i386 sparc64
> >> ONLY_FOR_ARCHS-java = amd64 i386 powerpc sparc64
> >> +NOT_FOR_ARCHS-full = mips64 mips64el
> > That doesn't really make sense. There is no subpackage named "full".
> > The chunk below should be enough.
>
> Alright I'll take that out.
>
> >> MULTI_PACKAGES = -main -f95 -objc -c++ -estdc -java -ada
> >>
> >> @@ -171,6 +169,11 @@ USE_GMAKE = yes
> >> # you shouldn't skip bootstrap unless you know what you're doing
> >> # use bootstrap-lean if you're pressed for space
> >> ALL_TARGET = bootstrap
> >> +# mips64* have issues with ld, but this method gets a working
> >> +# compiler suite.
> >> +.else if ${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "mips64"
> >> +CONFIGURE_ARGS += --disable-bootstrap
> >> +ALL_TARGET = all
> >> .else
> >> # skip the stage2/stage3 bullshit under normal circumstances
> >> ALL_TARGET = bootstrap2
>
>
Re: unable to open mandoc.db on vim installing
On Wed, Jun 18, 2014 at 01:40:43AM +0100, Stuart Henderson wrote: > On 2014/06/18 00:17, Ingo Schwarze wrote: > > So the question is how to ignore the error in this case, without > > ignoring other potential errors as well. I see the following options: > > > > a) When pkg_add(1) wants a new database and no warning, > > let it call makewhatis(8) without -d. > > > > b) Add an option "pkg_add(1) mode" to makewhatis(8), > > let pkg_add(1) always use that, and let makewhatis(8) > > ignore this particular error in this case. > > I suspect there will be a few more cases where pkg_add(1) > > wants makewhatis(8) behaviour that is slightly different > > from sane default behaviour in the non-pkg_add case. > > > > I could live with both approaches; the second one seems slightly > > more flexible and requires less code in pkg_add(1), at the > > expense of one more option for makewhatis(8). > > > > Which one do you prefer? > > I think you have sold B to me. :) Something like this? No, this is backwards. my makewhatis was perfectly fine creating the database from scratch. It did not throw any fit. If you're worried somebody may manually use makewhatis to create databases in wrong locations, well, that makes *no sense*. The add/remove pages to the database are there explicitly for programs like pkg_add/pkg_delete. They are *not* going to be used by normal users. It makes no sense to have to add *more code*, *more logic* to pkg_add (that may fail) and *more test cases* to prevent an error that should not be there in the first place. if you really want to worry about this, add a flag to makewhatis that says "shut the fuck up, I might be creating a database, it's none of your business". But think about it: does it make sense to create *more complicated logic* in pkg_add because of this ?
Re: unable to open mandoc.db on vim installing
Ignore most of this, especially since I read it a bit fast. I'm still wondering whether it makes sense to add a flag to makewhatis that will always be there. Who's gonna use -u and -d without that new flag -P ?
Re: diff to BSDmakefile in devel/arduino
On 2014/06/18 02:29, Daniel Bolgheroni wrote:
> Hi,
>
> In the revisions.txt file from Arduino source code, in the section
> related to changes from version 0022 to 1.0, there is this statement:
>
> * The WProgram.h file, which provides declarations for the Arduino API,
> has been renamed to Arduino.h. To create a library that will work in
> both Arduino 0022 and Arduino 1.0, you can use an #ifdef that checks
> for the ARDUINO constant, which was 22 and is now 100. For example:
>
> #if defined(ARDUINO) && ARDUINO >= 100
> #include "Arduino.h"
> #else
> #include "WProgram.h"
> #endif
>
> This can be seen here:
>
> https://github.com/arduino/Arduino/blob/master/build/shared/revisions.txt#L391-L400
>
> There are some libraries which depend on the ARDUINO macro to be defined, or
> will fallback to use WProgram.h. Since we are at 1.0.2, there is no longer
> WProgram.h, and the compiler will fail.
>
> The following diff defines this macro at runtime for such cases.
>
> OK? Thank you.
This file is somewhat hidden in the port. What are the consequences of
it not being updated if the port is updated? Does it need some check in
the port Makefile to ensure that it's correct, or at least a reminder
comment right next to DISTNAME? Also requires a REVISION bump.
> Index: BSDmakefile
> ===
> RCS file: /cvs/ports/devel/arduino/files/BSDmakefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 BSDmakefile
> --- BSDmakefile 14 May 2013 14:31:30 - 1.7
> +++ BSDmakefile 18 Jun 2014 05:22:09 -
> @@ -97,8 +97,8 @@ DEBUG = stabs
> OPT = s
>
> # Place -D or -U options here
> -CDEFS = -DF_CPU=$(F_CPU)
> -CXXDEFS = -DF_CPU=$(F_CPU)
> +CDEFS = -DF_CPU=$(F_CPU) -DARDUINO=100
> +CXXDEFS = -DF_CPU=$(F_CPU) -DARDUINO=100
>
> # Place -I options here
> ROOTLIBINCS=${LIBRARIES:S|^|-I$(ARDUINO)/libraries/|g}
>
alpine fails linking because of undefined reference to `RAND_egd'
Hi,
not sure if this is known already, but this happens to me on i386:
OpenBSD 5.5-current (GENERIC) #177: Sun Jun 15 10:11:48 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 536375296 (511MB)
avail mem = 515166208 (491MB)
/usr/local/bin/libtool --tag=CC--mode=link cc -pthread -O2 -pipe -g -O0
`cat ../c-client/LDFLAGS` -L/usr/lib -L/usr/local/lib -o alpine addrbook.o
adrbkcmd.o after.o alpine.o arg.o busy.o colorconf.o confscroll.o context.o
dispfilt.o flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o
ldapconf.o listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o
pattern.o pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o
signal.o status.o takeaddr.o titlebar.o smime.o newmail.o date.o
../pico/libpico.a ../pico/osdep/libpicoosd.a ../pith/libpith.a
../pith/osdep/libpithosd.a ../pith/charconv/libpithcc.a osdep/libpineosd.a
../c-client/c-client.a -L/usr/local/lib -lintl -L/usr/local/lib -liconv -lc
-R/usr/local/lib -lc -L/usr/lib -lssl -lcrypto -L/usr/local/lib -lintl
-L/usr/local/lib -liconv -lc -R/usr/local/lib -lncurses -lssl -lcrypto
libtool: link: cc -pthread -O2 -pipe -g -O0 -o alpine addrbook.o adrbkcmd.o
after.o alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o
flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o
listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o pipe.o
print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o status.o
takeaddr.o titlebar.o smime.o newmail.o date.o -L/usr/lib -L/usr/local/lib
../pico/libpico.a ../pico/osdep/libpicoosd.a ../pith/libpith.a
../pith/osdep/libpithosd.a ../pith/charconv/libpithcc.a osdep/libpineosd.a
../c-client/c-client.a -lintl -lc -liconv -lncurses -lssl -lcrypto -pthread
-Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/lib
../c-client/c-client.a(osdep.o)(.text+0xe0ee): In function `ssl_onceonlyinit':
/home/ports/pobj/alpine-2.11/alpine-2.11/imap/c-client/osdep.c:241: warning:
tmpnam() possibly used unsafely; consider using mkstemp()
help.o(.text+0xd37): In function `help_processor':
/home/ports/pobj/alpine-2.11/alpine-2.11/alpine/help.c:417: warning: strcpy()
is almost always misused, please use strlcpy()
alpine.o(.text+0x225): In function `main':
/home/ports/pobj/alpine-2.11/alpine-2.11/alpine/alpine.c:206: warning:
srandom() seed choices are invariably poor
busy.o(.text+0x48f): In function `busy_cue':
/home/ports/pobj/alpine-2.11/alpine-2.11/alpine/busy.c:270: warning: random()
isn't random; consider using arc4random()
../c-client/c-client.a(osdep.o)(.text+0x5455): In function `env_init':
/home/ports/pobj/alpine-2.11/alpine-2.11/imap/c-client/env_unix.c:867: warning:
strcat() is almost always misused, please use strlcat()
../pith/libpith.a(conf.o)(.text+0xba8a): In function `write_pinerc':
/home/ports/pobj/alpine-2.11/alpine-2.11/pith/conf.c:5892: warning: sprintf()
is often misused, please use snprintf()
../pith/libpith.a(smime.o)(.text+0x119): In function `app_RAND_load_file':
/home/ports/pobj/alpine-2.11/alpine-2.11/pith/smime.c:130: undefined reference
to `RAND_egd'
collect2: ld returned 1 exit status
*** Error 1 in alpine (Makefile:417 'alpine')
*** Error 1 in alpine (Makefile:530 'all-recursive')
*** Error 1 in alpine (Makefile:338 'all')
*** Error 1 in . (Makefile:448 'all-recursive'
Re: unable to open mandoc.db on vim installing
Hi Marc, Marc Espie wrote on Wed, Jun 18, 2014 at 10:20:09AM +0200: > I'm still wondering whether it makes sense to add a flag > to makewhatis that will always be there. > > Who's gonna use -u and -d without that new flag -P ? Heh. That's a very good point. I only considered the following aspect: "If somebody requests changing an existing database, and the database does not exist, an error message is required." But you are right that the only context where changing an existing database makes sense in the first place is installing and deinstalling software - that is, pkg_add(1)-like tools. I don't like useless knobs either (and if something makes sense in theory, but has no practical use, it is useless). So i will test sthen@'s original diff and check it by more thoroughly inspecting the surrounding code, then (probably) provide an OK unless i find additional issues. Yours, Ingo
Re: alpine fails linking because of undefined reference to `RAND_egd'
On 2014/06/18 18:54, Sebastian Reitenbach wrote: > Hi, > > not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html.
Re: unable to open mandoc.db on vim installing
Hi Stuart,
Marc Espie convinced me that pkg_add(1) is the only use case
of the -d and -u flags of makewhatis(8) that matters in practice,
and the code path you are touching here is only used by -d and -u.
So contrary to my earlier impression, and after some testing and
code inspection, this is
ok schwarze@
Yours,
Ingo
Stuart Henderson wrote on Tue, Jun 17, 2014 at 10:41:16PM +0100:
> Index: mandocdb.c
> ===
> RCS file: /cvs/src/usr.bin/mandoc/mandocdb.c,v
> retrieving revision 1.107
> diff -u -p -r1.107 mandocdb.c
> --- mandocdb.c5 Jun 2014 07:13:53 - 1.107
> +++ mandocdb.c17 Jun 2014 21:39:53 -
> @@ -2223,7 +2223,8 @@ dbopen(int real)
> rc = sqlite3_open_v2(MANDOC_DB, &db, ofl, NULL);
> if (SQLITE_OK != rc) {
> exitcode = (int)MANDOCLEVEL_SYSERR;
> - say(MANDOC_DB, "%s", sqlite3_errstr(rc));
> + if (SQLITE_CANTOPEN != rc)
> + say(MANDOC_DB, "%s", sqlite3_errstr(rc));
> return(0);
> }
> goto prepare_statements;
firefox eats my mouse cursor
Whenever firefox displays some overlay dialog, the mouse cursor disappears. It is super annoying when it happens for a "save password" dialog, because I can't see what I'm about to click, so I have to just press esc. Easy repro: go to the google box on top right, and type "app" then pause. When the suggestions show up, the mouse is gone. I'm using dwm on amd64.
Re: firefox eats my mouse cursor
On Wed, Jun 18, 2014 at 14:49, Ted Unangst wrote: > Whenever firefox displays some overlay dialog, the mouse cursor > disappears. It is super annoying when it happens for a "save password" > dialog, because I can't see what I'm about to click, so I have to just > press esc. > > Easy repro: go to the google box on top right, and type "app" then > pause. When the suggestions show up, the mouse is gone. > > I'm using dwm on amd64. And a minute later figured it out. I'm also using xbanish. I suppose xbanish hides the mouse, but then it never comes back as long as firefox has an overlay on the screen.
UPDATE: py-mysql
this is an update to py-mysql 1.2.5
there doesn't seem to be much movement on this project's
github page, but i've seen the version number 1.2.5
pop up on the internet from time to time, and it seems
to be the last stable release (says pypi, but not
sourceforge...)
i have run all the included test and they passed, but i
left the NO_TESTS in the makefile as it needs a running
mysql server and a custom .cnf file.
i am a docs junkie so i also added sphinx dependency
and the generated html docs.
please test and commit.
-f
--
no matter how cynical i get, i still can't keep up...
Index: Makefile
===
RCS file: /cvs/ports/databases/py-mysql/Makefile,v
retrieving revision 1.44
diff -u -p -r1.44 Makefile
--- Makefile12 Jun 2013 20:36:33 - 1.44
+++ Makefile18 Jun 2014 19:09:13 -
@@ -4,14 +4,14 @@ SHARED_ONLY = Yes
COMMENT = Python interface to MySQL
-MODPY_EGG_VERSION =1.2.3
+MODPY_EGG_VERSION =1.2.5
DISTNAME = MySQL-python-${MODPY_EGG_VERSION}
PKGNAME = py-mysql-${MODPY_EGG_VERSION}
-REVISION = 4
+EXTRACT_SUFX = .zip
CATEGORIES = databases
-HOMEPAGE = http://mysql-python.sourceforge.net/
+HOMEPAGE = https://github.com/farcepest/MySQLdb1
MAINTAINER = Benoit Lecocq
@@ -21,17 +21,27 @@ PERMIT_PACKAGE_CDROM= Yes
WANTLIB = crypto m pthread ssl z ${MODPY_WANTLIB}
WANTLIB += lib/mysql/mysqlclient_r>=14
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=mysql-python/}
+MASTER_SITES = ${MASTER_SITE_PYPI:=M/MySQL-python/}
MODULES = lang/python
+BUILD_DEPENDS =textproc/py-sphinx
LIB_DEPENDS = databases/mysql
NO_TEST = Yes
MODPY_SETUPTOOLS = Yes
+post-extract:
+ chmod -R go-w ${WRKSRC}
+
+DOCSRC = ${WRKSRC}/doc
+post-build:
+ cd ${DOCSRC} && ${LOCALBASE}/bin/sphinx-build -N . _build/html
+
+DOCS = ${PREFIX}/share/doc/py-mysql
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/py-mysql
- ${INSTALL_DATA} ${WRKBUILD}/doc/*.txt ${PREFIX}/share/doc/py-mysql/
+ ${INSTALL_DATA_DIR} ${DOCS}
+ cd ${DOCSRC}/_build/html && pax -rw * ${DOCS}
.include
Index: distinfo
===
RCS file: /cvs/ports/databases/py-mysql/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo14 Nov 2010 08:57:16 - 1.7
+++ distinfo18 Jun 2014 19:09:13 -
@@ -1,5 +1,2 @@
-MD5 (MySQL-python-1.2.3.tar.gz) = IV7dtthT9vS+W0r8QVQpLw==
-RMD160 (MySQL-python-1.2.3.tar.gz) = 45TnvwgScGh5Wu6/uup9w7ISfIY=
-SHA1 (MySQL-python-1.2.3.tar.gz) = NRG7jFfGAW7q+lMdXD6ktUiRXjw=
-SHA256 (MySQL-python-1.2.3.tar.gz) =
feZvu/kjY058llrq76dGQrp1riDuHO/O/DAJWVt6fm4=
-SIZE (MySQL-python-1.2.3.tar.gz) = 70305
+SHA256 (MySQL-python-1.2.5.zip) = gRBAtkfl1WhvhNtBXv1pfmJQAIsRK2kJunesBZ4UDHQ=
+SIZE (MySQL-python-1.2.5.zip) = 108935
Index: patches/patch-_mysql_c
===
RCS file: /cvs/ports/databases/py-mysql/patches/patch-_mysql_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-_mysql_c
--- patches/patch-_mysql_c 14 Nov 2010 08:57:17 - 1.3
+++ patches/patch-_mysql_c 18 Jun 2014 19:09:13 -
@@ -1,12 +1,12 @@
$OpenBSD: patch-_mysql_c,v 1.3 2010/11/14 08:57:17 benoit Exp $
_mysql.c.orig Thu Jun 17 09:21:56 2010
-+++ _mysql.c Sun Nov 14 09:30:49 2010
-@@ -1878,7 +1878,7 @@ _mysql_ConnectionObject_shutdown(
- check_connection(self);
- Py_BEGIN_ALLOW_THREADS
- r = mysql_shutdown(&(self->connection)
--#if MYSQL_VERSION_ID >= 40103
-+#if (MYSQL_VERSION_ID >= 40103 && MYSQL_VERSION_ID != 5)
- , SHUTDOWN_DEFAULT
- #endif
- );
+--- _mysql.c.orig Thu Jan 2 13:52:50 2014
_mysql.c Wed Jun 18 20:34:40 2014
+@@ -2079,7 +2079,7 @@ _mysql_ConnectionObject_shutdown(
+ check_connection(self);
+ Py_BEGIN_ALLOW_THREADS
+ r = mysql_shutdown(&(self->connection)
+-#if MYSQL_VERSION_ID >= 40103
++#if (MYSQL_VERSION_ID >= 40103 && MYSQL_VERSION_ID != 5)
+ , SHUTDOWN_DEFAULT
+ #endif
+ );
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/py-mysql/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST
--- pkg/PLIST 14 Nov 2010 08:57:19 - 1.11
+++ pkg/PLIST 18 Jun 2014 19:09:13 -
@@ -35,6 +35,47 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/_mysql.so
lib/python${MODPY_VERSION}/site-packages/_mysql_exceptions.py
lib/python${MODPY_VERSION}/site-packages/_mysql_exceptions.pyc
-share/doc/py-mysql/
-share/doc/py-mysql/FAQ.txt
-share/doc/py-mysql/MySQLdb.txt
+share/doc/${MODPY_PY_PREFIX}mysql/
+share/doc/${MODPY_PY_PREFIX}mysql/FAQ.html
+share/doc/${MODPY_PY_PREFIX}mysql/MySQLdb.constants.html
+share/doc/${MODPY_PY_PREFIX}mysql/MySQLdb.html
+share/doc/${MO
Re: alpine fails linking because of undefined reference to `RAND_egd'
On Wednesday, June 18, 2014 20:23 CEST, Stuart Henderson wrote: > On 2014/06/18 18:54, Sebastian Reitenbach wrote: > > Hi, > > > > not sure if this is known already, but this happens to me on i386: > > Check you don't have old libs around, especially make sure you've followed > the kerberos removal on current.html. I did not upgrade, it happens on a fresh clean install. cheers, Sebastian
Re: Add mips64* to lang/gcc/4.8
On Tue, Jun 17, 2014 at 01:42:28PM -0400, Brian Callahan wrote: > Hi ports -- > > And earlier version of the attached diff was passed around but I think it's > time now to get it in (thanks jasper for the prodding). > This will get gcc-4.8 built on mips64el (I'm assuming mips64 as well...). > This gcc was able to build working llvm binaries on mips64el from their HEAD > from about 3 weeks ago (did not build clang because clang doesn't support > mips3 yet). What this does is build gcc 4.8 with base gcc and stop. Normal gcc builds bootstrap themselves over a couple of stages, thus providing some assurance that the new compiler is actually working well enough to build itself. I suspect once you try to compile something with this 4.8, it will blow up in binutils with just the same error.
net/iodine needs update
Hi ports list. The net/iodine port is currently unmaintained and sitting at vulnerable version. http://code.kryo.se/iodine/CHANGELOG.html 0.7.0 was released to fix authentication bypass problem and make some other updates. Would someone be interested in adopting it?
Re: diff to BSDmakefile in devel/arduino
On Wed, Jun 18, 2014 at 10:10:24AM +0100, Stuart Henderson wrote: > > This file is somewhat hidden in the port. What are the consequences of > it not being updated if the port is updated? I think the main issue here is that if we don't define ARDUINO >= 100, even libraries already in the current distribution, like Firmata, will fail to compile looking for WProgram.h, which we don't have anymore since we are at 1.0.2. Test case: create a project with 'arduinoproject', edit the BSDmakefile and add Firmata to LIBRARIES, run make. The libraries I checked until now use this test very much like it was suggested in revisions.txt (Firmata case) like important 3rd-party libraries Time and DS1307RTC (real time clock modules). The problem would be if libraries begin to use this with another purpose than what was initially suggested in revisions.txt, e.g. using 105, 106 and so on, to check for other renaming schemes in the future. I really doubt it will occur, since the development is moving onto 1.5.x, and 1.0.x is pretty much stable. Otherwise, we are safe defining ARDUINO=100. > Does it need some check in the port Makefile to ensure that it's > correct, or at least a reminder comment right next to DISTNAME? Also > requires a REVISION bump. I don't see why. The alternative would be a comment in BSDmakefile stating that there are some libraries which depend on ARDUINO >= 100 if using Arduino 1.0.x, but since we already are at that version, I don't see a point in not defining it previously. Thank you. -- db
Re: Spelling Checking in Firefox and Thunderbird
Landry Breuil wrote, On 06/16/14 23:29: Spellchecking was fixed_after_ 5.5 was branched, so you'll either have to: - upgrade to -current to get seamonkey 2.26, which*should* be fixed - backport the fix, which consist in rebuilding the package adding --with-system-hunspell to CONFIGURE_ARGS. After backporting the fix above to the 5.5 release ports, I experienced a hellacious build. First, I was running out of drive space on my SSD. Then the build was exhausting memory at the linking stage. So I set WRKOBJDIR and `ulimit -d unlimited` to get past that. However, the spell checker was still broken. Finally, Google told me to use `--enable-system-hunspell` instead of `--with-system-hunspell`. I should have recognized the format just by looking at the other CONFIGURE_ARGS. Now I have a working spell checker! Thanks Landry and Stuart for your help. The remainder of this email is just an FYI. The Seamonkey build required 6.2 GB of disk space (not including build requirements) and 2300 MB of RAM at peak. Dang! Also, during my troubleshooting phase, I found dictionaries scattered throughout the filesystem: 1. /usr/local/lib/seamonkey-2.23/dictionaries/ 2. /usr/local/share/mozilla-dicts/ 3. /usr/local/share/hunspell/ (symlinks to mozilla-dicts) By default, Seamonkey uses the first one, which only contains the "en-US" dictionary. But as Stuart pointed out, you can manually choose a path using Mozilla/Seamonkey `spellchecker.dictionary_path` config. On my system, LibreOffice automatically installed hunspell, which also installed the "en-GB" dictionary by default into the second path. So if you wanted Mexican Spanish for example, you would have to install the "mozilla-dicts-es-MX" package and set spellchecker.dictionary_path = /usr/local/share/mozilla-dicts/ in `about:config`. Then set the language via Edit -> Preferences -> Appearance -> Spelling -> Language. Thanks again Landry for maintaining these monstrous Mozilla ports. Clint P.S. there should be no spelling errors in this email!
