Small contrib script

I have a small script which may be appropriate for the contrib section in Mailman 2. Basically, it simply assembles a few build-time options, including the option string given to the configure script, and spits them out to stdout when the script is executed.
Modifications to configure.in are accomplished using a patch file, and autoconf needs to be run to regenerate the configure script.
In what form and fashion should I submit this contribution, which consists of about 3 files. I can put these in a tarball and attach them, attach them seprately, put them on my public server and post the URL to this list, or upload them, whatever's appropriate. This is a small package, less than 3K.
Let me know.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/05/2018 12:21 AM, Lindsay Haisley wrote:
The ideal way is to register at launchpad, get a copy of the branch at <https://code.launchpad.net/~mailman-coders/mailman/2.1>, make your additions, push that to a branch in your account and create a merge proposal, but if that seems too complex, you can send me a tarball off list.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Fri, 2018-01-05 at 20:05 -0800, Mark Sapiro wrote:
This isn't too complex, and I'm almost there, but I haven't worked with version control since I was working with cvs some years ago (showing my age, I guess) so bzr is new to me.
I've made a local copy of the MM 2.1 source tree using 'bzr branch lp:mailman/2.1" and made appropriate revisions to it incorporating my mailman-config.py into the contrib directory of the source tree and modifying configure and configure.in to do the proper substitutions for the working copy that's generated in build/contrib at build time.
I'm a bit at sea on the last two parts of your instruction. How do I properly push my branch back to my launchpad account? Do I create a PPA?
How do I create a merge proposal?
This isn't, as they say, rocket science, and I've been a Linux system administrator for close to 20 years, so if I know what I'm doing I can easily handle it, but a few tips from you folks will save me a bunch of research. I don't want to go mucking around on a community resource without knowing what I'm doing :)
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/06/2018 02:51 PM, Lindsay Haisley wrote:
No, you don't need to create a PPA. It's been a while since I've done this, so I may not have it exactly right, but assume your launchpad user name is "example" and assuming you have committed all your changes in your bzr branch, first ensure you have uploaded your ssh public key to your Launchpad account.
Then in your bzr branch do
bzr push lp:~example/mailman/name "example" is your actual user name. "mailman" is the project this is associated with and "name" will be the Launchpad name of your branch and can be any name that is meaningful to you.
How do I create a merge proposal?
Once you have pushed your branch, go to it in Launchpad. It will be at <https://code.launchpad.net/~example/mailman/name> or you will also find it listed at <https://code.launchpad.net/~example/>.
On your branch's code page will be a "Propose for merging" link. Follow that, set the Target Branch to ~mailman-coders/mailman/2.1, add a description if you like and "Propose Merge"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sat, 2018-01-06 at 15:25 -0800, Mark Sapiro wrote:
OK, done. I had to frog around a bit and mentally review my work from some years ago with cvs, which bzr resembles. There's one deleted revision in the revision history for mailman (sorry) since I was learning by doing.
mailman-config.py, which this branch adds, is the result of a recent discussion in the mailman-users list. I use Courier as my mail suite (IMAP, MTA, Custom spam filtering, virtual mailboxes, etc.) and since Courier is often built from source outside of a distribution's package management, the Courier developers (notably Sam Varshavchik) have wisely included a "courier-config" utility which, when executed, shows the build-time configure options used in building the package plus a few other things.
MM is another suite that I generally install from source, since stuff such as DMARC mitigation doesn't make it down the pike into the Ubuntu package until long after it's needed.
If mailman-config.py is of interest, it's easy enough to make it show other build-time options. At present, all it shows is the MM version, the build date/time, prifix, var_prefix, mailman_user, mailman_group, mail_group, cgi_group and the list of options provided to configure. If it's of interest, and more output information is needed, let me know and I'll add it.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/06/2018 04:28 PM, Lindsay Haisley wrote:
I'm looking at it now.
The problem with what you currently have done is the configured script only exists in the source build/contrib directory which will disappear if one runs 'make distclean' and which is somewhat obscure to find in any case.
If this is to be truly useful, it should be a bin/ command so it gets into the installed Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sat, 2018-01-06 at 17:16 -0800, Mark Sapiro wrote:
True, that.
If this is to be truly useful, it should be a bin/ command so it gets into the installed Mailman.
I did give that some thought, and it should be a trivial change to put it in bin rather than build/contrib. I quite agree with you, but I wasn't sure if this utility conformed to policy for files in the bin directory. I'll look at the make install code, but I'd guess anything in bin in the source tree pretty much just gets configured (AC_SUBST) and then copied to ~mailman/bin during the install (assuming it's listed in SCRIPTS in Makefile.in).
-- Lindsay Haisley | "The only unchanging certainty FMP Computer Services | is the certainty of change" 512-259-1190 | http://www.fmp.com | - Ancient wisdom, all cultures

