Hello everybody!

In an effort to spare myself the grief...

Which, be specific, JamNNTPd WORKS with CMII 0.71 on *64bit* *buntu's specifically 14.04.5

The DEBS here? Are just as corrupt??? http://packages.ubuntu.com/xenial/amd64/jamnntpd/download

OR ONLY these ones work?
http://felten.yi.org/FILES/Billing/

And all these are broken, correct? https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/?source=navbar

Specifically the 1.3 listed as updated on 9/10/16...

IF the version of CM II I have now is working I can move on to adding JamNNTPd, and attempt to fix Pan/KNode access, as using thunderturkey long term is not viable. That program just annoys me.



Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

Hello Rick,

On 01 Nov 16 09:24, Rick Christian wrote to All:

In an effort to spare myself the grief...

Which, be specific, JamNNTPd WORKS with CMII 0.71 on *64bit* *buntu's specifically 14.04.5

The DEBS here? Are just as corrupt??? http://packages.ubuntu.com/xenial/amd64/jamnntpd/download

OR ONLY these ones work?
http://felten.yi.org/FILES/Billing/

And all these are broken, correct? https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/?source=navb
ar

Specifically the 1.3 listed as updated on 9/10/16...

I would NOT trust any of those unless you feel like thoroughly testing them yourself before using them. 0.71 is indeed the last official release by the original author, and the source was released into the wild.

IF the version of CM II I have now is working I can move on to adding JamNNTPd, and attempt to fix Pan/KNode access, as using thunderturkey
long term is not viable. That program just annoys me.

If CMII 0.71 is currently working for you, I would definitely stick with it and continue on with your mission.

Regards,
Nick

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

Hello Nicholas!

01 Nov 16 08:40, you wrote to me:

I would NOT trust any of those unless you feel like thoroughly testing them yourself before using them. 0.71 is indeed the last official
release by the original author, and the source was released into the
wild.

I am refering to - > *JamNNTPd* < - now.

Specifically which is the WORKING MAGIC version

link -? http:// ______________________________

file -? ___________________________________

I am want the corret version that works, and will not corrup the JAM base files etc...

If CMII 0.71 is currently working for you, I would definitely stick
with it and continue on with your mission.

I am referring to *JamNNTPd* now...

Thank you.


Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

I am refering to - > *JamNNTPd* < - now.

So was I in my reply to you.



..

--- 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)

Hello Rick,

On 01 Nov 16 22:01, Rick Christian wrote to Nicholas Boel:

I would NOT trust any of those unless you feel like thoroughly
testing them yourself before using them. 0.71 is indeed the last
official release by the original author, and the source was
released into the wild.

I am refering to - > *JamNNTPd* < - now.

Specifically which is the WORKING MAGIC version

link -? http:// ______________________________

file -? ___________________________________

I am want the corret version that works, and will not corrup the JAM
base files etc...

I believe Björn has already given you a link for that, almost a week ago?

Regards,
Nick

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

01 Nov 16 22:01, you wrote to Nicholas Boel:

I am refering to - > *JamNNTPd* < - now.

[...]

I am want the corret version that works, and will not corrup the JAM
base files etc...

i've never known jamnntpd to corrupt the message bases...

)\/(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 *am* a Size 10. My fat is just there to protect my perfect body.
---
* Origin: (1:3634/12.73)

Hello, mark lewis : Rick Christian.
On 02/11/2016 16:16 you wrote:

01 Nov 16 22:01, you wrote to Nicholas Boel:

I am refering to - > *JamNNTPd* < - now.

[...]

I am want the corret version that works, and will not corrup the JAM base files etc...

i've never known jamnntpd to corrupt the message bases...

Thats right! I have also run jamnntpd with golded, gecho and concord for years and years without any jam base corruption.

--- HotdogEd/2.12 (Android; Google Android; rv:1) Hotdoged/1474702396000 Hotdog
* Origin: *** nntp://rbb.bbs.fi *** Lake Ylo *** Finland *** (2:221/360)

Hello Tommi,

01 Nov 16 22:01, you wrote to Nicholas Boel:

I am refering to - > *JamNNTPd* < - now.

[...]

I am want the corret version that works, and will not corrup the JAM
base files etc...

i've never known jamnntpd to corrupt the message bases...

Thats right! I have also run jamnntpd with golded, gecho and concord for >years and years without any jam base corruption.

Same here. I have run JamNNTPd with Golded, Gecho, and FastEcho without any instance of corruption.

Jeff

--- BBBS/Li6 v4.10 Dada-2
* Origin: The OuijaBoard - Anoka, MN (1:282/1031)

Hi! Jeff,

On 11/03/2016 07:37 AM, you wrote to Tommi Koivula:

Thats right! I have also run jamnntpd with golded, gecho and concord for
years and years without any jam base corruption.

Same here. I have run JamNNTPd with Golded, Gecho, and FastEcho without any instance of corruption.

Same, same here. My main node celebrated 10 years' JamNNTPd operation last April, with Golded, and FastEcho.

This node has clocked up four years JamNNTPd co-operating with CrashMail and Golded quite nicely. Same with another smaller but identical test node having run for five years. :)

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)

Same, same here. My main node celebrated 10 years' JamNNTPd operation
last April, with Golded, and FastEcho.

Ditto, but more than twelve years now here. Sun, 27 Jun 2004 23:39:15 GMT is the first message posted in this echo when Mr Billing and I beta tested JamNNTPd after I urged him to resurrect this old project of his.

Originally for the Amiga world, but we all know by now how that world eventually went down the drains...? 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)

* Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


Hello Nicholas!

02 Nov 16 07:35, you wrote to me:

I believe Bjorn has already given you a link for that, almost a week

OK.. got it.. eljaco.se site is the only source of working JamNNTPd

V1.05b

I've contacted sourceforge to have that other corrupt mangled repo removed.

Thanks.


Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

OK.. got it.. eljaco.se site is the only source of working JamNNTPd

Well, maybe not entirely true, but this is where Johan Billing was operating when he and I got this baby bugfixed as well as we could by then, 12 years ago. 8-)

So this is where his end result is located nowadays. It's all up for grabs...

..

--- 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)

Hello mark!

Replying to a msg dated 02 Nov 16 10:16, from you to me.

02 Nov 16 10:16, you wrote to me:

01 Nov 16 22:01, you wrote to Nicholas Boel:

I am refering to - > *JamNNTPd* < - now.

i've never known jamnntpd to corrupt the message bases...

So the current 1.3 version modified 9/10/2016 is the "MAGIC" USABLE version of this??

Or ONLY THE VERSION at
http://eljaco.se/FILES/Billing/

Specifically:

http://eljaco.se/FILES/Billing/jamnntpd-1.0b5.zip

Is the only MAGIC WORKING version.

