mfreq v3.05 for linux

[Markus Reschke]

Hello!

Just wanted to tell you that mfreq v3.05 is released. A brief overview:

mfreq is a suite of tools for FTS style file requesting. It consists of a
file index generator, filelist generator and a SRIF compatible file request
handler.

Features:
- case-sensitive and long filenames
- filenames with spaces
- magics
- ifcico-style magic files
- password protected files
- case-insensitive freqests (if enabled by cfg)
- request limits
- response netmail or text
- dir.bbs and files.bbs
- update of file description files
- multiline support for filelists
- tested with binkd and qico-xe

Available via frequest "MFREQ" from 2:244/1661 :-)

Regards,
Markus

[Rj Clay]

Markus,

25 Jan 13 12:46, you wrote to all:

MR> Just wanted to tell you that mfreq v3.05 is released. A brief
MR> overview:

MR> mfreq is a suite of tools for FTS style file requesting. It consists
MR> of a file index generator, filelist generator and a SRIF compatible
MR> file request handler.

Is anyone packaging it for Debian/Ubuntu, do you know?


Jame

[Markus Reschke]

Hello Rj!

Jan 25 10:14 2013, Rj Clay wrote to Markus Reschke:

MR>> mfreq is a suite of tools for FTS style file requesting. It consists
MR>> of a file index generator, filelist generator and a SRIF compatible
MR>> file request handler.

RC> Is anyone packaging it for Debian/Ubuntu, do you know?

AFAIK, not yet.

Regards,
Markus

[Rj Clay]

Markus,

25 Jan 13 17:24, you wrote to me:

MR> Jan 25 10:14 2013, Rj Clay wrote to Markus Reschke:

MR>>> mfreq is a suite of tools for FTS style file requesting. It
MR>>> consists of a file index generator, filelist generator and a
MR>>> SRIF compatible file request handler.

RC>> Is anyone packaging it for Debian/Ubuntu, do you know?

MR> AFAIK, not yet.


I'll take a look at doing so.

Would I be correct in thinking that there isn't a public code repository?
I use a GIT repository for packaging work (which I usually make public
somewhere if I release the package publically) and like to also have the code
history even if all I'm working on is the packaging.



Jame

[Markus Reschke]

Hello Rj!

Jan 26 04:50 2013, Rj Clay wrote to Markus Reschke:

RC> I'll take a look at doing so.

RC> Would I be correct in thinking that there isn't a public code
RC> repository?

Yes, mfreq isn't in any public repository, just on my local disks.

RC> I use a GIT repository for packaging work (which I usually make
RC> public
RC> somewhere if I release the package publically) and like to also have
RC> the code
RC> history even if all I'm working on is the packaging.

I like to keep things simply for a one-man-project. But with a team a
repository with version control makes a lot of sense.

Regards,
Markus

[Rj Clay]

Markus,

26 Jan 13 16:55, you wrote to me:

MR> Jan 26 04:50 2013, Rj Clay wrote to Markus Reschke:

RC>> I'll take a look at doing so.

RC>> Would I be correct in thinking that there isn't a public code
RC>> repository?

MR> Yes, mfreq isn't in any public repository, just on my local disks.

RC>> I use a GIT repository for packaging work (which I usually make
RC>> public somewhere if I release the package publically) and like to
RC>> also have the code history even if all I'm working on is the
RC>> packaging.

MR> I like to keep things simply for a one-man-project.

One nice thing about using something like GIT is that it's easy to keep a
local code repository, which can then be simply 'pushed' to a public remote
system when you want to do that.


MR> But with a team a repository with version control makes a lot
MR> of sense.

Since it's an FTN app I was figureing to use the FTN Applications project
(ftnapps) at SourceForge; at least to put the GIT repo I started online. Or,
if you're interested, could make it a subproject instead (along with it's own
repo, also it's own wiki, tickets, etc.).

Could discuss this further via email, if you like.


jame
***@gmail.com

[Rj Clay]

Markus.

27 Jan 13 19:27, I wrote to you:

MR>> But with a team a repository with version control makes a lot
MR>> of sense.

RC> Since it's an FTN app I was figureing to use the FTN Applications
RC> project (ftnapps) at SourceForge; at least to put the GIT repo I
RC> started online.

I haven't put that online as yet pending further discussion with you. I'll
be importing your new version and proceeding from there, and I'll also be
checking into the work that Lars has done on mfreq.


RC> Or, if you're interested, could make it a subproject
RC> instead (along with it's own repo, also it's own wiki, tickets, etc.).

RC> Could discuss this further via email, if you like.

Hadn't heard from you yet so I emailed you about it today.



Jame

[Markus Reschke]

Hello Rj!

Feb 20 08:32 2013, Rj Clay wrote to Markus Reschke:

RC>> Could discuss this further via email, if you like.

RC> Hadn't heard from you yet so I emailed you about it today.

