Hello Bob!

Mon 2003-08-18 13:52, Bob Jones (1:343/41) wrote to Bo Simonsen:

 BJ> Hmmmm.....  My setup seems to be eating some messages between
 BJ> 1:343/41 and 1:343/40....  Or, I didn't catch this one on
 BJ> 1:343/40.....  Need to look closer. I believe BinkD is *not*
 BJ> properly handling failures on writing (or renaming) files when
 BJ> received.....

Just a problem i thought of.. if the reciever system isn't tossing
regulary, and squish calls the packages the same filename, what is the
mailer supposed to do?

Maybe squish should use sprintf(arcname, "%08x.%s", time(NULL),
...); for arcmail filenames..

 BS>>> Did anyone of you notice that the CVS version of maximus segfaults?

 BJ>> Do you mean when running with a telnet port?  Or via the local
 BJ>> console (with the -k option)?

 BS>> With the telnet port.

 BJ> Ok.  The telnet port broke on my system a few weeks ago.  I think
 BJ> Wes made a check in of some code related to getting serial / modem
 BJ> support, but I haven't dug into the logs enough to make sure of my
 BJ> suspision.  I'll have to try your suggested roll back to see if it
 BJ> clears up the problem here.  'bin/max -k' is running ok on
 BJ> 1:343/40.  The runbbs.sh script (using telnet) bombs out on
 BJ> 1:343/40 like I believe it is / was doing on your system.... 

I bet it's the same, if you run max -w what's happingen then?

 BJ>> I've known that the telnet port broke a bit ago, but hadn't figured
 BJ>> out why or spent time on it.  I figured Wes did an update and
 BJ>> figured when he got the modem code cleaned up, it would be
 BJ>> fixed....  

Let's hope so!

 BJ>> I'm ok running console mode, but some keys (such as
 BJ>> control-z, usually usesd to save a message in the full screen
 BJ>> editor) are trapped by the command shell and sent as signals to the
 BJ>> program....  

Hmm.. i didn't tested the editor in local mode.. Local mode is a bit wierd,
because i only see monocrome colors.. maybe my config is wrong? 

 BS>> Yes, but it's good that we can solve it :)

 BS>>> To solve it, you can use the libcompat.so and 
 BS>>> libcomm.so from the max-3.03b release.

 BJ> I need to dig that stuff out and see what the differences are. 
 BJ> Yesterday I tried to find my oldest uncompressed copy, but it
 BJ> looked like it didn't go back far enough.....  Thanks for the
 BJ> note....  I need to give your fix a try. 

Okey :)

 BJ>> Ah...  I'll have to take a look....  Thanks for the info..... 

 BS>> :-) Maybe we could put the old version on CVS, so 
 BS>> people can get something there _works_.

 BJ> Yes!  Since the .so files are generated by the make files, we need
 BJ> to track it back to which source files changed, check in the bad
 BJ> code as a branch, and re-check in the good code on the main line. 
 BJ> I won't get to this today..... 

It would be good if we could solve the code problem smoothly, because wes
added alots.

 BS>> Or make 2 modules, max-unstable and max-stable.. 
 BS>> Unstable could be a playground, while stable, should 
 BS>> contain a stable branch..

 BJ> Modules?  I believe you mean branches in the CVS tree.  Yes, we
 BJ> need to branch the CVS tree and have a stable (root) branch, and an
 BJ> unstable branch for dealing with code changes till we can get new
 BJ> code better tested.  I'd have to read over the CVS documentation to
 BJ> see how to do this, but I suspect it is just a matter of running
 BJ> cvs with a specific flag option and setting a label on each branch
 BJ> that stays on the "tip" of the branch, like RCS did things.

Nope 'cvs -d ... co module', that's what a mean, a new module..

Regards,
         Bo

--- timEd/Linux 1.11.b1