Closed Bug 957911 Opened 6 years ago Closed 4 years ago
Bug 894227 added configobj to python/configobj and to the virtualenv. It turns out we already had a copy of configobj in config/. It's now useless.
Note the version in python/configobj is more recent, but it shouldn't be a problem for config/printconfigsetting.py.
Attachment #8357563 - Flags: review?(gps)
So, it turns out we can't remove it, because printconfigsetting.py is run directly from outside the build by the build slave scripts. Even before running configure. https://tbpl.mozilla.org/php/getParsedLog.php?id=32743380&full=1&branch=try
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Although, maybe the order is misleading and the first one is actually run after the build...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
All the more reason why all this automation stuff needs to live in the tree.
So here's something interesting: the ConfigObj version in python/configobj (and the oldest version in the upstream git, which dates back to 2008) doesn't support semi-colons as a comment marker, while that's the normal way to mark comments in .ini files. The ConfigObj in config/ does, and we do rely on that (application.ini contains semi-colon comments), and using the ConfigObj from python/configobj doesn't work as a consequence.
Comment on attachment 8670647 [details] [diff] [review] Work around the lack of support for semi-colon comments in python/configobj Review of attachment 8670647 [details] [diff] [review]: ----------------------------------------------------------------- Yes, configobj's lack of support for semicolon comments is mind boggling. A number of people run into errors with `mach mercurial-setup` because of this, sadly.
Attachment #8670647 - Flags: review?(gps) → review+
Any idea why this might be breaking comm-central builds? File "build/mozilla/config/printconfigsetting.py", line 17, in <module> content = re.sub('^\s*;', '#', fh.read(), flags=re.M) TypeError: sub() got an unexpected keyword argument 'flags'
https://hg.mozilla.org/comm-central/rev/eecce9d6df787535c4339299b838d457dcbcc9af Bug 957911 - Remove config/configobj.py: keep comm-central in sync. rs,a=bustage-fix on CLOSED TREE
From the try results, it appears merely syncing c-c and m-c does not fix the problem.
I bet you are running this script with python 2.6 instead of 2.7 like everything else.
(In reply to Mike Hommey [:glandium] from comment #14) > I bet you are running this script with python 2.6 instead of 2.7 like > everything else. That was my first thought as well, but in the build log I only see references to 2.7: http://email@example.com/try-comm-central-linux/try-comm-central-linux-bm79-try1-build37.txt.gz But if this is indeed an issue with the python installed on the build machines, who would you suggest to contact?
(In reply to aleth [:aleth] from comment #15) > (In reply to Mike Hommey [:glandium] from comment #14) > > I bet you are running this script with python 2.6 instead of 2.7 like > > everything else. > > That was my first thought as well, but in the build log I only see > references to 2.7: There is in fact a reference to 2.6.6 being installed right at the beginning: INFO: Package python-2.6.6-29.el6.x86_64 already installed and latest version
nthomas: Could you help figure out why the comm-central builders are apparently using python 2.6 to run printconfigsetting.py at the beginning of the build? Thanks!
I'll be too busy for the next few days. I suggest you compare the setup in PLATFORM_VARS in http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla/thunderbird_config.py with the corresponding ones in http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla/config.py Ask in #releng if that doesn't help.
Filed a separate bug for the c-c issue.
You need to log in before you can comment on or make changes to this bug.