Should be "all better now".
Attempted to fix a minor bug last month,
didn't get it quite right, that then caused this month's
to not go out (on time). Fixed, that,
correctly this time, and now appears all is well
(reran the program slightly later this month after the fix).
Context was already within single quotes ('),
so needed to properly be '\'' to get a net single quote at that level.
Had earlier fixed whitespace after -m option - where shouldn't have
been, but that then caused the loop to error out, until the other issue
was properly corrected.
# rlog lists_monthly 2>&1 | sed -ne '/^revision 1\.6$/q;/^-\{28\}$/,$p'
----------------------------
revision 1.10 locked by: root;
date: 2026/03/02 06:07:30; author: root; state: Exp; lines: +1 -1
properly fix syntax around (intended) log message for context
----------------------------
revision 1.9
date: 2026/02/09 22:35:01; author: root; state: Exp; lines: +1 -2
http --> https; remove set -x
----------------------------
revision 1.8
date: 2026/02/09 22:28:06; author: root; state: Exp; lines: +1 -1
fix syntax on (intended) log message
----------------------------
revision 1.7
date: 2025/07/02 14:44:38; author: root; state: Exp; lines: +8 -0
filter out list has no members stdout output line in case list
membership [for --role] is empty
----------------------------
# rcsdiff -U 0 -r1.7 lists_monthly 2>&1
===================================================================
RCS file: RCS/lists_monthly,v
retrieving revision 1.7
diff -U 0 -r1.7 lists_monthly
--- lists_monthly 2025/07/02 14:44:38 1.7
+++ lists_monthly 2026/03/02 06:07:30
@@ -51 +51 @@
- ci -d -f -l -M -m 'membership update' membership
>>/dev/null 2>&1
+ ci -d -f -l -M -m'\''membership update'\'' membership
>>/dev/null 2>&1
@@ -62 +61,0 @@
- set -x
@@ -68 +67 @@
- echo '\''http://www.balug.org/#Lists'\''
+ echo '\''https://www.balug.org/#Lists'\''
#
On Sun, Mar 1, 2026 at 10:15 PM Michael Paoli via BALUG-Admin
<balug-admin(a)lists.balug.org> wrote:
> Date: Mon, 02 Mar 2026 06:15:38 +0000 (UTC)
> Subject: [BALUG-Admin] BALUG: Lists, stats, etc.
> dates, lists, number of members:
> YYYY-MM-DD announce talk admin
> 2026-03-02 456 238 31
> 2026-02-01 457 237 31
> 2026-01-01 457 236 31
...
Thanks, verified, etc., and roster for all 3 list now backed up.
3rd list admin? I could peek at my notes ... seems earlier time
we changed password we shared it among 3? - but I may be
mis-remembering. It was 2 or 3, anyway.
Can put out call for volunteers! :-) ... but I suspect we may
hear crickets.
And yes, I think 3 is about idea, ... but since, at least theoretically,
this is only shortish-term remaining on DreamHost, I tend to think
two is "okay" for now ... I'm more interested in working on getting it
off of DreamHost - and as smoothly as feasible - in reasonable timeframe
... than spending cycles "recruiting" a 3rd list admin ... but if one
jumps up and volunteers. :-)
I'll also update list stats around 2017-04-01 - now that I have
access to rosters again. (I think I've also omitted SF-LUG list stats
for a while now - I used to process and put out both right around the
same time, and generally about monthly). Anyway, now have access to
the BALUG data again ... and have had the SF-LUG data all along
(and the SF-LUG stuff is automagically backed up daily).
I typically do offsite backup rotations about monthly - typically
around the 1st of the month. Additional backups, "of course", may also
occur more frequently.
> From: "Rick Moen" <rick(a)linuxmafia.com>
> Subject: Re: [BALUG-Admin] 2 out of 3? 8-O Re: (forw) Your new
> balug-admin-balug.org list password
> Date: Wed, 29 Mar 2017 22:07:02 -0700
> Quoting Michael Paoli (Michael.Paoli(a)cal.berkeley.edu):
>
>> Well, got the password fine,
>> works find on the talk and admin lists but ...
>> alas, not on the announce list.
>
> Fixed. I had hit the 'Submit Your Changes' button, I swear, but
> probably didn't absolutely verify that I got a page reload, and on
> present evidence I did _not_ get a page reload, as the temporary
> password set by DreamHost Support was still accepted.
>
> This time, I did verify page reload.
>
> No thoughts / candidates for a third listadmin?
stats: list membership (~482 total uniques)
total uniques up slightly (by about 5%) from not too long ago.
list subscribers (does include also those with delivery disabled):
$ wc -l */memb*`date -I`
27 balug-admin/membership_2007-10-21
304 balug-announce/membership_2007-10-21
251 balug-talk/membership_2007-10-21
$ sort -u */membership_*`date -I` | wc -l
482
Note also that it appears we have a fairly large number of folks that
are subscribed to "talk", but *NOT* subscribed to "announce".
Theoretically (at least logically) that shouldn't be the case
(in general - typically exceptions being per-list e-mail addresses),
but it is totally under "user" control.
A quick count of that:
$ { sort -u balug-talk/membership_`date -I`
> cat balug-announce/membership_`date -I` \
> balug-announce/membership_`date -I`; } | sort | uniq -u | wc -l
172
... nevertheless *that* number is down moderately from not too long
ago.
After considering various options, what I'm inclined to do to
"rectify" that, is after announcing it and noting it on the lists
appropriately, for e-mail addresses that are on the "talk" and/or
"admin" list lists, they'll get periodically added to the "announce"
list - unless they specifically notify "us" (list admin(s)) that they
want to be on an "exception" list (e.g. if they have and want to use
separate per-list subscription addresses). The process would be
semi-manual at least initially, but would, longer term, be fully
automated (well, except for the being added to the "exception" list -
that might require manually adding the e-mail address to a file).
The above noted approach has the advantages of:
* it avoids the potential complications of lists subscribed to lists
and differing options/configurations (e.g. we want "announce" to be
non-digested, but we want folks to have digested form be option for
"talk"; if we subscribed "talk" to "announce", then those getting
"talk" digested, and not subscribed to "announce" would only see
"announce" within digested "talk" e-mails)
* it allows users to have separate per-list e-mail subscription
addresses if they desire such, and provides means for them to
request not being automatically added to "announce" based on
subscription to "talk" and/or "admin".
I'm also inclined to set up an alias for the balug list admin(s) -
that way folks have a consistent e-mail address that can be used for
that. (Mailman lists and displays the list admin e-mail address(es)
- it looks a lot more clean if there's a "generic" address for that
function, rather than listing all the individual folks that are in
the set of list admins for any given list).
references/excerpts:
http://lists.balug.org/pipermail/balug-admin-balug.org/2007-September/00040…