As per the other reply that the eljaco.se site is the golden resource of the working verions... NOTED, others removed.

I am contacting sourceforge as I type to have that removed so this will shut down another avenue of bad sources of this software.

THanks.

Rick



=== Cut ===

Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

On Wed, 2 Nov 2016 20:15:57 -0400 "Rick Christian wrote:

I am contacting sourceforge as I type to have that removed so this will shut down another avenue of bad sources of this software.

What the fuck are you talking about?? There is nothing wrong with any files at

https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/

If you disagree, just show us some proof!

--
Tommi

--- Sylpheed 3.5.1 (GTK+ 2.24.23; i686-pc-mingw32)
* Origin: *** nntp://rbb.bbs.fi *** Lake Ylo *** Finland *** (2:221/360)

02 Nov 16 20:15, you wrote to me:

I am refering to - > *JamNNTPd* < - now.

i've never known jamnntpd to corrupt the message bases...

So the current 1.3 version modified 9/10/2016 is the "MAGIC" USABLE version
of this??

i don't know of such a thing as "the MAGIC USABLE version"... for instance...

1. i don't need the ssl capabilities that were added at one point and numerous other bugs cleaned.
2. i added the ability to turn off rDNS lookups and log only the IPs.
3. i changed the identifier for OS/2 systems to be "OS2" instead of just "2" to conform more to how other OSes are depicted.
4. the compile i use uses the original jamlib instead of the SMAPI or MAPI libraries as some others have done.
5. my version ids itself (currently) as 1.21 with a beta number as well as a system id showing that it is my own build.
6. there was a fix wherein min and max were reversed in the 'list of news groups' output.
7. i fixed a bug in the xoverres output wherein it was missing the last \t which caused some news clients to error out.
8. i know that some of us have increased POST_MAXSIZE so that larger messages may be posted.
9. there was something else i was going to implement but i don't recall it without looking back in the echo at my posts.
10. fixes from other folks that i just don't recall at the moment.

i think i started with 1.3 but that doesn't explain why my version number is

JamNNTPd/OS2 1.21.b9/wpusa

1.21 being the operative portion... i'm going to guess that it is because i started this round with version 1.20 and incremented it by 0.01 as my first update to this version and b9 indicating my 9th beta of it...

Or ONLY THE VERSION at
http://eljaco.se/FILES/Billing/

Specifically:

http://eljaco.se/FILES/Billing/jamnntpd-1.0b5.zip

AFAIK, most of us started there... i really don't recall where i pulled my last up-to-date sources from before i added my fixes from above... i think it was the ftnapps repo on sourceforge...

[time passes]

yes, my last update was jamnntpd-1.2.tar.gz from ftnapps at sourceforge... IIRC, that's RJ Clay's repo... he is the Region 11 Coordinator in fidonet...

[/time passes]

Is the only MAGIC WORKING version.

there is no "only MAGIC WORKING version" AFAIK... they all work... some better than others... it depends on the JAM library used and which version of that selected... i just stick with the original jamlib, though...

As per the other reply that the eljaco.se site is the golden resource
of the working verions... NOTED, others removed.

I am contacting sourceforge as I type to have that removed so this will shut down another avenue of bad sources of this software.

now why would you do that? destroying someone else's hard work and effort? that's going to upset folks if you cause their repo and folks feeding from it to be removed... especially for working code... why? you have heard of collaborative development, right? i develop on my system as i don't have a repo there... i can set one up on my linux box which i could then update from my production box's updates... but for now i post patches in this echo so others can patch theirs if they want to... if they don't, that's their business but don't be going and having someone else's repos removed or killed off because you don't think they're up to snuff by your standards...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Cat's teach us tolerance....and how to see through walls
---
* Origin: (1:3634/12.73)

Hello Rick,

On 02 Nov 16 20:11, Rick Christian wrote to Nicholas Boel:

* Replying to a msg in PERSONAL_MESSAGES (Personal Messages)

Hello Nicholas!

02 Nov 16 07:35, you wrote to me:

I believe Bjorn has already given you a link for that, almost a
week

OK.. got it.. eljaco.se site is the only source of working JamNNTPd

V1.05b

I've contacted sourceforge to have that other corrupt mangled repo removed.

Thanks.

That's nowhere near what I said. :(

Regards,
Nick

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

Hello Tommi,

On 03 Nov 16 16:29, Tommi Koivula wrote to Rick Christian:

On Wed, 2 Nov 2016 20:15:57 -0400 "Rick Christian wrote:

I am contacting sourceforge as I type to have that removed so
this will shut down another avenue of bad sources of this
software.

What the fuck are you talking about?? There is nothing wrong with any files at

https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/

If you disagree, just show us some proof!

I know for a fact you've been paying attention to every other echo he has started some kind of argument in (ie: BINKD, GOLDED, and now this one). He seems to be basing his opinions on precompiled binaries that are years old, rather than actually taking a little less time complaining, and more time with the ole "trial and error" method of actually trying to compile the software himself, which he has already stated he absolutely will not do.

Either way, not our fault. Others have tried to help him and even direct him to working binaries, only to receive an argument out of it because he himself could not get it working.

I'm over it, and soon you will be too! :)

Regards,
Nick

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

Hello mark,

On 03 Nov 16 09:56, mark lewis wrote to Rick Christian:

I am contacting sourceforge as I type to have that removed so
this will shut down another avenue of bad sources of this
software.

now why would you do that? destroying someone else's hard work and
effort? that's going to upset folks if you cause their repo and folks

Habitual complainer, maybe?

feeding from it to be removed... especially for working code... why?
you have heard of collaborative development, right? i develop on my
system as i don't have a repo there... i can set one up on my linux
box which i could then update from my production box's updates... but
for now i post patches in this echo so others can patch theirs if they want to... if they don't, that's their business but don't be going and having someone else's repos removed or killed off because you don't
think they're up to snuff by your standards...

It probably IS indeed up to snuff. His lack of inspiration and absolute refusal to try to compile anything is holding him back from actually testing what's "currently" there for general use.

It seems as though he's just going to continue to complain and blame everyone else for his system not working as he expects it to.

Regards,
Nick

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

03 Nov 16 13:11, you wrote to me:

I am contacting sourceforge as I type to have that removed so this
will shut down another avenue of bad sources of this software.

now why would you do that? destroying someone else's hard work and
effort? that's going to upset folks if you cause their repo and folks

Habitual complainer, maybe?

