stop generating PkgInfo files

[skurfer]

The code signing process doesn’t like finding files at the root of a bundle, it seems. There’s no reason to keep these files around on a modern system, is there?

[skurfer]

And with this frustration behind us, let me just say… Xcode 6 is frickin’ fast.

I think this is all that stands between us and 1.2.0 (and being ready for 10.10). Unless we want to wait on the icon loading thing.

[pjrobertson]

So I don't really know the point of the files, but I did some searching and it seems like you should still either use a pkginfo or at least specify certain keys in Info.plist (CFBundleSignature key - which we're not setting)

Apparently it's used by Finder to populate Open With... but that might be old. The main thing that makes me think the pkginfo (or at least the info it contains - what is specified in the Info.plist CFBundleSignature) is that iOS uses it - which isn't a hang up from OS 9 days.

[pjrobertson]

So I've just gone through and tried to codesign QS. It worked, after I did some twiddling:

• Opened both automator actions individually and re-built them with codesigning enabled (I suggest that you Rob build them with codesigning, add them to git and push)
• Changed the path for QSDefaults.plist and QSRegistrations.plist to be in the 'resources' folder, and not in 'Contents'. It seems codesign doesn't like anything in the contents folder - strangely, it didn't complain about pkginfo.

I'm running Xcode 6.0.1

[skurfer]

I tried that, and it made no difference. I’m not sure if I said, but the problem has always been with the frameworks. I’ve never gotten complaints about the app or the automator actions.

Quicksilver.app: unsealed contents present in the root directory of an embedded framework
In subcomponent: /private/tmp/QS/build/Release/Quicksilver.app/Contents/Frameworks/QSCore.framework
Quicksilver.app: rejected
source=no usable signature

Were you building from the GUI, or command line? (I couldn’t get either to work. Just curious. Command line is all that matters anyway.)

In any case, I agree that I should sign and push new Automator actions. We just need to figure out if that commit goes here, or on another branch with different changes.

[pjrobertson]

I was building from the GUI. Maybe the problem is is that you’re only setting a code signing attribute for the QS app alone, as opposed to all projects? I click the ‘Quicksilver’ project at the top of the file bar, then under build settings changed the code signing identity there (so it set it for all projects)

I couldn’t find it on last look - is there a page on the wiki where you’ve described how you build QS from the command line? I was going to try that and see what I got.
One other possibility - is your developer certificate for specific bundle IDs only (e.g. com.qsapp.Quicksilver) or is it generic for all bundle IDs? It may be causing problems, but unlikely

On 30 Medi 2014, at 13:46, Rob McBroom notifications@github.com wrote:

I tried that, and it made no difference. I’m not sure if I said, but the problem has always been with the frameworks. I’ve never gotten complaints about the app or the automator actions.

Quicksilver.app: unsealed contents present in the root directory of an embedded framework
In subcomponent: /private/tmp/QS/build/Release/Quicksilver.app/Contents/Frameworks/QSCore.framework
Quicksilver.app: rejected
source=no usable signature
Were you building from the GUI, or command line? (I couldn’t get either to work. Just curious. Command line is all that matters anyway.)

—
Reply to this email directly or view it on GitHub.

[skurfer]

I think I set it for the entire project, but like I said, only the command-line really matters.

I think it’s in the wiki somewhere, but to test the command-line build, just run Tools/qsrelease. You might want to comment out the DMG stuff to speed up testing.

[pjrobertson]

Alright, I had a play (I completely forgot about qsrelease - oops)

This works but I'm still not sure of the implications.
I'd tried changing the 'build' line of qsrelease:

xcodebuild -configuration Release -scheme 'Quicksilver Distribution' build CODE_SIGN_IDENTITY="ME" OTHER_CODE_SIGN_FLAGS="--deep">> $LOG

and it worked, except I ran into the problem of needing to codesign the automator bundles. The method you're using is probably better - since we don't want to have to re-codesign those every time they change.
Apple's spent enough time wasting our time now.

[pjrobertson]

Oh and no - let's not wait on the icon loading stuff for v1.2 ;-)

[pjrobertson]

P.S. you're right about Xcode 6. If Yosemite is anything like Xcode 6 then it'll be blazing!

[skurfer]

Cool. I’ll push the updated Automator action builds straight to master.

1.2.0 will hopefully go out tonight.