Closed Bug 305233 Opened 19 years ago Closed 18 years ago

pacifica tinderbox builds and Talkback.exe have wrong buildID, taken from last nightly

Categories

(Webtools Graveyard :: Tinderbox, defect)

x86
Windows 98
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 353747

People

(Reporter: hhschwab, Assigned: coop)

References

()

Details

tested on two days, I found pacifica tinderbox builds are having the BuildID of last nightly. Nightly: http://mozilla.osuosl.org/pub/mozilla.org/firefox/nightly/2005-08-19-07-trunk/ firefox-1.6a1.en-US.win32.zip 19-Aug-2005 07:52 6.4M firefox.exe as seen from Windows Explorer: 1.9a1: 2005081907, Freitag, 19. August 2005 07:49:26, 6861 KB Tinderbox: http://mozilla.osuosl.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/ firefox-1.6a1.en-US.win32.zip 19-Aug-2005 11:16 6.4M firefox.exe as seen from Windows Explorer: 1.9a1: 2005081907, Freitag, 19. August 2005 11:13:48, 6866 KB I also tested Talkback, it also contains the wrong buildID, so anybody reporting with a tinderbox build may report crap.
http://mozilla.osuosl.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/ firefox-1.6a1.en-US.win32.zip 20-Aug-2005 02:47 6.4M firefox.exe as seen from Windows Explorer: 1.9a1: 2005081922, Samstag, 20. August 2005 02:45:06, 6883 KB http://mozilla.osuosl.org/pub/mozilla.org/firefox/nightly/2005-08-19-23-trunk/ firefox-1.6a1.en-US.win32.zip 19-Aug-2005 23:22 6.4M firefox.exe as seen from Windows Explorer: 1.9a1: 2005081922, Freitag, 19. August 2005 23:17:52, 6866 KB This time, I first downloaded from tinderbox, to check the BuildID. I then supposed the 1922 nightly to be in the 1923 directory, downloaded and checked. I checked a crasher bug, and submitted talkback TB8545278X Then I downloaded the 2005081922 nightly from the 2005081923 directory, unzipped and found the talkback when I started talkback.exe , though that firefox still was unused. As I'm typing without seeing a cursor, crap seen past this will be from Bug 305239 Text is entered invisible and backwards into <textarea>
Assignee: nobody → chase
Component: Build Config → Tinderbox Configuration
Product: Core → mozilla.org
QA Contact: build-config → ccooper
Version: Trunk → other
still buggy, pacifica trunk tinderbox builds get the BuildID of the latest nightly. If there are 5 tinderbox builds between nightlies, and they differ in time and size, they don't differ in the buildID, that's the buildID of the preceding nightly. To clarify: I don't talk about the UserAgent, which only displays year+month+day, but I talk about BuildId which consists of year+month+day+hour In Firefox you can't see the build ID, you can see the buildID in Talkback Records or Windows Explorer properties. User Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051009 Firefox/1.6a1 BuildID from WindowsExplorer Properties of Firefox.exe: 1.9a1: 2005100807 URL & link text: http://mozilla.osuosl.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/firefox-1.6a1.en-US.win32.zip firefox-1.6a1.en-US.win32.zip 09-Oct-2005 10:18 6.5M Windows directory entry is showing the file time: Firefox.exe 7.018 KB Anwendung 09.10.05 03:17 A
If someone wants to work on this, address it by ensuring that $(objdir)/dist is removed before a build starts, then if necessary changing the Tinderbox build scripts so they don't build in fullsoft/ if it's not a cached build.
Assignee: chase → nobody
Status: NEW → ASSIGNED
ccooper@deadsquid.com, I'm guessing you wanted to assign to yourself?
Assignee: nobody → ccooper
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
The dist/ dir on pacifica is now being blanked for non-release builds. Please keep an eye on the tinderbox builds to see whether the BUILDIDs are now correct.
same error as before. I downloaded two tinderbox builds in succession, dated wednesday Oct 19th. about: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051019 Firefox/1.6a1 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051019 Firefox/1.6a1 about: doesn't show the hour, so the strings above are o.k. though the hour is seen in talkback records, and in properties of firefox.exe as seen from windows explorer: Windows Explorer Properties of Firefox.exe: 1.9a1: 2005101906 Mittwoch, 19. Oktober 2005 08:47:06 1.9a1: 2005101906 Mittwoch, 19. Oktober 2005 10:15:10 Same buildID, but different file times. tests made today: Nightly: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051022 Firefox/1.6a1 1.9a1: 2005102212 Samstag, 22. Oktober 2005 12:37:04 Tinderbox: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051023 Firefox/1.6a1 1.9a1: 2005102212 Sonntag, 23. Oktober 2005 05:23:38 Tinderbox file time: 2005-10-23 05:23 todays tinderbox build was showing yesterdays nightlies BuildID. todays nightly: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051023 Firefox/1.6a1 1.9a1: 2005102306 Sonntag, 23. Oktober 2005 06:37:52 tinderbox build: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051023 Firefox/1.6a1 1.9a1: 2005102306 Sonntag, 23. Oktober 2005 07:40:28 Tinderbox file time: 2005-10-23 07:40 So nightlies are updating the BuildID, tinderbox builds not,they are using the same one as the last nightly, but differ in file time. I'm using zip builds.
1.8 builds are also affected, download link for the nightly (D) from Pacifica: Different timestamps, same buildID: http://mozilla.osuosl.org/pub/mozilla.org/firefox/nightly/2005-10-24-01-mozilla1.8/ Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 1.8b5: 2005102400 Montag, 24. Oktober 2005 01:08:08 http://mozilla.osuosl.org/pub/mozilla.org/firefox/nightly/2005-10-24-04-mozilla1.8/ Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 1.8b5: 2005102404 Montag, 24. Oktober 2005 04:38:48 http://mozilla.osuosl.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-mozilla1.8/ Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 1.8b5: 2005102404 Montag, 24. Oktober 2005 05:39:54 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 1.8b5: 2005102404 Montag, 24. Oktober 2005 07:55:14 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 1.8b5: 2005102404 Montag, 24. Oktober 2005 08:52:50
(In reply to comment #3) > If someone wants to work on this, address it by ensuring that $(objdir)/dist is > removed before a build starts, then if necessary changing the Tinderbox build > scripts so they don't build in fullsoft/ if it's not a cached build. The build scripts already avoid rebuilding talkback unless both $cachebuild and $shiptalkback are true: if (!is_os2()) { processtalkback($cachebuild && $Settings::shiptalkback, $objdir, "$mozilla_build_dir/${Settings::Topsrcdir}"); } (http://lxr.mozilla.org/mozilla/source/tools/tinderbox/post-mozilla-rel.pl#1153) Is the build ID for the nightly being set in the talkback DLL and then being used unchanged for subsequent builds? I don't know enough about talkback or how the build ID is set to answer this question.
Pacifica had _many_ security updates pending, so I also took this opportunity to upgrade/reinstall cygwin as well. This in itself might be enough to fix the build ID problem, but Chase has also noticed some odd code in a build-script that looks like an attempt to fix this bug. However, the snippet is in the wrong spot and shouldn't even be affecting the build. Here's the errant code: http://lxr.mozilla.org/mozilla/source/tools/tinderbox/post-mozilla-rel.pl#1107 If the build ID is not fixed, this will be a good place to start looking.
bug still seen on Pacifica trunk Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060212 Firefox/1.6a1 nightly: 1.9a1: 2006021206 12. Februar 2006 07:26:08 WINNT 5.2 pacifica Depend release Started 06:27, finished 07:28 1 hour, 1 minute elapsed tinderbox: 1.9a1: 2006021206 12. Februar 2006 12:04:20 WINNT 5.2 pacifica Depend release Started 11:30, finished 12:04 34 minutes elapsed about:buildconfig Build platform target i586-pc-msvc Build tools Compiler Version Compiler flags $(CYGWIN_WRAPPER) cl 12.00.8804 -TC -nologo -W3 -Gy -Fd$(PDBFILE) $(CYGWIN_WRAPPER) cl 12.00.8804 -TP -nologo -W3 -Gy -Fd$(PDBFILE) Configure arguments --enable-application=browser --enable-update-channel=nightly --enable-optimize --disable-debug --disable-tests --enable-static --disable-shared --enable-svg --enable-canvas --enable-update-packaging
I just updated the build scripts on pacifica; perhaps worth retesting to see if that perturbed this in any way.
(In reply to comment #11) > I just updated the build scripts on pacifica; perhaps worth retesting to see if > that perturbed this in any way. Still the same bug: the 22h tinderbux build contains the 06h nightlies talkback filesizes and dates are different, versioning is the same: Nightly: firefox-1.6a1.en-US.win32.zip 6.955.008 bytes 1.9a1: 2006021705 17. Februar 2006 06:35:06 Tinderbox: firefox-1.6a1.en-US.win32.zip 6.959.104 bytes 1.9a1: 2006021705 17. Februar 2006 22:13:02 files in the folder talkback@mozilla.org and subfolder components are identical. So I suppose download isn't needed to check this bug, it would be sufficient to check if talkback is contained in the zip, a tinderbox build without should be at least 200 kb smaller than the preceding nightly with talkback. If the tinderbox build has roughly same size as the nightly, I'll assume it contains talkback, and if it contains talkback, the windows-xpi directory should have about the same timestamp like the tinderbox build, not like the timestamp of the nightly. Have a look at: http://mozilla.osuosl.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/ http://mozilla.osuosl.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/windows-xpi/ files in the windows-xpi folder are from the nightly, the tinderbox zip build packages the talkback.xpi from the nightly.
bug still seen: tinderbox builds are having wrong BuildID, Talkback will sent wrong BuildID! Steps to reproduce: 1. download nightly (I use zips) 2. download a tinderboxversion some time later, but before next nightly. short version: open zips, compare file time of firefox\firefox.exe, different firefox\removed-files, identical firefox\extensions\talkback@mozilla.org\chrome.manifest, identical firefox\extensions\talkback@mozilla.org\install.rdf, identical firefox\extensions\talkback@mozilla.org\components\*.*, identical long version, needs unzipping the zips into directories where a directory firefox doesn't exist and can be created: 3. start firefox, compare about: for each version, version will show the same useragent. 4. compare properties from WindowsExplorer for firefox.exe: - version identical, like maybe 1.8.1b1: 2006072203 - filetimes different, like 22. Juli 2006 04:53:48 and 23. Juli 2006 02:19:52 - md5 different 5. compare timestamp of talkback.exe: identical test done this way using: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-07-22-03-mozilla1.8/firefox-2.0b1.en-US.win32.zip Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060722 BonEcho/2.0b1 1.8.1b1: 2006072203 22. Juli 2006 04:53:48 5a877e466eeb9dd494887b0b75d4761c http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-vm-mozilla1.8/firefox-2.0b1.en-US.win32.zip Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060722 BonEcho/2.0b1 1.8.1b1: 2006072203 23. Juli 2006 02:19:52 7031e4e2b8e12955b6909ba229367c4b firefox\extensions\talkback@mozilla.org\components\talkback.exe and all the other files in that folder: 22. Juli 2006 04:53:50
Summary: pacifica tinderbox builds have wrong buildID → pacifica tinderbox builds and Talkback.exe have wrong buildID, taken from last nightly
*** Bug 348078 has been marked as a duplicate of this bug. ***
This bug has more historical info, but I'm dupping it to what the issue seems to be. Feel free to boink me on the head if you think that's incorrect. *** This bug has been marked as a duplicate of 353747 *** *** This bug has been marked as a duplicate of 353747 ***
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Component: Tinderbox Configuration → Tinderbox
Product: mozilla.org → Webtools
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.