Closed
Bug 575566
Opened 14 years ago
Closed 14 years ago
Feedback/TestPilot not packaged into windows installer for 4.0b1 build1
Categories
(Firefox Build System :: General, defect)
Tracking
(blocking2.0 beta1+)
RESOLVED
FIXED
mozilla2.0b1
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta1+ |
People
(Reporter: nthomas, Assigned: mossop)
References
Details
(Whiteboard: [4b1])
Attachments
(1 file)
9.61 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Release/1277780816.1277788245.31160.gz
Error: file ../../dist/bin/extensions/testpilot@labs.mozilla.com/components is not a file or is not readable (package-manifest, browser, 263).
Error: file ../../dist/bin/extensions/testpilot@labs.mozilla.com/components/TestPilot.js is not a file or is not readable (package-manifest, browser, 263).
Error: file ../../dist/bin/extensions/testpilot@labs.mozilla.com/content is not a file or is not readable (package-manifest, browser, 263).
etc etc
No such errors in logs for zip and complete mar.
Reporter | ||
Comment 1•14 years ago
|
||
First directory and file appear accessible:
cltbld@MW32-IX-SLAVE03 /e/builds/moz2_slave/win32_build/build/obj-firefox
$ ls -la dist/bin/extensions/testpilot@labs.mozilla.com/components/
total 4
drwxr-xr-x 2 cltbld Administrators 0 Jun 28 21:10 .
drwxr-xr-x 10 cltbld Administrators 0 Jun 28 21:10 ..
-rw-r--r-- 1 cltbld Administrators 3426 Jun 28 21:57 TestPilot.js
Reporter | ||
Comment 2•14 years ago
|
||
Here are the two calls that use the manifest, first the zip then the exe:
/bin/sh /e/builds/moz2_slave/win32_build/build/build/msys-perl-wrapper -I/e/builds/moz2_slave/win32_build/build/xpinstall/packager -e 'use Packager; Packager::Copy( "/e/builds/moz2_slave/win32_build/build/obj-firefox/browser/installer/../../dist", "/e/builds/moz2_slave/win32_build/build/obj-firefox/browser/installer/../../dist/firefox", "package-manifest", "dos", 1, 0, 1);'
/bin/sh /e/builds/moz2_slave/win32_build/build/build/msys-perl-wrapper -I/e/builds/moz2_slave/win32_build/build/xpinstall/packager -e 'use Packager; Packager::Copy( "../../dist", "../../installer-stage/nonlocalized", "package-manifest", "dos", 1, 0, 1 , "xpcom" , "browser" );'
Note absolute vs relative paths there. Perhaps that causes problems when using
@BINPATH@/extensions/testpilot@labs.mozilla.com/*
which contains subdirectories. Can't see any other examples of deep dir structures in package-manifest.in.
Comment 3•14 years ago
|
||
Using Windows 4.0b1 Build 1 - the odd thing is that I see the Add-On listed in the Add-Ons Manager, so I guess that part of the install worked:
Feedback 1.0rc1
Updated Tuesday, June 29, 2010
Looks enabled, too, but there's no visible UI.
blocking2.0: --- → beta1+
Comment 4•14 years ago
|
||
(In reply to comment #3)
> Feedback 1.0rc1
> Updated Tuesday, June 29, 2010
>
> Looks enabled, too, but there's no visible UI.
I was about to also file that bug. Looking into the extensions folder shows that we only ship the install.rdf and the manifest. All other files are missing. That's the reason why we show it in the Add-ons Manager.
Whiteboard: [4b1]
Assignee | ||
Comment 5•14 years ago
|
||
I saw some problems similar to this in my first attempts at getting it packaged when symlinks were involved. I suspect the installer packaging just isn't smart enough to handle wildcards for directories which unfortunately probably means we're going to have to list every single file from the Feedback extension in package-manifest.in. I can create a patch to do that when I'm in the office in about 15 minutes.
Comment 6•14 years ago
|
||
(In reply to comment #5)
> I saw some problems similar to this in my first attempts at getting it packaged
> when symlinks were involved. I suspect the installer packaging just isn't smart
> enough to handle wildcards for directories which unfortunately probably means
> we're going to have to list every single file from the Feedback extension in
> package-manifest.in. I can create a patch to do that when I'm in the office in
> about 15 minutes.
Thanks, Dave. We'll have to do a build2 for this, but the OSX and Linux versions should be bitwise identical. Only question is whether or not we think we need a fix for bug 575597 as well.
Comment 7•14 years ago
|
||
There may be issues with wildcards and subdirectories, I'm not 100% sure. I don't trust the packaging code very much. We use wildcards currently, but probably only to package all the *files* in a directory.
Comment 8•14 years ago
|
||
Yep, I got burned that way on Tb's package-manifest.in - on Linux and Mac, just @BINPATH@/extensions/testpilot@labs.mozilla.com/ without even the * will recursively package all the files in all the subdirectories, but on Windows, you need the * and you need one for every subdirectory (but at least you don't have to list every single file, just every subdirectory/*).
Updated•14 years ago
|
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•14 years ago
|
||
This patch lists all the files. I tried wildcards and while it seemed to be working it was still throwing lots of errors so I think this is the safest solution for right now.
I have verified it by building the installer, installing it and then comparing the directory installed to the test pilot source in the tree.
Assignee: sdwilsh → dtownsend
Updated•14 years ago
|
Attachment #454916 -
Flags: review+
Assignee | ||
Comment 10•14 years ago
|
||
Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/48d7d96aba6a
And the relbranch: http://hg.mozilla.org/mozilla-central/rev/df280dd46a5f
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3b1
Comment 11•14 years ago
|
||
For future reference, was this needed for Mac and / or Linux as well?
Assignee | ||
Comment 12•14 years ago
|
||
(In reply to comment #11)
> For future reference, was this needed for Mac and / or Linux as well?
No, OSX dmg, Linux tar.bz and Windows zip all packaged fine with the wildcard. It was only the Windows installer that failed.
I'd like to try to solve that for b2 so we don't have to maintain this list so much.
Comment 13•14 years ago
|
||
Sounds good... to be clear though, I believe it is the Windows installer build scripts which copy the files to installer-stage and not the Windows installer itself. This should make it a lot easier to fix as well.
Comment 14•14 years ago
|
||
Filed bug 575838.
Comment 15•14 years ago
|
||
btw: it appears it just doesn't support copying sub-directories so specifying each directory with /* at the end would have sufficed.
Comment 16•14 years ago
|
||
I also updated Firefox's package-manifest when I fixed bug 575838... this should no longer be a problem.
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•