Hello Dumas,

On Sun Dec 31 2017 18:57:00, Dumas Walker wrote to DIGITAL MAN:

That could be because if I follow the cvs update directions on the
wiki, I eventually get to this step:

cd /sbbs/src/sbbs3; make RELEASE=1 symlinks

And get the following error:

make: *** No rule to make target 'symlinks'. Stop.

As far as I know, you don't need to run symlinks or SYMLINK=1 or whatever it is
unless you're installing for the first time. After that, the symlinks are already there, unless you go from a RELEASE build to a DEBUG build.

If I replace symlinks with install, it says there is nothing for it to
do. The next step gives the same "no rule" error. The other steps all appeared to do what they were supposed to, although it was not much.

Depending on what you want to accomplish, if you just want a release build, "make" should do just fine. If you want DOSEMU support, "make USE_DOSEMU=1" is good.. Check the wiki, there is only a mention of SYMLINK when you're installing for the first time. Scroll down a bit and you'll see the "Upgrading"
section.

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (723:1/1)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

That could be because if I follow the cvs update directions on the wiki, I eventually get to this step:

cd /sbbs/src/sbbs3; make RELEASE=1 symlinks

And get the following error:

make: *** No rule to make target 'symlinks'. Stop.

Did you run "cvs update" before that? That sounds like you don't have the latest src/sbbs3/GNUmakefile.

I ran the following, from the wiki:

export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
cvs update -d exec
cvs update -d src 3rdp

Then I ran the step quoted above.

And when you run jsexec, what does it say the build date is?

JSexec v3.17a-Linux (rev 1.184)
Compiled Nov 4 2017 13:52:09 with GCC 6.3.0

GNUmakefile in /src/sbbs3 is dated November 26, 2015, which sounds wrong for sure.

Thanks!

---
� SLMR 2.1a � My grubby halo, a vapour trail in the empty air...
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

That's an important step nevertheless, so keep those lines in place in your json-service.ini file. This tells your local JSON-DB server to host a 'tw2' module, and the game's configuration script will want to access that module when it does its thing.

Thanks to you and Al. I will keep them in there as they were not there
before.

---
� SLMR 2.1a � A restless eye across a weary room...
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Depending on what you want to accomplish, if you just want a release build, >"make" should do just fine. If you want DOSEMU support, "make USE_DOSEMU=1" is >good.. Check the wiki, there is only a mention of SYMLINK when you're >installing for the first time. Scroll down a bit and you'll see the "Upgrading"
section.

When I am looking at:

http://wiki.synchro.net/install:nix

The Updating section shows symlinks on the make lines, on Step 4 parts 1
and 2.

Maybe we are looking at different pages? :D

---
� SLMR 2.1a � A momentary lapse of reason that binds a life to a life..
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Mon Jan 01 2018 05:58 pm

That could be because if I follow the cvs update directions on the wiki, I eventually get to this step:

cd /sbbs/src/sbbs3; make RELEASE=1 symlinks

And get the following error:

make: *** No rule to make target 'symlinks'. Stop.

Did you run "cvs update" before that? That sounds like you don't have the latest src/sbbs3/GNUmakefile.

I ran the following, from the wiki:

export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
cvs update -d exec
cvs update -d src 3rdp

Then I ran the step quoted above.

And when you run jsexec, what does it say the build date is?

JSexec v3.17a-Linux (rev 1.184)
Compiled Nov 4 2017 13:52:09 with GCC 6.3.0

Okay, that means it hasn't been built since Nov-4-2017, so it won't include the fix for JS uifc.

GNUmakefile in /src/sbbs3 is dated November 26, 2015, which sounds wrong for sure.

No, actually that's correct: http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/GNUmakefile?view=log

What's likely happening is that the jsexec you're running is not the latest one you built. If you run "locate jsexec" on your system, it should report to all of the files named "jsexec" on your file system. My guess is, you have more than one.

When you run jsexec, are you typing the absolute path (e.g. /sbbs/exec/jsexec) or just letting your PATH pick the one to run? If you type "which jsexec", it'll tell you which one is running (if any) if you just type "jsexec" without the path.

My guess is that either the jsexec that's in your path is an old one or you're specifying the path to /sbbs/exec/jsexec which is an old one. Or maybe it's a symlink to src/sbbs3/gcc.linux.exe.debug/jsexec but you built a release binary when you ran make (or vice versa).