On Sat, 2018-01-06 at 17:16 -0800, Mark Sapiro wrote:
This has been changed as per your suggestion and pushed to Launchpad. I tried to post a merge request again, after making the changes, but it was disallowed by the system since I'd already done this for the original branch push. I presume mailman coders were notified of the change.
Sorry if I'm a bit clumsy at this. I'm not familiar with bzr and Launchpad version control, and community development techniques associated with them.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/06/2018 09:41 PM, Lindsay Haisley wrote:
When you push additional changes to your branch, your merge proposal is automatically updated.
I'll look at the changes in detail within the next few days.
That's OK. You're doing fine. However, try not to invest too much effort into learning bzr and Launchpad since we have moved to git and GitLab for Mailman 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sun, 2018-01-07 at 08:25 -0800, Mark Sapiro wrote:
When you push additional changes to your branch, your merge proposal is automatically updated.
Thanks.
I'll look at the changes in detail within the next few days.
Fine. The mailman-config program just provides a bit of convenient information. Code-wise, it's trivial. The parts that took time were boning up on autoconf and learning Launchpad's version control system.
Learning anything such as languages (programming or spoken), musical instruments and version control systems has the property that after you've learned one or two, learning others becomes much easier.
-- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard

What's the proper way to run autoconf on configure.in in MM2 in order to _not_ generate runstatedir options and code in the configure script? I note that the distributed configure script in MM2 doesn't have them, but simply running autoconf on configure.in produces a configure script that does. This option is harmless enough, since MM apparently doesn't need or use it, but for simplicity I'd like to be able to generate a configure script without it.
-- Lindsay Haisley | "I felt a great disturbance in the Force, FMP Computer Services | as if millions of voices suddenly cried out 512-259-1190 | in terror and were suddenly silenced." http://www.fmp.com | - Obi-Wan Kenobi

On 01/07/2018 12:28 PM, Lindsay Haisley wrote:
In my case, my autoconf which didn't generate those options in 2014 when I generated the current configure and which then was probably debian/ubuntu version 2.69-7 is now debian/ubuntu version 2.69-9 and it does generate them. See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759647>.
The bottom line is this is something that newer autoconf does and if your autoconf does it, I don't know a way to turn it off.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Tue, 2018-01-09 at 15:55 -0800, Mark Sapiro wrote:
I looked at the code and that's kinda what I figured. Thanks
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

Lindsay Haisley writes:
The autotools authors are *extremely* prescriptive, and try to implement as much of the "GNU standard" in code as they can. The first macro in an autoconf script is ac_init, which IIRC is boilerplate setup and environment consistency checks. Most likely one of the next two or three macro invocations sets up the standard options, and that will invoke a macro to set up these directories. Or it might be another layer deeper. Generally the way to turn stuff off is to unroll the macros and only use what you need.
All of the autotools stuff is deeply entwined. I suspect we only use autoconf, so surgery on the configure.in to only call the stuff we use is probably OK. But if we use anything like automake, it's likely there will be ripple effects if you remove GNU standard setup as Make variables that are defined by the standard and used in the Makefile go undefined.
It's probably not worth doing more.
Steve

On Wed, 2018-01-10 at 12:13 +0900, Stephen J. Turnbull wrote:
Frankly, my main issue is my timidity, and not wanting to make any changes not directly related to my proposed mailman-config script. If I ran autoconf in the source root without changing configure.in I wanted the resulting configure script to be byte for byte the same as the one distributed with every version of MM2 since dirt was new (or at least several version back). It wasn't. On the other hand, the only difference was code supporting a (relatively) new config variable, runstatedir, which allows flexible assignment of the location of temporary runtime process information such as the PID file and such. When this was introduced, there was a transition underway, maybe with the FSF standard too, moving files from /var/run to /run in some distributions. There's a FSF announcement about it at https://lists.gnu.org/archive/html/bug-autoconf/2013-09/msg00003.html
MM2 doesn't appear to use anything in /run or /var/run, so runstatedir is kind of moot, and looking at the supporting macros I didn't see any code which allowed reference to it to be removed without hacking a macro file, which didn't seem appropriate.
I had to make changes to configure.in, and I've generated the configure file with the autoconf I have here - v2.69. Going forward setting --runstatedir will be a configure option. As far as I can see, it's harmless, so I'll let it be and move on. If it needs attention down the road it can be dealt with then. If reference to runstatedir is surgically removed from the configure script here it becomes "politically correct" and byte for byte identical in all other respects to the old version of it.
Ciao, lh
-- Lindsay Haisley | "Dissent is what rescues democracy FMP Computer Services | from a quiet death behind 512-259-1190 | closed doors" http://www.fmp.com | - Molly Ivins