on the one hand, i tend to agree with both sides... i well remember the troubles i went through when i moved to this location and could not get a connection from the raleigh network or anywhere where else... i was finally able to get a connection though the fayetteville net but it was LD just as the raleigh net was... both wanted me to pay for my echos but in-state LD was more expensive than out-of-state so i told them i'd poll at least once a month for routed netmail and i'd pull my echos from whereever i wanted and could get a connection... that was not taken very lightly... this was before planet connect came along... then PC came along and proved my point and years later i'm now the NC of the entire state of north carolina... the mian point being tha ti've seen both sides and back in those days i was even looking for gated fidonet echos on usenet... there were very few and being able to get them didn't do anything to make my system a fidonet node...

the main thing that strikes me in all of this is that fidonet is and always has been a hobby network for those wanting to experiment with store-and-forward networking... i really have to wonder, sometimes, if some folks just don't know that or if they may have lost that vision... this especially pertains to some of our Z2 brethern who are in positions of influence and/or control... especially when they go so far as to refuse to see and acknowledge other FTNs and that what fidonet does also affects those other FTNs at the basest level...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... All I want for Christmas is... a 233Mhz with a 4.3Gb HD , 32MB, 4 Mb Video, 24
---
* Origin: (1:3634/12.73)

* Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


Hello Tommi!

03 Nov 16 16:29, you wrote to me:

What the fuck are you talking about?? There is nothing wrong with any files at

https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/

If you disagree, just show us some proof!

Per the replies *here*! The eljaco.se is the GOLDEN CODE per several replies.... it contains both CM II and JamNNTPd code.

So *now* that is not correct???

Which is it???

I asked to be informed which is the CURRENT GOLD VERSION of the *JamNNTPd code*, so as not to repeat the fiasco with CM II...


I was told paraphrase..." link already posted.." That is the eljaco.se site...so thus that is the GOLDEN SOURCE.

Anything else needs to be removed!

Seems now that is not the tune...

So for JamNNTPd what source is workds to be downloaded and used???

eljaco.se

OR

Some place else????

Again, I asked this, and was told, "link posted." paraphrased.




--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

* Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


Hello Nicholas!

02 Nov 16 07:35, you wrote to me:

Hello Rick,

On 01 Nov 16 22:01, Rick Christian wrote to Nicholas Boel:

I would NOT trust any of those unless you feel like thoroughly
testing them yourself before using them. 0.71 is indeed the last
official release by the original author, and the source was
released into the wild.

I am refering to - > *JamNNTPd* < - now.

Specifically which is the WORKING MAGIC version

link -? http:// ______________________________

file -? ___________________________________

I am want the corret version that works, and will not corrup the
JAM base files etc...

I believe Björn has already given you a link for that, almost a week
ago?

Regards,
Nick

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

Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

* Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


Hello mark!

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

AFAIK, most of us started there... i really don't recall where i
pulled my last up-to-date sources from before i added my fixes from above... i think it was the ftnapps repo on sourceforge...

[time passes]

yes, my last update was jamnntpd-1.2.tar.gz from ftnapps at
sourceforge... IIRC, that's RJ Clay's repo... he is the Region 11 Coordinator in fidonet...

[/time passes]

So umm.. that doesn't mesh... I was told the eljaco.se is the site to get the code...

So which is it??????

there is no "only MAGIC WORKING version" AFAIK... they all work...

Seems to be for CM II... and it seems that the source of the CM II issues are from the source for this 1.3, correct?

now why would you do that? destroying someone else's hard work and
effort? that's going to upset folks if you cause their repo and folks

Simple.... all the bad code for CM II and JamNNTPd and TinyTIC needs to be expunged and removed!

Why? See this discussion....

Seems to me the tune has changed and that the eljaco.se code is not that golden for JamNNTPd.

So which is it????



Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

* Replying to a msg in PERSONAL_MESSAGES (Personal Messages)


Hello Nicholas!

03 Nov 16 13:06, you wrote to me:

That's nowhere near what I said. :(

I asked for the current good code for JamNNTPd, I got a message back, link posted....

The link is for the eljaco.se site...

So this code is not the good code???

I asked for this and a simple, and the reply received stated was link posted already.

So is that not correct???

Seems the tune on this has changed...


Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

Hello Nicholas!

03 Nov 16 13:11, you wrote to mark lewis:

Habitual complainer, maybe?

It probably IS indeed up to snuff.

It either IS or IS NOT?

Which is it???

His lack of inspiration and

Lets see I wasted my free time to prove a point.. that NONE of the code in any of the sources is viable.

I did that!

NONE of it is viable.. INCLUDEING the source provided in the cm071linux.zip.

It might compile.. but it bombs on execution causing a seg fault.

If it were not for the *PRE-COMPILED* *binaries* in that zip.. it would still be an issue and that means moving on to the next part of this setting up JamNNTPd would either still be on hold or dead, possibly..

Since the *PRE-COMPILED* *binaries* in the zip work, then moving on to JamNNTPd is not possible.

absolute refusal to try to compile anything is holding him back from

See above! Compiling rarely works! Even the code in the cm071linux.zip doesn't work. YES it COMPILES, but a running it seg fault, core dump.

actually testing what's "currently" there for general use.

Testing is something I do a lot of....testing in re compiling, nope.

Lets say that we want to use nginx instead of Apache, not going to happen ever, but lets just use them as an example...

VM(s) would be setup to test nginx with the various things we do including .htaccess, and other modules for web...

How would this testing start...

Take seup the VM with ubuntu server 14.0.4.5 and then

sudo apt-get install nginx

Then go in modify the config for some test sites... etc..

It seems as though he's just going to continue to complain and blame everyone else for his system not working as he expects it to.

I am not blaming any one. I will say that in MY OPINION.. a lot of this could have been resolved with:

Hey, grab cm071linux.zip at eljaco.se and then unzip it, and in the bin dir, there are pre-compiled binaries that work.

Simple....

My reply would have been " Great, thanks... tested. works." Problem solved.

What I got was, get the source compile it yourself!

Well lets review my logs...

The source in various places, namely a certain SF site, is crap! And contains the same error(s) that cause what ever fault that produces the "Error reading Jam ..." Actually I have a good idea as to the issue, but I am keeping my hunch to myself right now.. I have a reason.

This SAME SOURCE has some JamNNTPd code that was modified 9/10/2016 and since the CM II source there is fubar'd and it is using what ever lib to access the JAM base then it probably is fubar'd too, and thus will cause issue with the JAM base for CM II AND JamNNTPd.

I asked in an attempt to cut off the repeat of this with JamNNTPd.. Which is the CORRECT CODE BASE..What I got again could have been as simple as:

The SF site has a VALID CODE BASE, with no errors or corruption to the Jam base...working good here on MegaLinux 1.2 64b....

I have a plan to make all of this a lot, whole, no ASTOUNDINGLY A LOT SIMPLER for any one in the future...

DEB Repo with these in it.. to install! No compiling!

AMD64, and hopefully ARMHF for the Pi's... Have to see on that one.. I am amazed that those binaries run on an AMD64 system, since for some reason alot of stuff is still compiled only against 32b.

