Subject: mailman: README.Debian update needed r.e. image location

From: Nathan Stratton Treadway <[email-masked]>
Date: Tue, 2 Mar 2004 13:28:41 -0500

Package: mailman
Version: 2.1.4-1
Severity: normal

The README.Debian file should be updated to reflect the new location
of the Mailman images files in /usr/share/images/mailman (i.e. bugs
#110148 and #89867).  (Currently README.Debian talks about the /doc/
webserver alias.)

						Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  [email-masked]  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

---

From: Siggy Brentrup <[email-masked]>
Date: Thu, 25 Mar 2004 02:17:09 -0500

Source: mailman
Source-Version: 2.1.4-2

We believe that the bug you reported is fixed in the latest version of
mailman, which is due to be installed in the Debian FTP archive:

mailman_2.1.4-2.diff.gz
  to pool/main/m/mailman/mailman_2.1.4-2.diff.gz
mailman_2.1.4-2.dsc
  to pool/main/m/mailman/mailman_2.1.4-2.dsc
mailman_2.1.4-2_i386.deb
  to pool/main/m/mailman/mailman_2.1.4-2_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email-masked],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Siggy Brentrup <[email-masked]> (supplier of updated mailman package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email-masked])

Format: 1.7
Date: Wed, 24 Mar 2004 23:48:15 +0100
Source: mailman
Binary: mailman
Architecture: source i386
Version: 2.1.4-2
Distribution: unstable
Urgency: low
Maintainer: Tollef Fog Heen <[email-masked]>
Changed-By: Siggy Brentrup <[email-masked]>
Description: 
 mailman    - Powerful, web-based mailing list manager