I know this seems like a lot of hassle just to run a door game, but you should get a handle on how you can can update sbbs (including jsexec) and actually benefit from those updates. :-)

digital man

Synchronet "Real Fact" #61:
How to get Synchronet technical support: http://wiki.synchro.net/howto:support Norco, CA WX: 73.7�F, 27.0% humidity, 0 mph NNE wind, 0.00 inches rain/24hrs ---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

Hello Dumas,

On Mon Jan 01 2018 17:44:00, Dumas Walker wrote to ACCESSION:

When I am looking at:

http://wiki.synchro.net/install:nix

The Updating section shows symlinks on the make lines, on Step 4 parts
1 and 2.

Maybe we are looking at different pages? :D

Nope. Same page. That must have been something added recently, as I've never seen or used "symlinks" on those lines before.

The only time I use SYMLINK=1 is when compiling for the first time, or changing
between a RELEASE build and a DEBUG build, which I also haven't done for quite some time, so I haven't needed to redo symlinks in a long time. Once they're created for the first time, they don't go away unless you delete them. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (723:1/1)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Javascript TW2
By: Accession to Dumas Walker on Mon Jan 01 2018 07:26 pm

Nope. Same page. That must have been something added recently, as I've never seen or used "symlinks" on those lines before.

I think it has been. I recently updated the BBS and I used symlinks on the command line as the wiki said and everything went smoothly here..

Happy New Year, BTW.. :)

Ttyl :-),
Al


... Reality is for those who can't handle computers.

---
� Synchronet � The Rusty MailBox - Penticton, BC Canada - trmb.synchro.net

Re: Javascript TW2
By: Accession to Dumas Walker on Mon Jan 01 2018 07:26 pm

Hello Dumas,

On Mon Jan 01 2018 17:44:00, Dumas Walker wrote to ACCESSION:

When I am looking at:

http://wiki.synchro.net/install:nix

The Updating section shows symlinks on the make lines, on Step 4 parts 1 and 2.

Maybe we are looking at different pages? :D

Nope. Same page. That must have been something added recently, as I've never seen or used "symlinks" on those lines before.

Yes, pretty new: http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/targets.mk

The only time I use SYMLINK=1 is when compiling for the first time, or changing
between a RELEASE build and a DEBUG build, which I also haven't done for quite some time, so I haven't needed to redo symlinks in a long time. Once they're created for the first time, they don't go away unless you delete them. ;)

Right, but when people switch between release and debug builds or copies and symlinks, those new targets can come in handy.

digital man

Synchronet/BBS Terminology Definition #18:
DSZ = DOS Send ZMODEM (by Chuck Forsberg)
Norco, CA WX: 55.9�F, 72.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

Hello Al,

On Mon Jan 01 2018 21:39:20, Al wrote to Accession:

Nope. Same page. That must have been something added recently, as
I've never seen or used "symlinks" on those lines before.

I think it has been. I recently updated the BBS and I used symlinks on
the command line as the wiki said and everything went smoothly here..

I recently (within the past week) went about installing/compiling new on new hardware using SYMLINK=1 in my make line and migrating over all my configuration and customizations. This also worked. However, after doing that I've upgraded a couple times now since (for new sbbslist.js updates) and didn't
need any reference to symlinks on those lines.

Happy New Year, BTW.. :)

And same to you! Starting off the year below 0F with windchills that make you feel like your fingers and face are going to burn off. It's lovely! ;(

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (723:1/1)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Hello Digital,

On Mon Jan 01 2018 23:42:10, Digital Man wrote to Accession:

The only time I use SYMLINK=1 is when compiling for the first time,
or changing between a RELEASE build and a DEBUG build, which I also
haven't done for quite some time, so I haven't needed to redo
symlinks in a long time. Once they're created for the first time,
they don't go away unless you delete them. ;)

Right, but when people switch between release and debug builds or
copies and symlinks, those new targets can come in handy.

So does "SYMLINK=1" and "symlinks" effectively do the same thing then? If so, we're accomplishing the same goal just in different (yet similar) ways. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (723:1/1)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Javascript TW2
By: Accession to Digital Man on Tue Jan 02 2018 08:28 am

Hello Digital,

On Mon Jan 01 2018 23:42:10, Digital Man wrote to Accession:

The only time I use SYMLINK=1 is when compiling for the first time,
or changing between a RELEASE build and a DEBUG build, which I also
haven't done for quite some time, so I haven't needed to redo
symlinks in a long time. Once they're created for the first time,
they don't go away unless you delete them. ;)

Right, but when people switch between release and debug builds or copies and symlinks, those new targets can come in handy.

So does "SYMLINK=1" and "symlinks" effectively do the same thing then? If so, we're accomplishing the same goal just in different (yet similar) ways. ;)

They're 2 different makefiles. The install/GNUmakefile (where SYMLINK=1 option may be used) is normally only used for the initial install. The src/sbbs3/GNUmakefile is used for building sbbs (and lot of the libraries and utilities) and now has "install" and "symlinks" targets. You don't need to recreate symlinks if they already exist and point where you want them to (but you already knew that). :-)

digital man

This Is Spinal Tap quote #40:
Morty the Mime: Come on, don't talk back, mime is money, come on, move it. Norco, CA WX: 76.2�F, 20.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

Hello Digital,

On Tue Jan 02 2018 16:34:26, Digital Man wrote to Accession:

So does "SYMLINK=1" and "symlinks" effectively do the same thing
then? If so, we're accomplishing the same goal just in different
(yet similar) ways. ;)

They're 2 different makefiles. The install/GNUmakefile (where
SYMLINK=1 option may be used) is normally only used for the initial install. The src/sbbs3/GNUmakefile is used for building sbbs (and lot
of the libraries and utilities) and now has "install" and "symlinks" targets. You don't need to recreate symlinks if they already exist and point where you want them to (but you already knew that). :-)

Ah ok. I was just making sure I wasn't going crazy, then. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (723:1/1)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

JSexec v3.17a-Linux (rev 1.184)
Compiled Nov 4 2017 13:52:09 with GCC 6.3.0

Okay, that means it hasn't been built since Nov-4-2017, so it won't include the
fix for JS uifc.

What's likely happening is that the jsexec you're running is not the latest one
you built. If you run "locate jsexec" on your system, it should report to all >of the files named "jsexec" on your file system. My guess is, you have more >than one.

You are right, but:

/opt/sbbs/exec/jsexec
/opt/sbbs/src/sbbs3/gcc.linux.exe.release/jsexec
/sbbs/exec/jsexec
/sbbs/src/sbbs3/gcc.linux.exe.release/jsexec

Those first two are old, from 2009, and are from a backup of a previous installation. The last two are a symlink and an actual build, from
November 4, 2017. I do not appear to have one more recent. I have tried running both "jsexec" and "/sbbs/exec/jsexec" during my attempts.

When you run jsexec, are you typing the absolute path (e.g. /sbbs/exec/jsexec) >or just letting your PATH pick the one to run? If you type "which jsexec", >it'll tell you which one is running (if any) if you just type "jsexec" without >the path.

I get no output from "which jsexec".

My guess is that either the jsexec that's in your path is an old one or you're >specifying the path to /sbbs/exec/jsexec which is an old one. Or maybe it's a >symlink to src/sbbs3/gcc.linux.exe.debug/jsexec but you built a release binary >when you ran make (or vice versa).

Apparently I did not build one when I ran make. :)

I know this seems like a lot of hassle just to run a door game, but you should >get a handle on how you can can update sbbs (including jsexec) and actually >benefit from those updates. :-)

Yes, I would like to get a handle on that, especially since I seem to have difficulty with it. Since you did not mention it, I am assuming that I
should be following the directions, as stated, on the UNIX install wiki page under the "Updating" heading? That is what I have been trying.

Thanks for you assistance!

on edit: decided to try something on my own. I split the line:

cd /sbbs/src/sbbs3; make RELEASE=1 symlinks

into:

cd /sbbs/src/sbbs3
make RELEASE=1 symlinks

Still got the "symlinks" error. So I ran "make RELEASE=1" in the /sbbs/src/sbbs3 directory without "symlinks". Well, that caused *something*
to happen! It ran 10-15 minutes, compiling this and that, befure ending with this new error:

make: *** No rule to make target 'base64.h', needed by 'gcc.linux.obj.release-mt/ js_file.o'. Stop.

If you get this message, I didn't plumb break it. :D I also still have a November 4 version of jsexec, unfortunately.

---
� SLMR 2.1a � He knows changes aren't permanent - but change is!
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Maybe we are looking at different pages? :D

The only time I use SYMLINK=1 is when compiling for the first time, or changing
between a RELEASE build and a DEBUG build, which I also haven't done for quite >some time, so I haven't needed to redo symlinks in a long time. Once they're >created for the first time, they don't go away unless you delete them. ;)

Thanks. The symlinks still appear to be there. I'd be in a heap of hurt
if they were not. :D

---
� SLMR 2.1a � Wind in my hair - shifting and drifting...
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Wed Jan 03 2018 06:51 pm

you built. If you run "locate jsexec" on your system, it should report to all >of the files named "jsexec" on your file system. My guess is, you have more >than one.

You are right, but:

/opt/sbbs/exec/jsexec
/opt/sbbs/src/sbbs3/gcc.linux.exe.release/jsexec
/sbbs/exec/jsexec
/sbbs/src/sbbs3/gcc.linux.exe.release/jsexec

Those first two are old, from 2009, and are from a backup of a previous installation. The last two are a symlink and an actual build, from
November 4, 2017. I do not appear to have one more recent. I have tried running both "jsexec" and "/sbbs/exec/jsexec" during my attempts.

Well if you don't have a recent build, then it doesn't really matter which one you run.

When you run jsexec, are you typing the absolute path (e.g. /sbbs/exec/jsexec) >or just letting your PATH pick the one to run? If you type "which jsexec", >it'll tell you which one is running (if any) if you just type "jsexec" without >the path.

I get no output from "which jsexec".

Then jsexec is not in your search path (which is fine).

My guess is that either the jsexec that's in your path is an old one or you're >specifying the path to /sbbs/exec/jsexec which is an old one. Or maybe it's a >symlink to src/sbbs3/gcc.linux.exe.debug/jsexec but you built a release binary >when you ran make (or vice versa).

Apparently I did not build one when I ran make. :)

I know this seems like a lot of hassle just to run a door game, but you should >get a handle on how you can can update sbbs (including jsexec) and actually >benefit from those updates. :-)

Yes, I would like to get a handle on that, especially since I seem to have difficulty with it. Since you did not mention it, I am assuming that I should be following the directions, as stated, on the UNIX install wiki page under the "Updating" heading? That is what I have been trying.

Okay, yes, that's correct.

Thanks for you assistance!

No problem.

on edit: decided to try something on my own. I split the line:

cd /sbbs/src/sbbs3; make RELEASE=1 symlinks

into:

cd /sbbs/src/sbbs3
make RELEASE=1 symlinks

Still got the "symlinks" error.

Then you're missing an update. What was the "cvs update" command you ran when you updated?

It sounds like you're missing rev 1.42 of src/sbbs3/targets.mk

So I ran "make RELEASE=1" in the
/sbbs/src/sbbs3 directory without "symlinks". Well, that caused *something* to happen! It ran 10-15 minutes, compiling this and that, befure ending with this new error:

make: *** No rule to make target 'base64.h', needed by 'gcc.linux.obj.release-mt/ js_file.o'. Stop.

You need to perform a "make clean" first as that file has been moved. See "Clean Rebuild" at http://wiki.synchro.net/install:nix#updating

digital man

Synchronet "Real Fact" #68:
Robert D. Bouman, the author of SyncEdit, died in the mid to late 1990's. Norco, CA WX: 68.3�F, 34.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

Then you're missing an update. What was the "cvs update" command you ran when you updated?

See below.

It sounds like you're missing rev 1.42 of src/sbbs3/targets.mk

Mine is dated December 31. Loading it up in mcview gives this info:

$Id: targets.mk,v 1.42 2017/12/13 21:25:21 rswindle Exp $

You need to perform a "make clean" first as that file has been moved. See "Clean Rebuild" at http://wiki.synchro.net/install:nix#updating

OK, here is a cut-and-paste from my lxterminal window:

$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs update -d exec
$ cvs update -d src 3rdp
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd scfg
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.
$ make RELEASE=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.

---
� SLMR 2.1a � "Gasoline clears my sinuses!" - Fred G. Sanford
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Thu Jan 04 2018 06:31 pm

Then you're missing an update. What was the "cvs update" command you ran when you updated?

See below.

It sounds like you're missing rev 1.42 of src/sbbs3/targets.mk

Mine is dated December 31. Loading it up in mcview gives this info:

$Id: targets.mk,v 1.42 2017/12/13 21:25:21 rswindle Exp $

Are you sure? That should read:

# $Id: targets.mk,v 1.42 2017/12/13 21:25:21 rswindell Exp $

I'll just assume that's a typo. What does "cvs status" report about that file? Should look like this (with a couple extra lines):

~/sbbs/src/sbbs3$ cvs status targets.mk ===================================================================
File: targets.mk Status: Up-to-date

Working revision: 1.42
Repository revision: 1.42 /cvsroot/sbbs/src/sbbs3/targets.mk,v
Commit Identifier: YArZCgUZpz38bMiA

You need to perform a "make clean" first as that file has been moved. See "Clean Rebuild" at http://wiki.synchro.net/install:nix#updating

OK, here is a cut-and-paste from my lxterminal window:

$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs update -d exec
$ cvs update -d src 3rdp
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd scfg
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.
$ make RELEASE=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.

Okay, good. So the base64.h error went away. The symlinks build error is mysterious. What if you remove that from the make command-line?


digital man

This Is Spinal Tap quote #10:
Dozens of people spontaneously combust each year... just not widely reported. Norco, CA WX: 68.3�F, 46.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

~/sbbs/src/sbbs3$ cvs status targets.mk ===================================================================
File: targets.mk Status: Up-to-date

Working revision: 1.42
Repository revision: 1.42 /cvsroot/sbbs/src/sbbs3/targets.mk,v
Commit Identifier: YArZCgUZpz38bMiA

$ cvs status targets.mk
cvs status: No CVSROOT specified! Please use the `-d' option
cvs [status aborted]: or set the CVSROOT environment variable.
$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs status targets.mk
cvs status: cannot open CVS/Entries for reading: No such file or directory
cvs [status aborted]: no repository

Does that provide any clues? :)

You need to perform a "make clean" first as that file has been moved. See
"Clean Rebuild" at http://wiki.synchro.net/install:nix#updating

OK, here is a cut-and-paste from my lxterminal window:

$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs update -d exec
$ cvs update -d src 3rdp
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd scfg
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.
$ make RELEASE=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.

Okay, good. So the base64.h error went away. The symlinks build error is mysterious. What if you remove that from the make command-line?

The last time I tried it, it ran for 5-10 minutes before
giving the base64.h error. I later realized it had erased most of my executables from the sbbs3 directory tree. So I am a little leary to try
it again. :)

FYI, that was the first and only time I saw the base64.h error was when I
ran "make RELEASE=1" without the "symlinks" included.

---
� SLMR 2.1a � "Kills millions of germs on contract"
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Fri Jan 05 2018 06:32 pm

~/sbbs/src/sbbs3$ cvs status targets.mk ===================================================================
File: targets.mk Status: Up-to-date

Working revision: 1.42
Repository revision: 1.42 /cvsroot/sbbs/src/sbbs3/targets.mk,v
Commit Identifier: YArZCgUZpz38bMiA

$ cvs status targets.mk
cvs status: No CVSROOT specified! Please use the `-d' option
cvs [status aborted]: or set the CVSROOT environment variable.
$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs status targets.mk
cvs status: cannot open CVS/Entries for reading: No such file or directory cvs [status aborted]: no repository

Does that provide any clues? :)

You didn't get the source using cvs in the first place?

Do you not have a src/sbbs3/CVS directory?

You need to perform a "make clean" first as that file has been moved. See
"Clean Rebuild" at http://wiki.synchro.net/install:nix#updating

OK, here is a cut-and-paste from my lxterminal window:

$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs update -d exec
$ cvs update -d src 3rdp
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd scfg
$ make RELEASE=1 USE_DOSEMU=1 clean
Deleting gcc.linux.obj.release/
Deleting gcc.linux.obj.release-mt/
Deleting gcc.linux.lib.release/
Deleting gcc.linux.exe.release/
$ cd /sbbs/src/sbbs3
$ make RELEASE=1 USE_DOSEMU=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.
$ make RELEASE=1 symlinks
make: *** No rule to make target 'symlinks'. Stop.

Okay, good. So the base64.h error went away. The symlinks build error is mysterious. What if you remove that from the make command-line?

The last time I tried it, it ran for 5-10 minutes before
giving the base64.h error. I later realized it had erased most of my executables from the sbbs3 directory tree. So I am a little leary to try
it again. :)

FYI, that was the first and only time I saw the base64.h error was when I ran "make RELEASE=1" without the "symlinks" included.