I also have a plan to fix something with JamNNTPd since using thunderturkey to access it on my end is not viable, and on Linux that is not the mainline NNTP client, and JamNNTPd doesn't work with it, right now.

With a working CM II at least I can move on to the next part of my setup.. I can turn up the final version of the server that will host this, and some of the other plans I have for it...

Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

On Fri, 4 Nov 2016 02:04:40 -0400, Rick Christian wrote:

Since the *PRE-COMPILED* *binaries* in the zip work, then moving on to JamNNTPd is not possible.

Rick, run this command on your crashmail or jamnntpd binary and post
what you get:

file /usr/sbin/jamnntpd

..../jamnntpd: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD
10.3, not stripped

---
* Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)

03 Nov 16 13:07, you wrote to me:

I am contacting sourceforge as I type to have that removed so
this will shut down another avenue of bad sources of this
software.

What the fuck are you talking about?? There is nothing wrong with
any files at

https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/

If you disagree, just show us some proof!

I know for a fact you've been paying attention to every other echo he
has started some kind of argument in (ie: BINKD, GOLDED, and now this one). He seems to be basing his opinions on precompiled binaries that
are years old, rather than actually taking a little less time
complaining, and more time with the ole "trial and error" method of actually trying to compile the software himself, which he has already stated he absolutely will not do.

Either way, not our fault. Others have tried to help him and even
direct him to working binaries, only to receive an argument out of it because he himself could not get it working.

I'm over it, and soon you will be too! :)

Yep. ;)

Nick

'Tommi

---
* Origin: Point One. Ylöjärvi, Finland. (2:221/6.1)

Hello mark,

On 03 Nov 16 20:48, mark lewis wrote to Nicholas Boel:

the main thing that strikes me in all of this is that fidonet is and always has been a hobby network for those wanting to experiment with

This is the main point of your entire reply, in my opinion. New people come in with the expectation that everything should be handed to them in working order. They do not realize that sysops have always done this as a hobby, as well as all the headaches that can come with it.

Sometimes you just need to do things yourself and make it work. :)

Regards,
Nick

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

Hello Rick,

On 03 Nov 16 20:20, Rick Christian wrote to Tommi Koivula:

03 Nov 16 16:29, you wrote to me:

What the fuck are you talking about?? There is nothing wrong with
any files at

https://sourceforge.net/projects/jamnntpd.ftnapps.p/files/

If you disagree, just show us some proof!

Per the replies *here*! The eljaco.se is the GOLDEN CODE per several replies.... it contains both CM II and JamNNTPd code.

You did not ask for the GOLDEN CODE. You asked for a working version.

I asked to be informed which is the CURRENT GOLD VERSION of the
*JamNNTPd code*, so as not to repeat the fiasco with CM II...

There is no CURRENT GOLD VERSION. You either go with a /working/ binary, or compile the code yourself. You were pointed to a place you could get a working binary from.

I was told paraphrase..." link already posted.." That is the eljaco.se
site...so thus that is the GOLDEN SOURCE.

No. The GOLDEN SOURCE is current source code you can compile yourself. You apparantly don't want to compile yourself, so you were pointed to one of the locations you could get a working binary from.

Anything else needs to be removed!

Maybe in your mind.

Seems now that is not the tune...

So for JamNNTPd what source is workds to be downloaded and used???

Wherever you want to get it from. There is no GOLDEN PALACE of goodies for BBS and FTN related stuff.

eljaco.se

OR

Some place else????

Again, I asked this, and was told, "link posted." paraphrased.

You seem to have a one track mind.

Regards,
Nick

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

Hello Rick,

On 03 Nov 16 20:42, Rick Christian wrote to Nicholas Boel:

I am want the corret version that works, and will not corrup the
JAM base files etc...

I believe Björn has already given you a link for that, almost a
week ago?

Did it not give you a binary that works?

Still doesn't mean it's the only place, and definitely not the current code.. just like we went through this with binkd and crashmail II with you.

Regards,
Nick

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

Hello Rick,

On 03 Nov 16 20:51, Rick Christian wrote to Nicholas Boel:

That's nowhere near what I said. :(

I asked for the current good code for JamNNTPd, I got a message back,
link posted....

No, you didn't. You asked for a WORKING VERSION that didn't corrupt your JAM bases.

The link is for the eljaco.se site...

That was one site that was offered to you, multiple times.

So this code is not the good code???

It is a link to a binary you wished to try out in hopes it would not corrupt your JAM bases. We solved that issue for you.

I asked for this and a simple, and the reply received stated was link posted already.

So is that not correct???

Seems the tune on this has changed...

Absolutely not. The only tune that has changed is your own. If you want current code, get it and compile it yourself from sourceforge/ftnapps. We gave you a link to a working compiled binary, that is all. You're making a mountain out of a mole hill here.

Regards,
Nick

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

Hello Rick,

On 03 Nov 16 21:04, Rick Christian wrote to Nicholas Boel:

Habitual complainer, maybe?

It probably IS indeed up to snuff.

It either IS or IS NOT?

Which is it???

You tell me! Did you try it? Or are you waiting for someone else to do it for you?

His lack of inspiration and

Lets see I wasted my free time to prove a point.. that NONE of the
code in any of the sources is viable.

You haven't proven anything, except that you're hard headed and not willing to learn. Your way or the highway, right?

NONE of it is viable.. INCLUDEING the source provided in the cm071linux.zip.

It might compile.. but it bombs on execution causing a seg fault.

If it does that for you, and nobody else.. do you still blame the code?

Testing is something I do a lot of....testing in re compiling, nope.

Exactly my point.

Lets say that we want to use nginx instead of Apache, not going to
happen ever, but lets just use them as an example...

VM(s) would be setup to test nginx with the various things we do
including .htaccess, and other modules for web...

How would this testing start...

Take seup the VM with ubuntu server 14.0.4.5 and then

sudo apt-get install nginx

Then go in modify the config for some test sites... etc..

apt-get/aptitude is not the end-all-be-all in the Linux world. Sorry to burst your bubble.

I have a plan to make all of this a lot, whole, no ASTOUNDINGLY A LOT SIMPLER for any one in the future...

We'll see.

DEB Repo with these in it.. to install! No compiling!

Not everyone uses Debian or any *buntu flavor. So while it may help some, it definitely won't help all.

AMD64, and hopefully ARMHF for the Pi's... Have to see on that one.. I
am amazed that those binaries run on an AMD64 system, since for some reason alot of stuff is still compiled only against 32b.

As long as multilib is enabled, 32 bit compiles have always worked fine on 64 bit systems.

I also have a plan to fix something with JamNNTPd since using thunderturkey to access it on my end is not viable, and on Linux that
is not the mainline NNTP client, and JamNNTPd doesn't work with it,
right now.

