Putting mutable data in Mailman-2.1.9 into VAR_PREFIX while executable code remains in PREFIX (and these are now different) requires a few fixes to scripts in ~mailman/bin. Since these directories have been synonymous for some time, people have gotten a bit sloppy in their programming and PREFIX and VAR_PREFIX were sometimes used interchangeably. Here are several suggested patches.
Created attachment 145449 [details, diff] Patch to misc/paths.py.in in the source directory paths.py is imported by several other scripts. This adds a var_prefix variable which is used in the patch to check_perms_grsecurity.py.
Created attachment 145450 [details, diff] Patch to contrib/check_perms_grsecurity.py in the source tree
Created attachment 145452 [details, diff] Patch to bin/update in the source tree
Please submit similar stuff upstream; maintaining this thing is enough PITA as it is.
(In reply to comment #4) > Please submit similar stuff upstream; maintaining this thing is enough PITA as > it is. If this is an ebuild bug against the Gentoo install of Mailman then it's an issue of whether or not to back out Gentoo dev's changes to the install locations which (finally!) put Mailman in sync with the Linux FSH. This won't happen, and it shouldn't. Since upstream still sets both PREFIX and VAR_PREFIX to /usr/local/mailman it's not a functional issue there. You can mark this as an "enhancement" if you wish, but the fact is that given the split between these two locations in the current Mailman ebuild, Gentoo is distributing broken software and installing it with the ebuild. Perhaps the non-compliant pieces should just be removed until upstream fixes them. Basically these patches were submitted as a courtesy because I uncovered them in the process of researching Bug 212462. If they get sidelined, it's a no-nevermind to me.
(In reply to comment #5) > Since upstream still sets both PREFIX and VAR_PREFIX to /usr/local/mailman it's > not a functional issue there. You can mark this as an "enhancement" if you > wish, but the fact is that given the split between these two locations in the > current Mailman ebuild, Gentoo is distributing broken software and installing > it with the ebuild. Perhaps the non-compliant pieces should just be removed > until upstream fixes them. Yeah, the whole design is pretty broken upstream. /usr/local/mailman is a completely FUBARed location for starters, config files belong to /etc, the whole uid/gid/username/groupname stuff should be configurable without any reinstall, etc. etc. etc. What's delivered in Gentoo now is a huge improvement compared to the upstream design, so I really don't get your complaints about Gentoo delivering broken ebuilds?! The entire point of my comment was that the above issues need to be fixed upstream finally, so pushing similar stuff makes a lot of sense.
(In reply to comment #6) > What's delivered in Gentoo now is a huge improvement compared to the upstream > design, No disagreement there :-) > so I really don't get your complaints about Gentoo delivering broken > ebuilds?! Jakub, it's not a complaint. I just noted that some of the stuff distributed with Mailman, which is potentially broken in the upstream distribution is in fact actually broken in the Gentoo ebuild. The broken pieces are more or less add-ons. One is included as a "contrib" piece in the source, but this distinction is erased in Gentoo since they all get installed in ~mailman/bin. The patches I provided are pretty simple fixes which I thought might be useful. If the ebuild maintainers aren't interested, so be it. These pieces are peripheral tools and don't affect the core functionality of Mailman, which is both capable and popular in spite of the fubar development history. > The entire point of my comment was that the above issues need to be > fixed upstream finally, so pushing similar stuff makes a lot of sense. Brad Knowles, one of the Mailman devs, is a friend of mine here in Austin. Even the bug reporting and feedback channels form Mailman are screwed up, it seems. Mailman has a bug reporting system on Sourceforge where it appears that nothing reported has been assigned in over a year, and more active attention is given to issues on the Mailman developers' forum. Even this is apparently being sidelined in favor of a developers' wiki to which Brad directed me, but I don't recall the URL and it's not well publicised. The whole situation is a mess! My understanding some time ago from Brad is that a major upgrade of Mailman is in the works which will address numerous issues which have been thorns in our sides for years with the current versions. It's a loooooong time coming! My last conversation with Brad on the matter was over a year ago. What attention is being given to Mailman upstream is apparently going into the planned complete revamp, and fixing contrib tools really isn't on their radar. It's been a while since I've visited the whole issue, so I really don't know where it all stands.
two of the patches are already fixed, they use a new variable LIST_DATA_DIR now. I've submitted the check_perms_grsecurity-patch upstream: https://bugs.launchpad.net/mailman/+bug/411192
All stuff is upstream-fixed, I don't consider that important enough for backporting, closing this.
No problem with the closure. This bug is almost 2 years old and we're well beyond this version of MM.