Sorry for the late feedback! Got your email and sent a response.

Regards,
Markus

[Benny Pedersen]

Hello Markus!

25 Jan 2013 12:46, Markus Reschke wrote to all:

MR> Available via frequest "MFREQ" from 2:244/1661 :-)

put it in my inbound, and i will create an ebuild for it


Regards Benny

... there can only be one way of life, and it works :)

[Ben Ritchey]

MR> Available via frequest "MFREQ" from 2:244/1661 :-)

If you could send me a copy, I can hatch into Filegate? Send me one anyway?

BinkD: cmech.dynip.com:24555 fidonet


--
Be well :^)

: Ben aka cMech Web: http://cmech.dynip.com:8080
: Home page: http://users.lusfiber.net/~fido4cmech
:
+ WildCat! Board 24/7 [phone] any BAUD 8,N,1

[Markus Reschke]

Hello Ben!

Jan 26 23:39 2013, Ben Ritchey wrote to Markus Reschke:

MR>> Available via frequest "MFREQ" from 2:244/1661 :-)

BR> If you could send me a copy, I can hatch into Filegate? Send me one
BR> anyway?

Please check your inbound! You're welcome ;-)

Regards,
Markus

[Benny Pedersen]

Hello Markus!

27 Jan 2013 13:33, Markus Reschke wrote to Ben Ritchey:

MR> Please check your inbound! You're welcome ;-)

bug report: 1234567.dat is invalid msdos filename ?

will begin create the ebuild today, that is the only bug i have found in it


Regards Benny

... there can only be one way of life, and it works :)

[Markus Reschke]

Hello Benny!

Feb 19 16:32 2013, Benny Pedersen wrote to Markus Reschke:

BP> bug report: 1234567.dat is invalid msdos filename ?

Could you please send me the affected files.bbs and the "Define files.bbs" line
from the mfreq-list configuration file.

BP> will begin create the ebuild today, that is the only bug i have found
BP> in it

Great! BTW, the current version is 3.06 with two bugs fixed (AKAs mixed up in
the INTL kludge of the response netmail and broken automatic filenames for
AutoMagics).

Regards,
Markus

[Lars Kellogg-Stedman]

Howdy,

I've made some patches to mfreq 3.06:

- It now compiles and runs under OS X, and
- It's easier to package because the Makefile supports DESTDIR and the default
configuration file path(s) can be specified easily at compile time.

You can find my changes in the "larsks" branch at
https://github.com/larsks/mfreq. If you're not familiar with github, you can
see a list of individual change sets here:

https://github.com/larsks/mfreq/commits/larsks

I've also created an Arch Linux package for mfreq. The PKGBUILD is available
from https://github.com/larsks/archpackages (you would pass this file to the
"makepkg" command to generate an installable package).

Cheers,

-- Lars

[Markus Reschke]

Hello Lars!

Feb 19 23:22 2013, Lars Kellogg-Stedman wrote to Markus Reschke:

LK> You can find my changes in the "larsks" branch at
LK> https://github.com/larsks/mfreq. If you're not familiar with github,
LK> you can see a list of individual change sets here:

Nice work! I think I'll incorporate some of your ideas. Someone over here also
tries to build a version for OS/2.

Regards,
Markus

[Lars Kellogg-Stedman]

Markus,

After using mfreq for a few days, I have a question: Is there any chance of
having both mfreq-list and mfreq-index use the same syntax for the "FileArea"
command? With this change and the addition of some sort of "Include"
functionality it would no longer be necessary to maintain the list of file
areas in two separate files (although obviously one could if one was so
inclined).

[Markus Reschke]

Hello Lars!

Feb 23 07:57 2013, Lars Kellogg-Stedman wrote to Markus Reschke:

LK> After using mfreq for a few days, I have a question: Is there any
LK> chance of having both mfreq-list and mfreq-index use the same syntax
LK> for the "FileArea" command? With this change and the addition of
LK> some sort of "Include" functionality it would no longer be necessary
LK> to maintain the list of file areas in two separate files (although
LK> obviously one could if one was so inclined).

Let's see. It's easy to add the options of the other FileArea command to be
ignored. But we will still have:
- mfreq-index: FileArea <path> ...
- mfreq-list: FileArea <name> Path <path> ...
So one of the commands need to be changed or a new common command (taking all
options) could be added instead.

For the Include command I see two possible solutions. One to change the
configuration read function and some other stuff to be re-entrant and
supporting a maximum depth level. And the other would be a dedicated read
function for the include file supporting just the common FileArea command. The
first one is the better way since it's flexible, the latter isn't.

Regards,
Markus

[Markus Reschke]

Hello!

Feb 23 15:56 2013, Markus Reschke wrote to Lars Kellogg-Stedman:

MR> Let's see. It's easy to add the options of the other FileArea command
MR> to be ignored. But we will still have:
MR> - mfreq-index: FileArea <path> ...
MR> - mfreq-list: FileArea <name> Path <path> ...
MR> So one of the commands need to be changed or a new common command
MR> (taking all options) could be added instead.

MR> For the Include command I see two possible solutions. One to change
MR> the configuration read function and some other stuff to be re-entrant
MR> and supporting a maximum depth level. And the other would be a
MR> dedicated read function for the include file supporting just the
MR> common FileArea command. The first one is the better way since it's
MR> flexible, the latter isn't.

Jame added mfreq to his http://sourceforge.net/projects/ftnapps/ and I just
pushed the new version 3.07 to the repository. Besides some minor changes I've
added an Include and SharedFileArea command. That way you can put all your
fileechos into one additional file and include that into the main configuration
files of the indexer and lister.

Regards,
Markus

[Paul Quinn]

Hi! Markus,

In a message to All you wrote:

MR> Jame added mfreq to his http://sourceforge.net/projects/ftnapps/ and
MR> I just pushed the new version 3.07 to the repository. Besides some
MR> minor changes I've added an Include and SharedFileArea command. That
MR> way you can put all your fileechos into one additional file and
MR> include that into the main configuration files of the indexer and
MR> lister.

Cool. One day you will see the light and start work on a TIC-handling function
in mFREQ, too. I hope I am repeating myself, BTW. ;-)

Cheers,
Paul.

... "Yeah, I wrote it but it's Jimi's song." - Dylan.

[Benny Pedersen]

Hello Markus!

19 Feb 2013 21:40, Markus Reschke wrote to Benny Pedersen:

MR> Could you please send me the affected files.bbs and the "Define
MR> files.bbs" line from the mfreq-list configuration file.

too late for me this time, i solvcd it the filex.bbs, just will remember it
could be usefull info next time

BP>> will begin create the ebuild today, that is the only bug i have found
BP>> in it

MR> Great! BTW, the current version is 3.06 with two bugs fixed (AKAs
MR> mixed up in the INTL kludge of the response netmail and broken
MR> automatic filenames for AutoMagics).

i cant figure out what Magic and MagicPath define here ?

but the rest is working for me :)

----- index.cfg begins -----
#
# sample config for mfreq-index
#

LogFile /home/xpoint/fido/log/mfreq-index.log

SetMode PathAliases

# Magic FILES File /home/xpoint/fido/magic/files
# MagicPath /home/ftp/pub

Exclude .*
Exclude dir.bbs
Exclude DIR.BBS
Exclude files.bbs
Exclude FILES.BBS

FileArea /home/ftp/pub/amylist
FileArea /home/ftp/pub/backbone
FileArea /home/ftp/pub/base
FileArea /home/ftp/pub/cbm-free_amy
FileArea /home/ftp/pub/coordutl
FileArea /home/ftp/pub/dk-point
FileArea /home/ftp/pub/dkp-util
FileArea /home/ftp/pub/echolist
FileArea /home/ftp/pub/fg_worf
FileArea /home/ftp/pub/fidonews
FileArea /home/ftp/pub/lnx4apps
FileArea /home/ftp/pub/lnx4games
FileArea /home/ftp/pub/lnx4kids
FileArea /home/ftp/pub/lordfile
FileArea /home/ftp/pub/nasa
FileArea /home/ftp/pub/nodedifa
FileArea /home/ftp/pub/nodedifz
FileArea /home/ftp/pub/nodelisa
FileArea /home/ftp/pub/nodelisz
FileArea /home/ftp/pub/oredson
FileArea /home/ftp/pub/oseinoaa
FileArea /home/ftp/pub/pdnunix
FileArea /home/ftp/pub/pdnwinnt
FileArea /home/ftp/pub/region23
FileArea /home/ftp/pub/utillnx
FileArea /home/ftp/pub/utilnet
FileArea /home/ftp/pub/utilwin
FileArea /home/ftp/pub/z2pnt
FileArea /home/ftp/pub/z2pnt_d

Index /home/xpoint/fido/magic/main

----- index.cfg ends -----


Regards Benny

... there can only be one way of life, and it works :)

[Markus Reschke]

Hello Benny!

Mar 06 06:01 2013, Benny Pedersen wrote to Markus Reschke:

BP> i cant figure out what Magic and MagicPath define here ?

BP> # Magic FILES File /home/xpoint/fido/magic/files

That's a classic magic. If someone requests "FILES" he'll get
/home/xpoint/fido/magic/files.

BP> # MagicPath /home/ftp/pub

And that's a special feature used by ifcico, which has a dedicated directory
for magic files. Those files are text files with filepaths (each line a
filepath). The name of the magic file will be the magic and all files listed in
the magic file will be sent. For example you would put following into your
ifcico config:
magic /home/ftp/pub

The latest version of mfreq (3.08) supports also smart magics (filepattern
matching and/or latest file).

Regards,
Markus