That has to do with thunderbird changing something on their end in the latest versions. This would be something someone would probably have to fix and compile themselves. If you're up to the task, by all means go for it.

With a working CM II at least I can move on to the next part of my
setup.. I can turn up the final version of the server that will host
this, and some of the other plans I have for it...

Good luck.

Regards,
Nick

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

03 Nov 16 20:20, you wrote to Tommi Koivula:

I asked to be informed which is the CURRENT GOLD VERSION of the
*JamNNTPd code*, so as not to repeat the fiasco with CM II...

I was told paraphrase..." link already posted.." That is the eljaco.se site...so thus that is the GOLDEN SOURCE.

Anything else needs to be removed!

no, it does not... versions in repos are either different releases or development code bases... they do not need to be removed... especially if they are still being worked on... i know that jame is still working on the stuff at ftnapps...

Seems now that is not the tune...

So for JamNNTPd what source is workds to be downloaded and used???

eljaco.se

OR

Some place else????

Again, I asked this, and was told, "link posted." paraphrased.

that is one of the code bases... it does not have all of the latest fixes and enhancements that some of us have added to our copies... you can take that one and follow the bread crumbs to add the parts that have been adjusted since then or you can start with 1.2 like i did and add the fixes from there... i haven't looked at 1.3 so i don't know what fixes have been added to it from 1.2... if/when i go to 1.3, i'll just compare the code with my 1.21.b9/wpusa code and see what needs to be added or changed there... then i'll compile and test it and assign it another of my personal version numbers at that time if it works as desired...

BTW: i responded to your issue #6 at the ftnapps repo... i read over the RFC and i don't think that your simple fix will work... mainly because JAMNNTPd is not a mode switching NNTP server... your news clients would know this if they used the CAPABILITIES request as noted in the RFC... anyway, just thought i'd let you know that i did consider the request and was going to add it to my code base for testing but not without further study of the RFC and consulting with others in this echo that have a better understanding than i...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Heck that's more fun than exploding a potato in the microwave. -Calvin
---
* Origin: (1:3634/12.73)

03 Nov 16 20:20, you wrote to me:

So for JamNNTPd what source is workds to be downloaded and used???

File request JMNTPD13.ZIP from 2:221/360. Binaries included!! :D

'Tommi

---
* Origin: p1.f1.n221.z2.dyn.binkp.net (2:221/1.1)

Hello mark!

03 Nov 16 20:48, you wrote to Nicholas Boel:

the main thing that strikes me in all of this is that fidonet is and always has been a hobby network for those wanting to experiment with

You, others, and I are ovbiously in this for a far different reasons!

Even in the 90's when I started originally..

I don't think of this as mainly a hobby.

And NO WAY is this an "experiment!" This is a means to a goal.

Example:

Echos are essentially "support groups" or maybe discussion groups for a topic be it software, golded, binkd, jamnntpd, crashmail.....etc...

They exist to *help* others get things going or resolve a problem.. at least thats the goal, as *I* see it...

Then as now, I operated my node to get access to those echos primarily, and to send emails all over the place via FTN tech... I later setup a UUCP gate for emails from the local net to go out via my UUCP account. I setup and maintained a private FTN net to get a very old niche group into the at the time cutting edge stuff. That group doesn't exist... run over by ... nevermind.. suffice it .. run over by the web....

I prefer echos v. web forums.. I am just not into that...never was.. part of some of the things I do right now via some Yahoo things are going to move to FTN based stuff, or more aptly RETURN to it. As I know VZW will start chopping off the dead wood, and this is definitely one of them.

store-and-forward networking... i really have to wonder, sometimes, if some folks just don't know that or if they may have lost that
vision... this especially pertains to some of our Z2 brethern who are

I don't know what the issue or schizim is with Z2 and/or others v. Z1.. and honeslty I don't care.... but what I do see is that in this there is the same issue..as here.

Simply, you, others and I are on different ends of the spectrum of things.. I am not here to exeriment, and this aint no hobby!

If that is how you view it, then that is your take...

Just as many things have an impact on how I view compiling.... and bluntly this fiasco has done nothing to change, but only enhance my ill view of it! And since the resolution to this was to use *PRE-COMPILED* binaries anyway... I think that speaks volumes enough.


Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

Hello Matt!

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

file /usr/sbin/jamnntpd

Mine is not installed that way... right now I have the CM II 0.71 in its own directory still.

I only use 64b.... thats why I referred to this as interesting that it worked, since I knew it was compiled as 32b.. a LOT of stuff like that doesn't work!

ec9140@fidodev:~/cmzip/crashmail-0.71/bin$ ls -la
total 376
drwxr-xr-x 2 rec9140 rec9140 4096 Oct 31 19:57 .
drwxr-xr-x 6 rec9140 rec9140 4096 Jul 10 2004 ..
-rwxr-xr-x 1 rec9140 rec9140 19476 Jul 10 2004 crashexport
-rwxr-xr-x 1 rec9140 rec9140 15768 Jul 10 2004 crashgetnode
-rwxr-xr-x 1 rec9140 rec9140 18464 Jul 10 2004 crashlist
-rwxr-xr-x 1 rec9140 rec9140 22272 Jul 10 2004 crashlistout
-rwxr-xr-x 1 rec9140 rec9140 205044 Jul 10 2004 crashmail
-rwxr-xr-x 1 rec9140 rec9140 38052 Jul 10 2004 crashmaint
-rwxr-xr-x 1 rec9140 rec9140 22164 Jul 10 2004 crashstats
-rwxr-xr-x 1 rec9140 rec9140 18516 Jul 10 2004 crashwrite rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ file ./crashmail
./crashmail: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ uname -a
Linux fidodev 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
rec9140@fidodev:~/cmzip/crashmail-0.71/bin$


Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

On Fri, 4 Nov 2016 18:57:48 -0400, Rick Christian wrote:

Mine is not installed that way... right now I have the CM II 0.71 in

its

own directory still.

I only use 64b.... thats why I referred to this as interesting that it worked, since I knew it was compiled as 32b.. a LOT of stuff like that doesn't work!

ec9140@fidodev:~/cmzip/crashmail-0.71/bin$ ls -la
total 376
drwxr-xr-x 2 rec9140 rec9140 4096 Oct 31 19:57 .
drwxr-xr-x 6 rec9140 rec9140 4096 Jul 10 2004 ..
-rwxr-xr-x 1 rec9140 rec9140 19476 Jul 10 2004 crashexport
-rwxr-xr-x 1 rec9140 rec9140 15768 Jul 10 2004 crashgetnode
-rwxr-xr-x 1 rec9140 rec9140 18464 Jul 10 2004 crashlist
-rwxr-xr-x 1 rec9140 rec9140 22272 Jul 10 2004 crashlistout
-rwxr-xr-x 1 rec9140 rec9140 205044 Jul 10 2004 crashmail
-rwxr-xr-x 1 rec9140 rec9140 38052 Jul 10 2004 crashmaint
-rwxr-xr-x 1 rec9140 rec9140 22164 Jul 10 2004 crashstats
-rwxr-xr-x 1 rec9140 rec9140 18516 Jul 10 2004 crashwrite rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ file ./crashmail
/crashmail: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ uname -a
Linux fidodev 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13
01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux rec9140@fidodev:~/cmzip/crashmail-0.71/bin$

