Feedback/TestPilot not packaged into windows installer for 4.0b1 build1

RESOLVED FIXED in mozilla2.0b1

Status

()

Core
Build Config
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: nthomas, Assigned: mossop)

Tracking

Trunk
mozilla2.0b1
x86
Windows Server 2003
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta1+)

Details

(Whiteboard: [4b1])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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

8 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

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

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

Updated

8 years ago
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
(Assignee)

Comment 9

8 years ago
Created attachment 454916 [details] [diff] [review]
patch rev 1

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

8 years ago
Attachment #454916 - Flags: review+
(Assignee)

Comment 10

8 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
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3b1
For future reference, was this needed for Mac and / or Linux as well?
(Assignee)

Comment 12

8 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.
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.
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.
You need to log in before you can comment on or make changes to this bug.