Lars,

06 Feb 13 22:48, you wrote to all:

There's also a packaged based on Johan Billing's CrashMail II tosser/scanner, but that appears to be a little buggy.

There are some fixes for Crashmail II in the Debian package (which I am now the maintainer for); some fixes for 64 bit issues as well as a fix for a build issue on GNU/kFreeBSD. I've been thinking of ways to make at least those fixes more generally available, plus there are the build warnings to take care of...



Jame

--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

There are some fixes for Crashmail II in the Debian package (which
I am now
the maintainer for); some fixes for 64 bit issues as well as a fix
for a build
issue on GNU/kFreeBSD. I've been thinking of ways to make at least
those fixes
more generally available, plus there are the build warnings to take
care of...

Oh, I have ripped the old build system to shreds and replaced just about all of
it. There's now a much more standard suite of Makefiles that should be much easier to maintain, as well as an "install" target. You can find all my changes at:

http://github.com/larsks/crashmail

None of these changes are distribution specific. At the moment I'm simply suppressing the build warnings (with -Wno-pointer-sign).

These changes have made my life as a packager substantially easier.

--- Msged/LNX 6.1.2
* Origin: Husky (1:322/761)

I've integrated most of the fixes from your package. I've also added a simple test suite (using roundup, http://bmizerany.github.com/roundup/), which turned up another integer-size-bug in crashwrite.c (which would generate invalid packet filenames on 64bit systems).

--- Msged/LNX 6.1.2
* Origin: Husky (1:322/761)

Lars,

07 Feb 13 12:38, you wrote to me:

I've also added a simple test suite (using roundup, http://bmizerany.github.com/roundup/),

That's an unfortunate name; the 'roundup' package is an issue tracker and has been in Debian since 2003...


Jame



--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

Lars,

07 Feb 13 12:38, you wrote to me:

which turned up another integer-size-bug in crashwrite.c (which would generate invalid packet filenames on 64bit systems).

I saw your commit for that; seemed to be a simple enough change...


Jame


--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

Lars,

07 Feb 13 09:04, you wrote to me:

There are some fixes for Crashmail II in the Debian package
(which I am now the maintainer for); some fixes for 64 bit issues
as well as a fix for a build issue on GNU/kFreeBSD. I've been
thinking of ways to make at least those fixes more generally
available, plus there are the build warnings to take care of...

Oh, I have ripped the old build system to shreds and replaced just
about all of it.

Not necessarily a good thing, IMHO, and it should make it interesting for me...<g>
(LDFLAGS?) If I leave what you currently have, (besides any other merge issues) I'd have to patch it or bypass it altogether for Debian/Ubuntu package builds...

There's now a much more standard suite of Makefiles that should be
much easier to maintain,

I'll have to see what you have there when I get the main development caught up (develop branch will be at the SF project, the Alioth project is just for the branches needed for the Debian packaging); and at least there should be plenty of room between the existing 0.71 and the work you've done.<g>

You can find all my changes at:
http://github.com/larsks/crashmail

I'll add a link to that on the two project pages I have for it, & later (like I said, I need to get caught up...<g>) set yours up as a remote for at least your master branch. (I have a GitHub account but since I'm already maintaining code repositories elsewhere, I don't see the point of forking yours instead of just linking to it...)

None of these changes are distribution specific. At the moment I'm
simply suppressing the build warnings (with -Wno-pointer-sign).

Those warnings are one of the main things I wanted to work on (and one of the places I'd currently have to patch for the Debian packaging, changing that "CFLAGS =" line at least to "CFLAGS+="), but I'll have to see when I'll be able to do so. May wait until after I work on getting your changes merged into what I'm working on, though I'm not for sure when I'll have a chance to work on that...





Jame



--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

None of these changes are distribution specific. At the moment I'm simply suppressing the build warnings (with -Wno-pointer-sign).

Those warnings are one of the main things I wanted to work on

I think they're fixed now. Make sure you grab the 'develop' branch from Github.

--- Not like the others.
* Origin: The Odd Bit (1:322/761.1)

Lars,

07 Feb 13 23:56, you wrote to me:

None of these changes are distribution specific. At the

moment I'm simply suppressing the build warnings (with
-Wno-pointer-sign).

Those warnings are one of the main things I wanted to work on

I think they're fixed now. Make sure you grab the 'develop' branch
from Github.

I did, & I also see that you've released another version. (Btw; I can't seem to find any changelog type entries? At least, not in docs/History.txt...)

I think I've figured a way to merge the fixes you did to what I'm working on (not public yet pending clarification by the author of some copyright year information); basically by doing 'git format-patch', manually editing the file path(s), then using 'git am' on the updated patch file. I'll post about how that goes.






Jame

--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

I did, & I also see that you've released another version. (Btw; I can't
seem to find any changelog type entries? At least, not in docs/History.txt...)

Please see the commit logs for information about changes.

With the most recent set of patches, the code now compiles cleanly with '-Wall -Werror' on both 64bit and 32bit systems (and passes the test suite I've added). The 'crashlist' command also understands "Boss" directives in pointlists, which makes them a little easier to maintain.

--- Msged/LNX 6.1.2
* Origin: Default origin (1:322/761)

Lars,

07 Feb 13 19:19, I wrote to you:

07 Feb 13 12:38, you wrote to me:

I've also added a simple test suite (using roundup,
http://bmizerany.github.com/roundup/),

That's an unfortunate name; the 'roundup' package is an issue
tracker and has been in Debian since 2003...

And since Debian is my primary dev platform, that means that using what you're currently useing for testing isn't particularly useful to me or to the packaging... OTOH; you're certianly correct that (as you've already found) it can be quite useful to have a test suite... I'll have to see what's available; perhaps there's something similar to what you're using that I can use...


Jame

--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

And since Debian is my primary dev platform, that means that using what
you're currently useing for testing isn't particularly useful to me
or to the
packaging...

The "roundup" script is included in the package, and since it's just a shell script I suspect you can use it without a problem. Calling it "not useful" seems...wrong? Having a test suite has already flushed out several bugs. If you're aware of another Bourne shell test harness that's as easy to use I'm willing to look at alternatives.

--- Msged/LNX 6.1.2
* Origin: Default origin (1:322/761)

Hi Lars!~

10 Feb 13 11:48, you wrote to me:

And since Debian is my primary dev platform, that means that
using what you're currently useing for testing isn't particularly
useful to me or to the packaging...

The "roundup" script is included in the package, and since it's just a shell script I suspect you can use it without a problem.

I will be looking at that, but my preference would be a least for something that is already available in Debian, if not also available on at least MS Windows. (I'm much more familiar with the testing facilities available to Perl modules and script than I am for the same kind of things for C programs...)

Calling it "not useful" seems...wrong?

Please keep in mind that while I can understand why you went the linux only route with what you're doing, my intention with what I'm working on is to keep it cross platform; even if I can't support all of the platforms directly myself. (For instance; I usually maintain at least one MS Windows VM, but don't have a similar setup for OS/2...) So my preference would be for something usable (if not already available) on all of the platforms.

OTOH; you're certainly correct that a test suite should be available and since 'roundup' is based on a shell script which can be included with the distribution (like you've already done), that means there is no concern about conflicting package names. (Not sure if that would be considered an embedded library, which is frowned upon in Debian, since it's only for testing...) And perhaps I could set a dependency for running the test suite for there being a bourne shell available (it has been ported all over, after all, even though it may not be available by default).

Having a test suite has already flushed out several bugs.

Yes, I saw that (and I like to use similar kind of thing for Perl modules and scripts); which is why I also am interested in having the same kind of thing.

If you're aware of another Bourne shell test harness that's as easy
to use

Not that I've been able to find, so far. Did find something called "cmdtest" ("blackbox testing of Unix command line programs") in Debian but that requires python.





Jame




--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

Lars,

10 Feb 13 11:48, you wrote to me:

.... If you're aware of another Bourne shell test
harness that's as easy to use I'm willing to look at alternatives.

Have you looked at shunit2? (http://code.google.com/p/shunit2/) For me, it has the advantage of already being available in Debian/Ubuntu so I'll be investigating it in any case...

OTOH; it does appear to be larger that what you're currently using, so it might not be as useful to you...



Jame

--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

Have you looked at shunit2? (http://code.google.com/p/shunit2/) For
me, it
has the advantage of already being available in Debian/Ubuntu so I'll be investigating it in any case...

Thanks for the pointer...I'll take a look.

-- Lars

--- Not like the others.
* Origin: The Odd Bit (1:322/761.1)

Lars.

11 Feb 13 10:51, I wrote to you:

Lars,

10 Feb 13 11:48, you wrote to me:

.... If you're aware of another Bourne shell test
harness that's as easy to use I'm willing to look at
alternatives.

Have you looked at shunit2? (http://code.google.com/p/shunit2/)

I may still take a look at that for other projects and if you take a look at it, I'm still interested in what you think; but for crashmail I've merged in what you're using instead. (That turned out to be pretty easy, btw...<g> Excellant work!)

Now, besides keeping up with what you do for testing; I need to try to get caught up with the code fixes you've done...<g>



Jame

--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

Lars,

11 Feb 13 07:51, I wrote to you:

10 Feb 13 11:48, you wrote to me:

The "roundup" script is included in the package, and since it's
just a shell script I suspect you can use it without a problem.

I will be looking at that,

And I did so by merging in your testing framework; with the way you have it set up, it was pretty easy to adapt! (Btw, I still need to know which email address you want as your primary one...)

.... So my preference would be for something usable (if not already available) on all of the platforms.

Because I also want to update the build system, what I plan to do is convert what I'm working on to using CMake as the primary build system. Amongst other things, that includes CTest for a testing framework and I'll be using that.

And perhaps I could set a dependency for running the test suite for
there being a bourne shell available

I plan to do that with the CMake/CTest implementation (when I'm able to get that far...<g>) and also see if that can be done for the current Makefile only implementation... (Right now it just depends on the 'linux' target...)




Jame


--- GoldED+/LNX 1.1.5--b20111217
* Origin: RJC eeePC (1:120/419)

set up, it was pretty easy to adapt! (Btw, I still need to know which email
address you want as your primary one...)

The email address in the README.md would be my preference.

There's a minor new feature in the 'develop' branch right now; crashwrite has been updated to accept an explicit output filename (so you can use it to generate outbound packets from a script). With this plus the filtering that's already available you could implement some interesting auto-responders (e.g., for handling PING requests or something).

I've started putting some of the documentation online here and trying to make it look nice:

https://github.com/larsks/crashmail/wiki

I've also updated History.txt.

Cheers,

-- Lars

--- Msged/LNX 6.1.2
* Origin: Default origin (1:322/761)