\
Your crashmail binary appears to be 32bit. What about the jamnntpd
binary you built?

32bit code will run fine there and honestly not a big advantage with
fido technology with 64bit.

---
* Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)

Hello Nicholas!

04 Nov 16 09:13, you wrote to me:

Absolutely not. The only tune that has changed is your own. If you
want current code, get it and compile it yourself from sourceforge/ftnapps. We gave you a link to a working compiled binary,

This has proven to be INCORRECT! Did that..with the 1.5 and 0.75 versions at that link... Same issue... as you will see what I've been holding as the ace in the hole is..

The code is written in a manner which is works on 32b fine, and when compiled on 64b it COMPILES but causes JAm base corruption.

See recent posts here..

See I've been holding my hole card... as I am with something else...bawahhahaaaa..... :) ;)


Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

Hello mark!

04 Nov 16 11:42, you wrote to me:

BTW: i responded to your issue #6 at the ftnapps repo... i read over
the RFC and i don't think that your simple fix will work... mainly
because JAMNNTPd is not a mode switching NNTP server...

Few NNTP servers are, other than INN, BUT they need to respond to the command as if they were.

They just need to fake out the readers which insist on this before doing anything.

your news
clients would know this if they used the CAPABILITIES request as noted

Ummm.. Just FYI .... JamNNTPD does NOT RESPOND to this!

~$ telnet news.wpusa.dynip.com 119
Trying 40.136.244.87...
Connected to news.wpusa.dynip.com.
Escape character is '^]'.
200 Welcome to JamNNTPd/OS2 1.21.b9/wpusa (posting may or may not be allowed, try your luck)
CAPABILITIES
500 Unknown command
CAPABILITIES
500 Unknown command

Based on https://tools.ietf.org/html/rfc3977

in the RFC... anyway, just thought i'd let you know that i did
consider the request and was going to add it to my code base for

Per the RFC and several sources... for reference: https://tools.ietf.org/html/rfc3977

An NNTP server when it gets MODE READER, should respond:

200 some text

So

200 Welcome to JamNNTPd/OS2 1.21.b9/wpusa (posting may or may not be allowed, try your luck)

Seems to be a good way to "*fake*" out PAN and KNode which issue this command before doing anything else like LIST to get a list of the groups.

testing but not without further study of the RFC and consulting with others in this echo that have a better understanding than i...

*I* will know soon enough...

Rick


--- GoldED+/LNX 1.1.5-b20160322
* Origin: Vina's Talos Moon Base Alpha (1:135/377)

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

BTW: i responded to your issue #6 at the ftnapps repo... i read over
the RFC and i don't think that your simple fix will work... mainly
because JAMNNTPd is not a mode switching NNTP server...

Few NNTP servers are, other than INN, BUT they need to respond to the command as if they were.

no sir, they do not... read the RFC... not just parts of it... the whole thing... that's an elephant, not a pillar, a rope, a tree branch, a hand fan, a wall, or a solid pipe...

They just need to fake out the readers which insist on this before
doing anything.

no... those clients are not implemented correctly... they should not attempt "MODE READER" unless the server shows "MODE-READER" capability... this because the server literally has to switch modes and disallow certain other commands when in "MODE READER" mode... "IHAVE" is one that i remember needing to be specifically disallowed but jamnntpd doesn't support that anyway althought its message would have to be changed when in "MODE READER" mode IF it is even implemented...

your news clients would know this if they used the CAPABILITIES
request as noted

Ummm.. Just FYI .... JamNNTPD does NOT RESPOND to this!

of course not! it is not a mode switching server ;)

~$ telnet news.wpusa.dynip.com 119
Trying 40.136.244.87...
Connected to news.wpusa.dynip.com.
Escape character is '^]'.
200 Welcome to JamNNTPd/OS2 1.21.b9/wpusa (posting may or may not be allowed, try your luck) CAPABILITIES 500 Unknown command CAPABILITIES 500 Unknown command

that right there is enough to tell the client that "MODE READER" is not supported and it should just use traditional methods of getting the articles... even "HELP" would be enough to tell that the "CAPABILITIES" command is not available...

Based on https://tools.ietf.org/html/rfc3977

in the RFC... anyway, just thought i'd let you know that i did
consider the request and was going to add it to my code base for

Per the RFC and several sources... for reference: https://tools.ietf.org/html/rfc3977

i already read that and referenced it in my response on SF... you should also read the whole RFC and not just pick out parts that suit some purpose... other parts may be required as well before even getting to that point... unfortunately we also see that problem with FTSC standards... folks not reading everything or taking shortcuts instead of following the entire path... that elephant thing again...

An NNTP server when it gets MODE READER, should respond:

200 some text

So

200 Welcome to JamNNTPd/OS2 1.21.b9/wpusa (posting may or may not be allowed, try your luck)

Seems to be a good way to "*fake*" out PAN and KNode which issue this command before doing anything else like LIST to get a list of the
groups.

screw /faking out/ anything... "fix yer shit!" as we used to say... PAN has not implemented "MODE READER" properly from what i've seen and read in the RFC... PAN should check if "MODE READER" is even available *before* attempting to use it... if it isn't available it should not even attempt to use that mode and PAN should fall back to the standard methods... this goes with KNode or whatever the other one was you tried to use...

plus, the above welcome message has already been sent on connection... IF "MODE READER" is implemented, the response should be something other than the welcome text again... perhaps

200 Reader mode engaged.

or

200 MODE READER enabled.

posting or not is something else and allowed on a per area as well as a per user basis... users can be prohibited from posting in areas where other users are allowed to post on the same server... it doesn't need to be restated... it might even be fun to do it with some snark :laugh:

testing but not without further study of the RFC and consulting with
others in this echo that have a better understanding than i...

*I* will know soon enough...