A "clean" fixed the base64.h error. It had nothing to do with including or excluding the "symlinks" argument.

digital man

Synchronet/BBS Terminology Definition #41:
REP = QWK Reply
Norco, CA WX: 63.6�F, 78.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

$ cvs status targets.mk
cvs status: No CVSROOT specified! Please use the `-d' option
cvs [status aborted]: or set the CVSROOT environment variable.
$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs status targets.mk
cvs status: cannot open CVS/Entries for reading: No such file or directory cvs [status aborted]: no repository

Does that provide any clues? :)

You didn't get the source using cvs in the first place?

I did do so.

Do you not have a src/sbbs3/CVS directory?

Yes.

~/src/sbbs3/CVS$ ls
Entries Repository Root Tag

Should I have been in the /src/sbbs3 directory when I ran the cvs status command?

---
� SLMR 2.1a � L&N -- The Old Reliable
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

The last time I tried it, it ran for 5-10 minutes before
giving the base64.h error. I later realized it had erased most of my executables from the sbbs3 directory tree. So I am a little leary to try it again. :)

FYI, that was the first and only time I saw the base64.h error was when I ran "make RELEASE=1" without the "symlinks" included.

A "clean" fixed the base64.h error. It had nothing to do with including or excluding the "symlinks" argument.

Ok, so running without symlinks does cause all of the make steps listed in
the wiki to complete with success, as does the update.js step. However, restarting synchronet after the compile does not work so good. It ends in
a segmentation fault. I had the output captured but apparently it got
deleted when I had to restore from backup.

Just for fun, I did go back through the wiki and attempt to install all of
the dependencies. apt-get reported that all were installed at at their
newest versions - none missing.

Also, one thing I did see synchronet complain about before abending was the SBBSCTRL not being set. I find this confusing as the script that starts synchronet contains these three lines, before sbbs is called:

export HOME=/sbbs
export SBBSCTRL=/sbbs/ctrl
export SBBSNODE=/sbbs/node1

???

---
� SLMR 2.1a � Safe sex used to mean to put the car in "Park"
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Sat Jan 06 2018 01:32 pm

$ cvs status targets.mk
cvs status: No CVSROOT specified! Please use the `-d' option
cvs [status aborted]: or set the CVSROOT environment variable.
$ export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
$ cvs status targets.mk
cvs status: cannot open CVS/Entries for reading: No such file or directory cvs [status aborted]: no repository

Does that provide any clues? :)

You didn't get the source using cvs in the first place?

I did do so.

Do you not have a src/sbbs3/CVS directory?

Yes.

~/src/sbbs3/CVS$ ls
Entries Repository Root Tag

Should I have been in the /src/sbbs3 directory when I ran the cvs status command?

Yes.

digital man

This Is Spinal Tap quote #13:
Nigel Tufnel: You can't really dust for vomit.
Norco, CA WX: 69.2�F, 61.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs ---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Sat Jan 06 2018 02:52 pm

The last time I tried it, it ran for 5-10 minutes before
giving the base64.h error. I later realized it had erased most of my executables from the sbbs3 directory tree. So I am a little leary to try it again. :)

FYI, that was the first and only time I saw the base64.h error was when I ran "make RELEASE=1" without the "symlinks" included.

A "clean" fixed the base64.h error. It had nothing to do with including or excluding the "symlinks" argument.

Ok, so running without symlinks does cause all of the make steps listed in the wiki to complete with success, as does the update.js step. However, restarting synchronet after the compile does not work so good. It ends in
a segmentation fault. I had the output captured but apparently it got deleted when I had to restore from backup.

The instructions for debugging crashes (e.g. segfaults) on *nix are here: http://wiki.synchro.net/howto:gdb

It'd be helpful if you had a core file from the crash.

Just for fun, I did go back through the wiki and attempt to install all of the dependencies. apt-get reported that all were installed at at their newest versions - none missing.

Also, one thing I did see synchronet complain about before abending was the SBBSCTRL not being set. I find this confusing as the script that starts synchronet contains these three lines, before sbbs is called:

export HOME=/sbbs
export SBBSCTRL=/sbbs/ctrl
export SBBSNODE=/sbbs/node1

???

What's the rest of the script look like? Are you running sbbs daemonized or in the foreground?

digital man

Synchronet/BBS Terminology Definition #37:
NNTP = Network News Transfer Protocol
Norco, CA WX: 69.2�F, 61.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs ---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