On 01/05/2018 12:21 AM, Lindsay Haisley wrote:
The ideal way is to register at launchpad, get a copy of the branch at <https://code.launchpad.net/~mailman-coders/mailman/2.1>, make your additions, push that to a branch in your account and create a merge proposal, but if that seems too complex, you can send me a tarball off list.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Fri, 2018-01-05 at 20:05 -0800, Mark Sapiro wrote:
This isn't too complex, and I'm almost there, but I haven't worked with version control since I was working with cvs some years ago (showing my age, I guess) so bzr is new to me.
I've made a local copy of the MM 2.1 source tree using 'bzr branch lp:mailman/2.1" and made appropriate revisions to it incorporating my mailman-config.py into the contrib directory of the source tree and modifying configure and configure.in to do the proper substitutions for the working copy that's generated in build/contrib at build time.
I'm a bit at sea on the last two parts of your instruction. How do I properly push my branch back to my launchpad account? Do I create a PPA?
How do I create a merge proposal?
This isn't, as they say, rocket science, and I've been a Linux system administrator for close to 20 years, so if I know what I'm doing I can easily handle it, but a few tips from you folks will save me a bunch of research. I don't want to go mucking around on a community resource without knowing what I'm doing :)
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/06/2018 02:51 PM, Lindsay Haisley wrote:
No, you don't need to create a PPA. It's been a while since I've done this, so I may not have it exactly right, but assume your launchpad user name is "example" and assuming you have committed all your changes in your bzr branch, first ensure you have uploaded your ssh public key to your Launchpad account.
Then in your bzr branch do
bzr push lp:~example/mailman/name "example" is your actual user name. "mailman" is the project this is associated with and "name" will be the Launchpad name of your branch and can be any name that is meaningful to you.
How do I create a merge proposal?
Once you have pushed your branch, go to it in Launchpad. It will be at <https://code.launchpad.net/~example/mailman/name> or you will also find it listed at <https://code.launchpad.net/~example/>.
On your branch's code page will be a "Propose for merging" link. Follow that, set the Target Branch to ~mailman-coders/mailman/2.1, add a description if you like and "Propose Merge"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sat, 2018-01-06 at 15:25 -0800, Mark Sapiro wrote:
OK, done. I had to frog around a bit and mentally review my work from some years ago with cvs, which bzr resembles. There's one deleted revision in the revision history for mailman (sorry) since I was learning by doing.
mailman-config.py, which this branch adds, is the result of a recent discussion in the mailman-users list. I use Courier as my mail suite (IMAP, MTA, Custom spam filtering, virtual mailboxes, etc.) and since Courier is often built from source outside of a distribution's package management, the Courier developers (notably Sam Varshavchik) have wisely included a "courier-config" utility which, when executed, shows the build-time configure options used in building the package plus a few other things.
MM is another suite that I generally install from source, since stuff such as DMARC mitigation doesn't make it down the pike into the Ubuntu package until long after it's needed.
If mailman-config.py is of interest, it's easy enough to make it show other build-time options. At present, all it shows is the MM version, the build date/time, prifix, var_prefix, mailman_user, mailman_group, mail_group, cgi_group and the list of options provided to configure. If it's of interest, and more output information is needed, let me know and I'll add it.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/06/2018 04:28 PM, Lindsay Haisley wrote:
I'm looking at it now.
The problem with what you currently have done is the configured script only exists in the source build/contrib directory which will disappear if one runs 'make distclean' and which is somewhat obscure to find in any case.
If this is to be truly useful, it should be a bin/ command so it gets into the installed Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sat, 2018-01-06 at 17:16 -0800, Mark Sapiro wrote:
True, that.
If this is to be truly useful, it should be a bin/ command so it gets into the installed Mailman.
I did give that some thought, and it should be a trivial change to put it in bin rather than build/contrib. I quite agree with you, but I wasn't sure if this utility conformed to policy for files in the bin directory. I'll look at the make install code, but I'd guess anything in bin in the source tree pretty much just gets configured (AC_SUBST) and then copied to ~mailman/bin during the install (assuming it's listed in SCRIPTS in Makefile.in).
-- Lindsay Haisley | "The only unchanging certainty FMP Computer Services | is the certainty of change" 512-259-1190 | http://www.fmp.com | - Ancient wisdom, all cultures

