Re: 5.4-beta#20 xterm(1)/luit(1) in cwm, CM-Return random defunc
mhe...@gmail.com (Matthieu Herrb), 2013.07.11 (Thu) 23:41 (CEST): > On Wed, Jul 10, 2013 at 01:30:23AM -0700, Philip Guenther wrote: > > On Wed, Jul 10, 2013 at 1:19 AM, Philip Guenther wrote: > > > Looks like a race in luit's startup, due to how it handles the > > > ttys/ptys. To work around the problem, invoke it with the -p > > > option...but I don't know how you can convince xterm to do that. > > > > Ha! I believe this bug is a result of posix_openpt() being > > implemented in 5.3 and the luit configure script picking that instead > > of openpty(), as the code for the former results in the client side > > being opened (by PTMGET), then closed, then reopened by name, which > > leaves a window where the master will read EOF. > > > > Naddy, can you coerce configure into ignoring posix_openpt()? > > Can you check the patch below ? > (sorry it's huge since it regenerates autotools files) I hate being a spoilsport, but... it does not change the random defunc. What I did: 1) cd /usr/xenocara/app/luit 2) patch < ~/luit.patch (no errors) 3) ./configure; make; make install (no errors) 4) ~/.Xresources: enable ``XTerm*locale:ISO8859-1'' 5) xrdb -merge ~/.Xresources 6) hit CM-Return 7) get a new xterm or not Bye, Marcus > Index: Makefile.in > === > RCS file: /cvs/xenocara/app/luit/Makefile.in,v > retrieving revision 1.6 > diff -u -r1.6 Makefile.in > --- Makefile.in 10 Feb 2013 15:38:36 - 1.6 > +++ Makefile.in 11 Jul 2013 21:40:11 - > @@ -252,6 +252,8 @@ > PACKAGE_VERSION = @PACKAGE_VERSION@ > PATH_SEPARATOR = @PATH_SEPARATOR@ > PKG_CONFIG = @PKG_CONFIG@ > +PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > SED = @SED@ > SET_MAKE = @SET_MAKE@ > SHELL = @SHELL@ > Index: aclocal.m4 > === > RCS file: /cvs/xenocara/app/luit/aclocal.m4,v > retrieving revision 1.10 > diff -u -r1.10 aclocal.m4 > --- aclocal.m410 Feb 2013 15:38:36 - 1.10 > +++ aclocal.m411 Jul 2013 21:40:13 - > @@ -20,6 +20,7 @@ > To do so, use the procedure documented by the package, typically > 'autoreconf'.])]) > > # pkg.m4 - Macros to locate and utilise pkg-config.-*- Autoconf > -*- > +# serial 1 (pkg-config-0.24) > # > # Copyright © 2004 Scott James Remnant . > # > @@ -46,8 +47,12 @@ > # -- > AC_DEFUN([PKG_PROG_PKG_CONFIG], > [m4_pattern_forbid([^_?PKG_[A-Z_]+$]) > -m4_pattern_allow([^PKG_CONFIG(_PATH)?$]) > -AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])dnl > +m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) > +m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) > +AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) > +AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search > path]) > +AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in > search path]) > + > if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then > AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) > fi > @@ -60,7 +65,6 @@ > AC_MSG_RESULT([no]) > PKG_CONFIG="" > fi > - > fi[]dnl > ])# PKG_PROG_PKG_CONFIG > > @@ -69,34 +73,32 @@ > # Check to see whether a particular set of modules exists. Similar > # to PKG_CHECK_MODULES(), but does not set variables or print errors. > # > -# > -# Similar to PKG_CHECK_MODULES, make sure that the first instance of > -# this or PKG_CHECK_MODULES is called, or make sure to call > -# PKG_CHECK_EXISTS manually > +# Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG]) > +# only at the first occurence in configure.ac, so if the first place > +# it's called might be skipped (such as if it is within an "if", you > +# have to call PKG_CHECK_EXISTS manually > # -- > AC_DEFUN([PKG_CHECK_EXISTS], > [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl > if test -n "$PKG_CONFIG" && \ > AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then > - m4_ifval([$2], [$2], [:]) > + m4_default([$2], [:]) > m4_ifvaln([$3], [else >$3])dnl > fi]) > > - > # _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES]) > # - > m4_define([_PKG_CONFIG], > -[if test -n "$PKG_CONFIG"; then > -if test -n "$$1"; then > -pkg_cv_[]$1="$$1" > -else > -PKG_CHECK_EXISTS([$3], > - [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`], > - [pkg_failed=yes]) > -fi > -else > - pkg_failed=untried > +[if test -n "$$1"; then > +pkg_cv_[]$1="$$1" > + elif test -n "$PKG_CONFIG"; then > +PKG_CHECK_EXISTS([$3], > + [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null` > + test "x$?" != "x0" && pkg_failed=yes ], > +
Re: Boning the Troll
Hi, Peter Hessler wrote: Responding to any of their emails feeds the troll. Ignore them. People feed them quick and eagerly! And when somebody asks more concrete questions for porting stuff to openbsd, the response pace gets much slower :) R
Re: Boning the Troll
On 2013-07-12, Riccardo Mottola wrote: > Hi, > > Peter Hessler wrote: >> Responding to any of their emails feeds the troll. Ignore them. > People feed them quick and eagerly! And when somebody asks more concrete > questions for porting stuff to openbsd, the response pace gets much > slower :) > > R > > Troll feeding is a mostly unskilled operation, many more people are available for this service than for anything requiring actual thought.
Re: Management of pf.conf
Hi, No we don't use the puppet firewall module as it doesn't support PF properly. We don't use any 'software' to manage PF rules, but we do still have rules sets with thousands of lines. I have never found any PF configuration software that comes anywhere near what can be done with a carefully designed and hand written PF file structure, using Vim (with a modified bashrc and filetypes), reading the Book of PF and following the OpenBSD change logs to keep up with new features/changes and knowing the PF flow diagram by heart ( http://notamentaldowu.files.wordpress.com/2009/08/flow.png?w=700). Their just simply isn't a magic bullet if you want to achieve the full power of PF.. There are many great pieces PF software out there which are good for people who are learning, but none which can ever fully support the extremely wide features and packet mangling capabilities of PF (which is continually growing and changing), or can correctly parse all of our rules. Things especially get more complicated for parsing when you have multiple 'related' rules attached to different physical interfaces, but where all are needed to pass and queue a desired flow. I believe that a well structured PF file which is built up using several includes etc with a strong consistent structure is the best way to have access to /all/ the latest features and functions whilst maintaining visibility and ease of management. To make PF super friendly in Vim, set-up your PF syntax highlighting; /root/.vimrc; so /root/.vim/filetypes.vim set guifont=9x15bold set ruler syntax on set tabstop=4 set shiftwidth=4 filetype on /root/.vim/filetypes.vim; augroup filetype au! au BufRead,BufNewFile *.c set filetype=c au BufRead,BufNewFile pf.* set filetype=pf au BufRead,BufNewFile pf.conf set filetype=pf au BufRead,BufNewFile pf.conf.* set filetype=pf au BufRead,BufNewFile snort.conf set filetype=hog au BufRead,BufNewFile snort.conf.* set filetype=hog augroup END Not wanting to waffle as this is already long, but seeing as people seem interested (tell me to shut up if I am just generating noise ;) we structure our PF's roughly as follows; Global common; 'pc.conf.internalnetworks' - Defines common macro names for /all/ of the different subnets we have globally; E.g. int_net_hbase="10.0.50.0/24", int_net_solr="10.0.51.0/24", int_net_stage="10.0.52.0/24" . 'pf.conf.hosts' - This is a dynamic file. We have a script on each firewall which connects to the 'local' LDAP server, downloads every host macro for that zone and prints the int_ip_= macros into pf.conf.hosts 'pf.conf.publicips' - defines common macro names for /all/ of our public IP addresses to the roles they provide access to (multiple roles means multiple macros with the same IP etc) 'pf.conf.tables' - defines common tables like , , , etc 'pf.conf.options' - defines all our non-default firewall options including 'states', 'table-entries' and all of our 'Stateful Tracking Option' macros 'pf.conf.portgroups' - defines common service groups. E.g. 'office_mail_protos="smtp, 465, submission, imaps, pop3s"', 'office_chat_tcpports="5190, 5222, 5223, 5269, 5349"' etc Per environment common (DC, Office etc); 'pf.conf.queues.office' - defines all our HFSC queues (NB; the bandwidth values are $variables which are defined in the site specific includes allowing for a generic queue structure for all offices). 'pf.conf.queues.livedc' - defines all our HFSC queues (NB; the bandwidth values are $variables which are defined in the site specific includes allowing for a generic queue structure for all offices). 'pf.conf.rules.common.office' - The common office rules 'pf.conf.rules.common.dc' - The common DC rules 'pf.conf.scrub' -antispoof, urpf-failed, non_routable drops, packet scrubbing and tagging etc Site Specific; 'pf.conf.interfaces.berlin' - Defines common macro names mapping to all the physical interface names; E.g. if_ext="em0", if_lan="em1", if_dmz="em2" . 'pf.conf.interfaces.newyork' - Defines common macro names mapping to all the physical interface names; E.g. if_ext="em0", if_lan="em1", if_dmz="em2" . 'pf.conf.rules.berlin' - rdr-to, binat-to, nat-to, block, pass etc.. These bespoke per site rule files are now small and easy to manage :) 'pf.conf.rules.newyork' - rdr-to, binat-to, nat-to, block, pass etc.. . etc Puppet then pushes out the appropriate files to the appropriate firewalls using simple manifests. Hope this makes sense.. By grouping and standardising common things, the final site specific rules become very small and easy to read, and making wider global/environment changes are a one file change :) NB; When writing filter rules try to continue to be consistent and maintain structure remembering the 'PF skip steps' (PF optimises rule inspection by grouping rules (skip steps) skipping by; interface, protocol, source, destination, and finally by dest port). # EXT Interface, WAN Transit Egress Rules (post NAT) # EXT Inter
Re: Boning the Troll
On Fri, 12 Jul 2013 10:59:33 + (UTC), Stuart Henderson wrote: > >Troll feeding is a mostly unskilled operation, many more people are >available for this service than for anything requiring actual thought. > +1! *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
mdoc(7) -width description
The mdoc(7) manpage says about .Bl that The -width and -offset arguments accept scaling widths as described in roff(7) or use the length of the given string. The words "width" or "offset" do not appear anywhere in roff(7). A description of the often seen 'Ds' is given in the .Bd section, but again it points to roff(7) for the complete description, which is not there. Is that meant to be another roff-related manpage from base? Or groff(7)? Jan
Re: goaccess 0.5
did export CPPFLAGS and LDFLAGS and did follow in ' http://goaccess.prosoftcorp.com/faq' the section 'How to build GoAccess 0.4.2 on OpenBSD 4.8-current'. I did the modification in 'parser.c' but in 'util.c', 'sys/socket.h' was already included. Probably a change in version 0.5? Unfortunately, 'configure' gives the same error. Should I send you the config.log too? Thanks On Wed, Jul 10, 2013 at 1:31 AM, Juan Francisco Cantero Hurtado < i...@juanfra.info> wrote: > On Wed, Jul 10, 2013 at 12:01:11AM +0300, Tony Berth wrote: > > is anyone using goaccess 0.5 with 5.2 or 5.3? > > > > When running './configure' I get: > > > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether build environment is sane... yes > > checking for a thread-safe mkdir -p... ./install-sh -c -d > > checking for gawk... no > > checking for mawk... no > > checking for nawk... no > > checking for awk... awk > > checking whether make sets $(MAKE)... yes > > checking for gcc... gcc > > checking for C compiler default output file name... a.out > > checking whether the C compiler works... yes > > checking whether we are cross compiling... no > > checking for suffix of executables... > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether gcc accepts -g... yes > > checking for gcc option to accept ISO C89... none needed > > checking for style of include used by make... GNU > > checking dependency style of gcc... gcc3 > > checking for pkg-config... /usr/bin/pkg-config > > checking pkg-config is at least version 0.9.0... yes > > checking for GLIB2... yes > > checking for refresh in -lncurses... yes > > checking for new_menu in -lmenu... yes > > checking for g_free in -lglib-2.0... no > > configure: error: glib-2.x is missing > > CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure > > -- > Juan Francisco Cantero Hurtado http://juanfra.info
author emails in manpages
Authors' emails in manpages are generally written as .e.g. .An Damien Miller Aq d...@openbsd.org Should these be like .An Damien Miller Aq Mt d...@openbsd.org ?
Re: Management of pf.conf
On Fri, Jul 12, 2013 at 11:12 AM, Andy wrote: > Hi, > > No we don't use the puppet firewall module as it doesn’t support PF > properly. We don't use any 'software' to manage PF rules, but we do still > have rules sets with thousands of lines. > > I have never found any PF configuration software that comes anywhere near > what can be done with a carefully designed and hand written PF file > structure, using Vim (with a modified bashrc and filetypes), reading the > Book of PF and following the OpenBSD change logs to keep up with new > features/changes and knowing the PF flow diagram by heart ( > http://notamentaldowu.files.wordpress.com/2009/08/flow.png?w=700). > Their just simply isn't a magic bullet if you want to achieve the full power > of PF.. > > There are many great pieces PF software out there which are good for people > who are learning, but none which can ever fully support the extremely wide > features and packet mangling capabilities of PF (which is continually > growing and changing), or can correctly parse all of our rules. Things > especially get more complicated for parsing when you have multiple 'related' > rules attached to different physical interfaces, but where all are needed to > pass and queue a desired flow. > > I believe that a well structured PF file which is built up using several > includes etc with a strong consistent structure is the best way to have > access to all the latest features and functions whilst maintaining > visibility and ease of management. > > To make PF super friendly in Vim, set-up your PF syntax highlighting; > /root/.vimrc; > so /root/.vim/filetypes.vim > set guifont=9x15bold > set ruler > syntax on > set tabstop=4 > set shiftwidth=4 > filetype on > > /root/.vim/filetypes.vim; > augroup filetype > au! > au BufRead,BufNewFile *.c set filetype=c > au BufRead,BufNewFile pf.* set filetype=pf > au BufRead,BufNewFile pf.conf set filetype=pf > au BufRead,BufNewFile pf.conf.* set filetype=pf > au BufRead,BufNewFile snort.conf set filetype=hog > au BufRead,BufNewFile snort.conf.* set filetype=hog > augroup END > > Not wanting to waffle as this is already long, but seeing as people seem > interested (tell me to shut up if I am just generating noise ;) we structure > our PF's roughly as follows; > Global common; > 'pc.conf.internalnetworks' - Defines common macro names for all of the > different subnets we have globally; E.g. int_net_hbase="10.0.50.0/24", > int_net_solr="10.0.51.0/24", int_net_stage="10.0.52.0/24" . > 'pf.conf.hosts' - This is a dynamic file. We have a script on each firewall > which connects to the 'local' LDAP server, downloads every host macro for > that zone and prints the int_ip_= macros into pf.conf.hosts > 'pf.conf.publicips' - defines common macro names for all of our public IP > addresses to the roles they provide access to (multiple roles means multiple > macros with the same IP etc) > 'pf.conf.tables' - defines common tables like , , > , etc > 'pf.conf.options' - defines all our non-default firewall options including > 'states', 'table-entries' and all of our 'Stateful Tracking Option' > macros > 'pf.conf.portgroups' - defines common service groups. E.g. > 'office_mail_protos="smtp, 465, submission, imaps, pop3s"', > 'office_chat_tcpports="5190, 5222, 5223, 5269, 5349"' etc > Per environment common (DC, Office etc); > 'pf.conf.queues.office' - defines all our HFSC queues (NB; the bandwidth > values are $variables which are defined in the site specific includes > allowing for a generic queue structure for all offices). > 'pf.conf.queues.livedc' - defines all our HFSC queues (NB; the bandwidth > values are $variables which are defined in the site specific includes > allowing for a generic queue structure for all offices). > 'pf.conf.rules.common.office' - The common office rules > 'pf.conf.rules.common.dc' - The common DC rules > 'pf.conf.scrub' -antispoof, urpf-failed, non_routable drops, packet > scrubbing and tagging etc > Site Specific; > 'pf.conf.interfaces.berlin' - Defines common macro names mapping to all the > physical interface names; E.g. if_ext="em0", if_lan="em1", if_dmz="em2" > . > 'pf.conf.interfaces.newyork' - Defines common macro names mapping to all the > physical interface names; E.g. if_ext="em0", if_lan="em1", if_dmz="em2" > . > 'pf.conf.rules.berlin' - rdr-to, binat-to, nat-to, block, pass etc.. These > bespoke per site rule files are now small and easy to manage :) > 'pf.conf.rules.newyork' - rdr-to, binat-to, nat-to, block, pass etc.. > . > etc > > Puppet then pushes out the appropriate files to the appropriate firewalls > using simple manifests. > > Hope this makes sense.. By grouping and standardising common things, the > final site specific rules become very small and easy to read, and making > wider global/environment changes are a one file change :) > > NB; When writing filter rules try to continue to be consistent and maintain > structure remembering the 'PF skip steps' (PF optimises rule
Re: mdoc(7) -width description
Jan Stary writes: > The mdoc(7) manpage says about .Bl that > >The -width and -offset arguments accept scaling widths >as described in roff(7) or use the length of the given string. > > The words "width" or "offset" do not appear anywhere in roff(7). You're looking at the roff(7) manpage that comes with groff. Your pager probably prints "/usr/local/man/cat7/roff.0" at the bottom of your screen. You could use man -a and then enter ":n" to get the base manpage. > A description of the often seen 'Ds' is given in the .Bd section, > but again it points to roff(7) for the complete description, > which is not there. > > Is that meant to be another roff-related > manpage from base? Or groff(7)? > > Jan -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: ACPI - shutdown on current kernel
Riccardo Mottola libero.it> writes: > I updated to a curent OpenBSD snapshot, to get more advanced ACPI > support my HP laptop (other thread about battery status). > > What I noticed now is an annoying behaviour: "shutdown -hp now" doesn't > poweroff my machine. It apparently kills all processes, the display goes > blank, but the CPU is still running and stays so forever. I accidentally > packed my laptop in the case and found it all hot half an hour later :) I'm really trying to guess here, but could you try to revert http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/acpi/acpiec.c.diff?r1=1.47;r2=1.48 rebuild kernel and see if problem remain.
Re: author emails in manpages
On Fri, Jul 12, 2013 at 02:04:03PM +0200, Jan Stary wrote: > Authors' emails in manpages are generally written as .e.g. > > .An Damien Miller Aq d...@openbsd.org > > Should these be like > > .An Damien Miller Aq Mt d...@openbsd.org > > ? > perhaps. either Mt is fairly new, or i never noticed it before. we could wholesale change stuff, but haven;t yet. it probably does make sense for folks who want stuff like html pages. i did add an Mt fairly recently, but there can;t be many in tree. jmc
Re: author emails in manpages
On Jul 12, 2013, at 3:16 PM, Jason McIntyre wrote: > perhaps. either Mt is fairly new, or i never noticed it before. we could > wholesale change stuff, but haven;t yet. it probably does make sense for > folks who want stuff like html pages. > > i did add an Mt fairly recently, but there can;t be many in tree. Looks like this is almost exclusively used in mandoc/mdocml for most BSDs. Apparently nobody got the memo. ;)
Wake via serial port?
I've a box that won't self start after a power failure. The BIOS docs shows: Remote Ring On This allows you to wake up the system from a serial port modem. How could this be done from another OpenBSD box connected via a serial cross over cable + cu/tip/etc? The serial link is operational & I get the console on the non-self-starting box after I manually press the power button. Thoughts? -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: 5.4-beta#20 xterm(1)/luit(1) in cwm, CM-Return random defunc
On Jul 11 23:41:56, mhe...@gmail.com wrote: > On Wed, Jul 10, 2013 at 01:30:23AM -0700, Philip Guenther wrote: > > On Wed, Jul 10, 2013 at 1:19 AM, Philip Guenther wrote: > > > Looks like a race in luit's startup, due to how it handles the > > > ttys/ptys. To work around the problem, invoke it with the -p > > > option...but I don't know how you can convince xterm to do that. > > > > Ha! I believe this bug is a result of posix_openpt() being > > implemented in 5.3 and the luit configure script picking that instead > > of openpty(), as the code for the former results in the client side > > being opened (by PTMGET), then closed, then reopened by name, which > > leaves a window where the master will read EOF. > > > > Naddy, can you coerce configure into ignoring posix_openpt()? > > Can you check the patch below ? > (sorry it's huge since it regenerates autotools files) On my current/i386 with this patch, it happens less often but it still happens. > Index: Makefile.in > === > RCS file: /cvs/xenocara/app/luit/Makefile.in,v > retrieving revision 1.6 > diff -u -r1.6 Makefile.in > --- Makefile.in 10 Feb 2013 15:38:36 - 1.6 > +++ Makefile.in 11 Jul 2013 21:40:11 - > @@ -252,6 +252,8 @@ > PACKAGE_VERSION = @PACKAGE_VERSION@ > PATH_SEPARATOR = @PATH_SEPARATOR@ > PKG_CONFIG = @PKG_CONFIG@ > +PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > SED = @SED@ > SET_MAKE = @SET_MAKE@ > SHELL = @SHELL@ > Index: aclocal.m4 > === > RCS file: /cvs/xenocara/app/luit/aclocal.m4,v > retrieving revision 1.10 > diff -u -r1.10 aclocal.m4 > --- aclocal.m410 Feb 2013 15:38:36 - 1.10 > +++ aclocal.m411 Jul 2013 21:40:13 - > @@ -20,6 +20,7 @@ > To do so, use the procedure documented by the package, typically > 'autoreconf'.])]) > > # pkg.m4 - Macros to locate and utilise pkg-config.-*- Autoconf > -*- > +# serial 1 (pkg-config-0.24) > # > # Copyright ? 2004 Scott James Remnant . > # > @@ -46,8 +47,12 @@ > # -- > AC_DEFUN([PKG_PROG_PKG_CONFIG], > [m4_pattern_forbid([^_?PKG_[A-Z_]+$]) > -m4_pattern_allow([^PKG_CONFIG(_PATH)?$]) > -AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])dnl > +m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) > +m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) > +AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) > +AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search > path]) > +AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in > search path]) > + > if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then > AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) > fi > @@ -60,7 +65,6 @@ > AC_MSG_RESULT([no]) > PKG_CONFIG="" > fi > - > fi[]dnl > ])# PKG_PROG_PKG_CONFIG > > @@ -69,34 +73,32 @@ > # Check to see whether a particular set of modules exists. Similar > # to PKG_CHECK_MODULES(), but does not set variables or print errors. > # > -# > -# Similar to PKG_CHECK_MODULES, make sure that the first instance of > -# this or PKG_CHECK_MODULES is called, or make sure to call > -# PKG_CHECK_EXISTS manually > +# Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG]) > +# only at the first occurence in configure.ac, so if the first place > +# it's called might be skipped (such as if it is within an "if", you > +# have to call PKG_CHECK_EXISTS manually > # -- > AC_DEFUN([PKG_CHECK_EXISTS], > [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl > if test -n "$PKG_CONFIG" && \ > AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then > - m4_ifval([$2], [$2], [:]) > + m4_default([$2], [:]) > m4_ifvaln([$3], [else >$3])dnl > fi]) > > - > # _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES]) > # - > m4_define([_PKG_CONFIG], > -[if test -n "$PKG_CONFIG"; then > -if test -n "$$1"; then > -pkg_cv_[]$1="$$1" > -else > -PKG_CHECK_EXISTS([$3], > - [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`], > - [pkg_failed=yes]) > -fi > -else > - pkg_failed=untried > +[if test -n "$$1"; then > +pkg_cv_[]$1="$$1" > + elif test -n "$PKG_CONFIG"; then > +PKG_CHECK_EXISTS([$3], > + [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null` > + test "x$?" != "x0" && pkg_failed=yes ], > + [pkg_failed=yes]) > + else > +pkg_failed=untried > fi[]dnl > ])# _PKG_CONFIG > > @@ -138,16 +140,17 @@ > See the pkg-config man page for more details.]) > > if test $pkg_failed = yes; then > + AC_MSG_RESULT([no]) > _PKG_SHORT_ERRORS_SUPPORTED >
Re: author emails in manpages
Hi, Franco Fichtner wrote on Fri, Jul 12, 2013 at 03:42:58PM +0200: > On Jul 12, 2013, at 3:16 PM, Jason McIntyre wrote: >> On Fri, Jul 12, 2013 at 02:04:03PM +0200, Jan Stary wrote: >>> Authors' emails in manpages are generally written as .e.g. >>> >>> .An Damien Miller Aq d...@openbsd.org >>> >>> Should these be like >>> >>> .An Damien Miller Aq Mt d...@openbsd.org >> perhaps. either Mt is fairly new, The first implementation i could find so far was committed to the groff CVS on March 23, 2001, and it was released with groff 1.17 on May 2, 2001. I can't exclude it appeared earlier elsewehere. Neither the final CSRG code nor Heirloom troff appear to support .Mt, though. >> or i never noticed it before. we could >> wholesale change stuff, but haven;t yet. I think i'd like that, even though we would have to touch large numbers of pages. I'd indeed prefer the following style, using pkg-config(1) as an example: .Sh AUTHORS .Nm was written by .An Chris Kuethe Aq Mt ckue...@openbsd.org as a replacement for the original freedesktop.org .Nm implementation. It was later extended and kept in sync (where relevant) with the original version by .An Marc Espie Aq Mt es...@openbsd.org and .An Jasper Lievisse Adriaanse Aq Mt jas...@openbsd.org . Note that so far, the mandoc manuals themselves use just `Mt' and not `Aq Mt', but i think `Aq Mt' reads better and i should probably change the mandoc manuals, too. >> it probably does make sense for >> folks who want stuff like html pages. Exactly. >> i did add an Mt fairly recently, but there can;t be many in tree. > Looks like this is almost exclusively used in mandoc/mdocml for most > BSDs. Apparently nobody got the memo. ;) Maybe, but groff has been supporting it for a long time and that was the de-facto reference implementation of mdoc(7) before mandoc was written. So i think it's just that nobody did the work of adding the markup, yet. Yours, Ingo
Re: author emails in manpages
On Jul 12 14:04:03, h...@stare.cz wrote: > Authors' emails in manpages are generally written as .e.g. > > .An Damien Miller Aq d...@openbsd.org > > Should these be like > > .An Damien Miller Aq Mt d...@openbsd.org > On Jul 12 15:42:58, slash...@gmail.com wrote: > Looks like this is almost exclusively used in mandoc/mdocml for most > BSDs. Apparently nobody got the memo. ;) I should have been more specific: I mean our tree, which uses mdocml (as do some other BSDs), which introduces .Mt - why don't we use it for authors' emails?
Re: Wake via serial port?
On 07/12/2013 09:45 AM, Craig R. Skinner wrote: I've a box that won't self start after a power failure. The BIOS docs shows: Remote Ring On This allows you to wake up the system from a serial port modem. How could this be done from another OpenBSD box connected via a serial cross over cable + cu/tip/etc? The serial link is operational & I get the console on the non-self-starting box after I manually press the power button. Thoughts? not going to give you a "do this and all will work", but I'll tell you how to figure it out. 1) verify that this "feature" really works on this machine... a) Get a nine volt battery and a battery clip ending in two wires. b) Connect the battery between the Ring Indicator (RI) pin and the ground pin. c) If it doesn't turn on, swap the red and black wires, and try again. d) If it still doesn't work, it's a left over feature in the bios, your hardware doesn't actually support this. 2) Find a line you can control on the terminal machine. man 4 tty, man 4 termios appear to be useful. a) Get/build an RS232 monitoring plug, and figure out what RS232 handshake line you can control (std two-pin, red/green LEDs and 1K resistors do just fine here) b) the pin you can control should default to the right polarity for what you wish to accomplish. 3) Make it work Build a custom cable which connects the line you can control to the ring detect line. Note that standard null modem cables don't generally pass the RI pin, so you will be building one. Maybe easier: just strap the RI pin to a level that causes the machine to light up on its own. An old cell phone charger or other wall wart may be usable to do this. A stupidly simple trick to make a box auto-start after a power failure, and I think I can credit Henning@ with suggesting it to me, is to put a capacitor across the power button lines. On power-up, the capacitor is discharged, so passes current, acting like someone was pushing the power button. It quickly charges up, and now it acts as if someone released the button. IIRC, 100uF worked pretty well on one machine I did this with, your results will vary. Make sure you get the cap polarity right, or it won't last very long!! I found it good to put a bleeder resistor across the cap/switch combo, too, as otherwise the power had to be off too long to auto-start when it came back up (the capacitor was still charged!), you will have to experiment with this. The bleeder resistor should be as low in resistance as doesn't cause the machine to think the button is pushed, maybe try 1k, 10k, 100k, 1M values. Nick.
Re: goaccess 0.5
On Fri, July 12, 2013 16:03, Tony Berth wrote: > did export CPPFLAGS and LDFLAGS and did follow in ' > http://goaccess.prosoftcorp.com/faq' the section 'How to build GoAccess > 0.4.2 on OpenBSD 4.8-current'. I did the modification in 'parser.c' but in > 'util.c', 'sys/socket.h' was already included. Probably a change in version > 0.5? > Unfortunately, 'configure' gives the same error. Should I send you the > config.log too? > > Thanks > Hi. Take a look at http://cvs.linklevel.net/index.cgi/ports/www/ > > On Wed, Jul 10, 2013 at 1:31 AM, Juan Francisco Cantero Hurtado < > i...@juanfra.info> wrote: > >> On Wed, Jul 10, 2013 at 12:01:11AM +0300, Tony Berth wrote: >> > is anyone using goaccess 0.5 with 5.2 or 5.3? >> > >> > When running './configure' I get: >> > >> > checking for a BSD-compatible install... /usr/bin/install -c >> > checking whether build environment is sane... yes >> > checking for a thread-safe mkdir -p... ./install-sh -c -d >> > checking for gawk... no >> > checking for mawk... no >> > checking for nawk... no >> > checking for awk... awk >> > checking whether make sets $(MAKE)... yes >> > checking for gcc... gcc >> > checking for C compiler default output file name... a.out >> > checking whether the C compiler works... yes >> > checking whether we are cross compiling... no >> > checking for suffix of executables... >> > checking for suffix of object files... o >> > checking whether we are using the GNU C compiler... yes >> > checking whether gcc accepts -g... yes >> > checking for gcc option to accept ISO C89... none needed >> > checking for style of include used by make... GNU >> > checking dependency style of gcc... gcc3 >> > checking for pkg-config... /usr/bin/pkg-config >> > checking pkg-config is at least version 0.9.0... yes >> > checking for GLIB2... yes >> > checking for refresh in -lncurses... yes >> > checking for new_menu in -lmenu... yes >> > checking for g_free in -lglib-2.0... no >> > configure: error: glib-2.x is missing >> >> CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure >> >> -- >> Juan Francisco Cantero Hurtado http://juanfra.info
Re: mdoc(7) -width description
Hi,
Jérémie Courrèges-Anglas wrote on Fri, Jul 12, 2013 at 02:05:48PM +0200:
> Jan Stary writes:
>> The mdoc(7) manpage says about .Bl that
>>
>> The -width and -offset arguments accept scaling widths
>> as described in roff(7) or use the length of the given string.
>>
>> The words "width" or "offset" do not appear anywhere in roff(7).
> You're looking at the roff(7) manpage that comes with groff.
I consider that a bug in man.conf(5), so I moved the thread to tech@
and proposed a patch there, watch out for
"Subject: man.conf(5) _subdir search order".
Please consider this thread closed in misc@, or at least,
if you must follow-up, make sure that you do not cross-post.
Yours,
Ingo
Index: man.conf
===
RCS file: /cvs/src/etc/man.conf,v
retrieving revision 1.17
diff -u -r1.17 man.conf
--- man.conf11 Apr 2011 14:45:41 - 1.17
+++ man.conf12 Jul 2013 15:25:14 -
@@ -9,7 +9,7 @@
_whatdb/usr/X11R6/man/whatis.db
# Subdirectories for paths ending in '/', IN SEARCH ORDER.
-_subdircat1 man1 cat8 man8 cat6 man6 cat2 man2 cat3 man3 cat5
man5 cat7 man7 cat4 man4 cat9 man9 cat3p man3p cat3f man3f catn mann
+_subdir{cat,man}1 {cat,man}8 {cat,man}6 {cat,man}2 {cat,man}3
{cat,man}5 {cat,man}7 {cat,man}4 {cat,man}9 {cat,man}3p {cat,man}3f {cat,man}n
# Files typed by suffix and their commands.
# Note the order: .Z must come after .[1-9n].Z, or it will match first.
Re: Snort vs Suricata
On 11. juli 2013 at 9:23 PM, "Chris Cappuccio" wrote: >> >> Anybody have any thoughts on Snort vs Suricata? > >Code quality is going to be a big question with the new one, as it >always has been with Snort (does running this utility open up a >new attack vector on your network) Yeah, good point. >> Also, how important is it to use an IDS if you run a server that >hosts a popular website? > >Depends on how well you configure the IDS and how well you monitor >it (and if you know what to even look for...) Maybe Snorby can help with that? https://github.com/Snorby/snorby >> I'm reading here (http://www.aldeid.com/wiki/Suricata-vs-snort): >> Suricata offers new features that Snort could implement in the >> future: multi-threading support, capture accelerators [...snip...] >> One advantage Suricata has is its ability to understand level 7 of >> the OSI model, which enhances its ability of detecting malwares. >> Suricata has demonstrated that it is far more efficient than Snort >> for detecting malwares, viruses and shellcodes. > >Snort is different, I don't see why you expect that it will >suddenly become equivalent. Both are supposed to help you detect intrusions so in that sense I guess they're the same? >For high-speed capture and analysis, a dedicated box with netmap >is much better for tools like this. I think i should finish the >port that I was working on :) Which one, /usr/ports/security/suricata? O.D.
Re: 5.4-beta#20 xterm(1)/luit(1) in cwm, CM-Return random defunc
On Fri, Jul 12, 2013 at 09:38:07AM +0200, MERIGHI Marcus wrote: > mhe...@gmail.com (Matthieu Herrb), 2013.07.11 (Thu) 23:41 (CEST): > > On Wed, Jul 10, 2013 at 01:30:23AM -0700, Philip Guenther wrote: > > > On Wed, Jul 10, 2013 at 1:19 AM, Philip Guenther > > > wrote: > > > > Looks like a race in luit's startup, due to how it handles the > > > > ttys/ptys. To work around the problem, invoke it with the -p > > > > option...but I don't know how you can convince xterm to do that. > > > > > > Ha! I believe this bug is a result of posix_openpt() being > > > implemented in 5.3 and the luit configure script picking that instead > > > of openpty(), as the code for the former results in the client side > > > being opened (by PTMGET), then closed, then reopened by name, which > > > leaves a window where the master will read EOF. > > > > > > Naddy, can you coerce configure into ignoring posix_openpt()? > > > > Can you check the patch below ? > > (sorry it's huge since it regenerates autotools files) > > I hate being a spoilsport, but... it does not change the random defunc. > > What I did: > 1) cd /usr/xenocara/app/luit > 2) patch < ~/luit.patch > (no errors) > 3) ./configure; make; make install That should be : rm /usr/xobj/xorg-config.cache.* make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build instead. And check with nm -u /usr/X11R6/bin/luit | grep openpty that openpty() is referenced (and not posix_openpt()). I can't reproduce the issue with that patch and the resulting luit binary (yes I was able to reproduce it before) > (no errors) > 4) ~/.Xresources: enable ``XTerm*locale:ISO8859-1'' > 5) xrdb -merge ~/.Xresources > 6) hit CM-Return > 7) get a new xterm or not > > Bye, Marcus > > > Index: Makefile.in > > === > > RCS file: /cvs/xenocara/app/luit/Makefile.in,v > > retrieving revision 1.6 > > diff -u -r1.6 Makefile.in > > --- Makefile.in 10 Feb 2013 15:38:36 - 1.6 > > +++ Makefile.in 11 Jul 2013 21:40:11 - > > @@ -252,6 +252,8 @@ > > PACKAGE_VERSION = @PACKAGE_VERSION@ > > PATH_SEPARATOR = @PATH_SEPARATOR@ > > PKG_CONFIG = @PKG_CONFIG@ > > +PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ > > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > > SED = @SED@ > > SET_MAKE = @SET_MAKE@ > > SHELL = @SHELL@ > > Index: aclocal.m4 > > === > > RCS file: /cvs/xenocara/app/luit/aclocal.m4,v > > retrieving revision 1.10 > > diff -u -r1.10 aclocal.m4 > > --- aclocal.m4 10 Feb 2013 15:38:36 - 1.10 > > +++ aclocal.m4 11 Jul 2013 21:40:13 - > > @@ -20,6 +20,7 @@ > > To do so, use the procedure documented by the package, typically > > 'autoreconf'.])]) > > > > # pkg.m4 - Macros to locate and utilise pkg-config.-*- > > Autoconf -*- > > +# serial 1 (pkg-config-0.24) > > # > > # Copyright © 2004 Scott James Remnant . > > # > > @@ -46,8 +47,12 @@ > > # -- > > AC_DEFUN([PKG_PROG_PKG_CONFIG], > > [m4_pattern_forbid([^_?PKG_[A-Z_]+$]) > > -m4_pattern_allow([^PKG_CONFIG(_PATH)?$]) > > -AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])dnl > > +m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) > > +m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) > > +AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) > > +AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search > > path]) > > +AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in > > search path]) > > + > > if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then > > AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) > > fi > > @@ -60,7 +65,6 @@ > > AC_MSG_RESULT([no]) > > PKG_CONFIG="" > > fi > > - > > fi[]dnl > > ])# PKG_PROG_PKG_CONFIG > > > > @@ -69,34 +73,32 @@ > > # Check to see whether a particular set of modules exists. Similar > > # to PKG_CHECK_MODULES(), but does not set variables or print errors. > > # > > -# > > -# Similar to PKG_CHECK_MODULES, make sure that the first instance of > > -# this or PKG_CHECK_MODULES is called, or make sure to call > > -# PKG_CHECK_EXISTS manually > > +# Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG]) > > +# only at the first occurence in configure.ac, so if the first place > > +# it's called might be skipped (such as if it is within an "if", you > > +# have to call PKG_CHECK_EXISTS manually > > # -- > > AC_DEFUN([PKG_CHECK_EXISTS], > > [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl > > if test -n "$PKG_CONFIG" && \ > > AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then > > - m4_ifval([$2], [$2], [:]) > > + m4_default([$2], [:]) > > m4_ifvaln([$3], [else > >$3])dnl > > fi]) > > > > - > > # _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES]) > > # --
Re: Wake via serial port?
On 2013-07-12 Fri 10:42 AM |, Nick Holland wrote: > > but I'll tell you how to figure it out. > > [ wise words of practical relevance ] > Solved! Thanks, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
DAYS OF THE MONTH
Hi, o.s.: OpenBSD 5.3/amd64 If I create a directory with the command: mkdir $(date +'%d') why this is the result: 1, 2, 3, 4, 5, 6, 7, 08, 09, 10, etc. Why the '0' [zero] appears only ahead the digit 8 and 9..? Thanks.
Re: days of the month
"Max Power" writes: > Hi, Hi. Please stop using all-caps mail subjects. > o.s.: OpenBSD 5.3/amd64 > > If I create a directory with the command: mkdir $(date +'%d') You'd better put double quotes around your command substitutions rather than simple quotes around fixed, non-special strings: "$(date '+%d')" > why this is the result: 1, 2, 3, 4, 5, 6, 7, 08, 09, 10, etc. > Why the '0' [zero] appears only ahead the digit 8 and 9..? You must have done something wrong: $ date -j +%d 2013701 01 $ See strftime(3). -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: Wake via serial port?
On 07/12/2013 10:38 PM, Craig R. Skinner wrote: > On 2013-07-12 Fri 10:42 AM |, Nick Holland wrote: >> >> but I'll tell you how to figure it out. >> >> [ wise words of practical relevance ] >> > > Solved! > > Thanks, > would you mind to share how you have solved the problem? otherwise someone has to ask the same question some day. best, thomas
Re: days of the month
> You must have done something wrong: I have not done anything. The system is the default installation. > You'd better put double quotes around your command substitutions rather > than simple quotes around fixed, non-special strings: "$(date '+%d')" Ok, but why the command: mkdir $(date +'%d') after the digit 7 works fine? If I insert the date manually then it works fine - example: # date 20130707 but no by default. Why? thanks > "Max Power" writes: > >> Hi, > > Hi. Please stop using all-caps mail subjects. > >> o.s.: OpenBSD 5.3/amd64 >> >> If I create a directory with the command: mkdir $(date +'%d') > > You'd better put double quotes around your command substitutions rather > than simple quotes around fixed, non-special strings: "$(date '+%d')" > >> why this is the result: 1, 2, 3, 4, 5, 6, 7, 08, 09, 10, etc. >> Why the '0' [zero] appears only ahead the digit 8 and 9..? > > You must have done something wrong: > > $ date -j +%d 2013701 > 01 > $ > > See strftime(3). > > -- > Jérémie Courrèges-Anglas > PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: 5.4-beta#20 xterm(1)/luit(1) in cwm, CM-Return random defunc
On Jul 12 22:11:58, mhe...@gmail.com wrote: > On Fri, Jul 12, 2013 at 09:38:07AM +0200, MERIGHI Marcus wrote: > > mhe...@gmail.com (Matthieu Herrb), 2013.07.11 (Thu) 23:41 (CEST): > > > On Wed, Jul 10, 2013 at 01:30:23AM -0700, Philip Guenther wrote: > > > > On Wed, Jul 10, 2013 at 1:19 AM, Philip Guenther > > > > wrote: > > > > > Looks like a race in luit's startup, due to how it handles the > > > > > ttys/ptys. To work around the problem, invoke it with the -p > > > > > option...but I don't know how you can convince xterm to do that. > > > > > > > > Ha! I believe this bug is a result of posix_openpt() being > > > > implemented in 5.3 and the luit configure script picking that instead > > > > of openpty(), as the code for the former results in the client side > > > > being opened (by PTMGET), then closed, then reopened by name, which > > > > leaves a window where the master will read EOF. > > > > > > > > Naddy, can you coerce configure into ignoring posix_openpt()? > > > > > > Can you check the patch below ? > > > (sorry it's huge since it regenerates autotools files) > > > > I hate being a spoilsport, but... it does not change the random defunc. > > > > What I did: > > 1) cd /usr/xenocara/app/luit > > 2) patch < ~/luit.patch > > (no errors) > > 3) ./configure; make; make install > > That should be : > > rm /usr/xobj/xorg-config.cache.* > make -f Makefile.bsd-wrapper obj > make -f Makefile.bsd-wrapper build > > instead. > > And check with nm -u /usr/X11R6/bin/luit | grep openpty that > openpty() is referenced (and not posix_openpt()). I just applied the patch and did exactly the above: # ls -l /usr/X11R6/bin/luit -rwxr-xr-x 1 root wheel 35824 Jul 12 23:36 /usr/X11R6/bin/luit # nm /usr/X11R6/bin/luit | grep -F openpt U posix_openpt Am I missing something? > I can't reproduce the issue with that patch and the resulting luit > binary (yes I was able to reproduce it before) > > > (no errors) > > 4) ~/.Xresources: enable ``XTerm*locale:ISO8859-1'' > > 5) xrdb -merge ~/.Xresources > > 6) hit CM-Return > > 7) get a new xterm or not > > > > Bye, Marcus > > > > > Index: Makefile.in > > > === > > > RCS file: /cvs/xenocara/app/luit/Makefile.in,v > > > retrieving revision 1.6 > > > diff -u -r1.6 Makefile.in > > > --- Makefile.in 10 Feb 2013 15:38:36 - 1.6 > > > +++ Makefile.in 11 Jul 2013 21:40:11 - > > > @@ -252,6 +252,8 @@ > > > PACKAGE_VERSION = @PACKAGE_VERSION@ > > > PATH_SEPARATOR = @PATH_SEPARATOR@ > > > PKG_CONFIG = @PKG_CONFIG@ > > > +PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ > > > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > > > SED = @SED@ > > > SET_MAKE = @SET_MAKE@ > > > SHELL = @SHELL@ > > > Index: aclocal.m4 > > > === > > > RCS file: /cvs/xenocara/app/luit/aclocal.m4,v > > > retrieving revision 1.10 > > > diff -u -r1.10 aclocal.m4 > > > --- aclocal.m410 Feb 2013 15:38:36 - 1.10 > > > +++ aclocal.m411 Jul 2013 21:40:13 - > > > @@ -20,6 +20,7 @@ > > > To do so, use the procedure documented by the package, typically > > > 'autoreconf'.])]) > > > > > > # pkg.m4 - Macros to locate and utilise pkg-config.-*- > > > Autoconf -*- > > > +# serial 1 (pkg-config-0.24) > > > # > > > # Copyright ? 2004 Scott James Remnant . > > > # > > > @@ -46,8 +47,12 @@ > > > # -- > > > AC_DEFUN([PKG_PROG_PKG_CONFIG], > > > [m4_pattern_forbid([^_?PKG_[A-Z_]+$]) > > > -m4_pattern_allow([^PKG_CONFIG(_PATH)?$]) > > > -AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])dnl > > > +m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) > > > +m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) > > > +AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) > > > +AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search > > > path]) > > > +AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in > > > search path]) > > > + > > > if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then > > > AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) > > > fi > > > @@ -60,7 +65,6 @@ > > > AC_MSG_RESULT([no]) > > > PKG_CONFIG="" > > > fi > > > - > > > fi[]dnl > > > ])# PKG_PROG_PKG_CONFIG > > > > > > @@ -69,34 +73,32 @@ > > > # Check to see whether a particular set of modules exists. Similar > > > # to PKG_CHECK_MODULES(), but does not set variables or print errors. > > > # > > > -# > > > -# Similar to PKG_CHECK_MODULES, make sure that the first instance of > > > -# this or PKG_CHECK_MODULES is called, or make sure to call > > > -# PKG_CHECK_EXISTS manually > > > +# Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG]) > > > +# only at the first occurence in configure.ac, so if the first place > > > +# it's called might be skipped (such as if it i
Re: days of the month
On Jul 12 23:34:27, open...@cpnetserver.net wrote: > > You must have done something wrong: > I have not done anything. The system is the default installation. > > > You'd better put double quotes around your command substitutions rather > > than simple quotes around fixed, non-special strings: "$(date '+%d')" > Ok, but why the command: mkdir $(date +'%d') after the digit 7 works fine? Come back on the first of August, with a script(1) in your hand.
IDE disk erasing/zeroing at ~2.4MB/s
I have a disk -- IIRC, Seagate Barracuda 160gb 7200RPM 8MB Cache SATA 3.0GB/s dmesg: wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors wd0 (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 hours, it's only running at ~2.4MB/s. CPU usage is about 30%. First, shouldn't SATA drives be sd0? (Looked in BIOS, can't find any SATA-to-IDE options enabled) Second, what can I do to speed it up? or troubleshoot it at least?
Re: days of the month
Forgive my fault and my English! What I want to know is why [technically] the scipt: mkdir $(date +'%d'), whith the default system date, with no manual insertion, return this sequence of digits: 1, 2, 3, 4, 5, 6, 7, 08, 09, 10, etc. Why the '0' [zero] appears only after the digit 7? I hope I explained myself. Thanks for the explanation and for your patience, Max Power. > On Jul 12 23:34:27, open...@cpnetserver.net wrote: >> > You must have done something wrong: >> I have not done anything. The system is the default installation. >> >> > You'd better put double quotes around your command substitutions >> rather >> > than simple quotes around fixed, non-special strings: "$(date '+%d')" >> Ok, but why the command: mkdir $(date +'%d') after the digit 7 works >> fine? > > Come back on the first of August, > with a script(1) in your hand.
Re: days of the month
2013/7/12 Max Power :
>> You must have done something wrong:
> I have not done anything. The system is the default installation.
Try to reproduce this:
$ for i in `jot -w %02d 31 1`; do date -j +%d 201307${i}; done
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Re: days of the month
"Max Power" writes: >> You must have done something wrong: > I have not done anything. Hey, you must have done *something*. Else you wouldn't be reporting about it. You just don't want to tell us *exactly* what you've done. > The system is the default installation. I'm not saying that you have fucked up your system. >> You'd better put double quotes around your command substitutions rather >> than simple quotes around fixed, non-special strings: "$(date '+%d')" > Ok, but why the command: mkdir $(date +'%d') after the digit 7 works fine? If you showed us the actual commands you use, we wouldn't have to guess. To further explain what Jan said in an earlier mail: somewhere in your script the number output by date(1) is interpreted while in an arithmetic context, where numbers starting with '0' are interpreted as octal, and their leading zero gets trimmed. But this doesn't happen for 08 and 09 which aren't valid octal numbers. ~$ v=03; v=$(($v)) ~$ echo $v 3 ~$ v=08; v=$(($v)) ksh: 08: bad number `08' ~$ echo $v 08 ~$ Hence the reference to August, where scripts that have worked fine so far start failing with weird error messages. > If I insert the date manually then it works fine - example: # date > 20130707 Now I can say that you're trying to fuck up your system. :) > but no by default. Why? thanks -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: days of the month
On Jul 12 23:54:56, open...@cpnetserver.net wrote: > Forgive my fault and my English! > What I want to know is why [technically] the scipt: mkdir $(date +'%d'), That's not a script. That's a line from some script which you haven't shown us. > whith the default system date, with no manual insertion, return this > sequence of digits: That line doesn't return any sequence of digits, it creates directories. > 1, 2, 3, 4, 5, 6, 7, 08, 09, 10, etc. > Why the '0' [zero] appears only after the digit 7? One might _guess_ that's where the "0n" is no longer a valid octal number, but without seeing your broken script, that's all: a guess.
Re: goaccess 0.5
On Friday 12 July 2013 19:33:13 Kirill Bychkov wrote: > On Fri, July 12, 2013 16:03, Tony Berth wrote: > > did export CPPFLAGS and LDFLAGS and did follow in ' > > http://goaccess.prosoftcorp.com/faq' the section 'How to build > > GoAccess 0.4.2 on OpenBSD 4.8-current'. I did the modification in > > 'parser.c' but in 'util.c', 'sys/socket.h' was already included. > > Probably a change in version 0.5? > > Unfortunately, 'configure' gives the same error. Should I send you > > the config.log too? > > > > Thanks Use the Kirill's port. Anyway, I don't have errors compiling goaccess by hand (OpenBSD-current). > > Hi. Take a look at http://cvs.linklevel.net/index.cgi/ports/www/ > Kirill, Can you commit the port?. It is useful and pretty. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: days of the month
On 07/13/13 00:06, Jérémie Courrèges-Anglas wrote: "Max Power" writes: You must have done something wrong: I have not done anything. Hey, you must have done *something*. Else you wouldn't be reporting about it. You just don't want to tell us *exactly* what you've done. The system is the default installation. I'm not saying that you have fucked up your system. You'd better put double quotes around your command substitutions rather than simple quotes around fixed, non-special strings: "$(date '+%d')" Ok, but why the command: mkdir $(date +'%d') after the digit 7 works fine? If you showed us the actual commands you use, we wouldn't have to guess. To further explain what Jan said in an earlier mail: somewhere in your script the number output by date(1) is interpreted while in an arithmetic context, where numbers starting with '0' are interpreted as octal, and their leading zero gets trimmed. But this doesn't happen for 08 and 09 which aren't valid octal numbers. ~$ v=03; v=$(($v)) ~$ echo $v 3 ~$ v=08; v=$(($v)) ksh: 08: bad number `08' ~$ echo $v 08 ~$ My *guess*: typeset -i /Alexander Hence the reference to August, where scripts that have worked fine so far start failing with weird error messages. If I insert the date manually then it works fine - example: # date 20130707 Now I can say that you're trying to fuck up your system. :) but no by default. Why? thanks
Re: IDE disk erasing/zeroing at ~2.4MB/s (full dmesg)
Full GENERIC kernel dmesg on request:
OpenBSD 5.3 (GENERIC) #26: Fri Jul 12 16:26:16 MDT 2013
r...@binarynet.hsd1.nm.comcast.net.:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) D CPU 3.20GHz ("GenuineIntel" 686-class) 3.22 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,PDCM,LAHF
real mem = 3220697088 (3071MB)
avail mem = 3157102592 (3010MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/04/06, BIOS32 rev. 0 @ 0xfaea0,
SMBIOS rev. 2.3 @ 0xf0100 (39 entries)
bios0: vendor Award Software International, Inc. version "F2" date
08/04/2006
bios0: Gigabyte Technology Co., Ltd. 945P-S3
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP MCFG APIC
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5)
PEX5(S5) HUB0(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USBE(S1) AZAL(S5)
PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus 3 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 4 (HUB0)
acpicpu0 at acpi0
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xf600 0xd/0x8000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82945G PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon X1650 Pro" rev 0x9e
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 16
drm0 at radeondrm0
"ATI Radeon X1650 Pro Sec" rev 0x9e at pci1 dev 0 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
azalia0: codecs: Realtek ALC883
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 2 int 16
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 2 int 19
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x01: RTL8168 2
(0x3800), apic 2 int 19, address 00:16:e6:6c:48:bd
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci4 at ppb3 bus 4
"Ralink RT3060" rev 0x00 at pci4 dev 0 function 0 not configured
xl0 at pci4 dev 1 function 0 "3Com 3c905B 100Base-TX" rev 0x24: apic 2
int 19, address 00:10:4b:64:a6:10
exphy0 at xl0 phy 24: 3Com internal media interface
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01: PM disabled
pciide0 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI
5/cdrom removable
wd1 at pciide0 channel 1 drive 1:
wd1: 16-sector PIO, LBA, 38166MB, 78165360 sectors
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 5
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 2
int 19
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 512MB DDR2 SDRAM non-parity PC2-6400CL5
spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-6400CL5
spdmem2 at iic0 addr 0x52: 512MB DDR2 SDRAM non-parity PC2-6400CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at
Re: IDE disk erasing/zeroing at ~2.4MB/s
On 07/12/13 23:50, Nathan Goings wrote: I have a disk -- IIRC, Seagate Barracuda 160gb 7200RPM 8MB Cache SATA 3.0GB/s dmesg: wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors wd0 (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 use the raw device, /dev/rwd0c, not the block device. I have found close to no speed improvements with bs > 64k. /Alexander hours, it's only running at ~2.4MB/s. CPU usage is about 30%. First, shouldn't SATA drives be sd0? (Looked in BIOS, can't find any SATA-to-IDE options enabled) Second, what can I do to speed it up? or troubleshoot it at least?
Re: IDE disk erasing/zeroing at ~2.4MB/s
On Fri, Jul 12, 2013 at 03:50:58PM -0600, Nathan Goings wrote: > However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 > hours, it's only running at ~2.4MB/s. CPU usage is about 30%. Do instead: dd if=/dev/zero of=/dev/rwd0c bs=1M Nicolai
Re: IDE disk erasing/zeroing at ~2.4MB/s
On 7/12/2013 5:12 PM, Alexander Hall wrote: use the raw device, /dev/rwd0c, not the block device. Tried: dd if=/dev/zero of=/dev/rwd0c bs=64k It runs at ~72MB/s. Thanks!
Re: IDE disk erasing/zeroing at ~2.4MB/s
Nathan Goings writes: > I have a disk -- IIRC, Seagate Barracuda 160gb 7200RPM 8MB Cache SATA > 3.0GB/s > > dmesg: > wd0 at pciide0 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors > wd0 (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 > > However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 > hours, it's only running at ~2.4MB/s. CPU usage is about 30%. See other replies. > First, shouldn't SATA drives be sd0? (Looked in BIOS, can't find any > SATA-to-IDE options enabled) Second, what can I do to speed it up? or > troubleshoot it at least? See pciide(4). My day-to-day laptop has the same drive controller, previous BIOS versions had a switch to choose SATA but they removed it. *shrug* -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: Wake via serial port?
Thomas What you are asking only makes sense, unfortunately Craig appears to be like a lot of malling list subscribers. They are "takers" not "givers". g.day diana On Fri, 12 Jul 2013, Thomas Reiter wrote: On 07/12/2013 10:38 PM, Craig R. Skinner wrote: On 2013-07-12 Fri 10:42 AM |, Nick Holland wrote: but I'll tell you how to figure it out. [ wise words of practical relevance ] Solved! Thanks, would you mind to share how you have solved the problem? otherwise someone has to ask the same question some day. best, thomas
Re: Wake via serial port?
On Fri, Jul 12, 2013 at 4:39 PM, Diana Eichert wrote: > Thomas > > What you are asking only makes sense, unfortunately > Craig appears to be like a lot of malling list > subscribers. They are "takers" not "givers". Nick already explained and outlined all the necessary steps. Did he not? --patrick > g.day > > diana > > On Fri, 12 Jul 2013, Thomas Reiter wrote: > >> On 07/12/2013 10:38 PM, Craig R. Skinner wrote: >>> >>> On 2013-07-12 Fri 10:42 AM |, Nick Holland wrote: but I'll tell you how to figure it out. [ wise words of practical relevance ] >>> >>> Solved! >>> >>> Thanks, >>> >> >> would you mind to share how you have solved the problem? >> otherwise someone has to ask the same question some day. >> >> >> best, >> thomas
Re: Wake via serial port?
On 07/12/13 20:05, patrick keshishian wrote: > On Fri, Jul 12, 2013 at 4:39 PM, Diana Eichert wrote: >> Thomas >> >> What you are asking only makes sense, unfortunately >> Craig appears to be like a lot of malling list >> subscribers. They are "takers" not "givers". > > Nick already explained and outlined all the necessary steps. Did he not? > > --patrick > yeah, but people usually nod off after the second or third sentence. :) Nick. (Curing Insomnia since 1983)
Re: IDE disk erasing/zeroing at ~2.4MB/s
On 07/12/13 19:11, Alexander Hall wrote: > On 07/12/13 23:50, Nathan Goings wrote: ... >> However, when I run `dd if=/dev/zero of=/dev/wd0c bs=1M' After 3-4 > > use the raw device, /dev/rwd0c, not the block device. I have found close > to no speed improvements with bs > 64k. A few years ago, after someone said basically the same thing (actually, I think it was more emphatic -- as in, "it is impossible to see gains beyond ..."), I played with it and saw significant gains well beyond bs=64k for raw devices. I'd be surprised if individual experience didn't vary, though. Personally, I like bs=1m for another reason, though. "pkill -INFO dd" produces very readable output. >> hours, it's only running at ~2.4MB/s. CPU usage is about 30%. >> >> First, shouldn't SATA drives be sd0? (Looked in BIOS, can't find any >> SATA-to-IDE options enabled) Second, what can I do to speed it up? or >> troubleshoot it at least? well, maybe they SHOULD be (philosophically), but they WILL be whatever your controller hardware supports. If your controller is ahci(4) compliant, it will be sd(4) devices, if it isn't, it ends up being pciide(4) and wd(4). Nick.
Re: 5.4-beta#20 xterm(1)/luit(1) in cwm, CM-Return random defunc
On Fri, Jul 12, 2013 at 11:39:05PM +0200, Jan Stary wrote: > On Jul 12 22:11:58, mhe...@gmail.com wrote: > > On Fri, Jul 12, 2013 at 09:38:07AM +0200, MERIGHI Marcus wrote: > > > mhe...@gmail.com (Matthieu Herrb), 2013.07.11 (Thu) 23:41 (CEST): > > > > On Wed, Jul 10, 2013 at 01:30:23AM -0700, Philip Guenther wrote: > > > > > On Wed, Jul 10, 2013 at 1:19 AM, Philip Guenther > > > > > wrote: > > > > > > Looks like a race in luit's startup, due to how it handles the > > > > > > ttys/ptys. To work around the problem, invoke it with the -p > > > > > > option...but I don't know how you can convince xterm to do that. > > > > > > > > > > Ha! I believe this bug is a result of posix_openpt() being > > > > > implemented in 5.3 and the luit configure script picking that instead > > > > > of openpty(), as the code for the former results in the client side > > > > > being opened (by PTMGET), then closed, then reopened by name, which > > > > > leaves a window where the master will read EOF. > > > > > > > > > > Naddy, can you coerce configure into ignoring posix_openpt()? > > > > > > > > Can you check the patch below ? > > > > (sorry it's huge since it regenerates autotools files) > > > > > > I hate being a spoilsport, but... it does not change the random defunc. > > > > > > What I did: > > > 1) cd /usr/xenocara/app/luit > > > 2) patch < ~/luit.patch > > > (no errors) > > > 3) ./configure; make; make install > > > > That should be : > > > > rm /usr/xobj/xorg-config.cache.* > > make -f Makefile.bsd-wrapper obj > > make -f Makefile.bsd-wrapper build > > > > instead. > > > > And check with nm -u /usr/X11R6/bin/luit | grep openpty that > > openpty() is referenced (and not posix_openpt()). > > I just applied the patch and did exactly the above: > > # ls -l /usr/X11R6/bin/luit > -rwxr-xr-x 1 root wheel 35824 Jul 12 23:36 /usr/X11R6/bin/luit > > # nm /usr/X11R6/bin/luit | grep -F openpt > U posix_openpt > > Am I missing something? > Hmm ok. My patch is wrong. It only works the 2nd time configure is run. Find a better patch below. Index: Makefile.in === RCS file: /cvs/xenocara/app/luit/Makefile.in,v retrieving revision 1.6 diff -u -r1.6 Makefile.in --- Makefile.in 10 Feb 2013 15:38:36 - 1.6 +++ Makefile.in 13 Jul 2013 06:10:50 - @@ -252,6 +252,8 @@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PKG_CONFIG = @PKG_CONFIG@ +PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@ +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ SED = @SED@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ Index: aclocal.m4 === RCS file: /cvs/xenocara/app/luit/aclocal.m4,v retrieving revision 1.10 diff -u -r1.10 aclocal.m4 --- aclocal.m4 10 Feb 2013 15:38:36 - 1.10 +++ aclocal.m4 13 Jul 2013 06:10:53 - @@ -20,6 +20,7 @@ To do so, use the procedure documented by the package, typically 'autoreconf'.])]) # pkg.m4 - Macros to locate and utilise pkg-config.-*- Autoconf -*- +# serial 1 (pkg-config-0.24) # # Copyright © 2004 Scott James Remnant . # @@ -46,8 +47,12 @@ # -- AC_DEFUN([PKG_PROG_PKG_CONFIG], [m4_pattern_forbid([^_?PKG_[A-Z_]+$]) -m4_pattern_allow([^PKG_CONFIG(_PATH)?$]) -AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])dnl +m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) +m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) +AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) +AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path]) +AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path]) + if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) fi @@ -60,7 +65,6 @@ AC_MSG_RESULT([no]) PKG_CONFIG="" fi - fi[]dnl ])# PKG_PROG_PKG_CONFIG @@ -69,34 +73,32 @@ # Check to see whether a particular set of modules exists. Similar # to PKG_CHECK_MODULES(), but does not set variables or print errors. # -# -# Similar to PKG_CHECK_MODULES, make sure that the first instance of -# this or PKG_CHECK_MODULES is called, or make sure to call -# PKG_CHECK_EXISTS manually +# Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG]) +# only at the first occurence in configure.ac, so if the first place +# it's called might be skipped (such as if it is within an "if", you +# have to call PKG_CHECK_EXISTS manually # -- AC_DEFUN([PKG_CHECK_EXISTS], [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl if test -n "$PKG_CONFIG" && \ AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then - m4_ifval([$2], [$2], [:]) + m4_default([$2], [:]) m4_ifvaln([$3], [else $3])dnl fi]) - # _PKG_CONFIG([VARIABLE], [COMMAND], [MODUL