Closes: 204006 224012 226152 228123 231468 231967 232005 232273 232452 232546 233048 233161 233693 235835 235913 236473 236666 237006
Changes: 
 mailman (2.1.4-2) unstable; urgency=low
 .
   * Brown bag release.
   * Move that pid file.  Now.  (closes: #226152)
   * Switch to dpatch
   * Don't traceback when using admin password (closes: #233161)
   * Fix up MAILMAN_OWNER. (closes: #232452, #232273)
   * Make the postinst a lot less chatty (closes: #232546)
   * Update Spanish debconf translation (closes: #233693)
   * Update pt_BR debconf translation (closes: #228123)
   * Add Hungarian debconf translation (by GCS)
   * Wait for termination on restart|force-reload (by GCS,
     closes: #231468, #204006, #224012)
   * Fix --purge, thanks to Lionel Elie Mamane and Tollef (by GCS)
   * Revert gate_news changes (by GCS, closes: #237006)
   * Fix messages/de/LC_MESSAGES/mailman.po for now, but forward to upstream;
     patch from Ralf Doeblitz <[email-masked]> (closes: #233048)
   * Added german debconf translation (bsb).
   * Added myself to Uploaders (bsb).
   * Bumped 'Standards Version' to 3.6.1 (bsb, GCS's commit was lost during
     the alioth move).
   * Added catalan debconf translation from Aleix Badia i Bosch <[email-masked]>
     (by GCS, closes: #236666)
   * Change obsolete MAILMAN_OWNER to MAILMAN_SITE_LIST, note that this
     invalidate #232273 and #232452 (by GCS, closes: #235913)
   * Add debconf question for languages supported at a site reducing space
     required in /etc and chattyness (bsb, closes: #232005).
   * Backed out hack in 05_config_list_member_options.dpatch since it
     breaks config_list in mm 2.1.4 (bsb, closes: #231967).
   * Added debian/contrib/postfix-to-mailman.py installing it as
     /usr/lib/mailman/bin/postfix-to-mailman.py (bsb).
   * Cleaned up README.Debian removing obsolete mailman-owner alias and
     adding a section on using postfix-to-mailman.py (bsb).
   * Fix path problems, found by Nathan Stratton Treadway <[email-masked]>
     (by GCS, closes: #235835, #236473)
   * Added missing manpages withlist.8 and list_admins.8 (bsb).
Files: 
 0b2fe1055cb0901f7e353ea02d12809f 639 mail optional mailman_2.1.4-2.dsc
 39166ba730152d993c9ccf8c3f10ea82 50803 mail optional mailman_2.1.4-2.diff.gz
 4c4ae5d9c9a87b6ad92b2e582726af7c 6290210 mail optional mailman_2.1.4-2_i386.deb

---

From: Nathan Stratton Treadway <[email-masked]>
Date: Thu, 25 Mar 2004 16:32:31 -0500

>      (by GCS, closes: #235835, #236473)

I see that you updated README.Debian so that it mentions the images are
now found in /usr/share/images/.  However, the bug 89867 that I
mentioned in my original report is actually about changing the URL for
accessing images from "/doc/" to "/images/", a change that isn't
mentioned in the new README.Debian paragraph.

Also, I believe the DELIVERED_BY_URL variable is no longer used in
the current version of Mailman.

Here's that same paragraph reworded to explain the situation as I
understand it:

------
If your mailman HTML pages have broken images (e.g. in the page footer),
it is probably because you don't have the /images/ alias enabled in your
webserver.   This alias should map from the "/images/" URL to 
the "/usr/share/images" directory (e.g. 
  Alias /images /usr/share/images
for Apache.)

If you are unable to use the default "/images/" alias for some reason, you
can copy the files from /usr/share/images/mailman/ to a place where your
webserver can access them, or create some other web server alias
pointing to the /usr/share/images directory.  Then modify the
IMAGE_LOGOS option accordingly in your mm_cfg.py.
-------

It appears the "apache" package has had this alias defined in the
delivered config files since the 1.3.27-0.1 release (see the last
message posted in bug 89867).  However, I'm not sure if it's defined in
the delievered configuration files for the apache2 package (or
any other web server), so it may be necessary to expand the above
paragraphs a bit if these other servers aren't going to be updated to
match this convention....

						Nathan

---

From: Siggy Brentrup <[email-masked]>
Date: Tue, 6 Apr 2004 23:59:46 +0200

package mailman
reopen 235835
severity 235835 minor
tags 235835 +pending
thanks

On Tue, Apr 06, 2004 at 02:43:46PM -0500, Nathan Stratton Treadway wrote:
> On Fri, Mar 26, 2004 at 07:48:52AM +0100, Siggy Brentrup wrote:
> > Regarding your followups, I'll respond soon.

I apologize for forgetting these documentation issues.

> I don't think you have responded to my followup for bug 235835, and
> I was wondering if you wanted me to re-open the bug before it gets
> archived (while you investigate the situation).

Simply following up to the bug trail will keep it from being archived;
in this case I'm reopening and downgrading the bug since it's only
a documentation flaw. Fixed in repository but don't hold your breath. 

> I am not up-to-speed on Debian policy enough to know what is
> happening with the idea to make "/images/" a standard alias for
> Debian web server packages, ...

IMHO that's a bad idea, since it allows anyone with access to location
/images/ to browse the directory tree below /usr/share/images/ when no
further precaution is taken. I use

   Alias /images/mailman/ /use/share/images/mailman/

in a vhost, knowing there are only MM images in that directory.

> ... but I do think it's important to have the mailman README.Debian
> explain clearly what needs to be done to get the links working with
> whatever web server package is used to fill the "httpd" package
> dependency....

I'm not the person to write tutorials on web server configuration, so
I'll only fixed faulty stuff in README.Debian.

> (If there isn't going to be any "/images/" standard, then the switch
> from "/doc/mailman/images/" to "/images/mailman" for the IMAGE_LOGOS
> setting in mm_cfg.py a few versions ago might be worth
> re-evaluating....

Nope, on many installations location /doc/ is only accessible locally.
/usr/share/images/mailman/ being the canonical place for mailman's
logos, mapping location /images/mailman/ is TRT[tm].  
Location /mailman/images/ looks even more attractive, but when using
ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/ there may be problems
with some httpd - didn't check all of them.

> Of course, in that situation perhaps a new, more general, bug should be
> opened in the BTS.)

And what would that be?

Regards
 . Siggy

---

From: Nathan Stratton Treadway <[email-masked]>
Date: Wed, 7 Apr 2004 10:51:43 -0500

> > On Fri, Mar 26, 2004 at 07:48:52AM +0100, Siggy Brentrup wrote:
[...]
> a documentation flaw. Fixed in repository but don't hold your breath. 

My most recent comments were made in light of bug 89867, which was
attempting to address the image-file-location issue from the point of
view of Debian policy (and not just mailman documentation)....

From the discussion in that bug, it seems that the location of the image
files in the mailman package was orginally changed from
"/doc/mailman/images" to "/images/mailman" based on the policy proposal
found in that bug, and so I thought that the mailman package should be
kept in sync with the results of that discussion.  However, I just
noticed that the last message in that bug from more than year ago, so it
would seem mailman will have to solve this on its own :)

> in a vhost, knowing there are only MM images in that directory.

Well, part of my confusion stems from the fact that the current "apache"
package does come with "/images/" defined in the distributed
configuration file (but with directory browsing turned off to avoid the
problem you mention).  That addition to the apache config was mentioned
in the discussion for 89867, but I guess that's as far as it went. 
(It's not in the apache2 package configs, for example.)

(From my point of view as a "user" a Debian-wide policy allowing these
sort of images to "just work" when I install web-application packages seems
like a good idea, but I don't know enough about other web servers to
know if that policy proposal is realistic.  In the end, your approach is
almost as easy as long as the info is easy to find in the
documentation.)

> I'll only fixed faulty stuff in README.Debian.

Right.

When I first open the bug I was just pointing out that the description
in README.Debian didn't match the actual configuration mailman was
using.  When I discovered 89867 I realized that the discussion there
could further affect the way the mailman package was configured.   Since
that's not going anywhere, we're back to just being sure the
documentation matches the actual configuration.

In that case, the sample text I submitted earlier is mostly correct,
though obviously you may want to change the example Alias line to the
one you show above.  And instead of 
  the /images/ alias enabled in your webserver.
perhaps 
  an appropriate alias to the image files enabled in your webserver
  configuration.
is would be better since /images/ is not actually a "standard" alias.

> logos, mapping location /images/mailman/ is TRT[tm].  

Right -- this was the reasoning behind the policy proposal in 89867, and
makes a lot of sense to me.  I just wasn't sure if you would want to
be creating /usr/share/images independently of a more general agreement
to use that location....

> > Of course, in that situation perhaps a new, more general, bug should be

That would have been something like "since /usr/share/images is not
going to be adopted as a standard directory after all, the mailman
package should move the image files back where they used to be".... :)
But since you do want to keep using the new location, it's not an issue.

						Nathan