On Sat, 2018-01-06 at 17:16 -0800, Mark Sapiro wrote:
This has been changed as per your suggestion and pushed to Launchpad. I tried to post a merge request again, after making the changes, but it was disallowed by the system since I'd already done this for the original branch push. I presume mailman coders were notified of the change.
Sorry if I'm a bit clumsy at this. I'm not familiar with bzr and Launchpad version control, and community development techniques associated with them.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

On 01/06/2018 09:41 PM, Lindsay Haisley wrote:
When you push additional changes to your branch, your merge proposal is automatically updated.
I'll look at the changes in detail within the next few days.
That's OK. You're doing fine. However, try not to invest too much effort into learning bzr and Launchpad since we have moved to git and GitLab for Mailman 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sun, 2018-01-07 at 08:25 -0800, Mark Sapiro wrote:
When you push additional changes to your branch, your merge proposal is automatically updated.
Thanks.
I'll look at the changes in detail within the next few days.
Fine. The mailman-config program just provides a bit of convenient information. Code-wise, it's trivial. The parts that took time were boning up on autoconf and learning Launchpad's version control system.
Learning anything such as languages (programming or spoken), musical instruments and version control systems has the property that after you've learned one or two, learning others becomes much easier.
-- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard

What's the proper way to run autoconf on configure.in in MM2 in order to _not_ generate runstatedir options and code in the configure script? I note that the distributed configure script in MM2 doesn't have them, but simply running autoconf on configure.in produces a configure script that does. This option is harmless enough, since MM apparently doesn't need or use it, but for simplicity I'd like to be able to generate a configure script without it.
-- Lindsay Haisley | "I felt a great disturbance in the Force, FMP Computer Services | as if millions of voices suddenly cried out 512-259-1190 | in terror and were suddenly silenced." http://www.fmp.com | - Obi-Wan Kenobi

On 01/07/2018 12:28 PM, Lindsay Haisley wrote:
In my case, my autoconf which didn't generate those options in 2014 when I generated the current configure and which then was probably debian/ubuntu version 2.69-7 is now debian/ubuntu version 2.69-9 and it does generate them. See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759647>.
The bottom line is this is something that newer autoconf does and if your autoconf does it, I don't know a way to turn it off.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Tue, 2018-01-09 at 15:55 -0800, Mark Sapiro wrote:
I looked at the code and that's kinda what I figured. Thanks
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

Lindsay Haisley writes:
The autotools authors are *extremely* prescriptive, and try to implement as much of the "GNU standard" in code as they can. The first macro in an autoconf script is ac_init, which IIRC is boilerplate setup and environment consistency checks. Most likely one of the next two or three macro invocations sets up the standard options, and that will invoke a macro to set up these directories. Or it might be another layer deeper. Generally the way to turn stuff off is to unroll the macros and only use what you need.
All of the autotools stuff is deeply entwined. I suspect we only use autoconf, so surgery on the configure.in to only call the stuff we use is probably OK. But if we use anything like automake, it's likely there will be ripple effects if you remove GNU standard setup as Make variables that are defined by the standard and used in the Makefile go undefined.
It's probably not worth doing more.
Steve

On Wed, 2018-01-10 at 12:13 +0900, Stephen J. Turnbull wrote:
Frankly, my main issue is my timidity, and not wanting to make any changes not directly related to my proposed mailman-config script. If I ran autoconf in the source root without changing configure.in I wanted the resulting configure script to be byte for byte the same as the one distributed with every version of MM2 since dirt was new (or at least several version back). It wasn't. On the other hand, the only difference was code supporting a (relatively) new config variable, runstatedir, which allows flexible assignment of the location of temporary runtime process information such as the PID file and such. When this was introduced, there was a transition underway, maybe with the FSF standard too, moving files from /var/run to /run in some distributions. There's a FSF announcement about it at https://lists.gnu.org/archive/html/bug-autoconf/2013-09/msg00003.html
MM2 doesn't appear to use anything in /run or /var/run, so runstatedir is kind of moot, and looking at the supporting macros I didn't see any code which allowed reference to it to be removed without hacking a macro file, which didn't seem appropriate.
I had to make changes to configure.in, and I've generated the configure file with the autoconf I have here - v2.69. Going forward setting --runstatedir will be a configure option. As far as I can see, it's harmless, so I'll let it be and move on. If it needs attention down the road it can be dealt with then. If reference to runstatedir is surgically removed from the configure script here it becomes "politically correct" and byte for byte identical in all other respects to the old version of it.
Ciao, lh
-- Lindsay Haisley | "Dissent is what rescues democracy FMP Computer Services | from a quiet death behind 512-259-1190 | closed doors" http://www.fmp.com | - Molly Ivins
participants (3)
-
Lindsay Haisley
-
Mark Sapiro
-
Stephen J. Turnbull