Closed Bug 1084139 Opened 12 years ago Closed 4 years ago

Due to Bug 1074019, OSX64 tests are failing from not finding the buildid.

Categories

(SeaMonkey :: Release Engineering, defect)

Product:
SeaMonkey
Component:
Release Engineering
Version:
SeaMonkey 2.31 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ewong, Assigned: ewong)

References

Details

Attachments

(1 file, 2 obsolete files)

buildbotcustom changes (v2)
1.94 KB, patch
Callek
: review-
Details | Diff | Splinter Review
Bug 1074019 made changes to the OSX file structure. SeaMonkey's tests (I believe the ReLeng steps) need to be fixed.
i.e. this: python /builds/slave/test/tools/buildfarm/utils/printbuildrev.py ./SeaMonkeyDebug.app/Contents/MacOS in dir /builds/slave/test/build (timeout 1200 secs) watching logfiles {} argv: ['python', '/builds/slave/test/tools/buildfarm/utils/printbuildrev.py', './SeaMonkeyDebug.app/Contents/MacOS'] environment: Apple_PubSub_Socket_Render=/tmp/launch-igMgqT/Render CVS_RSH=ssh DISPLAY=/tmp/launch-D1NTiV/org.x:0 HOME=/Users/seabld LOGNAME=seabld PATH=/tools/buildbot/bin:/tools/python/bin:/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin PWD=/builds/slave/test/build PYTHONPATH=/tools/buildbot/lib/python2.7/site-packages SHELL=/bin/bash SSH_AUTH_SOCK=/tmp/launch-EQ9Czj/Listeners TMPDIR=/var/folders/bm/kc_3cyjj2v15yn2741pj8s6r0000gn/T/ USER=seabld VERSIONER_PYTHON_PREFER_32_BIT=no VERSIONER_PYTHON_VERSION=2.7 __CF_USER_TEXT_ENCODING=0x1F5:0:0 using PTY: False Traceback (most recent call last): File "/builds/slave/test/tools/buildfarm/utils/printbuildrev.py", line 14, in <module> buildid = appini.get('App', 'BuildID') File "/tools/python27/lib/python2.7/ConfigParser.py", line 607, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'App' program finished with exit code 1 elapsedTime=0.036184
OS: Windows Vista → Mac OS X
FYI Thunderbird has the same problem.
Attached patch config changes (v1) (obsolete) — — Splinter Review
Attachment #8507649 - Flags: review?(bugspam.Callek)
Attached patch buildbotcustom changes (v1) (obsolete) — — Splinter Review
Attachment #8507650 - Flags: review?(bugspam.Callek)
Attachment #8507649 - Flags: review?(bugspam.Callek)
Attachment #8507650 - Flags: review?(bugspam.Callek)
Blocks: 1072713
Attachment #8507649 - Attachment is obsolete: true
Attachment #8507650 - Attachment is obsolete: true
Attachment #8509127 - Flags: review?(bugspam.Callek)
Blocks: 1085762
Comment on attachment 8509127 [details] [diff] [review] buildbotcustom changes (v2) Review of attachment 8509127 [details] [diff] [review]: ----------------------------------------------------------------- this alone won't do it, since its returning a *file* path not its containing directory. I'm also not sure on efficiency here.... Also note how exedir goes to: ./DailyDebug.app/Contents/MacOS for thunderbird, while the application.ini is in ./DailyDebug.app/Contents/Resources/ Maybe just a normpath against ./%{exepath}s/../Resources/ would suffice? This will *need* to be tested though, do we have any active TB or seamonkey trees atm without v2 signing format setup?
Attachment #8509127 - Flags: review?(bugspam.Callek) → review-
(In reply to Justin Wood (:Callek) from comment #76) > Comment on attachment 8509127 [details] [diff] [review] > buildbotcustom changes (v2) > > Review of attachment 8509127 [details] [diff] [review]: > ----------------------------------------------------------------- > > this alone won't do it, since its returning a *file* path not its containing > directory. Ah right. I realized now that printbuildrev.py already tags the ini file at the end of the path. Duh > > I'm also not sure on efficiency here.... Yes, that was one of my concerns as well. > > Also note how exedir goes to: > ./DailyDebug.app/Contents/MacOS > > for thunderbird, while the application.ini is in > ./DailyDebug.app/Contents/Resources/ > > Maybe just a normpath against ./%{exepath}s/../Resources/ would suffice? > The issue I feel with this approach with relative dirs is the possibility of breakage should Apple decide a v3. I figured letting the slave find the ini path would be better, even if it could potentially slow down the system a bit.

I don't believe this is applicable anymore.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: