Re: [Mailman-Developers] [Mailman-Users] mailman user password
*shimmied over to mailman-devs* (from -users)
On Fri, Aug 07, 2009 at 10:33:06AM -0400, Barry Warsaw wrote:
It kind of sucks that there are so many other Mailman command line
scripts, which is one reason why I've always put them in a separate
Mailman specific bin directory. With MM3 though I intend to use a
'subcommand' approach so that there's only one 'mailman' command.
Think things like 'mailman listmembers foo'. I'll probably keep
mailmanctl separate though I haven't decided about that yet.
Would it too much to ask for the 'old' (read 'current') scripts/commands to be aliased: at least in the first few releases?
e.g., for 'list_members' to link to 'mailman listmembers'Perhaps as an install/configure/compilation option? "Create old-style links?" --old-style-links
(maybe that's more for people who package: ISTR a couple of packagers are on list, yes?)
(wonders how many other people have scripts that would need re-writing otherwise...)
Sorry Adam for hijacking, I'm not subscribed to mm-users.
On Fri, Aug 07, 2009 at 15:46 +0100, Adam McGreggor wrote:
*shimmied over to mailman-devs* (from -users)
On Fri, Aug 07, 2009 at 10:33:06AM -0400, Barry Warsaw wrote:
It kind of sucks that there are so many other Mailman command line
scripts, which is one reason why I've always put them in a separate
Mailman specific bin directory. With MM3 though I intend to use a
'subcommand' approach so that there's only one 'mailman' command.
Think things like 'mailman listmembers foo'. I'll probably keep
mailmanctl separate though I haven't decided about that yet.
I applaud you on this, Barry. I seem to remember discussions where to place these commands for Debian, ATM they pollute the /usr/sbin namespace. May I suggest to put mailman in /usr/bin while mailmanctl stays in /usr/sbin.
Would it too much to ask for the 'old' (read 'current') scripts/commands to be aliased: at least in the first few releases?
e.g., for 'list_members' to link to 'mailman listmembers'Perhaps as an install/configure/compilation option? "Create old-style links?" --old-style-links
You might contribute some shell scripts simulating old behavior, a Debian package would then ask an additional debconf question whether to install these compatibility scripts or not.
Regards Siggy
bsb-at-psycho-dot-informationsanarchistik-dot-de
or: bsb-at-psycho-dot-i21k-dot-deO< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Aug 7, 2009, at 11:26 AM, Bernd 'Siggy' Brentrup wrote:
I applaud you on this, Barry. I seem to remember discussions where to place these commands for Debian, ATM they pollute the /usr/sbin namespace. May I suggest to put mailman in /usr/bin while mailmanctl stays in /usr/sbin.
I'm not yet sure how the buildout based source build will translate
into installation recipes, but I generally concur with this. I'm
nearly certain that mailmanctl's functionality will not appear in the
'mailman' command (which I already have working and committed to the
trunk!). We'll have to figure that out when the release is closer.
-Barry
On Fri, Aug 07, 2009 at 05:26:21PM +0200, Bernd 'Siggy' Brentrup wrote:
Sorry Adam for hijacking, I'm not subscribed to mm-users.
no prob!
Would it too much to ask for the 'old' (read 'current') scripts/commands to be aliased: at least in the first few releases?
e.g., for 'list_members' to link to 'mailman listmembers'Perhaps as an install/configure/compilation option? "Create old-style links?" --old-style-links
You might contribute some shell scripts simulating old behavior, a Debian package would then ask an additional debconf question whether to install these compatibility scripts or not.
I'll see what comes out, before committing to write scripts for Debian &c. I've been known to whine about 'Debian policy': some Debianistic traits annoy me (having came to Debian via BSD).
Saying that, a new version may be a good chance to migrate/re-write the scripts I've been using for some time: what may be quite useful is something to hunt various directory trees for references to 'old mailman' commands, and offer replacements for 'new mailman'.
I'd probably write something that would do that, for my own installs, so it's not too bad releasing back to the community. (although I tend to license stuff under (Attribute Share-Alike) Creative Commons.)
-- If tin whistles are made of tin, what are foghorns made of?
On Mon, Aug 10, 2009 at 13:06 +0100, Adam McGreggor wrote:
On Fri, Aug 07, 2009 at 05:26:21PM +0200, Bernd 'Siggy' Brentrup wrote:
You might contribute some shell scripts simulating old behavior, a Debian package would then ask an additional debconf question whether to install these compatibility scripts or not.
I'll see what comes out, before committing to write scripts for Debian &c. I've been known to whine about 'Debian policy': some Debianistic traits annoy me (having came to Debian via BSD).
I'm using Debian here only as a reference for a packaging system that I happen to be most acquainted with. You may read Ubuntu, RH or whatever you like.
Don't ask me about 'Debian Policy' as long as I am waiting for DAM to reopen my account bsb@d.o, I might be forced to lie like a trooper before I have a vote again :)
Regards Siggy
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org bsb-at-psycho-dot-informationsanarchistik-dot-de or: bsb-at-psycho-dot-i21k-dot-de ========> ceterum censeo javascriptum esse restrictam <========
On Aug 7, 2009, at 10:46 AM, Adam McGreggor wrote:
*shimmied over to mailman-devs* (from -users)
Thanks!
On Fri, Aug 07, 2009 at 10:33:06AM -0400, Barry Warsaw wrote:
It kind of sucks that there are so many other Mailman command line scripts, which is one reason why I've always put them in a separate Mailman specific bin directory. With MM3 though I intend to use a 'subcommand' approach so that there's only one 'mailman' command. Think things like 'mailman listmembers foo'. I'll probably keep mailmanctl separate though I haven't decided about that yet.
Would it too much to ask for the 'old' (read 'current') scripts/ commands to be aliased: at least in the first few releases?
e.g., for 'list_members' to link to 'mailman listmembers'
Perhaps as an install/configure/compilation option? "Create old-style links?" --old-style-links
(maybe that's more for people who package: ISTR a couple of packagers are on list, yes?)
(wonders how many other people have scripts that would need re-writing otherwise...)
There won't be a cmmi recipe for MM3 (no configure; make; make
install) at least from upstream, but I'm happy to work with distros to
figure out the right way to package Mailman 3.
As for aliases, I think it won't be worth it. I also want to
standardize and make consistent all the command line options so that
the whole suite of commands makes more sense.
-Barry
On Fri, Aug 07, 2009 at 17:59 -0400, Barry Warsaw wrote:
There won't be a cmmi recipe for MM3 (no configure; make; make install) at least from upstream, but I'm happy to work with distros to figure out the right way to package Mailman 3.
I'd suggest /usr/bin/mailman and /usr/sbin/mailmanctl Modules might take advantage of python-support or be installed under /usr/share/mailman/ resp. /usr/lib/mailman/ for arch dependent stuff, queues &c in /var/spool/mailman/, for archives I still have to consult LSB.
As for aliases, I think it won't be worth it. I also want to standardize and make consistent all the command line options so that the whole suite of commands makes more sense.
Args, looks like I posted from my standard address bsb@p.i.d instead of from my subscription address lists@p.s.d, would you kindly approve those messages.
Regards Siggy (going to add yet another hook to .muttrc)
bsb-at-psycho-dot-informationsanarchistik-dot-de
or: bsb-at-psycho-dot-i21k-dot-deO< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Aug 7, 2009, at 6:16 PM, Bernd 'Siggy' Brentrup wrote:
On Fri, Aug 07, 2009 at 17:59 -0400, Barry Warsaw wrote:
There won't be a cmmi recipe for MM3 (no configure; make; make install) at least from upstream, but I'm happy to work with distros to figure out the right way to package Mailman 3.
I'd suggest /usr/bin/mailman and /usr/sbin/mailmanctl Modules might take advantage of python-support or be installed under /usr/share/mailman/ resp. /usr/lib/mailman/ for arch dependent stuff, queues &c in /var/spool/mailman/, for archives I still have to consult LSB.
There should be little or no architecture dependent stuff in MM3. All
those binaries for "security" are gone. I definitely want to support
the LSB for MM3, but I haven't put too much thought into that yet.
The command line scripts will be interesting, but less so in MM3 than
in MM2. Already I have several REST APIs fleshed out and as soon as
you can subscribe to mailing lists via REST I will release the next
alpha (hopefully in the next week or two).
-Barry
participants (5)
-
Adam McGreggor -
Barry Warsaw -
Bernd 'Siggy' Brentrup -
Bernd 'Siggy' Brentrup -
Bernd Siggy Brentrup