Emerge of Mailman 2.1.5 fails when running check_perm. Also, instructions urge user to run check_perm as either root or mailman user. In either case, the script fails with this python stacktrace: Traceback (most recent call last): File "bin/check_perms.orig", line 367, in ? checkdata() File "bin/check_perms.orig", line 321, in checkdata mode = statmode(path) File "bin/check_perms.orig", line 81, in statmode return os.stat(path)[ST_MODE] OSError: [Errno 20] Not a directory: '/usr/local/mailman/lists/.keep/config.pck' Reproducible: Always Steps to Reproduce: 1. Run bin/check_perms in /usr/local/mailman Actual Results: Script failed and said: Traceback (most recent call last): File "bin/check_perms.orig", line 367, in ? checkdata() File "bin/check_perms.orig", line 321, in checkdata mode = statmode(path) File "bin/check_perms.orig", line 81, in statmode return os.stat(path)[ST_MODE] OSError: [Errno 20] Not a directory: '/usr/local/mailman/lists/.keep/config.pck' Expected Results: Checked permissions and completed successfully This is because some directories have a .keep file added by the ebuild system in some directories that this script is not expecting. The following patch seems to fix it: --- check_perms.orig 2004-06-10 09:26:22.717024396 -0600 +++ check_perms 2004-06-09 16:27:49.000000000 -0600 @@ -313,23 +313,24 @@ print _('checking permissions on list data') # BAW: This needs to be converted to the Site module abstraction for dir in os.listdir(mm_cfg.LIST_DATA_DIR): - for file in checkfiles: - path = os.path.join(mm_cfg.LIST_DATA_DIR, dir, file) - if STATE.VERBOSE: - print _(' checking permissions on: %(path)s') - try: - mode = statmode(path) - except OSError, e: - if e.errno <> errno.ENOENT: raise - continue - if (mode & targetmode) <> targetmode: - STATE.ERRORS += 1 - print _('file permissions must be at least 660: %(path)s'), - if STATE.FIX: - print _('(fixing)') - os.chmod(path, mode | targetmode) - else: - print + if dir != '.keep': + for file in checkfiles: + path = os.path.join(mm_cfg.LIST_DATA_DIR, dir, file) + if STATE.VERBOSE: + print _(' checking permissions on: %(path)s') + try: + mode = statmode(path) + except OSError, e: + if e.errno <> errno.ENOENT: raise + continue + if (mode & targetmode) <> targetmode: + STATE.ERRORS += 1 + print _('file permissions must be at least 660: %(path)s'), + if STATE.FIX: + print _('(fixing)') + os.chmod(path, mode | targetmode) + else: + print
Thank you, this works for me. Could you create an attachment with the patch? It makes it easier to include it in portage / try it out / keep things in order.
Created attachment 34345 [details, diff] Patch to 'check_perm' script to make it ignore '.keep' files
Wouldn't a simpler solution be to delete the .keep file from the lists directory before calling the check_perms script?
Yes, but I'm assuming that the .keep file is there for a reason... Probably to stop some gentoo-only process somewhere from deleting that directory if there aren't any lists yet.
the '.keep' file put in there to _keep_ the directory from wipeout by portage during unmerge the older version if it's empty. Jim, I don't know any python, so I asked. Will your patch skips check on the file '.keep' or skips any directory that contains '.keep'?
Created attachment 35893 [details, diff] mailman-2.1.5-directory-check.patch Problem with this code is that it assumes everything in mm_cfg.LIST_DATA_DIR is going to be a directory (which the .keep file has disproven already). I'm not much for singling out just the .keep file to ignore; in my books, if it ain't a directory, don't try using it as one :) Either way, this is a 2 line fix that checks to see if dir is actually a directory; if so, do the checks in that directory, otherwise go on to the next returned entry from os.listdir .
Created attachment 35923 [details, diff] mailman-2.1.5-directory-check.patch ...and I'm a tool for not concattenating the path :D Corrected version.
fixed in mailman-2.1.5-r1 with ~arch keywords. Please test and report back you experience any problem. Thanks everyone. sparc: this is a minor fix. Please test stable this if you can. Thanks.
*** Bug 56250 has been marked as a duplicate of this bug. ***
Works here.