more power to you but just remember, this is a hobby and abuse doesn't win friends or result in problems being fixed with any speed ;)

)\/(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'm too sexy for this conference...
---
* Origin: (1:3634/12.73)

Hello Matt!

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

\
Your crashmail binary appears to be 32bit.

*I* did *NOT* build this one... it is the *PRE-COMPILED* binary that comes in that cm071linux.zip at the http://eljaco.se site.

I am surprised it runs on 64b at all... since normally there is something that doesn't work there..

What about the jamnntpd
binary you built?

I *HAVE NOT* and *WILL NOT* build jamNNTPd till I resolve which source or precompiled binary or DEB provides a version that works on *64b* with out ruining the JAM base files.

That is why I asked about the source to use.. as I don't/didn't want to repeath this whole fiasco again...There just seems to be too many versions floating around.

32bit code will run fine there and honestly not a big advantage with

Not always.. there seems to be issues v. arch in some cases.. where the 32b binaries won't run... probably has to do with the shared libs...

And while this thing is using shared libs, it appears that it INCLUDES all the libs in the source and thus really just compiles them in... Above my code base level...

Not a C monkey, and really not interested in becoming one or a gcc one or make one.

fido technology with 64bit.

Yeah, probably true, but I only have 64b systems for most stuff.. The few 32b only stuff I have is dedicated to other resources... maybe if some other clunker comes along..

And having some source which works so that that this can be compiled on ARMHF for Pi's would be good.... I think they have this in the Pi Raspbian repo, but since the Pi's are still 32b it may not matter.... I've not decided if I am putting all this on a Pi or on one of my VPS setups in the DC yet...for now it can reside on my internal VM setup..

Whats interesting is this:

https://github.com/larsks/crashmail

This is a fork of Johan Billing's CrashMail II distribution. Major changes in this fork include:

Support for 64-bit operating (POSIX) operating systems.

Unfortuntaely from a post in Sept. seems this author too has abandoned it...might be interesting to see what it does...but play time is over right now.

Thanks for the info... I will look at some of this when I have some time.....

Have to get back to rea life and put the toys away.... :) ;)


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)

Hello Rick,

On 04 Nov 16 14:08, Rick Christian wrote to Nicholas Boel:

Absolutely not. The only tune that has changed is your own. If
you want current code, get it and compile it yourself from
sourceforge/ftnapps. We gave you a link to a working compiled
binary,

This has proven to be INCORRECT! Did that..with the 1.5 and 0.75
versions at that link... Same issue... as you will see what I've been holding as the ace in the hole is..

We never gave you a link to 1.5 or 0.75. You found those on your own after we gave you a link to 0.71, and told you it was the last version released by the original developer.

Regards,
Nick

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

05 Nov 16 09:05, you wrote to Matt Bedynek:

Your crashmail binary appears to be 32bit.

*I* did *NOT* build this one... it is the *PRE-COMPILED* binary that comes in that cm071linux.zip at the http://eljaco.se site.

I am surprised it runs on 64b at all... since normally there is something that doesn't work there..

apparently you have the multi-arch stuff installed... that's the only way to be able to run 32bit on 64bit unless they are built static instead of dynamic... IIRC, paul's build of crashmail 0.71 is built static... file will tell you that if you haven't looked already...

[trim]

Not a C monkey, and really not interested in becoming one or a gcc one
or make one.

i'm not one of those monkeys either... never have been but i can mostly muddle my way through when necessary... like when i fixed a couple of bugs and added some features to my private build...

fido technology with 64bit.

Yeah, probably true, but I only have 64b systems for most stuff.. The
few 32b only stuff I have is dedicated to other resources... maybe if
some other clunker comes along..

who needs a real iron clunker when one can run a VM? ;)

And having some source which works so that that this can be compiled
on ARMHF for Pi's would be good.... I think they have this in the Pi Raspbian repo, but since the Pi's are still 32b it may not matter....
I've not decided if I am putting all this on a Pi or on one of my VPS setups in the DC yet...for now it can reside on my internal VM setup..

i'd be really surprised if these packages can be compiled on ARM systems... especially jamnntpd since there's only linux, os2 and win32 headers...

Whats interesting is this:

https://github.com/larsks/crashmail

This is a fork of Johan Billing's CrashMail II distribution. Major
changes in this fork include:

Support for 64-bit operating (POSIX) operating systems.

Unfortuntaely from a post in Sept. seems this author too has abandoned it...might be interesting to see what it does...but play time is over right now.

i'd be concerned about the switching from unsigned variables to signed ones...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Some women are terribly hard to please . . . the rest are impossible!
---
* Origin: (1:3634/12.73)

Hi! mark,

On 11/06/2016 12:56 AM, you wrote to Rick Christian:

apparently you have the multi-arch stuff installed... that's the only
way to be able to run 32bit on 64bit unless they are built static
instead of dynamic... IIRC, paul's build of crashmail 0.71 is built static... file will tell you that if you haven't looked already...

By the numbers, per the dox: it turns out 'dynamic', and slightly smaller than the original binary (~4k). (The last time I was a C genius was 1996 using TurboC, at a tech college.) I did the compiles per the idiot sheet in the CM package; i.e. no inventiveness on my part.

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)

Hello mark!

05 Nov 16 10:56, you wrote to me:

apparently you have the multi-arch stuff installed... that's the only
way to be able to run 32bit on 64bit unless they are built static

I don't think those are included by default any more in *buntu...I think they got nuked 11.x or possibly before the 12.04 ESR

Yepppers, pre 12.04 they nuked IA-32 libs for this:

https://wiki.ubuntu.com/MultiarchSpec

I didn't and don't follow that.. I know there is stuff that didn't like that...and stuff that will not work on 64b as its 32b and it spits out ELF errors.

Maybe that got resolved in 14.04.. as I only use the ESR's... so 10.04, 12.04, 14.04... other stuff I will test with, ie: see how they borq up my KDE etc..

Like I said I didn't follow it, I just sudo apt-get and obviously its going to pull AMD64 stuff since I am a 64b system...

instead of dynamic... IIRC, paul's build of crashmail 0.71 is built static... file will tell you that if you haven't looked already...

ummm...$ file ~/crashmail-0.71/bin/crashmail /home/rec9140/crashmail-0.71/bin/crashmail: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=27de05981b233984f8ca78c8af4a3d4113d0bd2b, stripped


This shows *dynamically linked (uses shared libs),*


Guess that is 64b, which is why it runs.. as its "ELF 64-bit LSB" ... I don't now... too many things I've looked at...

i'm not one of those monkeys either... never have been but i can
mostly muddle my way through when necessary... like when i fixed a
couple of bugs and added some features to my private build...

Well unfortunately I know a lot, A LOT more C than I care to admit.. simply because of lot of things I'd rather not remember....

I am looking as posted in ehco and the bug report to "fake out" PAN and KNode to work with JamNNTPd.. but I need to make sure I've resolved any potential of this nonsense in re the corruption of JAM bases because of the 32b v. 64b issues..

Thats the point in asking is the SF site and 1.3 good??? No, its flawed like post 071 CM II's or if the resolution of an option to force m32 solves this.. or only the code form the eljaco.se site should be messed with???

