348575 - No GTK2 Seamonkey builds since August 9th

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[Boris Zbarsky [:bzbarsky]]

The last GTK2 Seamonkey build on the FTP site is 2006-08-09-01.  After that, there are two days of no -01 directory, followed by several days of that directory existing but being empty.

Looking at tinderbox, lhasa is building.  So the problem is presumably getting the builds pushed to the FTP site?

In any case, this is blocking me hunting down some Gecko regressions right now.  :(

Comment 1

[Andrew Schultz]

lhasa's build log includes

cp /builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/installer/../dist/*.tar.* /builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/installer/2006-08-14-13-trunk/
cp: cannot create regular file `/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/installer/2006-08-14-13-trunk/seamonkey-1.5a.en-US.linux-i686.tar.bz2': No such file or directory

Comment 2

[Chris Cooper [:coop] (he/him)]

I've reverted the tinderbox patches from 2006/07/09 (http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=preed&whotype=regexp&sortby=Date&hours=2&date=explicit&mindate=2006-08-09+12%3A00%3A00&maxdate=2006-08-09+13%3A00%3A00&cvsroot=%2Fcvsroot). Tinderbox has been clobbered and restarted.

Nothing obvious leaps out at me from those patches, but that patch is from the exact timeframe when lhasa failed. There is probably a subtle directory creation/naming difference in the script that we are missing.

Comment 3

[Chris Cooper [:coop] (he/him)]

(In reply to comment #2)
> I've reverted the tinderbox patches from 2006/07/09

Er, 2006/08/09. The bonsai query is correct though.

Comment 4

[Robert Kaiser]

Attachment: hacky workaround used on hoshi tinderbox

On my "hoshi" SeaMonkey Linuc tinderbox, I have this workaround in place. I'm not sure why this is needed, as before the if block, $stagedir should be created on all platforms, but somehow it sometimes fails on Linux, though it works perfectly on Windows and Mac.

Comment 5

[Andrew Schultz]

Oh!  I have that patch too on nye.  :)

The installer packaging nukes the directory.

Comment 6

[Robert Helmer [:rhelmer]]

Attachment: same hacky workaround, applies cleanly to trunk

Comment 7

[Robert Helmer [:rhelmer]]

This is temporary, until we figure out why this directory is getting blown away (presumably by the packaging process).

Comment 8

[Robert Helmer [:rhelmer]]

Checking in post-mozilla-rel.pl;
/cvsroot/mozilla/tools/tinderbox/post-mozilla-rel.pl,v  <--  post-mozilla-rel.plnew revision: 1.104; previous revision: 1.103
done


Let's leave this open until we have a better solution.

Comment 9

[Andrew Schultz]

So... the tbox scripts
1. create [tbox_path]/mozilla/installer/2006-08-15-15-trunk
2. create [tbox_path]/mozilla/installer
3. invoke installer packaging, which puts the results in [tbox_path]/mozilla/installer
4. expects the directory created in #1 to exist.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/tools/tinderbox/post-mozilla-rel.pl&rev=1.103&mark=240,254,266,319,1274#230
(stagedir is made to be a subdirectory of package_location on line 1274)

The difference on windows seems to be that it seems to use (and nuke) dist/stage/mozilla/ to stage files for the installer (outside of dist/install/ where it seems to put the final packages).  The toolkit packaging is similar.

I'll attach a patch that should make tbox happy.

Comment 10

[Andrew Schultz]

Attachment: patch

just nuke the stuff in installer/

Comment 11

[Robert Helmer [:rhelmer]]

(In reply to comment #10)
> Created an attachment (id=233935) [edit]
> patch
> 
> just nuke the stuff in installer/
> 

aj, can you land this patch? feel free to remove the hacky workaround patch too, or I will do it after you land.

Comment 12

[Andrew Schultz]

someone needs to pretend to know this code first  :)

Comment 13

[Robert Kaiser]

Comment on attachment 233935 [details] [diff] [review]
patch

OK, I'll pretend to know the code then ;-)
r=me, looks like we're cleaning up everything the installer build process needs.

What we're not doing now though is cleaning up the packaging directory tinderbox uses inside installer/ so we'll pile up those directories in installer/ which isn't good.

Currently, the call to packit() in http://lxr.mozilla.org/mozilla/source/tools/tinderbox/post-mozilla-rel.pl#1283
causes $local_build_dir to be created in that function (through the previously wiped away command and our dirty workaround).
After http://lxr.mozilla.org/mozilla/source/tools/tinderbox/post-mozilla-rel.pl#1326 copies that to a better location, I guess we could clean that up, so installer/ has no remnants of tinderbox's work.

Comment 14

[Andrew Schultz]

> What we're not doing now though is cleaning up the packaging directory
> tinderbox uses inside installer/

Right.  Windows doesn't do this either.  I assumed that the tbox scripts would take care of whatever garbage they create.  Do these installer packages just build up on the windows tboxes?

Comment 15

[Andrew Schultz]

Attachment: let tbox nuke its own staging dir

This implements what Robert mentioned in comment 13

Comment 16

[Andrew Schultz]

OK, I landed both patches.

KaiRo, should we land the packaging script fix on the branch?  I guess if you leave the hack in it won't matter.

Comment 17

[Robert Kaiser]

Andrew, I think a branch landing would probably be nice, esp. as this code is only used in SeaMonkey nowadays anyways and we haven't shipped a beta yet so we have no freeze in SeaMonkey-specific code at the moment.

Comment 18

[Robert Kaiser]

Comment on attachment 233935 [details] [diff] [review]
patch

This is a small, Linux installer only fix, very low risk, I think it would be good to take it on 1.8.0 as well, so a first a=me for SeaMonkey 1.0.6 (marking this with the 1.0.5 flag request as we don't have a 1.0.6 one yet), need another Council member to set to +

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 233935 [details] [diff] [review]
patch

a=biesi

Comment 20

[Andrew Schultz]

we need new keywords too...