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.

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

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.

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.

(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.

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.

(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.

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.

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/*).

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.

Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/48d7d96aba6a And the relbranch: http://hg.mozilla.org/mozilla-central/rev/df280dd46a5f

For future reference, was this needed for Mac and / or Linux as well?

(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.

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.

Filed bug 575838.

btw: it appears it just doesn't support copying sub-directories so specifying each directory with /* at the end would have sufficed.

I also updated Firefox's package-manifest when I fixed bug 575838... this should no longer be a problem.