The instructions for debugging crashes (e.g. segfaults) on *nix are here: http://wiki.synchro.net/howto:gdb

It'd be helpful if you had a core file from the crash.

I think the problem is that I probably have to keep up with a
cvs/make/etc. routine pretty regular in order not to get out of sync at
some point. I am not a PC platform developer, or a bleeding edge user, so
I would not be one to do so.

That is part of the reason I chose debian stable over slackware... I knew
I'd wind up screwing up a "compile the packages yourself" distro because I would not keep up with every single release of my favorite packages. I
figured out that a release with prebuild binaries and package/dependency management built in was going to be my friend. :)

Just so long as the ftp server and qwk mail doesn't stop working (what folks really use here), I should probably be happy with what I have.

Thanks!

---
� SLMR 2.1a � ???
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Javascript TW2
By: Dumas Walker to DIGITAL MAN on Sun Jan 07 2018 11:00 am

I think the problem is that I probably have to keep up with a cvs/make/etc. routine pretty regular in order not to get out of sync at some point. I am not a PC platform developer, or a bleeding edge user, so I would not be one to do so.

You are on the bleeding edge here.. I find Synchronet to be very stable so no worries.. :)

That is part of the reason I chose debian stable over slackware... I knew I'd wind up screwing up a "compile the packages yourself" distro because I would not keep up with every single release of my favorite packages. I figured out that a release with prebuild binaries and package/dependency management built in was going to be my friend. :)

I still consider myself a debianite. The stable release can get old, I think we ran woody for 5 or 6 years before sarge was released but it certainly is stable.

I took Slackware for a walkabout many years ago and I am still here. I might be a slacker now. I have a hundred or two packages I build myself and update them when they need it. One nice thing about slackware is that the build environment is complete one you install it. No further button pushing is needed. It's a good idea to keep things upto date though.

One thing I have found, at least with slackware is that there are a few packages that need a real root shell to build successfully. If I build those from a desktop terminal I need to source /etc/profile with a command like ". /etc/profile". I build and run Synchronet as a regular user so I don't need that for Synchronet and it may or may not be an issue for you.

Ttyl :-),
Al


...Everybody should believe in something - I believe I'll have a beer

---
� Synchronet � The Rusty MailBox - Penticton, BC Canada - trmb.synchro.net

The instructions for debugging crashes (e.g. segfaults) on *nix are here: http://wiki.synchro.net/howto:gdb

It'd be helpful if you had a core file from the crash.

OK, so after Al's encouragement, I decided to try a different approach. I set up a second sbbs directory, /opt/sbbs, and did a brand new install there. Afterwards, I ran my script that exports paths under /opt/sbbs and starts sbbs.
It came up without any apparent issue.

Then I created a symlink under the /opt/bbs "test" environment back to the /sbbs/data directory in "production." I did the same thing with the ctrl directory. When I refired /opt/sbbs/exec/sbbs, I get a segfault again... 26991.

From what I can tell, I have to compile a debug version in order to get core files to generate? Or will changing the limits.conf settings cause the core file to be created without using a debug version?

---
� Synchronet � CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Re: Javascript TW2
By: Dumas Walker to Digital Man on Fri Jan 12 2018 04:02 pm

The instructions for debugging crashes (e.g. segfaults) on *nix are here: http://wiki.synchro.net/howto:gdb

It'd be helpful if you had a core file from the crash.

OK, so after Al's encouragement, I decided to try a different approach. I set up a second sbbs directory, /opt/sbbs, and did a brand new install there. Afterwards, I ran my script that exports paths under /opt/sbbs and starts sbbs.
It came up without any apparent issue.

Then I created a symlink under the /opt/bbs "test" environment back to the /sbbs/data directory in "production." I did the same thing with the ctrl directory. When I refired /opt/sbbs/exec/sbbs, I get a segfault again... 26991.

From what I can tell, I have to compile a debug version in order to get core files to generate?

No, release (non-debug) builds will generate core files too if your system will allow it.

Or will changing the limits.conf settings cause the core
file to be created without using a debug version?

A non-debug core file can still be very useful and yes, there a various ways to instruct your system to allow core files to be created. Detailed here: http://wiki.synchro.net/howto:gdb#core_file

digital man

Synchronet "Real Fact" #35:
The irc.synchro.net network has more servers than users.
Norco, CA WX: 68.4�F, 39.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net