• crashmail Echo JAM Base - Errors and Exporting

    From rick christian@1:3634/12 to All on Sun Oct 23 22:43:50 2016
    I have gotten setup with a node, changed the crashmail.prefs to that node.

    Did my Areafix, and added some echos.. but when importing them I get:

    ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #57 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #53 in JAM messagebase "/home/rec9140/fido/jam/NET135HUB"
    ! 23-Oct-16 22:09:37 Failed to read message #62 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #63 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #64 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #65 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #66 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #67 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #68 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #69 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #70 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #71 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #72 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    ! 23-Oct-16 22:09:37 Failed to read message #73 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"

    Also creating a reply or new message, does NOT EXPORT...

    I even created a TESTECHO.... same... doesn't export the message.

    NETMAIL WORKS FINE! Echos do NOT export.

    $ crashmail VERSION
    This is CrashMail II version 0.71

    Operating system: Linux
    Compilation date: Jan 30 2013
    Compilation time: 05:08:45

    Available messagebase formats:
    MSG Standard *.msg messagebase as specified in FTS-1
    JAM JAM Messagebase

    Available nodelist formats:
    CMNL CrashMail nodelist index
    V7+ Version 7+ format
    rec9140@rec9140-VirtualBox:~/fido/logs$

    from K|Ubunuto repo.


    Kubuntu 14.04.5 64b

    Message created in GoldED+ LNX 1.1.5 http://old-releases.ubuntu.com/ubuntu/pool/universe/g/goldedplus/

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From Paul Quinn@3:640/1384 to rick christian on Mon Oct 24 18:25:04 2016
    Hi! rick,

    On 10/23/2016 10:43 PM, you wrote to All:

    I have gotten setup with a node, changed the crashmail.prefs to that node.

    Neat...

    Did my Areafix, and added some echos.. but when importing them I get:

    ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #57 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    [ ...let's concentrate on one echo... ]
    Also creating a reply or new message, does NOT EXPORT...

    Mmm...

    I even created a TESTECHO.... same... doesn't export the message.

    Mmm...

    This is the BINKD echo definition in my CM II prefs...

    [...]
    AREA "BINKD" 3:640/1384.0 JAM "/opt/ftn/fido/msgbase/40e2a7c3"
    EXPORT 3:640/384.0 2:221/0.0
    DESCRIPTION "The BinkD TCP/IP FTN mailer"
    GROUP F
    KEEPNUM 4000
    [...]

    It's the same one that CrashExport uses to feed to Golded. Ignoring the path, how does the AREA line differ from yours?

    NETMAIL WORKS FINE! Echos do NOT export.

    Mmm... you managed to do something right. ;)

    $ crashmail VERSION
    This is CrashMail II version 0.71

    Mine is the same, though it's a local compile from the original (i.e. the author's).

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From Björn Felten@2:203/2 to rick christian on Mon Oct 24 13:25:41 2016
    ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"

    Did you let crashmail create the message base? Just wondering what permissions you have there.





    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Tommi Koivula@2:221/6 to rick christian on Mon Oct 24 17:11:40 2016
    rc> ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase
    rc> "/home/rec9140/fido/jam/BINKD"

    Did you let crashmail create the message base? Just wondering what permissions you have there.

    I second the last question. Since it is running under linux, can jamnntpd read the base created by another user/program (crashmail/golded?) ?

    'Tommi

    ---
    * Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)
  • From rick christian@1:3634/12 to Paul Quinn on Tue Oct 25 11:39:28 2016
    On 10/24/2016 04:25 AM, Paul Quinn -> rick christian wrote:


    It's the same one that CrashExport uses to feed to Golded. Ignoring the path, how does the AREA line differ from yours?

    AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
    EXPORT %1:135/300.0
    GROUP A

    These were added my crashmail, not me.

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From rick christian@1:3634/12 to Björn Felten on Tue Oct 25 11:41:57 2016
    On 10/24/2016 07:25 AM, Bjrn Felten -> rick christian wrote:
    ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase
    "/home/rec9140/fido/jam/BINKD"

    Did you let crashmail create the message base? Just wondering what permissions you have there.

    Yes..

    All fido stuff is in

    ~/fido/

    with messagebases ~/fido/jam/

    All fido activity is done under MY USER, I changed binkd's init script to run under me and not under any of that ftn:ftn stuff that it was setup.

    ~/fido/jam$ ls -la
    total 1992
    drwxrwxr-x 2 rec9140 rec9140 4096 Oct 23 22:30 .
    drwxrwxr-x 19 rec9140 rec9140 4096 Oct 22 09:51 ..
    -rw-rw-r-- 1 rec9140 rec9140 1280 Sep 20 12:54 BAD.jdt
    -rw-rw-r-- 1 rec9140 rec9140 8 Sep 20 12:54 BAD.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1301 Oct 20 21:44 BAD.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 20 21:44 BAD.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 23 22:30 BBT.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 23 22:30 BBT.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 25 06:33 BBT.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 25 06:33 BBT.jlr
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 23 22:09 BINKD.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 475898 Oct 23 22:09 BINKD.jdt
    -rw-rw-r-- 1 rec9140 rec9140 912 Oct 23 22:09 BINKD.jdx
    -rw-rw-r-- 1 rec9140 rec9140 83137 Oct 23 22:09 BINKD.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 21 12:45 BINKD.jlr
    -rw-rw-r-- 1 rec9140 rec9140 106 Oct 23 22:14 echomail.jam
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 25 06:33 FIDONEWS.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 285138 Oct 25 06:33 FIDONEWS.jdt
    -rw-rw-r-- 1 rec9140 rec9140 1352 Oct 25 06:33 FIDONEWS.jdx
    -rw-rw-r-- 1 rec9140 rec9140 126017 Oct 25 06:39 FIDONEWS.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 25 06:39 FIDONEWS.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 21 12:43 GMRS.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 21 12:43 GMRS.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 25 06:39 GMRS.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 25 06:39 GMRS.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:28 JAMMNNTPD.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:28 JAMMNNTPD.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 16:29 JAMMNNTPD.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 16:29 JAMMNNTPD.jlr
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 25 06:33 JAMNNTPD.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 94983 Oct 25 06:33 JAMNNTPD.jdt
    -rw-rw-r-- 1 rec9140 rec9140 848 Oct 25 06:33 JAMNNTPD.jdx
    -rw-rw-r-- 1 rec9140 rec9140 67571 Oct 25 11:37 JAMNNTPD.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 25 11:37 JAMNNTPD.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LALSCAN.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LALSCAN.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 16:30 LALSCAN.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 16:30 LALSCAN.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LIS.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LIS.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 16:30 LIS.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 16:30 LIS.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LMS.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LMS.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 16:30 LMS.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 16:30 LMS.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LONGMIRE.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 LONGMIRE.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 16:30 LONGMIRE.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 16:30 LONGMIRE.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 MURS.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 16:30 MURS.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 16:30 MURS.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 16:30 MURS.jlr
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 20 21:10 NET135.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 25 06:33 NET135FILE.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 157775 Oct 25 06:33 NET135FILE.jdt
    -rw-rw-r-- 1 rec9140 rec9140 816 Oct 25 06:33 NET135FILE.jdx
    -rw-rw-r-- 1 rec9140 rec9140 38234 Oct 25 06:33 NET135FILE.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 21 12:39 NET135FILE.jlr
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 25 06:33 NET135HUB.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 198278 Oct 25 06:33 NET135HUB.jdt
    -rw-rw-r-- 1 rec9140 rec9140 880 Oct 25 06:33 NET135HUB.jdx
    -rw-rw-r-- 1 rec9140 rec9140 40604 Oct 25 06:33 NET135HUB.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 21 12:39 NET135HUB.jlr
    -rw-rw-r-- 1 rec9140 rec9140 6238 Oct 20 21:10 NET135.jdt
    -rw-rw-r-- 1 rec9140 rec9140 24 Oct 20 21:10 NET135.jdx
    -rw-rw-r-- 1 rec9140 rec9140 2343 Oct 20 21:57 NET135.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 20 21:57 NET135.jlr
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 22 09:48 RBERRYPI.cmhw
    -rw-rw-r-- 1 rec9140 rec9140 157658 Oct 22 09:48 RBERRYPI.jdt
    -rw-rw-r-- 1 rec9140 rec9140 800 Oct 22 09:48 RBERRYPI.jdx
    -rw-rw-r-- 1 rec9140 rec9140 65653 Oct 22 09:48 RBERRYPI.jhr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 09:48 RBERRYPI.jlr
    -rw-rw-r-- 1 rec9140 rec9140 93 Oct 23 22:14 TESTECHO.jdt
    -rw-rw-r-- 1 rec9140 rec9140 8 Oct 23 22:14 TESTECHO.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1229 Oct 23 22:14 TESTECHO.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 23 22:14 TESTECHO.jlr
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 09:58 TPAWX.jdt
    -rw-rw-r-- 1 rec9140 rec9140 0 Oct 22 09:58 TPAWX.jdx
    -rw-rw-r-- 1 rec9140 rec9140 1024 Oct 22 09:58 TPAWX.jhr
    -rw-rw-r-- 1 rec9140 rec9140 16 Oct 22 09:58 TPAWX.jlr

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From rick christian@1:3634/12 to Tommi Koivula on Tue Oct 25 11:43:49 2016
    On 10/24/2016 10:11 AM, Tommi Koivula -> rick christian wrote:


    I second the last question. Since it is running under linux, can
    jamnntpd read the base created by another user/program
    (crashmail/golded?) ?

    Reads it fine

    golded
    crashmail

    All fido stuff is under my user including binkd, as I changed the init script to use my user instead of this split up stuff and group membership.



    ~/fido/jam$ fidomail
    CrashMail II 0.71 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...


    Total -> Read messages: 0 Written messages: 0
    Imported -> Imported messages: 0 Routed netmails: 0
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Scanning area BINKD
    Scanning area NET135
    Scanning area NET135FILE
    Scanning area NET135HUB
    Scanning area FIDONEWS
    Scanning area RBERRYPI
    Scanning area JAMNNTPD

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From mark lewis@1:3634/12.73 to rick christian on Tue Oct 25 14:26:46 2016

    25 Oct 16 11:39, you wrote to Paul Quinn:

    On 10/24/2016 04:25 AM, Paul Quinn -> rick christian wrote:


    It's the same one that CrashExport uses to feed to Golded. Ignoring
    the path, how does the AREA line differ from yours?

    AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
    EXPORT %1:135/300.0
    GROUP A

    These were added my crashmail, not me.

    where'd that % sign come from in the EXPORT line?

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The day I stop flirting, you'll read about it in the obituaries.
    ---
    * Origin: (1:3634/12.73)
  • From rick christian@1:3634/12 to mark lewis on Tue Oct 25 15:31:11 2016
    On 10/25/2016 02:26 PM, mark lewis -> rick christian wrote:


    AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
    EXPORT %1:135/300.0
    GROUP A

    These were added my crashmail, not me.

    where'd that % sign come from in the EXPORT line?


    The line and all parts of it added by crashmail directly

    and per the documentation in the file:


    ; and % means that the node is the feed for this area.
    ;

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From mark lewis@1:3634/12.73 to rick christian on Tue Oct 25 16:32:58 2016

    25 Oct 16 15:31, you wrote to me:

    AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
    EXPORT %1:135/300.0
    GROUP A

    These were added my crashmail, not me.

    where'd that % sign come from in the EXPORT line?

    The line and all parts of it added by crashmail directly

    and per the documentation in the file:

    ; and % means that the node is the feed for this area.

    ahhhh... ok... i don't know that that is important in the grand scheme of things but i noticed it and didn't see one in paul's example...

    FWIW: FTN echomail is not a hierarchy like so many were lead to believe over the years... if you have only one connection, sure, that may be viewed as your "feed" or "upstream" but if you have several connections to an echo, they're all "feeds" and there's no real "upstream" or "downstream"...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... A pat on the back, also a hug, she's trying to squash the smoking bug!
    ---
    * Origin: (1:3634/12.73)
  • From rick christian@1:3634/12 to mark lewis on Tue Oct 25 18:11:53 2016
    On 10/25/2016 04:32 PM, mark lewis -> rick christian wrote:

    ahhhh... ok... i don't know that that is important in the grand scheme
    of things but i noticed it and didn't see one in paul's example...

    And taking it out, doesn't seem to make it export.

    FWIW: FTN echomail is not a hierarchy like so many were lead to believe over the years... if you have only one connection, sure, that may be viewed as your "feed" or "upstream" but if you have several connections
    to an echo, they're all "feeds" and there's no real "upstream" or "downstream"...

    Well ummm.. why would you have a feed of the SAME echo from different nodes????

    I can see if echo a is an echo on my system on not fed via NAB so nodes come to me to get it... BUT why would they also want to say add binkd as well??

    Especially in 2016, where for the most part the delay is the cycle on which a node runs their exporting process...and/or TZ for the users.

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From Paul Quinn@3:640/1384 to mark lewis on Wed Oct 26 08:40:40 2016
    Hi! mark,

    On 10/26/2016 04:26 AM, you wrote:

    EXPORT %1:135/300.0
    GROUP A

    These were added my crashmail, not me.

    where'd that % sign come from in the EXPORT line?

    It's the primary feed indicator for an echo. Not really required or important.

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From Paul Quinn@3:640/1384 to rick christian on Wed Oct 26 18:13:28 2016
    Hi! rick,

    On 10/25/2016 11:39 AM, you wrote:

    AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
    EXPORT %1:135/300.0
    GROUP A

    These were added my crashmail, not me.

    So, which program put those messages into the echo's JAM file(s) in the first place? (I only ask as I 'seeded' _this_ node's messagebase with some matching JAM files from my other node, created by FastEcho [a DOS program].) If CM did the deed then are there any errors in the/a previous logfile, when the messages were tossed in?

    Simply put: how can CM put things in that it cannot get out again?

    Something changed in the between-times? Some other program changed the JAM-stored data?

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From Richard Menedetter@2:310/31 to Rick Christian on Wed Oct 26 11:42:36 2016
    Hi Rick!

    25 Oct 2016 18:11, from rick christian -> mark lewis:

    Well ummm.. why would you have a feed of the SAME echo from different nodes????

    In order to get redundancy.
    If one of the feeds fails (down/unreachable), you will not even notice, as you get the mails from the other feed(s).

    CU, Ricsi

    --- GoldED+/LNX
    * Origin: We are star-stuff. We are the universe made manifest. (2:310/31)
  • From rick christian@1:3634/12 to Paul Quinn on Wed Oct 26 07:04:37 2016
    On 10/26/2016 04:13 AM, Paul Quinn -> rick christian wrote:

    So, which program put those messages into the echo's JAM file(s) in the first place? (I only ask as I 'seeded' _this_ node's messagebase with
    some matching JAM files from my other node, created by FastEcho [a DOS program].) If CM did the deed then are there any errors in the/a
    previous logfile, when the messages were tossed in?\

    Yes. crashmail tossed these in, and I get log from this AM's run:

    ~/fido/logs$ fidomail
    CrashMail II 0.71 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...

    Unarchiving /home/rec9140/fido/binkd/inb/0fbafc02.tu0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/0fbafc02.tu0
    inflating: 0fbafc04.pkt

    Tossing 0fbafc04.pkt (1K) from 1:135/300.0 (25-Oct-16 16:03:48) / 4d
    Is in HandleMessage()

    Unarchiving /home/rec9140/fido/binkd/inb/0fc6b802.tu0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/0fc6b802.tu0
    inflating: 0fc6b804.pkt
    inflating: 0fc91004.pkt
    inflating: 0fca3c04.pkt

    Tossing 0fc6b804.pkt (3K) from 1:135/300.0 (25-Oct-16 16:53:52) / 4d
    Is in HandleMessage()
    Tossing 0fc91004.pkt (1K) from 1:135/300.0 (25-Oct-16 17:03:52) / 4d
    Is in HandleMessage()
    Tossing 0fca3c04.pkt (2K) from 1:135/300.0 (25-Oct-16 17:08:52) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES

    Unarchiving /home/rec9140/fido/binkd/inb/0fceef01.tu0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/0fceef01.tu0
    inflating: 0fceef04.pkt
    inflating: 0fd72704.pkt

    Tossing 0fceef04.pkt (12K) from 1:135/300.0 (25-Oct-16 17:28:55) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Tossing 0fd72704.pkt (2K) from 1:135/300.0 (25-Oct-16 18:03:59) / 4d
    Is in HandleMessage()

    Unarchiving /home/rec9140/fido/binkd/inb/0fde3202.tu0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/0fde3202.tu0
    inflating: 0fde3104.pkt
    inflating: 0fe53c04.pkt
    inflating: 0fe75804.pkt

    Tossing 0fde3104.pkt (2K) from 1:135/300.0 (25-Oct-16 18:34:01) / 4d
    Is in HandleMessage()
    Tossing 0fe53c04.pkt (2K) from 1:135/300.0 (25-Oct-16 19:04:04) / 4d
    Is in HandleMessage()
    Tossing 0fe75804.pkt (3K) from 1:135/300.0 (25-Oct-16 19:13:04) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES

    Unarchiving /home/rec9140/fido/binkd/inb/0fe88502.tu0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/0fe88502.tu0
    inflating: 0fe88504.pkt
    inflating: 0fef9004.pkt
    inflating: 0ff44104.pkt

    Tossing 0fe88504.pkt (1K) from 1:135/300.0 (25-Oct-16 19:18:05) / 4d
    Is in HandleMessage()
    Tossing 0fef9004.pkt (4K) from 1:135/300.0 (25-Oct-16 19:48:08) / 4d
    Is in HandleMessage()
    Tossing 0ff44104.pkt (4K) from 1:135/300.0 (25-Oct-16 20:08:09) / 4d
    Is in HandleMessage()
    Is in HandleMessage()

    Unarchiving /home/rec9140/fido/binkd/inb/1019ce03.tu0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/1019ce03.tu0
    inflating: 1019ce04.pkt

    Tossing 1019ce04.pkt (5K) from 1:135/300.0 (25-Oct-16 22:48:22) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES

    Unarchiving /home/rec9140/fido/binkd/inb/102ad903.we0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/102ad903.we0
    inflating: 102ad905.pkt
    inflating: 102add05.pkt

    Tossing 102ad905.pkt (2K) from 1:135/300.0 (26-Oct-16 00:01:05) / 4d
    Is in HandleMessage()
    Tossing 102add05.pkt (3K) from 1:135/300.0 (26-Oct-16 00:01:09) / 4d
    Is in HandleMessage()

    Unarchiving /home/rec9140/fido/binkd/inb/1034c903.we0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/1034c903.we0
    inflating: 1034c904.pkt

    Tossing 1034c904.pkt (1K) from 1:135/300.0 (26-Oct-16 00:43:29) / 4d
    Is in HandleMessage()

    Unarchiving /home/rec9140/fido/binkd/inb/106f7001.we0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/106f7001.we0
    inflating: 106f7004.pkt

    Tossing 106f7004.pkt (1K) from 1:135/300.0 (26-Oct-16 04:53:44) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES

    Unarchiving /home/rec9140/fido/binkd/inb/107b2a01.we0 using ZIP

    Archive: /home/rec9140/fido/binkd/inb/107b2a01.we0
    inflating: 107b2a04.pkt
    inflating: 107c5704.pkt
    inflating: 107fdd04.pkt

    Tossing 107b2a04.pkt (2K) from 1:135/300.0 (26-Oct-16 05:43:46) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Tossing 107c5704.pkt (2K) from 1:135/300.0 (26-Oct-16 05:48:47) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Tossing 107fdd04.pkt (1K) from 1:135/300.0 (26-Oct-16 06:03:49) / 4d
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES

    Area PERSONAL_MESSAGES -- 9 messages
    Area BINKD -- 8 messages
    Area NET135HUB -- 2 messages
    Area FIDONEWS -- 8 messages
    Area JAMNNTPD -- 6 messages

    Total -> Read messages: 24 Written messages: 0
    Imported -> Imported messages: 24 Routed netmails: 0
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Linking JAM area JAMNNTPD
    Linking JAM area FIDONEWS
    Linking JAM area BINKD
    Linking JAM area NET135HUB
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Scanning area BINKD
    Failed to read message #59 in JAM messagebase "/home/rec9140/fido/jam/BINKD" Failed to read message #60 in JAM messagebase "/home/rec9140/fido/jam/BINKD" Failed to read message #61 in JAM messagebase "/home/rec9140/fido/jam/BINKD" Failed to read message #62 in JAM messagebase "/home/rec9140/fido/jam/BINKD" Scanning area NET135
    Scanning area NET135FILE
    Scanning area NET135HUB
    Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/NET135HUB"
    Scanning area FIDONEWS
    Failed to read message #86 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Failed to read message #87 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Failed to read message #88 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Failed to read message #89 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Scanning area RBERRYPI
    Scanning area JAMNNTPD
    Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #57 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #58 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD"

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end

    Simply put: how can CM put things in that it cannot get out again?

    I'd love to know, but crashmail just refuses to take the messages I put in any echo area and export it.

    Something changed in the between-times? Some other program changed the JAM-stored data?

    The only program to access things is Golded and Crashmail

    I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From mark lewis@1:3634/12.73 to rick christian on Wed Oct 26 06:50:50 2016

    25 Oct 16 18:11, you wrote to me:

    ahhhh... ok... i don't know that that is important in the grand scheme
    of things but i noticed it and didn't see one in paul's example...

    And taking it out, doesn't seem to make it export.

    FWIW: FTN echomail is not a hierarchy like so many were lead to
    believe over the years... if you have only one connection, sure, that
    may be viewed as your "feed" or "upstream" but if you have several
    connections to an echo, they're all "feeds" and there's no real
    "upstream" or "downstream"...

    Well ummm.. why would you have a feed of the SAME echo from different nodes????

    reread my first statement after FWIW... there is no real hierarchy in echomail...

    I can see if echo a is an echo on my system on not fed via NAB so
    nodes come to me to get it...

    that is private distribution...

    BUT why would they also want to say add binkd as well??

    because they can... because they want redundant feeds to ensure they get all posts and get them as fast as possible... if any route breaks, the mail still flows and only the broken system is out...

    you mention the NAB... those three systems are a fully connected polygon... there was, at one time, the Z1B... there were five or six systems (at least) that were fully connected... today, there is what is loosely called the FidoWeb... there is no top level set of systems in a fully connected polygon... instead each system may connect to as many other systems as they want for redundancy... some systems may be connected to ten or more other systems which may be connected to those same ten or maybe not... the big thing for today's echomail is that the tossers can be configured to /not/ strip seenby lines from messages crossing zonal boundaries... there are no more duplicate nets in fidonet so seenby stripping is not necessary and the seenbys prevent duplicate messages from being sent out... used in conjunction with the MSGID, it should be pretty fool proof...

    Especially in 2016, where for the most part the delay is the cycle on which a node runs their exporting process...and/or TZ for the users.

    the processing cycle is different... on my system, i process mail once an hour because there's a lot of work done on it... some times it takes a couple of minutes while other times it takes 15 or 20 minutes... that's why i tell systems polling here to poll after xx:30... note that polling is not delivering your newly written outbound mail... polling is empty and you're only looking to pick up waiting mail... other than that, unless i have a system on hold for some reason, there's little to no reason to poll my system at all... the mail will be delivered as soon as it is ready... i currently have only two systems on hold and that only because i cannot connect to them... i don't know why and their operators can't seem to figure out how to get set up so that i can but they (supposedly) have callers connecting to their systems... why they can get one working and not the other is beyond me...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I wondered why the basketball was getting bigger. Then it hit me!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to rick christian on Wed Oct 26 12:09:42 2016

    26 Oct 16 07:04, you wrote to Paul Quinn:

    Something changed in the between-times? Some other program changed
    the JAM-stored data?

    The only program to access things is Golded and Crashmail

    what versions, please?? is that plain old golded or golded+?? which message base library is it compiled with??

    I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.

    well, there's your problem... it would have been nice to know that sooner ;)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... If it pisses us off its off topic.
    ---
    * Origin: (1:3634/12.73)
  • From Björn Felten@2:203/2 to rick christian on Thu Oct 27 01:14:41 2016
    Well ummm.. why would you have a feed of the SAME echo from different nodes????

    I guess you haven't read all the articles about this in the Fidonews the last five or so years ago?

    I'll not dive into this just now, since I read mark's excellent explanation, but please do pay attention to the modern fidonet evolution.



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Björn Felten@2:203/2 to mark lewis on Thu Oct 27 01:20:24 2016
    mark lewis -> rick christian skrev 2016-10-26 12:50:

    i currently have only two systems on hold and that only because i cannot connect to them... i don't know why and their operators can't seem to figure out how to get set up so that i can but they (supposedly) have callers connecting to their systems... why they can get one working and not the other is beyond me...

    I have a very similar setup here (but at the moment only one node remaining on hold). Just a thought: can it be that your two troubled nodes are both running Mystic...?

    I've had as many as three troublesome nodes here, but as they realized that Mystic is crappy and changed to something else, they were gradually making it to the crash gang.



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Björn Felten@2:203/2 to rick christian on Thu Oct 27 03:51:08 2016
    The only program to access things is Golded and Crashmail

    I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.

    So why would you use Golded then, when it obviously corrupts your JAM message bases? Run a JamNNTPd server and use Thunderbird or something similar and you'll get tons of advantages.



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Paul Quinn@3:640/384 to rick christian on Thu Oct 27 11:36:28 2016
    Hi! rick,

    On 26 Oct 16 07:04, you wrote to me:

    Something changed in the between-times? Some other program
    changed the JAM-stored data?
    The only program to access things is Golded and Crashmail

    This is an extract from my other node's CM logfile for a toss run this morning...

    ##==T=O=S=S=E=R====T=A=S=K==
    - 27-Oct-16 07:06:00 CrashMail II 0.71 started successfully!
    ^ 27-Oct-16 07:06:00 Tossing files in /opt/ftn/fido/inbound...
    = 27-Oct-16 07:06:00 Unarchiving /opt/ftn/fido/inbound/BD8F0F8C.THM using ZIP
    ^ 27-Oct-16 07:06:00 Tossing 70AB0983.PKT (6K) from 3:640/384.0 (27-Oct-16 07:05:17) / pw, 4d
    = 27-Oct-16 07:06:00 Area ALLFIX_FILE -- 1 messages
    = 27-Oct-16 07:06:00 Area FDN_ANNOUNCE -- 1 messages
    = 27-Oct-16 07:06:00 Area FIDO-REQ -- 1 messages
    = 27-Oct-16 07:06:00 Total -> Read messages: 3 Written messages: 4
    = 27-Oct-16 07:06:00 Imported -> Imported messages: 3 Routed netmails: 0
    = 27-Oct-16 07:06:00 Bad -> Bad messages: 0 Duplicate messages: 0
    ^ 27-Oct-16 07:06:00 Scanning for orphan files
    ^ 27-Oct-16 07:06:00 Scanning for old packets
    ^ 27-Oct-16 07:06:00 Scanning for new files to pack
    = 27-Oct-16 07:06:00 Packing 111ab800.pkt for 2:460/58.0 with ZIP
    = 27-Oct-16 07:06:00 Sending 111ab801.pkt unpacked to 2:221/0.0
    - 27-Oct-16 07:06:00 CrashMail end

    You'll note straight up that there's no warning of bad things about the headers.

    I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.

    Yep. There's your problem. You most likely have bad binaries. I've seen similar behaviour on my 'shadow' system, even with recent incarnations of later version binaries.

    I'll send you a copy of the original archive. It'll just arrive unanounced in your _insecure_ inbound. The original binaries worked well in Puppy Linux 5.25 and Xubuntu 11.10, and still run nicely in the current Puppy 4.21 (yes, a retrograde step for very good reasons).

    To use the original binaries, you'll need to:

    * stop your binkD;
    * destroy your existing JAM messagebase (completely? see note, below);
    * replace your current executables with the originals in the ZIP; and,
    * restart binkD.

    Your netmail area _may_ be okay? Is it a *.Msg area? Otherwise, trash it too.

    No other changes needed... fingers crossed. ;) Just let CM re-create your messagebase...

    Cheers,
    Paul.

    ... My toys! My toys! I can't do this job without my toys!
    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Paul Quinn@3:640/1384 to Björn Felten on Thu Oct 27 12:27:32 2016
    Hi! Björn,

    On 10/27/2016 11:51 AM, you wrote:

    The only program to access things is Golded and Crashmail

    I can read messages, BUT they have CORRUPT to and from headers, ie:
    garbled names and node numbers.

    So why would you use Golded then, when it obviously corrupts your
    JAM message bases? Run a JamNNTPd server and use Thunderbird or
    something similar and you'll get tons of advantages.

    My money is on CM, as I indicated to rick. His messagebase is getting trashed by CM, even before some other tool accesses it.

    Though... I did have an afterthought that maybe his hub is constructing bad packets... 8-)

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From rick christian@1:3634/12 to mark lewis on Wed Oct 26 22:21:56 2016
    On 10/26/2016 12:09 PM, mark lewis -> rick christian wrote:

    what versions, please?? is that plain old golded or golded+?? which message base library is it compiled with??

    $ crashmail VERSION
    This is CrashMail II version 0.71

    Operating system: Linux
    Compilation date: Jan 30 2013
    Compilation time: 05:08:45

    Available messagebase formats:
    MSG Standard *.msg messagebase as specified in FTS-1
    JAM JAM Messagebase

    Available nodelist formats:
    CMNL CrashMail nodelist index
    V7+ Version 7+ format
    rec9140@rec9140-VirtualBox:~/fido/logs$

    from K|Ubunuto repo.


    Kubuntu 14.04.5 64b

    Message created in GoldED+ LNX 1.1.5 http://old-releases.ubuntu.com/ubuntu/pool/universe/g/goldedplus/

    Specifically: http://old-releases.ubuntu.com/ubuntu/pool/universe/g/goldedplus/goldedplus_1.1.4.7+1.1.5.20051016-3_amd64.deb


    well, there's your problem... it would have been nice to know that
    sooner ;)

    I never noticed it till today.. I looked at the messages.. not the headers...some are fine, others have just gobbleygook... can post here as they are non ASCII garbage.

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From rick christian@1:3634/12 to mark lewis on Wed Oct 26 22:26:32 2016
    On 10/26/2016 06:50 AM, mark lewis -> rick christian wrote:

    reread my first statement after FWIW... there is no real hierarchy in echomail...........two systems on hold and that
    only because i cannot connect to them... i don't know why and their operators can't seem to figure out how to get set up so that i can but they (supposedly) have callers connecting to their systems... why they
    can get one working and not the other is beyond me...

    Obviously thats changed since the 90's...

    It was very very well beaten in to nodes in my area at that time. Thou shalt get echos via the net hub/NC/ what ever it was... Otherwise you ran the risk of be expelled..

    I also can see one little glitch some where misconfigured and huge amounts of dupes being moved around... in 2016 via TCP/IP who cares mostly.. in the modem days... Some one definitely cares real quick.


    Obviously thats changed since the 90's...

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From rick christian@1:3634/12 to Björn Felten on Wed Oct 26 22:28:13 2016
    On 10/26/2016 07:14 PM, Bjrn Felten -> rick christian wrote:

    I guess you haven't read all the articles about this in the Fidonews the last five or so years ago?

    Nope.. Last I read any thing there was in '94

    I'll not dive into this just now, since I read mark's excellent explanation, but please do pay attention to the modern fidonet evolution.

    And with that.. I am out, Peace, love, and all that.. Enjoy..

    Singing off.. Out.

    * Origin: news://news.wpusa.dynip.com | acct req'd to post (1:3634/12)
  • From Björn Felten@2:203/2 to Paul Quinn on Thu Oct 27 05:07:11 2016
    * destroy your existing JAM messagebase

    Ouch!

    There is another way that relies on a program written by one of the originators of the JAM message base. The FrontDoor editor has never failed me once when investigating or converting message bases to and fro JAM.





    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Björn Felten@2:203/2 to rick christian on Thu Oct 27 05:36:17 2016
    but please do pay attention to the modern fidonet evolution.

    And with that.. I am out, Peace, love, and all that.. Enjoy..

    Singing off.. Out.

    Strange reaction... Really?



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Paul Quinn@3:640/1384 to Björn Felten on Thu Oct 27 14:15:05 2016
    Hi! Björn,

    On 10/27/2016 01:07 PM, you wrote:

    * destroy your existing JAM messagebase

    Ouch!

    There is another way that relies on a program written by one of the originators of the JAM message base. The FrontDoor editor has never
    failed me once when investigating or converting message bases to and fro JAM.

    Whatever floats yer boat, don't ask for permission...

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From Paul Quinn@3:640/1384 to Björn Felten on Thu Oct 27 14:17:47 2016
    Hi! Björn,

    On 10/27/2016 01:36 PM, you wrote:

    but please do pay attention to the modern fidonet evolution.

    And with that.. I am out, Peace, love, and all that.. Enjoy..

    Singing off.. Out.

    Strange reaction... Really?

    Sometimes all it takes is *free* beer somewhere else... 8-)

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From mark lewis@1:3634/12.73 to Björn Felten on Thu Oct 27 05:45:34 2016

    27 Oct 16 01:20, you wrote to me:

    i currently have only two systems on hold and that only because i
    cannot connect to them... i don't know why and their operators can't
    seem to figure out how to get set up so that i can but they
    (supposedly) have callers connecting to their systems... why they can
    get one working and not the other is beyond me...

    I have a very similar setup here (but at the moment only one node remaining on hold). Just a thought: can it be that your two troubled
    nodes are both running Mystic...?

    they are not...

    I've had as many as three troublesome nodes here, but as they realized that Mystic is crappy and changed to something else, they were
    gradually making it to the crash gang.

    the newer mystic 1.12 alphas might not be as up to snuff as 1.11 which there are two of running over here...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... CPU not found. Press F1 for software emulation.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to rick christian on Thu Oct 27 05:51:14 2016

    26 Oct 16 22:26, you wrote to me:

    reread my first statement after FWIW... there is no real hierarchy in
    echomail...........two systems on hold and that only because i cannot
    connect to them... i don't know why and their operators can't seem to
    figure out how to get set up so that i can but they (supposedly) have
    callers connecting to their systems... why they can get one working
    and not the other is beyond me...

    Obviously thats changed since the 90's...

    no, it hasn't changed... what happened is that nodes woke up and saw the truth...

    It was very very well beaten in to nodes in my area at that time. Thou shalt get echos via the net hub/NC/ what ever it was... Otherwise you
    ran the risk of be expelled..

    yeah, that was all roun out of town on a rail when Planet Connect came around with their satellite feed of the full fidonet backbones and file distribution networks... those *Cs/*ECs that played those games didn't last too long after that...

    I also can see one little glitch some where misconfigured and huge
    amounts of dupes being moved around... in 2016 via TCP/IP who cares mostly.. in the modem days... Some one definitely cares real quick.

    that's the story some use these days... some of us old timers still don't like it but :shrug:

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Those Polish folks sure make one hell of a good shoe-shining compound.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Björn Felten on Thu Oct 27 05:55:36 2016

    27 Oct 16 05:07, you wrote to Paul Quinn:

    * destroy your existing JAM messagebase

    Ouch!

    There is another way that relies on a program written by one of the originators of the JAM message base. The FrontDoor editor has never failed me once when investigating or converting message bases to and fro JAM.

    you cannot fix corrupted bases... not with FM, anyway... not and keep all messages... i had a tool that i wrote that allowed corruption to be fixed but it was extremely manual and required that you adjust the offsets of the fields and the pointer to the message body... it could easily fix corrupted messages but with a loss of data if it wasn't in the correct place... i don't even know where that tool is as it was just so much easier to bite the bullet and start the message base(s) over once new binaries came around... IIRC, you joined the FD beta team after JAM was introduced so you missed a lot of the fun we had testing the format at that time... as far as i recall, you were also the last FD beta member to join the team... good times those day... good times :)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Hospitals: they clean you with alcohol, but make you drink water...
    ---
    * Origin: (1:3634/12.73)
  • From Richard Menedetter@2:310/31 to Bj÷rn Felten on Thu Oct 27 14:40:16 2016
    Hi Bjrn!

    27 Oct 2016 03:51, from Bjrn Felten -> rick christian:

    The only program to access things is Golded and Crashmail
    I can read messages, BUT they have CORRUPT to and from headers,
    ie: garbled names and node numbers.
    So why would you use Golded then, when it obviously corrupts your
    JAM message bases?

    To me that is not obvious by the fact presented here.

    I use JAM exclusively, and Golded+ never corrupted anything here.
    This naturally does not mean that it is not the culprit, but I have big doubts about that ... ;)

    CU, Ricsi

    --- GoldED+/LNX
    * Origin: You are not only what you eat, but what you eat eats. (2:310/31)
  • From Björn Felten@2:203/2 to Richard Menedetter on Sun Oct 30 03:00:19 2016
    I use JAM exclusively, and Golded+ never corrupted anything here.

    The question is what happens when another program (such as crashmail) accesses the same JAM file.

    crashmail uses it's own rudimentary lock function, with a lock file, preventing it from having multiple runs at the same time (happens quite often here) writing to the same JAM file.

    I guess Golded don't respect the crashmail busy file? 8-)



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From mark lewis@1:3634/12.73 to Björn Felten on Sun Oct 30 05:13:46 2016

    30 Oct 16 03:00, you wrote to Richard Menedetter:

    I use JAM exclusively, and Golded+ never corrupted anything here.

    The question is what happens when another program (such as crashmail) accesses the same JAM file.

    that shouldn't be a problem in most cases...

    crashmail uses it's own rudimentary lock function, with a lock file, preventing it from having multiple runs at the same time (happens

    that's normal for most tossers that i'm aware of...

    quite often here) writing to the same JAM file.

    JAM has its own special lock method, too... i forget which file it is but there's a region that is locked during writing... reading is allowed by all... if something else wants to write, it tries to lock the same region... if it cannot, which it should not because of the existing lock, then it should delay and retry the lock for some period of time... if it gets the lock, then it can do its write... otherwise it either aborts or asks the operator what to do...

    I guess Golded don't respect the crashmail busy file? 8-)

    maybe, maybe not... depends on the config, i guess...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Next! Next! Number 17! Number 17!
    ---
    * Origin: (1:3634/12.73)
  • From Björn Felten@2:203/2 to mark lewis on Sun Oct 30 11:38:37 2016
    The question is what happens when another program (such as crashmail)
    accesses the same JAM file.

    that shouldn't be a problem in most cases...

    True, it never ever happened to me, but in this case it seems to have?

    Well, it was just a thought. It is of course impossible to the rest of us to know what actually happened here...



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Paul Quinn@3:640/384 to Björn Felten on Sun Oct 30 20:50:31 2016
    Hi! Bjrn,

    On 30 Oct 16 11:38, you wrote to mark lewis:

    It is of course impossible to the rest of us to know what actually happened here...

    Bad binaries. Whomsoever was the cretin that packaged the friggin' .DEB that Rick downloaded from the Ubuntu repository obviously up-f@cked it. Not Rick's fault but perhaps the fault of his stubborness. Mmm... that sounds a little like me... ;)

    Say, while you're in a talkative mood, and before I adjourn for the night to catch a movie...

    #1 - why did you give up on your Tedious doover?

    #2 - was there ever a public Linux version of Squish?

    There's a couple of pennies in it for your musings. 8-)

    Cheers,
    Paul.

    ... All stressed out and no one to choke.
    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Björn Felten@2:203/2 to Paul Quinn on Sun Oct 30 12:56:33 2016
    #1 - why did you give up on your Tedious doover?

    #1 Anita
    #2 binkd performs well enough

    #2 - was there ever a public Linux version of Squish?

    Dunno, but the source code is PD so if anybody want to have a go on it, it's up for the grabs.

    There's a couple of pennies in it for your musings. 8-)

    Fuck the pennies, give me a barrel of good old Aussie beer and I'm game.




    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Paul Quinn@3:640/384 to Björn Felten on Sun Oct 30 22:06:53 2016
    Hi! Bjrn,

    On 30 Oct 16 12:56, you wrote to me:

    There's a couple of pennies in it for your musings. 8-)

    Fuck the pennies, give me a barrel of good old Aussie beer and I'm game.

    Good answer! Just between you, me & that Aardvark over there: I have to confess that all the good beer has 'walked'. :)

    Cheers,
    Paul.

    ... "I don't suffer from insanity; I enjoy every minute of it."
    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Björn Felten@2:203/2 to Paul Quinn on Sun Oct 30 13:24:14 2016
    Good answer! Just between you, me & that Aardvark over there: I have to confess that all the good beer has 'walked'. :)

    That certainly gives a new meaning to Walkabout Creek (Crocodile Dundee 1, 2 and 3 being some of my absolute favourite movies ever).



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Paul Quinn@3:640/384 to Björn Felten on Sun Oct 30 22:34:18 2016
    Hi! Bjrn,

    On 30 Oct 16 13:24, you wrote to me:

    I have to confess that all the good beer has 'walked'. :)

    That certainly gives a new meaning to Walkabout Creek (Crocodile
    Dundee 1, 2 and 3 being some of my absolute favourite movies ever).

    Frankly, #1 was alright. 2 & 3 were 'export' quality, after the movie house realised they could maybe make a buck from Hoges.

    Oh, yes... beer. I'm not a beer drinking feller but I'll tell you this much: 1982 was a very hot year, and there was a particularly nice ale produced by XXXX in Brisbane for the Commonwealth Games that same year. For that year only. The formula was never bottled again. I did my part for the games and downed a gallon or two. :)

    Cheers,
    Paul.

    ... Only those who attempt the absurd achieve the impossible.
    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From mark lewis@1:3634/12.73 to Paul Quinn on Sun Oct 30 08:09:12 2016

    30 Oct 16 20:50, you wrote to Bjrn Felten:

    #2 - was there ever a public Linux version of Squish?

    yes... the code for squish and maximus bbs were both released GPL and were available on a repository... i had compiled the code at one time but then some changes were made and i couldn't compile it any more... that was ""several"" years ago... i don't think much of anything has been done on it since...

    https://en.wikipedia.org/wiki/Squish_(FidoNet)

    https://sourceforge.net/projects/maximus/

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Take yourself seriously - and be taken for a fool.
    ---
    * Origin: (1:3634/12.73)
  • From Björn Felten@2:203/2 to Paul Quinn on Sun Oct 30 14:12:59 2016
    Oh, yes... beer. I'm not a beer drinking feller but I'll tell you this much: 1982 was a very hot year, and there was a particularly nice ale produced by XXXX in Brisbane for the Commonwealth Games that same year. For that year only. The formula was never bottled again. I did my part for the games and downed a gallon or two. :)

    I started brewing my own beer circa 1980ish and then I relied on canned imports from the UK. Even if it tasted good, it wasn't exceptional. And yes, I have a complete pub like station with carbonating stuff and all.

    But then I discovered the Aussie Cooper's line of products, and my entire beer world changed. I realized that the Englishmen that went to Australia took with them something that was left behind -- true beer making.

    I'm forever indebted to you Aussie guys for giving me the best brew you can make yourself.

    BTW: From what I've heard it's the Swedish company Alfa Laval that made the machines for Cooper. 8-)



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From mark lewis@1:3634/12.73 to Björn Felten on Sun Oct 30 12:58:26 2016

    30 Oct 16 12:56, you wrote to Paul Quinn:

    #2 - was there ever a public Linux version of Squish?

    Dunno, but the source code is PD so if anybody want to have a go on it, it's up for the grabs.

    not PD... GPL ;)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Always remember you're unique, just like everyone else.
    ---
    * Origin: (1:3634/12.73)
  • From Paul Quinn@3:640/1384 to mark lewis on Mon Oct 31 08:59:16 2016
    Hi! mark,
    On 10/30/2016 10:09 PM, mark lewis -> Paul Quinn wrote:

    #2 - was there ever a public Linux version of Squish?

    yes... the code for squish and maximus bbs were both released GPL and
    were available on a repository... i had compiled the code at one time
    but then some changes were made and i couldn't compile it any more...
    that was ""several"" years ago... i don't think much of anything has
    been done on it since...

    Ah, I expected as much. I just wasn't sure, from my limited perspective as I was a very happy jock for so very long with FastEcho. I'm still trying to find that golden (for me) Linux tosser. Even with FE, I had dabbled with Squish areas and came to understand Squish. It was a question I had to ask.

    Thanks, Mark.

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From David Drummond@3:640/305 to Björn Felten on Mon Oct 31 20:08:42 2016
    On 30/10/2016 9:56 PM, 2:203/2 wrote:

    There's a couple of pennies in it for your musings. 8-)

    Fuck the pennies, give me a barrel of good old Aussie beer and I'm game.

    If you were to show your face in this part of the world I'm sure we could arrange something like that.

    --

    Regards
    David

    E&OE

    --- Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
    * Origin: Cleveland QueeNZland Australia (3:640/305)
  • From David Drummond@3:640/305 to Paul Quinn on Mon Oct 31 20:10:01 2016
    On 30/10/2016 10:06 PM, 3:640/384 wrote:

    There's a couple of pennies in it for your musings. 8-)

    Fuck the pennies, give me a barrel of good old Aussie beer and I'm
    game.

    Good answer! Just between you, me & that Aardvark over there: I have to confess that all the good beer has 'walked'. :)

    Some of it is tolerable, some better than tolerable.

    I am still working my way through the sample selections.

    --

    Regards
    David

    E&OE

    --- Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
    * Origin: Cleveland QueeNZland Australia (3:640/305)
  • From David Drummond@3:640/305 to Björn Felten on Mon Oct 31 20:11:54 2016
    On 30/10/2016 11:12 PM, 2:203/2 wrote:

    But then I discovered the Aussie Cooper's line of products, and my entire beer world changed. I realized that the Englishmen that went to Australia took with them something that was left behind -- true beer making.

    I'm forever indebted to you Aussie guys for giving me the best brew you can make yourself.

    BTW: From what I've heard it's the Swedish company Alfa Laval that made the machines for Cooper. 8-)

    Coopers Sparkling Ale is my preferred tipple.

    --

    Regards
    David

    E&OE

    --- Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
    * Origin: Cleveland QueeNZland Australia (3:640/305)
  • From Rick Christian@1:135/377 to Paul Quinn on Mon Oct 31 10:04:18 2016
    * Replying to a msg in PERSONAL_MESSAGES (Personal Messages)

    You'll note straight up that there's no warning of bad things about
    the headers.

    What is the setup on this? Distro and arch and version(s)?

    DEV VM for fido

    Has no message bases, or anything on it.

    took crashmail 1.5 DEB and installed

    took crashmail.prefs from operating node and scp'd

    took some PKT's from my arhcive (I keep'em) and scp'd

    ran a test.. Same errors!

    Golded has NEVER TOUCHED the JAM files on here, as its not on there to run..

    Kubuntu 14.04.5 *64bit*

    I am replying to this on my operating node, which I *changed* to MSG format as that is the ONLY format that will export and generate PKTS.

    Log/transcript follows:

    rec9140@fidodev:~$ sudo dpkg -i crashmail_1.5-1_amd64.deb
    [sudo] password for rec9140:
    Selecting previously unselected package crashmail.
    (Reading database ... 77870 files and directories currently installed.) Preparing to unpack crashmail_1.5-1_amd64.deb ...
    Unpacking crashmail (1.5-1) ...
    Setting up crashmail (1.5-1) ...
    Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
    rec9140@fidodev:~$ crashmail
    Failed to read configuration file crashmail.prefs
    rec9140@fidodev:~$ cd fido/
    rec9140@fidodev:~/fido$ ls -la
    total 12


    rec9140@fidodev:~/fido/crashmail$ crashmail TOSS SCAN SETTINGS ~/fido/crashmail/crashmail.prefs
    Creating new dupe file /home/rec9140/fido/logs/crashmail.dupes
    CrashMail II 1.5 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...


    Total -> Read messages: 0 Written messages: 0
    Imported -> Imported messages: 0 Routed netmails: 0
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Creating JAM messagebase "/home/rec9140/fido/jam/TESTECHO"
    Scanning area TEST
    Scanning area BINKD
    Creating JAM messagebase "/home/rec9140/fido/jam/BINKD"
    Scanning area NET135
    Creating JAM messagebase "/home/rec9140/fido/jam/NET135"
    Scanning area NET135FILE
    Creating JAM messagebase "/home/rec9140/fido/jam/NET135FILE"
    Scanning area NET135HUB
    Creating JAM messagebase "/home/rec9140/fido/jam/NET135HUB"
    Scanning area FIDONEWS
    Creating JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    Scanning area RBERRYPI
    Creating JAM messagebase "/home/rec9140/fido/jam/RBERRYPI"
    Scanning area JAMNNTPD
    Creating JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD"

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end
    rec9140@fidodev:~/fido/crashmail$ crashmail TOSS SCAN SETTINGS ~/fido/crashmail/crashmail.prefs
    CrashMail II 1.5 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...
    Tossing c5b3ac3d.pkt (16K) from 1:135/300.0 (20-Oct-16 15:41:03) / 4d
    Is in HandleMessage()

    Area NETMAIL -- 1 messages

    Total -> Read messages: 1 Written messages: 0
    Imported -> Imported messages: 1 Routed netmails: 0
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Scanning area TEST
    Scanning area BINKD
    Scanning area NET135
    Scanning area NET135FILE
    Scanning area NET135HUB
    Scanning area FIDONEWS
    Scanning area RBERRYPI
    Scanning area JAMNNTPD

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end
    rec9140@fidodev:~/fido/crashmail$ crashmail TOSS SCAN SETTINGS ~/fido/crashmail/crashmail.prefs
    CrashMail II 1.5 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...
    Tossing 16827d04.pkt (33K) from 1:135/300.0 (30-Oct-16 19:28:37) / 4d
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()

    Area FIDONEWS -- 6 messages

    Total -> Read messages: 6 Written messages: 0
    Imported -> Imported messages: 6 Routed netmails: 0
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Linking JAM area FIDONEWS
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Scanning area TEST
    Scanning area BINKD
    Scanning area NET135
    Scanning area NET135FILE
    Scanning area NET135HUB
    Scanning area FIDONEWS
    Failed to read message #2 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Failed to read message #4 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Scanning area RBERRYPI
    Scanning area JAMNNTPD

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end
    rec9140@fidodev:~/fido/crashmail$




    There's your problem. You most likely have bad binaries. I've
    seen similar behaviour on my 'shadow' system, even with recent incarnations of later version binaries.

    I don't think so.. as it runs, and see above, *Same errors*.

    I'll send you a copy of the original archive. It'll just arrive unanounced in your _insecure_ inbound. The original binaries worked
    well in Puppy Linux 5.25 and Xubuntu 11.10, and still run nicely in
    the current Puppy 4.21 (yes, a retrograde step for very good reasons).

    Nothing here...


    * destroy your existing JAM messagebase (completely? see note, below);

    I did this on the operating node, this one, I am replying from.. *same erorrs* on old or new packets

    Did it a couple times to nuke the JAM files...

    Finally created a TEST Echo in MSG format.... WORKS!


    Your netmail area _may_ be okay? Is it a *.Msg area? Otherwise,
    trash it too.

    Nope, Netmail is/always is MSG format....

    No other changes needed... fingers crossed. ;) Just let CM re-create your messagebase...


    No joy! See above.



    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: (1:135/377)
  • From Rick Christian@1:135/377 to Bjrn Felten on Mon Oct 31 10:39:34 2016
    * Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


    Hello Bjrn!

    So why would you use Golded then, when it obviously corrupts your
    JAM message bases? Run a JamNNTPd server and use Thunderbird or
    something similar and you'll get tons of advantages.

    I don't think it is Golded, you can see reply elsewhere... but

    1) I nuked JAM base crashmail recreated them on receving new PKT - same error 2) repeated #1 - insanity, see def., same
    3) Used a 1.5 version on clean machine (VM) which has never had a JAM based, same error, see reply
    4) Used Golded 1.1.5 from the 3/22/16 source code and it doesn't change anything

    So I don't think this is Golded BUT CM II..

    I have a hunch but I want some one else to post some info before I go that route... its a hunch on something....


    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talso Moon Base Alpha (1:135/377)
  • From Rick Christian@1:135/377 to Bjorn Felten on Mon Oct 31 11:03:44 2016
    * Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


    Hello Bjorn!

    27 Oct 16 03:51, Bjorn Felten wrote to me:

    So why would you use Golded then

    1) I like, no LOVE GoldED.

    2) I do NOT belive GoldED is the issue, see reply(s).


    , when it obviously corrupts your
    JAM message bases?

    See above.

    Run a JamNNTPd server

    In the future I will, but till JAM and export of Echo's work.. No joy.

    I also have to resolve getting Pan and KNode and/or other NNTP clients to work,

    and use Thunderbird

    Well I despise, *DESPISE* with the hate of 100000000 suns thunderturkey... I used it for a while to access a JamNNTPd server as thats the only Linux client that ignore the 500 error from the servers on the mode reader command.. you can see tix and possible resolution reply and git thingy...


    something similar and you'll get tons of
    advantages.

    I will be using Pan and/or Knode if can resolve issue #6


    Rick


    -- GoldED+/LNX 1.1.5-b20160322
    ---
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From Rick Christian@1:135/377 to Bjorn Felten on Mon Oct 31 11:15:52 2016

    Hello Bjorn!

    30 Oct 16 14:12, Bjrn Felten wrote to Paul Quinn:


    Australia took with them something that was left behind -- true beer making.

    True beer making is being/has been ruined by:

    1) schlocl-heiser wursch in the US
    2) Really any US made yellowish looking urinal waste
    3) InBev! URRRRGHHHHHHHHHH

    My prefered beer is Diebels Alt.. got hooked in Dusseldorf, used to be able to snag it some German restaraunts, but it seems when InBev took over they nuked the export deals to the US.. or something as nobody not even the restaraunts that had it before have it now.

    Next on the list would be Budweiser. NOPE! The REAL ONE! The one made by Budvar Brewery in Czechoslovakia. The REAL BUDWEISER! That is another one I got hooked on..

    So long as its not made in the US or US export version, I am fine.



    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From Nicholas Boel@1:154/10 to Rick Christian on Mon Oct 31 11:19:03 2016
    Hello Rick,

    On 31 Oct 16 10:39, Rick Christian wrote to Bjrn Felten:

    I don't think it is Golded, you can see reply elsewhere... but

    1) I nuked JAM base crashmail recreated them on receving new PKT -
    same error 2) repeated #1 - insanity, see def., same 3) Used a 1.5
    version on clean machine (VM) which has never had a JAM based, same
    error, see reply 4) Used Golded 1.1.5 from the 3/22/16 source code and
    it doesn't change anything

    So I don't think this is Golded BUT CM II..

    I have a hunch but I want some one else to post some info before I go
    that route... its a hunch on something....

    I believe you were already told that CM v1.5's deb package includes broken binaries. Your better bet is probably to compile the original (.71?) or have someone (I believe Paul Quinn already offered you binaries of the original version) give you some binaries to try out.

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From Rick Christian@1:135/377 to Nicholas Boel on Mon Oct 31 16:33:55 2016

    Hello Nicholas!

    Replying to a msg dated 31 Oct 16 11:19, from you to me.

    Hello Nicholas!

    31 Oct 16 11:19, you wrote to me:

    I believe you were already told that CM v1.5's deb package includes
    broken binaries. Your better bet is probably to compile the original (.71?) or have someone (I believe Paul Quinn already offered you
    binaries of the original version) give you some binaries to try out.

    I don't think it matters what version it is...

    I've managed to some how compile

    1.5
    0.75

    and *ALL* exhibit the same behavior... error reading ....

    for each version, clean sweep, each time for each version.

    nuked JAM files

    nuked crashmail.stats

    reran CM on PKT's saved and brought over from my operating setup.

    Same errors

    Golded has NOT touched the JAM files on the dev machine.

    0.71 has 5-6 files in the directory some too small to be source, no clear directions on what to use, so moved on to 0.75 instead.


    And FYI on 0.75 you need to mkdir bin in the crashmail-0.7.5 directory before compiling or it won't compile... little step NOT IN THE DIRECTIONS...for whatever reason 1.5 does this on its on....

    Log:

    ./crashmail TOSS SCAN SETTINGS ~/fido/crashmail/crashmail.prefs
    CrashMail II 0.75.1 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...
    Tossing 16827d04.pkt (33K) from 1:135/300.0 (30-Oct-16 19:28:37) / 4d
    Is in HandleMessage()
    Creating JAM messagebase "/home/rec9140/fido/jam/FIDONEWS"
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Tossing c5b3ac3d.pkt (16K) from 1:135/300.0 (20-Oct-16 15:41:03) / 4d
    Is in HandleMessage()
    Tossing 0bc9c000.pkt (140K) from 1:135/300.0 (22-Oct-16 16:17:44) / 4d
    Is in HandleMessage()
    Creating JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD"
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Filter: Copying message to area PERSONAL_MESSAGES
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()
    Is in HandleMessage()

    Area NETMAIL -- 1 messages
    Area PERSONAL_MESSAGES -- 16 messages
    Area FIDONEWS -- 6 messages
    Area JAMNNTPD -- 100 messages

    Total -> Read messages: 107 Written messages: 0
    Imported -> Imported messages: 107 Routed netmails: 0
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Linking JAM area FIDONEWS
    Linking JAM area JAMNNTPD
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Creating JAM messagebase "/home/rec9140/fido/jam/TESTECHO"
    Scanning area TEST
    Scanning area BINKD
    Creating JAM messagebase "/home/rec9140/fido/jam/BINKD"
    Scanning area NET135
    Creating JAM messagebase "/home/rec9140/fido/jam/NET135"
    Scanning area NET135FILE
    Creating JAM messagebase "/home/rec9140/fido/jam/NET135FILE"
    Scanning area NET135HUB
    Creating JAM messagebase "/home/rec9140/fido/jam/NET135HUB"
    Scanning area FIDONEWS
    Failed to read message #1 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Failed to read message #2 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Failed to read message #3 in JAM messagebase "/home/rec9140/fido/jam/FIDONEWS" Scanning area RBERRYPI
    Creating JAM messagebase "/home/rec9140/fido/jam/RBERRYPI"
    Scanning area JAMNNTPD
    Failed to read message #1 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #2 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #3 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #4 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #5 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #6 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #7 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #8 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #9 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #10 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #11 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #12 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #13 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #14 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #15 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #16 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #17 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #18 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #19 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #20 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #21 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #22 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #23 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #24 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #25 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #26 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #27 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #28 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #29 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #30 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #31 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #32 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #33 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #34 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #35 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #36 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #37 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #38 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #39 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #40 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #41 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #42 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #43 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #44 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #45 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #46 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #47 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #48 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #49 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD" Failed to read message #50 in JAM messagebase "/home/rec9140/fido/jam/JAMNNTPD"

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end
    rec9140@fidodev:~/crashmail-0.75.1/bin$



    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From Nicholas Boel@1:154/10 to Rick Christian on Mon Oct 31 16:09:43 2016
    Hello Rick,

    On 31 Oct 16 16:33, Rick Christian wrote to Nicholas Boel:

    I believe you were already told that CM v1.5's deb package
    includes broken binaries. Your better bet is probably to compile
    the original (.71?) or have someone (I believe Paul Quinn already
    offered you binaries of the original version) give you some
    binaries to try out.

    I don't think it matters what version it is...

    Ok. Again you seem to have all the answers and care more to argue about it than actually try what you've been told multiple times to try, even though every *WORKING* version running these days (ie: Björn and Paul off the top of my head) are running 0.71, not any of the other versions you are attempting and failing with.

    0.71 has 5-6 files in the directory some too small to be source, no
    clear directions on what to use, so moved on to 0.75 instead.

    Anything above 0.71 was NOT by the original author. Whoever decided to break the package did it on their own. We are all telling you that you should give 0.71 a try, yet you've now tried two versions besides that one with no luck.

    FWIW, I've tried three times to help you out (ie: binkd, husky project, and now crashmail), and you've refused the help, deciding to argue your point instead, to get multiple softwares working. Good luck in your adventure. It will get harder and harder the more you refuse the assistance from others.

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From Paul Quinn@3:640/1384 to Rick Christian on Tue Nov 1 09:52:44 2016
    Hi! Rick,

    On 11/01/2016 12:04 AM, you wrote:

    You'll note straight up that there's no warning of bad things about
    the headers.
    What is the setup on this? Distro and arch and version(s)?

    Puppy 4.21 ('wildcat' multi-user version) Linux ver 2.6.25.16, i686.

    DEV VM for fido
    Has no message bases, or anything on it.
    took crashmail 1.5 DEB and installed

    That version, on a shadow system here, compiled direct from Sourceforge source repo kept mangling JAM bases and up-f@cked my Golded regularly. That's with changing only the CM binaries; _nothing_ else.

    V1.4 wasn't much better. Golded was more stable for a short test (2-3 days) but CM seemed to have a difficulty with not detecting some dupes.

    I went back to using the original CM 0.71 binaries. No problems since, except for the usual annoying out-of-zone SEENBY stripping hiccup.


    I'll send you a copy of the original archive.
    [ ...trimmed... ]
    Nothing here...

    I told my Radius mailer to give up: polled both 24554 & port 23 alternately for 10 hours. (Is that nodelisted domain of yours 'fidonet.tampascanner.info' kosher?) You are welcome to FREQ the original CM archive "cm071linux.zip" from 3:640/384, any time.

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From Rick Christian@1:135/377 to Nicholas Boel on Mon Oct 31 19:45:40 2016
    * Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


    Hello Nicholas!

    31 Oct 16 16:09, you wrote to me:



    0.71 has 5-6 files in the directory some too small to be source,
    no clear directions on what to use, so moved on to 0.75 instead.

    As per above, which of these:
    crashmail_0.71-4.diff.gz 2010-08-12 14.3 kB 0 i crashmail_0.71-4.dsc 2010-08-12 1.1 kB 0 i crashmail_0.71-3.diff.gz 2009-07-11 14.0 kB 0 i crashmail_0.71-3.dsc 2009-07-11 1.1 kB 0 i
    cm071linux.zip 2009-02-17 361.6 kB 0 i crashmail_0.71-2.diff.gz 2007-09-02 4.0 kB 0 i crashmail_0.71-2.dsc 2007-09-02 567 Bytes 0 i crashmail_0.71-1.diff.gz 2004-07-28 3.8 kB 0 i crashmail_0.71-1.dsc 2004-07-28 567 Bytes 0 i crashmail_0.71.orig.tar.gz 2004-07-28 169.9 kB

    Only the .orig.tar.gz and the cm071linux.zip seem to big enough to be source


    Anything above 0.71 was NOT by the original author. Whoever decided to

    So which of these?????????????????????

    Only 2 are of any way close to be soure

    SO crashmail_071.orig.tar.gz it is!

    rec9140@fidodev:~/crashmail-0.71$ cd bin
    rec9140@fidodev:~/crashmail-0.71/bin$ ./crashmail VERSION
    This is CrashMail II version 0.71

    Operating system: Linux
    Compilation date: Oct 31 2016
    Compilation time: 19:48:29

    Available messagebase formats:
    MSG Standard *.msg messagebase as specified in FTS-1
    JAM JAM Messagebase

    Available nodelist formats:
    CMNL CrashMail nodelist index
    V7+ Version 7+ format
    rec9140@fidodev:~/crashmail-0.71/bin$

    And BOOM!

    rec9140@fidodev:~/crashmail-0.71/bin$ ./crashmail TOSS SCAN SETTINGS ~/fido/crashmail/crashmail.prefs
    CrashMail II 0.71 started successfully!
    Tossing files in /home/rec9140/fido/binkd/inb...
    Segmentation fault (core dumped)
    rec9140@fidodev:~/crashmail-0.71/bin$

    OK... so

    lets see this cm071linux.zip is big enough to have source

    hmmm it has binaries already in it:
    rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ ./crashmail VERSION
    This is CrashMail II version 0.71

    Operating system: Linux
    Compilation date: Jul 10 2004
    Compilation time: 14:56:38

    Available messagebase formats:
    MSG Standard *.msg messagebase as specified in FTS-1
    JAM JAM Messagebase

    Available nodelist formats:
    CMNL CrashMail nodelist index
    V7+ Version 7+ format

    Hmmm.. OK so it runs....

    Lets throw the library of PKTs at it!



    Area NETMAIL -- 10 messages
    Area PERSONAL_MESSAGES -- 77 messages
    Area BINKD -- 151 messages
    Area NET135 -- 3 messages
    Area NET135FILE -- 104 messages
    Area NET135HUB -- 122 messages
    Area FIDONEWS -- 224 messages
    Area RBERRYPI -- 110 messages
    Area JAMNNTPD -- 150 messages

    Total -> Read messages: 881 Written messages: 7
    Imported -> Imported messages: 874 Routed netmails: 7
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Sending unpacked netmail to 1:135/300.0 (Normal)
    Linking JAM area BINKD
    Linking JAM area NET135
    Linking JAM area NET135FILE
    Linking JAM area NET135HUB
    Linking JAM area FIDONEWS
    Linking JAM area RBERRYPI
    Linking JAM area JAMNNTPD
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Scanning area TEST
    Scanning area BINKD
    Scanning area NET135
    Scanning area NET135FILE
    Scanning area NET135HUB
    Scanning area FIDONEWS
    Scanning area RBERRYPI
    Scanning area JAMNNTPD

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end
    rec9140@fidodev:~/cmzip/crashmail-0.71/bin$

    So... hmmm.. THIS file seems to work... as no error can't read messages...


    FWIW, I've tried three times to help you out (ie: binkd, husky

    I've spent the better part of 20+ hours on this over the past 2 days...

    Thats TOO MUCH! I've moved servers with less headaches in less time than that.

    It should be far simpler.. sudo apt-get install .... edit configs move on.

    Now it appears that possibly I've found a version that is the "original" version.

    Which you could have posted:

    "Hey grab this file... cm071linux.zip at..http://......." and then run this.

    Versus compile it from source... well the source of 0.71 as per above BOMBS with a seg fault.

    I am not sure yet how to get this into the working system... BUT if this is the true one version that works, then I will be on a mission to

    EXPUNGE the DEB's in the repos. and all the other files on the source thingy and elsewhere... and see what kind of DEB's I can create that will install a WORKING version of this....

    I am not sure yet how to test this on the working setup.. I guess I can run a parallel setup with the MSG format till it works and toss in things to a test JAM setup.... don't know.

    I need booze right now... and lots of it....

    I've got to get my notes into some sort of readable fashion and then work on testing it, and then getting this online so NOBODY ever goes through this crap again!

    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From Paul Quinn@3:640/1384 to Rick Christian on Tue Nov 1 11:26:14 2016
    Hi! Rick,

    On 11/01/2016 09:45 AM, you wrote to Nicholas Boel:

    lets see this cm071linux.zip is big enough to have source

    hmmm it has binaries already in it: rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ ./crashmail VERSION
    This is CrashMail II version 0.71

    Operating system: Linux
    Compilation date: Jul 10 2004
    Compilation time: 14:56:38
    [ ...trimmed... ]
    So... hmmm.. THIS file seems to work... as no error can't read messages...

    That's the one! Good stuff, Rick. That's the one to stick with.

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From mark lewis@1:3634/12.73 to Rick Christian on Mon Oct 31 23:21:24 2016

    31 Oct 16 16:33, you wrote to Nicholas Boel:

    I believe you were already told that CM v1.5's deb package includes
    broken binaries. Your better bet is probably to compile the original
    (.71?) or have someone (I believe Paul Quinn already offered you
    binaries of the original version) give you some binaries to try out.

    I don't think it matters what version it is...

    I've managed to some how compile

    1.5 0.75

    and *ALL* exhibit the same behavior... error reading ....

    in my experiance, those using crashmail have been extremely lucky that it works for them... why and how is another story... i've seen both sides but i've never tried to run it myself... why? specifically because of the problems you are seeing... for my tastes, it was never stable enough for me to consider... other's mileage has obviously varied...

    i won't even mention that the original author has been gone for over a decade and that they completely abandoned all their software when they left... they were at least kind enough to release it for others to play with but that doesn't mean it was working software at that time...

    i also won't mention the couple of message based libraries that also came out that had their own, sometimes erroneously, ways of handling message bases... MAPI and SMAPI are two that i recall... the history leaves /much/ to be desired... you really need to consider that a lot was also hobby stuff written bt teenagers and twenty-somethings that did the code for grades in school and left it at that...

    i'm sorry to say that you seem to be expecting much too much of the software that you are choosing to test... descent linux based FTN stuff hasn't been around all that long... it has been a long and hard fought battle to get what little bit of fTN software available for anyone to use...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Cheese is senior citizen milk.
    ---
    * Origin: (1:3634/12.73)
  • From Björn Felten@2:203/2 to Rick Christian on Tue Nov 1 08:57:00 2016
    So which of these?????????????????????

    Only 2 are of any way close to be soure

    It feels like I have posted the link a hundred times now:

    http://eljaco.se/FILES/Billing/



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Nicholas Boel@1:154/10 to Rick Christian on Tue Nov 1 08:16:04 2016
    Hello Rick,

    On 31 Oct 16 19:45, Rick Christian wrote to Nicholas Boel:

    0.71 has 5-6 files in the directory some too small to be source,
    no clear directions on what to use, so moved on to 0.75 instead.

    As per above, which of these:
    crashmail_0.71-4.diff.gz 2010-08-12 14.3 kB 0
    i crashmail_0.71-4.dsc 2010-08-12 1.1 kB 0
    i crashmail_0.71-3.diff.gz 2009-07-11 14.0 kB 0
    i crashmail_0.71-3.dsc 2009-07-11 1.1 kB 0
    i cm071linux.zip 2009-02-17 361.6 kB 0
    i crashmail_0.71-2.diff.gz 2007-09-02 4.0 kB 0
    i crashmail_0.71-2.dsc 2007-09-02 567 Bytes 0
    i crashmail_0.71-1.diff.gz 2004-07-28 3.8 kB 0
    i crashmail_0.71-1.dsc 2004-07-28 567 Bytes 0
    i crashmail_0.71.orig.tar.gz 2004-07-28 169.9 kB

    Only the .orig.tar.gz and the cm071linux.zip seem to big enough to be source

    cm071linux.zip is the original source archive (as confirmed by Paul).

    lets see this cm071linux.zip is big enough to have source

    See? A little trial and error goes a long way!

    Lets throw the library of PKTs at it!

    Area NETMAIL -- 10 messages
    Area PERSONAL_MESSAGES -- 77 messages
    Area BINKD -- 151 messages
    Area NET135 -- 3 messages
    Area NET135FILE -- 104 messages
    Area NET135HUB -- 122 messages
    Area FIDONEWS -- 224 messages
    Area RBERRYPI -- 110 messages
    Area JAMNNTPD -- 150 messages

    Total -> Read messages: 881 Written messages: 7 Imported -> Imported messages: 874 Routed netmails: 7
    Bad -> Bad messages: 0 Duplicate messages: 0

    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    Sending unpacked netmail to 1:135/300.0 (Normal)
    Linking JAM area BINKD
    Linking JAM area NET135
    Linking JAM area NET135FILE
    Linking JAM area NET135HUB
    Linking JAM area FIDONEWS
    Linking JAM area RBERRYPI
    Linking JAM area JAMNNTPD
    Scanning all areas for messages to export
    Scanning area NETMAIL
    Scanning area TESTECHO
    Scanning area TEST
    Scanning area BINKD
    Scanning area NET135
    Scanning area NET135FILE
    Scanning area NET135HUB
    Scanning area FIDONEWS
    Scanning area RBERRYPI
    Scanning area JAMNNTPD

    No messages exported
    Scanning for orphan files
    Scanning for old packets
    Scanning for new files to pack
    CrashMail end
    rec9140@fidodev:~/cmzip/crashmail-0.71/bin$

    So... hmmm.. THIS file seems to work... as no error can't read
    messages...

    CONTRATS!

    I've spent the better part of 20+ hours on this over the past 2
    days...

    Thats TOO MUCH! I've moved servers with less headaches in less time
    than that.

    Had you listened to some of us (especially Paul) in the first place, you would not have spent so much time with headaches.

    It should be far simpler.. sudo apt-get install .... edit configs move
    on.

    This is Fidonet and FTN software. Most of it does NOT make it into specific Linux distribution repositories and/or package managers. And obviously as you can see, when they do make it there, they are left alone untested and quite possibly broken (as in this case you've just witnessed).

    Now it appears that possibly I've found a version that is the
    "original" version.

    Which you could have posted:

    "Hey grab this file... cm071linux.zip at..http://......." and then run this.

    I didn't realize you being a linux guy for so many years still needed your hand held?

    EXPUNGE the DEB's in the repos. and all the other files on the source thingy and elsewhere... and see what kind of DEB's I can create that
    will install a WORKING version of this....

    You're probably better off using the binaries included with the original release, rather than trying to go through hoops to get it put into the Debian repositories. Since the better part of 5 people total seem to actually be using that tosser.

    I am not sure yet how to test this on the working setup.. I guess I
    can run a parallel setup with the MSG format till it works and toss in things to a test JAM setup.... don't know.

    I need booze right now... and lots of it....

    SAME! :)

    I've got to get my notes into some sort of readable fashion and then
    work on testing it, and then getting this online so NOBODY ever goes through this crap again!

    Going through that crap was completely unnecessary. You were told from the beginning that 0.71 was the original release, and that you should use that. It was you who decided to try two other versions prior to that one, because you found some broken (and obviously untested) packages in the Debian repositories.

    If you want to go about getting those packages removed from the repos, you may want to talk to RJ Clay (1:120/544), as I believe he's the guy that attempts to make deb packages out of FTN software. If it truly is broken, maybe he can fix it?

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to mark lewis on Tue Nov 1 08:28:44 2016
    Hello mark,

    On 31 Oct 16 23:21, mark lewis wrote to Rick Christian:

    i'm sorry to say that you seem to be expecting much too much of the software that you are choosing to test... descent linux based FTN
    stuff hasn't been around all that long... it has been a long and hard fought battle to get what little bit of fTN software available for
    anyone to use...

    Very true, but the battle continues! :)

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From Richard Menedetter@2:310/31 to Bj÷rn Felten on Tue Nov 1 16:03:38 2016
    Hi Bjrn!

    30 Oct 2016 03:00, from Bjrn Felten -> Richard Menedetter:

    I use JAM exclusively, and Golded+ never corrupted anything here.
    The question is what happens when another program (such as
    crashmail) accesses the same JAM file.

    Golded locks the files it writes to.
    If another process tries to write in parallel, then the other process is buggy and should be replaced.

    CU, Ricsi

    --- GoldED+/LNX
    * Origin: Academy: A modern school where football is taught (2:310/31)
  • From Matt Bedynek@1:19/10 to rick christian on Thu Nov 3 22:09:38 2016
    On Sun, 23 Oct 2016 22:43:50 GMT, rick christian <rec9140@n377.r135.z1.fidonet.org> wrote:

    I have gotten setup with a node, changed the crashmail.prefs to that node.

    Did my Areafix, and added some echos.. but when importing them I get:

    ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
    ! 23-Oct-16 22:09:37 Failed to read message #57 in JAM messagebase "/home/rec9140/fido/jam/BINKD"

    I have not ran crashmail but since it was developed by same person may
    have this one issue that I ran into.

    When I started trying to setup jamnntpd here I noticed that when
    posting messages it would corrupt a message base or not see all the
    messages. I concluded it was an alignment error because the int's
    used in the library are not of size specific. the sizeof an int can
    vary on architectures.. So when jamnntp's jamlib is built on a 64 bit
    platform some of them are wrong size.

    It wouldn't take much to go thru the code and fix this, or simply
    build it with -m32 option (which I tested and works fine).

    For jamnntpd, I just went with the smapi version (though it had bad
    bugs too) which are now corrected. It builds as a 64bit binary too...
    no issues. I used golded, hpt, and jamnntpd together. I just need to
    get off my butt and release what I have but there is one more thing I
    want to correct before I do as well as test building on windows.

    The state of fido software is that once someone gets something working
    they tend to not share it outright. Not out of malice - just out of
    time constaints. they also don't tend to make things "release grade"
    such that a novice user can simply install them. I do believe some
    people want and would come back. We need to figure out how to make
    this great modern software more easy to use and understand.

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From mark lewis@1:3634/12.73 to Matt Bedynek on Fri Nov 4 11:31:58 2016

    03 Nov 16 22:09, you wrote to rick christian:

    When I started trying to setup jamnntpd here I noticed that when
    posting messages it would corrupt a message base or not see all the messages. I concluded it was an alignment error because the int's
    used in the library are not of size specific. the sizeof an int can
    vary on architectures.. So when jamnntp's jamlib is built on a 64 bit platform some of them are wrong size.

    ahhh... 64bitness hasn't been indicated... i've been compiling my jamnntpd on OS/2 with EMX so at best, only 32bit...

    It wouldn't take much to go thru the code and fix this, or simply
    build it with -m32 option (which I tested and works fine).

    definitely something to remember... especially if one is, as i am, using the original jamlib instead of the MAPI or SMAPI libraries...

    For jamnntpd, I just went with the smapi version (though it had bad
    bugs too) which are now corrected. It builds as a 64bit binary too...
    no issues. I used golded, hpt, and jamnntpd together. I just need to
    get off my butt and release what I have but there is one more thing I
    want to correct before I do as well as test building on windows.

    that's kind of my situation, too... but i did post patches or code to this echo for others to grab and add to their code bases... it is just easier that way for me since i'm not going to fight trying to add repo stuffs to my production OS/2 box ;)

    The state of fido software is that once someone gets something working they tend to not share it outright. Not out of malice - just out of
    time constaints. they also don't tend to make things "release grade"
    such that a novice user can simply install them. I do believe some
    people want and would come back. We need to figure out how to make
    this great modern software more easy to use and understand.

    agreed :)

    PS: it is good to see you again, matt!

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The smallest good deed is better than the grandest intention.
    ---
    * Origin: (1:3634/12.73)
  • From Rick Christian@1:135/377 to Matt Bedynek on Fri Nov 4 13:46:47 2016

    Hello Matt!

    03 Nov 16 22:09, you wrote to me:

    When I started trying to setup jamnntpd here I noticed that when
    posting messages it would corrupt a message base or not see all the messages. I concluded it was an alignment error because the int's
    used in the library are not of size specific. the sizeof an int can
    vary on architectures.. So when jamnntp's jamlib is built on a 64 bit platform some of them are wrong size.

    It wouldn't take much to go thru the code and fix this, or simply
    build it with -m32 option (which I tested and works fine).

    DING!! DING!!

    Well you have spilled the beans as it were.. I've been digging through that circular bug mess on this exact issue..

    That is what I think the issue is with the DEB's... they may compile, so Launchpad just takes it as GOOD TO GO! Problem is that if you run it on *64b* corruption due to exactly waht you said... be it CM II or JamNNTPd...

    THIS is EXACTLY why I asked... I had the ace up my sleeve the whole time! :) ;)

    So is the V1.3 code at the SF stuff *correct* for *64b* operation or no one knows as for some reason every one is using 32b??? And the only other working server user seems to be using OS/2 ... although his bug patch was added to the V1.3 code on 9/10/16.....

    I don't know but I have a hunch that if any one is running this on Linux they are using 32b for it for some reason.. maybe thats all the hardware they have for a spare... don't know...

    BUT..

    Again, this is why I asked, I want to use JamNNTPd to do some things.. but not CORRUPT of the Jam base with something that has the same issue..

    So where is this -m32 option used????

    in other words this:

    sudo make -m32 linux (think thats lised in the compile it note) or some other edit???


    Seems there IS a *magic golden* code base for JamNNTPd as well!


    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From Rick Christian@1:135/377 to Matt Bedynek on Fri Nov 4 14:02:48 2016

    Hello Matt!

    03 Nov 16 22:09, you wrote to me:

    It wouldn't take much to go thru the code and fix this, or simply

    build it with -m32 option (which I tested and works fine).

    doesn't seem like that option is supported by "make" per man file:

    -b, -m
    These options are ignored for compatibility with other versions of make.


    So this is changed where??


    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From mark lewis@1:3634/12.73 to Rick Christian on Fri Nov 4 18:17:18 2016

    04 Nov 16 13:46, you wrote to Matt Bedynek:

    When I started trying to setup jamnntpd here I noticed that when
    posting messages it would corrupt a message base or not see all the
    messages. I concluded it was an alignment error because the int's
    used in the library are not of size specific. the sizeof an int can
    vary on architectures.. So when jamnntp's jamlib is built on a 64
    bit platform some of them are wrong size.

    It wouldn't take much to go thru the code and fix this, or simply
    build it with -m32 option (which I tested and works fine).

    DING!! DING!!

    Well you have spilled the beans as it were.. I've been digging through that circular bug mess on this exact issue..

    i don't recall you saying anything about 64bit :( i hope this alignment stuff makes it into the rest of the code bases soonish... i was actually contemplating taking my code on my production OS/2 box and copying it over to my 64bit ubuntu box and letting it fly... i will thank you for stepping into that mess and bringing the bitness problem to light... i have to wonder who else has fallen into that trap without knowing it? rossC over at 123/500 has a very popular jamnntpd server and there has been some weirdness problems there that may be due to this bitness stuff... i don't know and i don't know what bitness he has compiled his jamnntpd for... he does use HPT for his tosser, IIRC... i think it does 32bit and 64bit as i'm using it on this 64bit ubuntu box and i compiled HPT here with no bitness stuff specified...

    [trim]

    So is the V1.3 code at the SF stuff *correct* for *64b* operation or
    no one knows as for some reason every one is using 32b??? And the only other working server user seems to be using OS/2 ... although his bug patch was added to the V1.3 code on 9/10/16.....

    i don't know which bug patch that was... i posted several of them to this echo over a couple of weeks... i haven't been back into the code since then... i also hope you aren't mixing me up with jame or anyone else... jame is the one managing the ftnapps repo...


    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Care for a shrimp cocktail? No, thanks - I need a BIG one.
    ---
    * Origin: (1:3634/12.73)
  • From Matt Bedynek@1:19/10 to Rick Christian on Fri Nov 4 21:16:22 2016
    On Fri, 4 Nov 2016 18:46:46 -0400, Rick Christian wrote:


    Again, this is why I asked, I want to use JamNNTPd to do some things..
    but not CORRUPT of the Jam base with something that has the same issue..

    So where is this -m32 option used????

    You need to edit the Makefile. In jamnntpd, it should be in
    src/Makefile.unix.

    Find the line, CCOPTS and add to it -m32.

    Seems there IS a *magic golden* code base for JamNNTPd as well!

    There were some modified versions floating around - some which did not
    work that well. The versions used by folks here work well provided
    you dont get caught by the march issue.

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Matt Bedynek@1:19/10 to Rick Christian on Fri Nov 4 21:17:12 2016
    On Fri, 4 Nov 2016 19:02:48 -0400, Rick Christian wrote:

    doesn't seem like that option is supported by "make" per man file:

    -b, -m
    These options are ignored for compatibility with other versions of make.


    So this is changed where??

    It is not a make option. It is a compiler option.

    After you add it, wiill want to do a make cleanunix then make unix

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Matt Bedynek@1:19/10 to mark lewis on Fri Nov 4 21:22:08 2016
    On Fri, 4 Nov 2016 16:31:58 -0400, mark lewis wrote:

    ahhh... 64bitness hasn't been indicated... i've been compiling my
    jamnntpd on OS/2 with EMX so at best, only 32bit...

    definitely something to remember... especially if one is, as i am, using the original jamlib instead of the MAPI or SMAPI libraries...

    I specifically choose the smapi route because I knew it would be fine
    with 64bit. There was simply a bug in jamnntpd's use of it such that
    it wasn't closing the base after posting a message. If the process
    crashed it would corrupt the msgbase.

    that's kind of my situation, too... but i did post patches or code to
    this echo for others to grab and add to their code bases... it is just easier that way for me since i'm not going to fight trying to add repo stuffs to my production OS/2 box ;)

    Does OS/2 support IPV6? I wondered if the changes I made for it would
    compile there though I am skeptical.

    PS: it is good to see you again, matt!

    thanks. Hopefully things are more civil in the areas. Havent read
    them throughlly for a few months.

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Rick Christian@1:135/377 to mark lewis on Fri Nov 4 14:12:47 2016

    Hello mark!

    04 Nov 16 11:31, you wrote to Matt Bedynek:


    03 Nov 16 22:09, you wrote to rick christian:


    ahhh... 64bitness hasn't been indicated... i've been compiling my

    I indicated that from the start Ubuntu server 14.0.4.5 *64b*

    Rick


    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From mark lewis@1:3634/12.73 to Rick Christian on Sat Nov 5 06:41:46 2016

    04 Nov 16 14:12, you wrote to me:

    ahhh... 64bitness hasn't been indicated... i've been compiling my

    I indicated that from the start Ubuntu server 14.0.4.5 *64b*

    it wasn't prominent and repeated or otherwise made obvious... i'm on kubuntu 14.04.5 64bit here on this workstation and all the hosted VMs are ubuntu server but a mix of 32bit and 64bit... i've not yet attempted to build or run jamnntpd on any of them but it has been considered... you posted a slew of messages... many quite verbal but this being a 32bit vs a 64bit problem was not evident until now... ace in the hole? bullshit... if you knew this was the problem causing your message base corruption, you should have said so from the beginning...

    it is also not a coding problem causing the different variable sizes between 32bit and 64bit... it is a declaration problem when the variables are declared... it is only a problem because compiler maintainers made the bad decision to change existing variable types and make them larger instead of creating new types for them... new types had to be created any way so that would not have been a problem and their decision has caused even more problems... this situation is also not limited to C compilers... i've seen it in pascal compilers, too... i'm sure it exists in many different languages as well...

    now, if someone would be so kind as to post what changes are needed for the variable declarations so we don't need to worry about the arch or have to allow for multi-arch on 64bit systems, it would be a good thing... some folks like to run pure 64bit with 32bit multi-arch totally disallowed and banned... i'm surprised that you even allow 32bit on your 64bit setup... especially since you are so adamant about this and some political stuffs you've participated in...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... "Gledlig jul og godt Nytt Aar." - Norse-Danish Christmas
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Matt Bedynek on Sat Nov 5 06:42:44 2016

    04 Nov 16 21:22, you wrote to me:

    ahhh... 64bitness hasn't been indicated... i've been compiling my
    jamnntpd on OS/2 with EMX so at best, only 32bit...

    definitely something to remember... especially if one is, as i am,
    using the original jamlib instead of the MAPI or SMAPI libraries...

    I specifically choose the smapi route because I knew it would be fine
    with 64bit. There was simply a bug in jamnntpd's use of it such that
    it wasn't closing the base after posting a message. If the process crashed it would corrupt the msgbase.

    the only reason i can see for using SMAPI is if one wanted to use other message base formats than JAM... i guess this 64bit problem may be another reason but i'd rather see jamlib fixed properly to handle this...

    that's kind of my situation, too... but i did post patches or code to
    this echo for others to grab and add to their code bases... it is
    just easier that way for me since i'm not going to fight trying to
    add repo stuffs to my production OS/2 box ;)

    Does OS/2 support IPV6? I wondered if the changes I made for it would compile there though I am skeptical.

    i don't think so... i haven't read anything about it and i'm not planning on going to IPv6 for several more years... there is simply no need for it over here...

    PS: it is good to see you again, matt!

    thanks. Hopefully things are more civil in the areas. Havent read
    them throughlly for a few months.

    kinda yeah but it depends... i've been making liberal use of my twit filter, biting my tongue a lot, and not getting on the machine while consuming adult beverages and saying how i really feel about certain things... that's on my part but i still feel like saying a lot more than i have, beverages or no...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Chastity is curable - if detected early
    ---
    * Origin: (1:3634/12.73)
  • From Rick Christian@1:135/377 to Matt Bedynek on Sat Nov 5 09:19:55 2016

    Hello Matt!

    04 Nov 16 21:16, you wrote to me:

    You need to edit the Makefile. In jamnntpd, it should be in src/Makefile.unix.

    Ahhh....mmmmmm.. Thanks....

    Rrrrawwwttroooo RRRRroooge .. no such file here..

    Makefile.linux

    And it has this to start:

    Makefile for Linux

    # General

    PLATFORMDEF = -DPLATFORM_LINUX
    EXESUFFIX =

    CC = gcc $(DEFS) -Wall
    RM = rm -f
    STRIP = strip

    OBJS = main.o nntpserv.o os_linux.o sockio.o groups.o misc.o xlat.o allow.o login.o mime.o

    Change the CC = line????

    CC = gcc $(DEFS) -Wall -m32 ????

    This is the V1.3 code from the SF/ftnapps....

    $ ls -la
    total 260
    drwxrwxr-x 3 rec9140 rec9140 4096 Sep 10 14:17 .
    drwxrwxr-x 6 rec9140 rec9140 4096 Sep 10 14:17 ..
    -rw-rw-r-- 1 rec9140 rec9140 1105 Sep 10 14:17 allow.c
    -rw-rw-r-- 1 rec9140 rec9140 45 Sep 10 14:17 allow.h
    -rw-rw-r-- 1 rec9140 rec9140 2873 Sep 10 14:17 groups.c
    -rw-rw-r-- 1 rec9140 rec9140 265 Sep 10 14:17 groups.h
    drwxrwxr-x 2 rec9140 rec9140 4096 Sep 10 14:17 jamlib
    -rw-rw-r-- 1 rec9140 rec9140 1685 Sep 10 14:17 login.c
    -rw-rw-r-- 1 rec9140 rec9140 53 Sep 10 14:17 login.h
    -rw-rw-r-- 1 rec9140 rec9140 14487 Sep 10 14:17 main.c
    -rw-rw-r-- 1 rec9140 rec9140 26093 Sep 10 14:17 makechs.c
    -rw-rw-r-- 1 rec9140 rec9140 972 Sep 10 14:17 Makefile
    -rw-rw-r-- 1 rec9140 rec9140 1171 Sep 10 14:17 Makefile.linux
    -rw-rw-r-- 1 rec9140 rec9140 1189 Sep 10 14:17 Makefile.os2
    -rw-rw-r-- 1 rec9140 rec9140 1194 Sep 10 14:17 Makefile.win32
    -rw-rw-r-- 1 rec9140 rec9140 10199 Sep 10 14:17 mime.c
    -rw-rw-r-- 1 rec9140 rec9140 493 Sep 10 14:17 mime.h
    -rw-rw-r-- 1 rec9140 rec9140 3726 Sep 10 14:17 misc.c
    -rw-rw-r-- 1 rec9140 rec9140 544 Sep 10 14:17 misc.h
    -rw-rw-r-- 1 rec9140 rec9140 79337 Sep 10 14:17 nntpserv.c
    -rw-rw-r-- 1 rec9140 rec9140 2577 Nov 5 08:12 nntpserv.h
    -rw-rw-r-- 1 rec9140 rec9140 471 Sep 10 14:17 os.h
    -rw-rw-r-- 1 rec9140 rec9140 1999 Sep 10 14:17 os_linux.c
    -rw-rw-r-- 1 rec9140 rec9140 412 Sep 10 14:17 os_linux.h
    -rw-rw-r-- 1 rec9140 rec9140 3377 Sep 10 14:17 os_os2.c
    -rw-rw-r-- 1 rec9140 rec9140 421 Sep 10 14:17 os_os2.h
    -rw-rw-r-- 1 rec9140 rec9140 2575 Sep 10 14:17 os_win32.c
    -rw-rw-r-- 1 rec9140 rec9140 156 Sep 10 14:17 os_win32.h
    -rw-rw-r-- 1 rec9140 rec9140 1902 Sep 10 14:17 sockio.c
    -rw-rw-r-- 1 rec9140 rec9140 383 Sep 10 14:17 sockio.h
    -rw-rw-r-- 1 rec9140 rec9140 14488 Sep 10 14:17 xlat.c
    -rw-rw-r-- 1 rec9140 rec9140 738 Sep 10 14:17 xlat.h

    Find the line, CCOPTS and add to it -m32.


    That is a file I don't like messing with.... hmmm... that will need a new VM so it can borq it up with core dumps and spewage to disk that overwrites everything... so no big loss... :) ;)

    I don't trust things when you monkey with that stuff... :) ;)


    We'll see... but there seems to be a difference to what we are using...

    Thanks.


    Rick


    ... Vote Trump 2016 and Make America Great Again!
    --- GoldED+/LNX 1.1.5-b20160322
    * Origin: Vina's Talos Moon Base Alpha (1:135/377)
  • From Nicholas Boel@1:154/10 to mark lewis on Sat Nov 5 09:28:19 2016
    Hello mark,

    On 05 Nov 16 06:42, mark lewis wrote to Matt Bedynek:

    kinda yeah but it depends... i've been making liberal use of my twit filter, biting my tongue a lot, and not getting on the machine while consuming adult beverages and saying how i really feel about certain things... that's on my part but i still feel like saying a lot more
    than i have, beverages or no...

    More beverages + Less Fidonet = Happy camper. :)

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Sat Nov 5 13:45:42 2016

    05 Nov 16 09:28, you wrote to me:

    kinda yeah but it depends... i've been making liberal use of my twit
    filter, biting my tongue a lot, and not getting on the machine while
    consuming adult beverages and saying how i really feel about certain
    things... that's on my part but i still feel like saying a lot more
    than i have, beverages or no...

    More beverages + Less Fidonet = Happy camper. :)

    yup, to a point... now i've been taking my beverages and going outside to look for and count satellites i see flying over... sometimes i even make notes about them to i can determine which ones i've seen ;)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... In a dog-eat-dog world, don't wear Milk Bone underwear.
    ---
    * Origin: (1:3634/12.73)
  • From Björn Felten@2:203/2 to mark lewis on Sat Nov 5 19:36:13 2016
    yup, to a point... now i've been taking my beverages and going outside
    to look for and count satellites i see flying over... sometimes i even make notes about them to i can determine which ones i've seen ;)

    Yeah, right. 8-)

    Can you even determine if they are satellites or "falling stars"?




    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From mark lewis@1:3634/12.73 to Björn Felten on Sat Nov 5 15:16:08 2016

    05 Nov 16 19:36, you wrote to me:

    yup, to a point... now i've been taking my beverages and going
    outside to look for and count satellites i see flying over...
    sometimes i even make notes about them to i can determine which ones
    i've seen ;)

    Yeah, right. 8-)

    yes, absolutely true :)

    Can you even determine if they are satellites or "falling stars"?

    absolutely... meteors move much faster and are brighter for the most part... they may also leave trails... satellites do not leave trails unless they are breaking up on reentry but they are no where near as fast as meteors... also satellites are fairly steady in brightness or fade in and out... sometimes they might flare or flash (fast flare) but they don't blink like airplanes... it is extremely easy to tell the three apart...

    we do naked eye viewing here and sometimes will use binoculars but they really need a mount to hold them steady... some folks use large binoculars as well as photographic devices attached to eh binos or even to a telescope... some telescopes also have motors on them that can move the scope fast enough to track a satellite for viewing or photography... i haven't gotten to the point that i can work on looking for geosync satellites but there are a number of folks that do... we've even tracked the USAF's X-37B space plane as well as a number of classified satellites... we recently watched the MUOS 5 craft reach geosync orbit after it had a failure of the apogee or perigee kick motor... i forget which it was using but they had to let it go and use the satellite's own thrusters to try to reach desired orbit... it finally made it but has to change its mission due to the lack of fuel it now has...

    most of what i see here are Iridium or Cosmos generally on north-south or south-north tracks... Iridium flares are way cool when you can see them... we've even seen them in the day time ;)

    we do also see the ISS regularly as well as others on angular tracks and i was lucky enough, one early morning when i was working at the taxi stand, to be able to see the HST fly over... HST is tougher for us to see because of its altitude above the horizon compared with our latitude... it only makes it up maybe 20 or so degrees (two fist widths at arm's length) and is behind the trees for us... in this case, being in town instead of out here in the country, it was very clear to the south with no trees in the way... it took about five minutes to pass by...

    i also read and occasionally participate on the SEESAT-L mailing list... well known observers like Ted Molczan, Marco Langbroek, Dr. Jonathan McDowell, and numerous others participate there posting their sightings for updating the various TLE (Two Line element) lists that are available... they also help others figure out what they may have seen in the sky...

    http://www.satobs.org/
    http://planet4589.org/
    http://www.marcolangbroek.nl/
    http://sattrackcam.blogspot.nl/
    https://www.google.com/search?q=ted+molczan

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Your reasoning is excellent. It's your basic assumptions that are wrong. ---
    * Origin: (1:3634/12.73)
  • From Nicholas Boel@1:154/10 to mark lewis on Sat Nov 5 21:52:13 2016
    Hello mark,

    On 05 Nov 16 13:45, mark lewis wrote to Nicholas Boel:

    More beverages + Less Fidonet = Happy camper. :)

    yup, to a point... now i've been taking my beverages and going outside
    to look for and count satellites i see flying over... sometimes i even make notes about them to i can determine which ones i've seen ;)

    Still falls under the same category, doesn't it? :)

    I'm just done arguing with this guy. He's in multiple echoes demanding he is correct in everything he says. I just don't care enough. lol

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Sun Nov 6 05:40:52 2016

    05 Nov 16 21:52, you wrote to me:

    More beverages + Less Fidonet = Happy camper. :)

    yup, to a point... now i've been taking my beverages and going
    outside to look for and count satellites i see flying over...
    sometimes i even make notes about them to i can determine which ones
    i've seen ;)

    Still falls under the same category, doesn't it? :)

    yeah, i think so :)

    I'm just done arguing with this guy. He's in multiple echoes demanding
    he is correct in everything he says. I just don't care enough. lol

    i think he's seeing the light and realizing more now... it just takes time... i remember another fella that came around some years back full of vim and vigor... he was of similar nature at the time... today he is much easier to get along with and to chat with ;)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... We don't care HOW you do things up north.
    ---
    * Origin: (1:3634/12.73)
  • From Nicholas Boel@1:154/10 to mark lewis on Sun Nov 6 09:51:38 2016
    Hello mark,

    On 06 Nov 16 05:40, mark lewis wrote to Nicholas Boel:

    I'm just done arguing with this guy. He's in multiple echoes
    demanding he is correct in everything he says. I just don't care
    enough. lol

    i think he's seeing the light and realizing more now... it just takes time... i remember another fella that came around some years back full
    of vim and vigor... he was of similar nature at the time... today he
    is much easier to get along with and to chat with ;)

    Hopefully (to the first part)!

    Touché (to the second part)!

    :)

    Regards,
    Nick

    ... "Не знаю. Я здесь только работаю."
    --- GoldED+/LNX 1.1.5-b20160827
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Sun Nov 6 12:21:44 2016

    06 Nov 16 09:51, you wrote to me:

    I'm just done arguing with this guy. He's in multiple echoes
    demanding he is correct in everything he says. I just don't care
    enough. lol

    i think he's seeing the light and realizing more now... it just takes
    time... i remember another fella that came around some years back
    full of vim and vigor... he was of similar nature at the time...
    today he is much easier to get along with and to chat with ;)

    Hopefully (to the first part)!

    yep...

    Touché (to the second part)!

    :)

    HAHAHAHAHAHAHAHAHA! i was hoping you'd catch that and understand it as it was intended... you done great, grasshopper! :)

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Happy Holidays and a Wonderful 2017 to you and yours!
    ---
    * Origin: (1:3634/12.73)
  • From Nicholas Boel@1:154/10 to mark lewis on Mon Nov 7 08:07:44 2016
    Hello mark,

    On 06 Nov 16 12:21, mark lewis wrote to Nicholas Boel:

    i think he's seeing the light and realizing more now... it just
    takes time... i remember another fella that came around some
    years back full of vim and vigor... he was of similar nature at
    the time... today he is much easier to get along with and to
    chat with ;)

    Hopefully (to the first part)!

    yep...

    Touché (to the second part)!

    :)

    HAHAHAHAHAHAHAHAHA! i was hoping you'd catch that and understand it as
    it was intended... you done great, grasshopper! :)

    Most definitely. It seems the longer I stick around, the less I care (to argue, at least).

    Regards,
    Nick

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