I've put several ideas on faking out PAN/KNode... I just need to find a decent c interpreter to play with... its not a project I want to take on, but I am forced to.. as using thunderturkey just crankles me to no end....

who needs a real iron clunker when one can run a VM? ;)

Unfortunately you can't virtualize SDR sticks or Line in's for audio.. so real hardware at times is what it takes....

Plus I dislike throwing out perfectly working hardware that might need a little TLC to upgrde a CPU, max out some RAM or a bigger HD.. and then turn it into a VM host for somethings, or run LXC containers, or VPN server or .....

But for the RTL-SDR stuff and some other stuff I am invoved in, I need hardware to plug it into.. SDR doesn't work good, no at all under VMWare, and it has much better USB support than the love child of the Linux crowd.. thats why VMWare is my goto VM for anything production.. test and play with any thing from VMW to LXC..

i'd be really surprised if these packages can be compiled on ARM systems... especially jamnntpd since there's only linux, os2 and win32 headers...

ARMHF for the PI's probably is not a problem as the Pi's are still using 32b.. the Pi3 is or can be 64b, but Raspbian or something was not set up that way.. or.. I didn't keep up with it... Raspbian has issues in re Jessie and systemd.... justlike post 14.x *buntus...

I'd have to find some spare PI's first.. these get gobbled up for projects quick!

i'd be concerned about the switching from unsigned variables to signed ones...

I don't know.. what was changed... I just know I found it interesting that it showed up, and was/is/possibly a result of this whole mess with what ever happened past the 071 version.. based on that 64b support... I didn't go any further than bookmark it... for later review... its just something thats out there...but dormant too.


Rick


... Vote Trump 2016 and Make America Great Again!
SEEN-BY: 124/5016 154/10 203/0 280/464 5006 5555 640/1384 2320/100 5019/40 SEEN-BY: 5075/35

05 Nov 16 17:56, you wrote to me:

instead of dynamic... IIRC, paul's build of crashmail 0.71 is built
static... file will tell you that if you haven't looked already...

ummm...$ file ~/crashmail-0.71/bin/crashmail /home/rec9140/crashmail-0.71/bin/crashmail: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=27de05981b233984f8ca78c8af4a3d4113d0bd2b, stripped

This shows *dynamically linked (uses shared libs),*

i thought i had seen him say that he compiled something static... oh well... i didn't go hunting for that post in my bases...

Guess that is 64b, which is why it runs.. as its "ELF 64-bit LSB" ...
I don't now... too many things I've looked at...

yes, that's what it says above... i guess you'll know in time if that ace up your sleeve was really the ace you thought it was...

i'm not one of those monkeys either... never have been but i can
mostly muddle my way through when necessary... like when i fixed a
couple of bugs and added some features to my private build...

Well unfortunately I know a lot, A LOT more C than I care to admit.. simply because of lot of things I'd rather not remember....

;)

I am looking as posted in ehco and the bug report to "fake out" PAN
and KNode to work with JamNNTPd.. but I need to make sure I've
resolved any potential of this nonsense in re the corruption of JAM
bases because of the 32b v. 64b issues..

do we even know if it was an alignement problem yet? no... all we know is that you were seeing corruption but there's been no detailed analysis of the data files AFAIK... "detailed analysis" as in studying them under a hex viewer or similar...

Thats the point in asking is the SF site and 1.3 good??? No, its
flawed like post 071 CM II's or if the resolution of an option to
force m32 solves this.. or only the code form the eljaco.se site
should be messed with???

i've already stated that i'm running a modified 32bit 1.2 compile over here on my main system... the one you were using... my main system is/was a beta site for JAM when it was first introduced... if there's corruption i definitely know about it... especially with retaining posts for as long as i do...

I've put several ideas on faking out PAN/KNode... I just need to find
a decent c interpreter to play with... its not a project I want to
take on, but I am forced to.. as using thunderturkey just crankles me
to no end....

i've used pine, slrn, and similar with no problems... i've never tried knode or pan... don't intend to, either... i'm trying to remember the python one i used that allowed me to find and fix a bug or two... ahhh... XPN 1.2.6...

who needs a real iron clunker when one can run a VM? ;)

Unfortunately you can't virtualize SDR sticks or Line in's for audio.. so real hardware at times is what it takes....

who needs an sdr or sound card on a fidonet system?

Plus I dislike throwing out perfectly working hardware that might need
a little TLC to upgrde a CPU, max out some RAM or a bigger HD.. and
then turn it into a VM host for somethings, or run LXC containers, or
VPN server or .....

But for the RTL-SDR stuff and some other stuff I am invoved in, I need hardware to plug it into.. SDR doesn't work good, no at all under VMWare,

yech... have you tried QEMU/KVM? that's all i use...

and it has much better USB support than the love child of the Linux crowd.. thats why VMWare is my goto VM for anything production.. test
and play with any thing from VMW to LXC..

oh well :shrug:

i'd be really surprised if these packages can be compiled on ARM
systems... especially jamnntpd since there's only linux, os2 and
win32 headers...

ARMHF for the PI's probably is not a problem as the Pi's are still
using 32b.. the Pi3 is or can be 64b, but Raspbian or something was
not set up that way.. or.. I didn't keep up with it... Raspbian has
issues in re Jessie and systemd.... justlike post 14.x *buntus...

i understand that they're using a 32bit OS only because there's only 1Gig of RAM on the things... i've thought about getting one to play with but 1Gig is not enough for the projects i have in mind... 2Gig is just barely adequate...

I'd have to find some spare PI's first.. these get gobbled up for
projects quick!

:lol:

i'd be concerned about the switching from unsigned variables to
signed ones...

I don't know.. what was changed...

i specifically looked and read the diff...

I just know I found it interesting that it showed up, and
was/is/possibly a result of this whole mess with what ever happened
past the 071 version.. based on that 64b support... I didn't go any further than bookmark it... for later review... its just something
thats out there...but dormant too.

there's a lot out there... quite a few people have repos where they are working on the code and then contributing their work back to a central repo... that's why your stupid comment about having 1.3 removed from SF was well... stupid... and people let you know about it... you don't go taking someone else's hard work away like that when you don't know the condition or even why it is like it is... there are choices in life and using ancient broken binaries from some distribution's repo or pulling newer sources from another repo and compiling yourself is just part of the linux world... apparently you've been sheltered in that respect... that's not a bad thing but it sure is a wake up call, as you've found out, when you step off into other worlds that are definitely hobbiest oriented... welcome to the club! maybe you can help in getting some other things updated and fixed but the first step is seeing the land for what it really is ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Law of Combat: No inspection-ready unit has ever passed combat.
---
* Origin: (1:3634/12.73)