After a while of wondering why my local configuration file 'localconfig' was not being used, I discovered that the file access permissions were not set properly for it. The code ought to be modified so that a warning is generated in the script when a problem in the local config occurs (so that it can be rectified by the maintainer). It also came to my attention (when implementing exception handling on loading the localconfig file) that it is possible for the file to return 0 (if the last array in the code is empty). So the checkconfig script was changed to fix this problem. A patch to fix these 'features' will follow. I hope this will be of use and considered for inclusion.
inclusion into 2.12
Assignee: tara → cyeh
Status: ASSIGNED → NEW
This patch is going to continually add a "1;" to the end of the localconfig script every time checksetup.pl is run. Is there a way to check if that 1; is there already or not? In case extra variables are added, I would suggest removing any existing one before adding extra variables, too, just to keep the file clean...
firstname.lastname@example.org - do you have any comment about what Dave said? Gerv
Removing from 2.12. No hurry on this one.
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16
Taking all of cyeh's Bugzilla bugs.
Assignee: Chris.Yeh → justdave
-> Bugzilla product, Administration component, reassigning.
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
Version: other → unspecified
Comment on attachment 10044 [details] [diff] [review] Patch to check for loading of 'localconfig' per previous comments on bug, marking needs-work
Attachment #10044 - Flags: review-
OS: Linux → All
Hardware: PC → All
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Checksetup now checks as part of bug 97290, but globals.pl still needs to error out.
These unloved bugs have been sitting untouched since June 2002 or longer. If nobody does anything else to them, they certainly won't make 2.18 Retargetting to 2.20. If you really plan to push them right now, you might pull them back in.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to email@example.com or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.
Target Milestone: Bugzilla 2.20 → ---
Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.
Assignee: justdave → administration
QA Contact: mattyt-bugzilla → default-qa
Max, I suppose we can close this bug?
Yeah, this was fixed as part of the creation of Bugzilla::Install::Localconfig.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Depends on: 346344
Resolution: --- → FIXED
Whiteboard: [fixed by blocker]
You need to log in before you can comment on or make changes to this bug.