Re: textproc/sphinx rc.d script
Ok so that's to workaround a bug. At the very least it warrants a comment in the rc.d script. Perhaps something like this? #!/bin/ksh # # searchd - Sphinxsearch network daemon # # Use --nodetach flag in combination with rc_bg to workaround searchd not # listening on specified network ports daemon="/usr/local/bin/searchd" daemon_flags="--nodetach" # daemon_user="www" # force start the daemon in background rc_bg=YES . /etc/rc.d/rc.subr rc_cmd $1 -- Jay Williams
Re: textproc/sphinx rc.d script
Why using --nodetach and then rc_bg=YES ? Without the --nodetach flag, the Sphinx daemon doesn't keep listening on the specified inet ports. (There very well may be a bug in this version of Sphinx, especially considering it's age, but that's beyond my skills.) According to the searchd(1) man page, it states: --nodetach Do not 'daemonize', or, do not detach into background. Apart debug purposes, this switch is useful when you manage sphinx with upstart init daemon. In this case actual 'daemonizing' will be done by upstart itself, and also all tasks like starting, stopping, reloading the config and respawning on crash will be done by the system, not the sphinx. Using the --nodetach flag, in combination with rc_bg allows rcctl to reliability control the searchd process. I tried numerous other combinations, and they only proved partially successful or failed completely. -- Jay Williams
textproc/sphinx rc.d script
I've installed the Sphinx search daemon (searchd), and noticed that the port didn't come with a rc.d script. After a good bit of man page reading and debugging, I was able to get the Sphinx search daemon to behave properly, namely using the --nodetach and rc_bg options. To help improve the port, would you want to include this rc.d script, or something similar? That way if someone wants to setup a Sphinx Search daemon, they won't have to spend all the time debugging as I did. -- Jay Williams #!/bin/ksh # # searchd - Sphinxsearch network daemon daemon="/usr/local/bin/searchd" daemon_flags="--nodetach" # daemon_user="deploy" # force start the daemon in background rc_bg=YES . /etc/rc.d/rc.subr rc_cmd $1
Re: bsd.port.mk, stuff to kill
On 02/20/2012 16:07, Marc Espie wrote: I'm wondering if someone is actually using make readmes, or link-categories... I'm thinking of killing those targets, they are purely convenience stuff, and I don't think they serve a real purpose these days. (if anything, readmes or category indices should be generated off sqlports, which holds all the relevant information for *every* listed port, including dependency handling). FWIW, I've used make readmes. It's very convenient since I'm still pretty new to OpenBSD and still learning about the available packages. But don't keep it just for me, I think there are other ways to find what I need. Jay Huldeen j...@huldeen.com
Re: another got overflow
Thanks Stu. I removed the gtk2 = cups dependency as you suggested and then was
able to build iodbc.
make install is still running.
(I didn't test the diff, I just removed it unconditionally; presumably the diff
is obvious then.)
- Jay
Date: Fri, 30 Jul 2010 14:56:47 +0100
From: stu@
To: jay.krell
Subject: Re: another got overflow
On 2010/07/30 12:47, Jay K wrote:
# uname -a
OpenBSD mobsd.my.domain 4.7 GENERIC#2 loongson
This is now building normal stuff, ports, not my unusual project.
There wasn't a package for iodbc, which is what I really after.
Please try the diff (for gtk+2) below and let me know how it goes.
I don't have any mips64 hardware to test it myself. It's something of
a hack but it should work and it should let significantly more of
the ports tree build so I think it might be a good idea for now.
Looks like it is known:
..
- remove mips64 gcc workaround, though this still won't build because of ld
..
any fix in sight?
There is a binutils update in progress, but given the number of arch
we support it's a huge undertaking to make sure it works correctly
everywhere, don't expect to see it this side of 4.8.
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.109
diff -u -p -r1.109 Makefile
--- Makefile 22 Jul 2010 10:40:35 - 1.109
+++ Makefile 30 Jul 2010 13:46:37 -
@@ -37,12 +37,17 @@ WANTLIB += xcb-render xcb-render-util z
MASTER_SITES=
${MASTER_SITE_GNOME:=sources/gtk+/${VERSION:C/^([0-9]+\.[0-9]+).*/\1/}/}
EXTRACT_SUFX= .tar.bz2
-MULTI_PACKAGES= -main -docs -cups
+MULTI_PACKAGES= -main -docs
+
+# XXX cups build fails on mips64/mips64el due to a binutils problem
+.if ! ${MACHINE_ARCH:Mmips64*}
+MULTI_PACKAGES+=-cups
+BUILD_DEPENDS= ::print/cups
+.endif
MODULES= devel/gettext \
lang/python
-BUILD_DEPENDS= ::print/cups
RUN_DEPENDS= ::x11/hicolor-icon-theme \
::misc/shared-mime-info
Confirm your subscription to The Parlaywheel
The parlay wheel has a full live person video tutorial showing you how the system work. Also check out Jay's video podcast giving you smart money tips. Confirm to list: The Parlaywheel https://app.icontact.com/icp/confirm.php?r=39568481s=QFLUgid=67656c=480214l=51322m=234999 This message was sent by: The Parlaywheel, 19907 Mason Creek Dr. , Katy, Texas 77449 Powered by iContact: http://freetrial.icontact.com
Re: gcc 4.3 on OpenBSD?
Tero, I think I have what I need, thank you. It would be nice though if the OpenBSD port worked, and if the patches were in mainline gcc. I'm running 4.3 now, but that doesn't fix it. I took what I needed of the patches, submitted those to our cvs, and code to apply them at build time. I only need the backend, not any front end. This is for Modula-3. Also, all those changes of 0 to NULL, those aren't really needed, are they?I understand that IF 0 is defined simply as 0, which is legal, and there is varargs, and pointer is bigger than int, such as most 64 bit systems, and you want a null pointer, you won't likely get it. However this seems like a stretch. In C, NULL is likely at least ((void*)0) already, or in C++ at least 0L instead of plain 0. Or even some compiler builtin __null, though I don't think that is necessary. Granted, if #define NULL 0, then a change would be needed. I'd also have to check if NULL can be any integral type, or if the standard mandates it is the size of a pointer. It's possible #define NULL 0 on a 64 bit system with 32 bit int is not standard-legal. Thanks. - Jay Date: Mon, 9 Jun 2008 17:56:18 +0300 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: ports@openbsd.org Subject: Re: gcc 4.3 on OpenBSD? On Tue, 20 May 2008 20:50:58 + Jay wrote: The gcc 4.3 port is mildly broken, right? At least on OpenBSD 4.2? I'll upgrade to OpenBSD 4.3 soon. Actually I have OpenBSD 4.2 on one machine and OpenBSD 4.3 on another and I think broken on both but I have to check. I have partially working gcc 4.3.0 port at http://gnuada.svn.sourceforge.net/viewvc/gnuada/trunk/OpenBSD/current/lang/gcc/4.3/ While the URL says current I have actually tested the port only on OpenBSD 4.3-release. Partially working means that the port is not pretty, but produces a working executable on i386 platform with C and Ada frontends. I haven't really tested the C frontend, but the Ada frontend can compile things like AWS and Polyorb from Adacore Subversion repository. -- Tero Koskinen [EMAIL PROTECTED]
gcc 4.3 on OpenBSD?
The gcc 4.3 port is mildly broken, right? At least on OpenBSD 4.2? I'll upgrade to OpenBSD 4.3 soon. Actually I have OpenBSD 4.2 on one machine and OpenBSD 4.3 on another and I think broken on both but I have to check. In particular, if you get the gcc 4.3 release, not all the OpenBSD patches successfully apply. Some of the context and/or line numbers are off. One good example is omp-low.c. In particular I have a code base that is also a *slightly* patched gcc 4.3, really, my patches are not the cause of the problem, but I will double check, since I didn't write them. Mostly we just add a file, but there are probably a few very small changes otherwise. I'm working on bringing it up on OpenBSD. On a few architectures, not all at the same time, but ultimately x86, AMD64, Sparc64, PowerPC. Sparc64 and PowerPC first at least for now. The first problem you hit is in configure-gcc, powerpc-*-openbsd not supported. Now, we only really use the backend. So many of the OpenBSD patches don't matter, anything related to the driver, the C front end, the libraries, and I think specs. That rules out almost everything, leaving mainly tree-ssa-pre.c, *config*, *openbsd*, libtool*. Two other things here: 1) Even the name/date/version of the tarball seems wrong and not found. It's back in 2007. I think it was just copied from 4.2. 2) It's not super obvious what to do with rs6000/openbsd1.h, based on a cursory surfacy skim pattern matching against other targets. I'm guess I should look more at 4.2 to figure this out. All the NULL vs. (type *) 0 patches? I understand the problem with this code: #define NULL 0 char* concat(const char* a, ...); /* NULL terminated list */ concat(a, NULL); However, the following is ok, right: #define NULL ((void*)0) char* concat(const char* a, ...); /* NULL terminated list */ concat(a, NULL); and, not 100% portably in theory, but in practise: #define NULL 0L char* concat(const char* a, ...); /* NULL terminated list */ concat(a, NULL); Furthermore, I understand that #define NULL ((void*)0) is legal C but not legal C++. I understand that, ideally #define NULL __some_magic_builtin_null that the compiler knows must be the size of a pointer, and not just for checking but also to get things correct, but that you can't realy on this. OpenBSD has something here: #ifndef NULL #ifdef __GNUG__ #define NULL __null #else #define NULL 0L #endif but I haven't dug in to see what those are. I'm guessing __GNUG__ means C++, and __null means what I want, but I need to check. So..these patches...usually don't matter? They don't matter on OpenBSD? They might matter on other systems or bootstrapping with older headers? Any chance of the various patches going upstream? The code base I have does track upstream so they'd come back around naturally if so, and leave me with much less to do. :) If it is confirmed broken, just copied from 4.2, I wouldn't mind contributing some fixes/testing, but I'd like to confirm first that I'm not too far afield. It looks easy given the 4.2 patches, the only small mystery I think is around rs6000/openbsd1.h or such. I also thought the use of freebsd.h surprising, but upon a closer look, not for nothing. Yes I searched the web but it's hard to scope this down. Lots of stuff about gcc and OpenBSD, but hard to find about gcc 4.3 on OpenBSD. And 4.3 is also an OpenBSD version. Thanks for any information, - Jay
