Long story short, after I updated Mailman from 2.1.9-r1 to 2.1.9-r2, it broke mailman badly... I didn't think minor bumps like this were supposed to introduce major changes, but this one did... I fixed the worst of it, but I still have the problem where the init scripts don't work, and mailman will not start at boot time - it gives the [ !! ] error. Issuing the commands manually works, ie: "/usr/lib64/mailman/bin/mailctl -s start" starts the qrunner and the lists work. Maybe this is another path issue? Reproducible: Always Steps to Reproduce: 1. Update mailman 2.1.9-r1 to 2.1.9-r2 2. Try to start mailman 3. Actual Results: mailman refuses to start with an [[ !! ]] error. Expected Results: mailman should start successfully.
*** This bug has been marked as a duplicate of bug 203714 ***
Well, if this is simply a documentation issue, maybe you could be so kind as to point out the error? It would be most appreciated.
Hello, Maybe my prior post sounded a bit rude, but it certainly was not intended... Please help me with this, since you seem to know the answer/solution... If you are saying that this is a documentation problem, similar to the bug I reported that WAS an actual documentation problem (file system layout changes that didn't jive with the README file), then, please, before ytou close this bug again, explain what the problem is so I can get my init script for mailman working again... Thanks!
http://www.gentoo.org/main/en/support.xml
(In reply to comment #4) > http://www.gentoo.org/main/en/support.xml What is this supposed to mean? I mean, seriously... is it too much to ask for you to actually write a few WORDS to explain what you are trying to convey? I already asked for help on this in the forums here with no response: http://forums.gentoo.org/viewtopic-t-641573-highlight-.html Or are you suggesting that I should opt for paid support? The last option on that poage is to - report a bug, which is back to where we are now. Sorry, I just don't understand... am I doing something wrong? If so, then SAY SO, instead of just closing the bug as a duplicate of another apparently completely UNRELATED bug WITHOUT COMMENT, and then posting a generic link to the support page after I reopen it. Sheesh...
Well, apparently Jakub doesn't have an answer to this problem but is only interested in *appearing* to help - first closing the bug as a duplicate of a TOTALLY UNRELATED bug - without any comment whatsoever - then, after I point this out and reopen the bug, he posts a link to the general support page, again with absolutely no other comment. So... thanks for trying Jakub, but we're back to square one - the bug stands as reported. The mailman people are saying this is obviously a gentoo issue, so aren't able to help... Does no one else even use mailman? At least, someone willing to take a few minutes and lend a hand?
Charles, being rude won't help you. In fact, the package you're complaining about is in "testing" (~x86) and it's there for a reason. If you don't intend to test and fix things your self, don't use testing. -r2 is a rather big change and I'll have a look at the various issues asap, but if you rely on a stable running system, just don't use it and stick with 2.1.9.
Hi Hanno, Now I'm even more confused. I honestly don't see how you could accuse me of being rude. I do understand that using packages in ~testing can cause problems. It is also my understanding they are supposed to be *reasonably* stable (not cause massive, fundamental breakage) - and in fact, the maintainer *wants* people to TEST them (hence the mask name). This is as opposed to packages that are hard masked, which should only be used by competent devs who know exactly what they are doing and *can* fix major breakage on their own. Am I wrong? When I first reported the problems with this update, I didn't accuse anyone, I simply asked for help to fix the problem, and opened a bug to fix the documentation. I did comment that I didn't think minor bumps (-r1 to -r2) were supposed to introduce major changes (like filesystem layout changes), but I wasn't 'complaining', just opening the door for someone to correct my understanding. This is still my understanding - am I wrong? I also opened this bug after not getting any help in the forums. Again, I didn't accuse anyone of anything - and I was/am more than happy to help the dev figure out why it isn't working. I'd just like to get it fixed - and I don't believe it is a major problem - more than likely something trivial in fact. Maybe my understanding of the rules (are there any?) as to who should use testing need updating... Are you saying it is a requirement for one to be a developer, and/or have the skills necessary to write your own ebuilds or do extensive troubleshooting on your own to figure out and actually FIX the problem yourself, before you should use ~testing? I thought it was enough to simply: 1. want to be a part of the testing process - to help the ebuild authors test their ebuilds, and fix any problems encountered, 1. be reasonably competent and able to fix minor issues on my own, and major problems with some assistance, and 2. be willing to take a hit if something goes badly wrong. I added ~amd64 to package.keywords for mailman because 2.1.10 is in beta and getting ready to be released, and I am *very* interested in a new feature it has, so am willing to 'experiment' to get it working. Since I am NOT a dev, but am interested in helping out if/when I can (by testing unstable packages that are important to me), I thought I was doing a 'good' thing. Now... am I wrong?
the problem is that the mailman homedir isn't changed automatically. This can't be easily done, so now a warning is issued at the end of the build process. You can fix it by using usermod -d (new mailman home, something like /usr/lib/mailman) mailman which the ebuild now tells you
