pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Core Data -- treats Python app as "another application" when trying to save data

[Bill B. <bb...@ma...>]

On Nov 23, 2007, at 5:58 PM, s s wrote:
> 	I've got a mixed Python/objc application using Core Data.
>
> 	My Python code is triggered on a button press and adds data via =
the :
>
> 	=20
> NSEntityDescription=20
> .pyobjc_classMethods=20
> .insertNewObjectForEntityForName_inManagedObjectContext_(...)
>
> 	All goes fine, and my data is reflected in the interface =
properly.
>
> 	When I go to save the document, I get the message:
>
> 		This document=92s file has been changed by another =
application since =20
> you opened or saved it.
>
> 	It seems like the Python portion of my app is being treated as =20=

> "another application."
>
> 	Can anyone tell me where there's docs on this or how to resolve =
it?

That is completely bizarre.  I would suggest you use fs_usage to =20
figure out where the second write is coming from.

b.bum=

[Pyobjc-dev] Core Data -- treats Python app as "another application" when trying to save data

[s s <li...@in...>]

Hi!

	I've got a mixed Python/objc application using Core Data.

	My Python code is triggered on a button press and adds data via =
the :

	=20
NSEntityDescription=20
.pyobjc_classMethods=20
.insertNewObjectForEntityForName_inManagedObjectContext_(...)

	All goes fine, and my data is reflected in the interface =
properly.

	When I go to save the document, I get the message:

		This document=92s file has been changed by another =
application since =20
you opened or saved it.

	It seems like the Python portion of my app is being treated as =20=

"another application."

	Can anyone tell me where there's docs on this or how to resolve =
it?

Thankss,

S

[Pyobjc-dev] Interface Builder 3.0 plug-in using pyobjc

[brew <bru...@ya...>]

Hi list,

I'm quite new to cocoa/objective-c/pyobjc, so please forgive the  
intrusion of my learning curve onto the list.

I have a Cocoa-Python project that uses the Xcode 3.0 templates.  
There's a custom view that I'd like to expose the bindings of to use  
in the bindings panel of Interface Builder. I think I'm right in  
saying that I need to create my custom view as an .ibplugin for the  
Interface Builder library. At least that seems to be the case if I was  
talking about a straight Objective-C project. (I'm quite happy to be  
corrected on this.)

I've worked through the IB plugin guide (http://developer.apple.com/documentation/DeveloperTools/Conceptual/IBPlugInGuide/index.html#/ 
/apple_ref/doc/uid/TP40004323) but can't figure out how to load my  
python class that codes the view.

My first thought was that the ibplugin should be an Objective-C  
project that uses a python plugin (as per the tutorial here: http://pyobjc.sourceforge.net/doc/extending_objc_with_python.php 
  and some info from here: http://www.jonathansaggau.com/blog/2006/07/python_from_objectivec.html) 
.

Can I have any pointers that may help in setting up an .ibplugin  
project that uses pyobjc.

many thanks,
brook

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Bill B. <bb...@ma...>]

On Nov 21, 2007, at 11:28 PM, Ronald Oussoren wrote:
> I agree. I've filed a bug for this as radar #5610558. Feel free to  
> do the same to boost the priority of this issue.

No need -- I filed the bug directly earlier today, including a  
description of the severity.   I'll follow up with the appropriate  
folks on Monday.   If you have specific notes about failure modes or  
severity that you want added to the discussion, send them to me  
directly and I'll add 'em to the bug.

rdar://5610412 is the master bug, in this case, if anyone needs to ask  
ADC for current status.

b.bum

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Ronald O. <ron...@ma...>]

On 21 Nov, 2007, at 22:41, Jack Jansen wrote:

>
> On  20-Nov-2007, at 19:03 , Ronald Oussoren wrote:
>> Py2app isn't signing code. The problem is that the py2app  
>> executable stub inside the py2app package is signed by Apple (it  
>> isn't signed in the repository).
> Interesting. The first question that comes to mind is: Should Apple  
> be signing those stubs in the first place? Do they sign other  
> components that are going to be repackaged and redistributed by the  
> end user (such as static libraries)? I'm tempted to say Apple should  
> not sign the stub.
>
> And if Apple indeed signed the stub on purpose they should allow for  
> the signature to be removed somehow,

I agree. I've filed a bug for this as radar #5610558. Feel free to do  
the same to boost the priority of this issue.

Ronald

>
> --
> Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma  
> Goldman
>
>

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Bill B. <bb...@ma...>]

On Nov 21, 2007, at 1:41 PM, Jack Jansen wrote:
> On  20-Nov-2007, at 19:03 , Ronald Oussoren wrote:
>> Py2app isn't signing code. The problem is that the py2app  
>> executable stub inside the py2app package is signed by Apple (it  
>> isn't signed in the repository).
> Interesting. The first question that comes to mind is: Should Apple  
> be signing those stubs in the first place? Do they sign other  
> components that are going to be repackaged and redistributed by the  
> end user (such as static libraries)? I'm tempted to say Apple should  
> not sign the stub.

It was a default that fell through the cracks;  the stubs were not  
added to an exception list *not* to be signed during the mastering  
process.

Bug filed.

b.bum

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[James R E. <ea...@ba...>]

On Nov 21, 2007, at 14:13 , Ben Artin wrote:

>> And if Apple indeed signed the stub on purpose they should allow for
>> the signature to be removed somehow,
>
> Well, it can be removed by resigning the bundle with your own secure
> identity, which you should do anyway.


Thanks, Ben.  You are exactly correct, and this is exactly what I was  
trying to do.  The catch is that the normal codesigning procedure will  
gripe that the code is already signed, so you'll have to force it with  
the -f option (e.g. codesign -fs <myidentity> <my.app>).

James

--
Against stupidity the very Gods themselves contend in vain.

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Ben A. <be...@ar...>]

> And if Apple indeed signed the stub on purpose they should allow for  
> the signature to be removed somehow,

Well, it can be removed by resigning the bundle with your own secure  
identity, which you should do anyway.

--

<http://artins.org/ben>

"It takes a great deal of bravery to stand up to our enemies,
but just as much to stand up to our friends" -- Albus Dumbledore

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Jack J. <Jac...@cw...>]

On  20-Nov-2007, at 19:03 , Ronald Oussoren wrote:
> Py2app isn't signing code. The problem is that the py2app  
> executable stub inside the py2app package is signed by Apple (it  
> isn't signed in the repository).
Interesting. The first question that comes to mind is: Should Apple  
be signing those stubs in the first place? Do they sign other  
components that are going to be repackaged and redistributed by the  
end user (such as static libraries)? I'm tempted to say Apple should  
not sign the stub.

And if Apple indeed signed the stub on purpose they should allow for  
the signature to be removed somehow,
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman

Re: [Pyobjc-dev] Compile problems under Leopard

[Bill B. <bb...@ma...>]

On Nov 21, 2007, at 8:04 AM, Ronald Oussoren wrote:
> I meant (1), if you build PyObjC on Tiger it should work on Leopard.

I can confirm that it does work fine across the handful of built  
PyObjC apps that I have had sitting on my system since Tiger.

b.bm

Re: [Pyobjc-dev] Compile problems under Leopard

[Ronald O. <ron...@ma...>]

 
On Wednesday, November 21, 2007, at 04:40PM, "James R Eagan" <ea...@ba...> wrote:
>On Nov 21, 2007, at 01:46 , Ronald Oussoren wrote:
>
>> PyObjC 1.4 does not support Leopard and never will.
>
>Are you saying that (1) PyObjC 1.4 will never be installable and  
>usable for developing applications on Leopard, (2) that applications  
>built using PyObjC 1.4 [on Tiger] will not run properly on Leopard, or  
>(3) both?

I meant (1), if you build PyObjC on Tiger it should work on Leopard.

Ronald

Re: [Pyobjc-dev] Compile problems under Leopard

[James R E. <ea...@ba...>]

On Nov 21, 2007, at 01:46 , Ronald Oussoren wrote:

> PyObjC 1.4 does not support Leopard and never will.

Are you saying that (1) PyObjC 1.4 will never be installable and  
usable for developing applications on Leopard, (2) that applications  
built using PyObjC 1.4 [on Tiger] will not run properly on Leopard, or  
(3) both?

I assume you just meant (1), but if you did mean (3), what problems  
arise?  So far, I've been fortunate enough not to see any issues arise  
in my 1.4-built targets on Leopard.  Is that to be expected, or have I  
just been lucky/not looking hard enough?

Thanks!
James

--
The embarassing thing is that the salad dressing
is outgrossing my films.
		-- Paul Newman

Re: [Pyobjc-dev] Compile problems under Leopard

[Ronald O. <ron...@ma...>]

 
On Wednesday, November 21, 2007, at 04:31AM, "Nathan" <nat...@gm...> wrote:
>Hmmm, so...then I suppose the bug with Macports is that it's trying to
>build it as a dependency of py-game at all?
>
>Maybe I can modify the py-game portfile myself and remove the pyobjc
>1.4 dependency.

PyObjC 1.4 does not support Leopard and never will.  I have no idea if pygame works with PyObjC 2.0.

BTW. AFAIK there is no macports portfile for PyObjC 2.0, and that wouldn't make much sense until PyObjC 2.0 supports Tiger as well.

Ronald

>
>~ Nathan
>
>On Nov 20, 2007 8:28 PM, Ben Artin <be...@ar...> wrote:
>> > What's the status of Leopard support for pyobjc?
>>
>> It's included with the OS, as is Python 2.5.1.
>>
>> --
>>
>> <http://artins.org/ben>
>>
>> A: Because it reverses the logical flow of conversation.
>> Q: Why is top posting frowned upon?
>>
>>
>>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] NSAnyEventMask depythonifies as int, not uint in pyobjc2

[Ronald O. <ron...@ma...>]

 
On Wednesday, November 21, 2007, at 02:11AM, "Barry Wark" <bar...@gm...> wrote:
>I'm not tracking the pyobjc2 sources very closely, so forgive me if
>this has already been fixed....
>
>I noticed that the PyInterpreter example from pyobjc2 no longer works
>in pyobjc2. It appears that NSAnyEventMask (imported from AppKit)
>depythonifies as -1 (type int) rather than an unsigned int, thus
>causing an exception when it's used as a parameter to
>NSApplication.nextEventMatchingMask_untilDate_inMode_dequeue_.
>
>Changing NSAnyEventMask to 0xffffffff (its definition, per the docs)
>appears to solve the problem. Is this a BridgeSupport issue?

This is a bridgesupport issue, but one that could be worked around.  Or rather, it is misuse of enums by some Apple engineers (not that they are the only ones doing this): NSAnyEventMask is defined inside an enum and is therefore a signed integer, not an unsigned one as the author of that code obviously whishes it to be.  This is not a problem in (Objective-)C because NSAnyEventMask is automaticly casted to an unsigned integer when needed.

BTW. NSAnyEventMask is not 0xFFFFFFFF, but NSUIntegerMax, which has a different value on 64-bit builds.

Ronald

>
>Barry
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] Compile problems under Leopard

[Ben A. <be...@ar...>]

> Hmmm, so...then I suppose the bug with Macports is that it's trying to
> build it as a dependency of py-game at all?

It depends on what the MacPorts policy on such things is; I believe in  
the past they've always relied on their own build of Python and  
associated libraries. They may continue doing so on Leopard.

The problem that you will run into is that the pyobjc package in  
MacPorts currently has no maintainer, so if you want to get it changed  
(for example, by updating it to pyobjc2), you'll probably have to do  
the work yourself or wait for someone in a similar predicament to do  
it for you.

> Maybe I can modify the py-game portfile myself and remove the pyobjc  
> 1.4 dependency.

That will give you a pygame in MacPorts' package folder rather than  
the system package folder; this is not the right thing, but it may get  
you closer to being able to ignore the problem -- or it may not work  
at all. Depends on how complex pygame is.

--

<http://artins.org/ben>

"It takes a great deal of bravery to stand up to our enemies,
but just as much to stand up to our friends" -- Albus Dumbledore

Re: [Pyobjc-dev] Compile problems under Leopard

[Nathan <nat...@gm...>]

Hmmm, so...then I suppose the bug with Macports is that it's trying to
build it as a dependency of py-game at all?

Maybe I can modify the py-game portfile myself and remove the pyobjc
1.4 dependency.

~ Nathan

On Nov 20, 2007 8:28 PM, Ben Artin <be...@ar...> wrote:
> > What's the status of Leopard support for pyobjc?
>
> It's included with the OS, as is Python 2.5.1.
>
> --
>
> <http://artins.org/ben>
>
> A: Because it reverses the logical flow of conversation.
> Q: Why is top posting frowned upon?
>
>
>

Re: [Pyobjc-dev] Compile problems under Leopard

[Ben A. <be...@ar...>]

> What's the status of Leopard support for pyobjc?

It's included with the OS, as is Python 2.5.1.

--

<http://artins.org/ben>

A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?

[Pyobjc-dev] Compile problems under Leopard

[Nathan <nat...@gm...>]

What's the status of Leopard support for pyobjc?  I tried searching
the list archives on sourceforge, but apparently they're having some
problems currently.

If this question has been asked a lot, feel free to just point me to
where to start reading.  If not, here's the problem I have:

On Leopard, I'm using MacPorts to try to install pyobjc 1.4 ("sudo
port install py-pyobjc"), which fails with:

In file included from Modules/SyncServices/_SyncServices.m:23:
build/codegen/_SyncServices_Enum.inc:49: error:
'ISyncSessionDriverModeFast' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:49: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:49: warning: (near initialization
for 'enum_table[10].value')
build/codegen/_SyncServices_Enum.inc:50: error:
'ISyncSessionDriverModeSlow' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:50: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:50: warning: (near initialization
for 'enum_table[11].value')
build/codegen/_SyncServices_Enum.inc:51: error:
'ISyncSessionDriverModeRefresh' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:51: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:51: warning: (near initialization
for 'enum_table[12].value')
build/codegen/_SyncServices_Enum.inc:52: error:
'ISyncSessionDriverChangeRefused' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:52: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:52: warning: (near initialization
for 'enum_table[13].value')
build/codegen/_SyncServices_Enum.inc:53: error:
'ISyncSessionDriverChangeAccepted' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:53: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:53: warning: (near initialization
for 'enum_table[14].value')
build/codegen/_SyncServices_Enum.inc:54: error:
'ISyncSessionDriverChangeIgnored' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:54: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:54: warning: (near initialization
for 'enum_table[15].value')
build/codegen/_SyncServices_Enum.inc:55: error:
'ISyncSessionDriverChangeError' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:55: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:55: warning: (near initialization
for 'enum_table[16].value')
build/codegen/_SyncServices_Enum.inc:62: error:
'ISyncSessionClientAlreadySyncingError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:62: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:62: warning: (near initialization
for 'enum_table[17].value')
build/codegen/_SyncServices_Enum.inc:63: error:
'ISyncSessionUserCanceledSessionError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:63: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:63: warning: (near initialization
for 'enum_table[18].value')
build/codegen/_SyncServices_Enum.inc:64: error:
'ISyncSessionDriverRegistrationError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:64: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:64: warning: (near initialization
for 'enum_table[19].value')
build/codegen/_SyncServices_Enum.inc:65: error:
'ISyncSessionDriverPullFailureError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:65: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:65: warning: (near initialization
for 'enum_table[20].value')
build/codegen/_SyncServices_Enum.inc:66: error:
'ISyncSessionDriverFatalError' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:66: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:66: warning: (near initialization
for 'enum_table[21].value')
error: command 'gcc' failed with exit status 1
Error: Target org.macports.build returned: shell command " cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-pyobjc/work/pyobjc-1.4"
&& /opt/local/bin/python2.4 setup.py build " returned error 1
Command output: build/codegen/_SyncServices_Enum.inc:51: warning:
missing initializer
build/codegen/_SyncServices_Enum.inc:51: warning: (near initialization
for 'enum_table[12].value')
build/codegen/_SyncServices_Enum.inc:52: error:
'ISyncSessionDriverChangeRefused' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:52: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:52: warning: (near initialization
for 'enum_table[13].value')
build/codegen/_SyncServices_Enum.inc:53: error:
'ISyncSessionDriverChangeAccepted' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:53: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:53: warning: (near initialization
for 'enum_table[14].value')
build/codegen/_SyncServices_Enum.inc:54: error:
'ISyncSessionDriverChangeIgnored' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:54: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:54: warning: (near initialization
for 'enum_table[15].value')
build/codegen/_SyncServices_Enum.inc:55: error:
'ISyncSessionDriverChangeError' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:55: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:55: warning: (near initialization
for 'enum_table[16].value')
build/codegen/_SyncServices_Enum.inc:62: error:
'ISyncSessionClientAlreadySyncingError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:62: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:62: warning: (near initialization
for 'enum_table[17].value')
build/codegen/_SyncServices_Enum.inc:63: error:
'ISyncSessionUserCanceledSessionError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:63: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:63: warning: (near initialization
for 'enum_table[18].value')
build/codegen/_SyncServices_Enum.inc:64: error:
'ISyncSessionDriverRegistrationError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:64: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:64: warning: (near initialization
for 'enum_table[19].value')
build/codegen/_SyncServices_Enum.inc:65: error:
'ISyncSessionDriverPullFailureError' undeclared here (not in a
function)
build/codegen/_SyncServices_Enum.inc:65: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:65: warning: (near initialization
for 'enum_table[20].value')
build/codegen/_SyncServices_Enum.inc:66: error:
'ISyncSessionDriverFatalError' undeclared here (not in a function)
build/codegen/_SyncServices_Enum.inc:66: warning: missing initializer
build/codegen/_SyncServices_Enum.inc:66: warning: (near initialization
for 'enum_table[21].value')
error: command 'gcc' failed with exit status 1

Warning: the following items did not execute (for py-pyobjc):
org.macports.activate org.macports.build org.macports.destroot
org.macports.install
Error: The following dependencies failed to build: py-pyobjc
Error: Status 1 encountered during processing.

[Pyobjc-dev] NSAnyEventMask depythonifies as int, not uint in pyobjc2

[Barry W. <bar...@gm...>]

I'm not tracking the pyobjc2 sources very closely, so forgive me if
this has already been fixed....

I noticed that the PyInterpreter example from pyobjc2 no longer works
in pyobjc2. It appears that NSAnyEventMask (imported from AppKit)
depythonifies as -1 (type int) rather than an unsigned int, thus
causing an exception when it's used as a parameter to
NSApplication.nextEventMatchingMask_untilDate_inMode_dequeue_.

Changing NSAnyEventMask to 0xffffffff (its definition, per the docs)
appears to solve the problem. Is this a BridgeSupport issue?

Barry

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Ronald O. <ron...@ma...>]

On 20 Nov, 2007, at 19:30, Kevin Walzer wrote:

> Ronald Oussoren wrote:
>> Py2app isn't signing code. The problem is that the py2app  
>> executable stub inside the py2app package is signed by Apple (it  
>> isn't signed in the repository).
>> I don't know how to remove that signature, but you can download the  
>> stub executable from pyobjc's repository (downloading from https://svn.red-bean.com/pyobjc/branches/pyobjc2/py2app/py2app/apptemplate/prebuilt/main 
>>  might work for that)
>
> I don't quite understand the problem here, but do these issues mean  
> it's a Bad Idea to use the Apple-shipped py2app and PyObjC? I was  
> planning on doing this when I upgraded to Leopard.

Apple-shipped PyObjC and py2app are good enough. The issue with py2app  
is pretty small, and can be worked around by replacing two files in  
the py2app package. There are also a number of small bugs in the  
pyobjc-core package, but nothing major.

I will provide update packages some time in the future, but I have no  
idea when that will be.

Ronald

>
>
> --Kevin
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Bill B. <bb...@ma...>]

On Nov 20, 2007, at 10:30 AM, Kevin Walzer wrote:
> I don't quite understand the problem here, but do these issues mean  
> it's a Bad Idea to use the Apple-shipped py2app and PyObjC? I was  
> planning on doing this when I upgraded to Leopard.

Apple-shipped PyObjC is fine unless you need the post 2.0 bugfixes  
that Ronald has committed.   If you are using the Xcode based project  
templates, this is all a non-issue as they do not use py2app (but  
you'll have to add a 'copy files' or 'shell script' build phase to add  
any python specific non-standard resources to your app's resources).

It also sounds like the py2app executable stubs should *not* have been  
signed when Leopard was built.   I'll have to look into that.

b.bum

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Kevin W. <kw...@co...>]

Ronald Oussoren wrote:
> 
> 
> Py2app isn't signing code. The problem is that the py2app executable 
> stub inside the py2app package is signed by Apple (it isn't signed in 
> the repository).
> 
> I don't know how to remove that signature, but you can download the stub 
> executable from pyobjc's repository (downloading from 
> https://svn.red-bean.com/pyobjc/branches/pyobjc2/py2app/py2app/apptemplate/prebuilt/main might 
> work for that)
> 

I don't quite understand the problem here, but do these issues mean it's 
a Bad Idea to use the Apple-shipped py2app and PyObjC? I was planning on 
doing this when I upgraded to Leopard.

--Kevin
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[James R E. <ea...@ba...>]

On Nov 20, 2007, at 13:03 , Ronald Oussoren wrote:

> Py2app isn't signing code. The problem is that the py2app executable  
> stub inside the py2app package is signed by Apple (it isn't signed  
> in the repository).

Thanks Ronald [and Bill],

Amusingly enough, I had -just- tracked that down myself and was about  
to send a followup email to the list.  Of course, as I was typing it  
up, *wildeep!* and there's your mail with the solution.

You guys rock!

Thanks!
James

--
One day if I do go to heaven... I'll look around and say,
"It ain't bad, but it ain't San Francisco."
		-- Herb Caen

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Ronald O. <ron...@ma...>]

On 19 Nov, 2007, at 20:14, James R Eagan wrote:

> On Nov 18, 2007, at 20:22 , Bill Bumgarner wrote:
>
>> Might it be that py2app is copying, then stripping, the  
>> keychain.framework?
>
>
> The Keychain framework is a symptom, not the cause.  Upon further  
> digging, it appears that all py2app applications built under Leopard  
> have extraneous code signatures, regardless of whether they include  
> a framework or not.  Using another example that does not use any  
> external frameworks, when I run codesign on it to check its  
> validity, it again claims to be modified:
>
> % codesign -dvvv CocoaRegexMaker.app
> CocoaRegexMaker.app: code or signature modified
>
> When I check the integrity of my application built by Xcode, I get a  
> different result:
> % codesign -dvvv Login\ Authenticator.app
> Login Authenticator.app: code object is not signed
>
> (and, for completeness, when checking Login\ Authenticator.app as  
> built by py2app):
> % codesign -dvvv Login\ Authenticator.app
> Login Authenticator.app: code or signature modified
>
>
> It appears that Xcode is never signing the code (which makes sense  
> -- I've never specified my certificate anywhere).  Something that  
> py2app does, however, appears to make Leopard think the resulting  
> application has been signed.  I'm not deeply familiar enough with  
> Leopard's codesigning, however, to be able to tell where this  
> extraneous signature is coming from.  (I'm assuming that py2app is  
> not implicitly signing the code somewhere with a hidden certificate,  
> since that would be pretty whack.)

Py2app isn't signing code. The problem is that the py2app executable  
stub inside the py2app package is signed by Apple (it isn't signed in  
the repository).

I don't know how to remove that signature, but you can download the  
stub executable from pyobjc's repository (downloading from https://svn.red-bean.com/pyobjc/branches/pyobjc2/py2app/py2app/apptemplate/prebuilt/main 
  might work for that)

Ronald

>
>
> --------
> setup.py (from CocoaRegexMaker)
> --------
>
> from distutils.core import setup
> import py2app
>
> setup(
>    app=['CocoaRegexMaker.py'],
>    data_files=['MainMenu.nib'],
> )
>
>
> --
> That's the trouble with computers -- always thinking in black and  
> white.
> No aquamarines, no blues, no imagination.
>                    -- The (Fourth) Doctor
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[James R E. <ea...@ba...>]

On Nov 18, 2007, at 20:22 , Bill Bumgarner wrote:

> Might it be that py2app is copying, then stripping, the  
> keychain.framework?


The Keychain framework is a symptom, not the cause.  Upon further  
digging, it appears that all py2app applications built under Leopard  
have extraneous code signatures, regardless of whether they include a  
framework or not.  Using another example that does not use any  
external frameworks, when I run codesign on it to check its validity,  
it again claims to be modified:

% codesign -dvvv CocoaRegexMaker.app
CocoaRegexMaker.app: code or signature modified

When I check the integrity of my application built by Xcode, I get a  
different result:
% codesign -dvvv Login\ Authenticator.app
Login Authenticator.app: code object is not signed

(and, for completeness, when checking Login\ Authenticator.app as  
built by py2app):
% codesign -dvvv Login\ Authenticator.app
Login Authenticator.app: code or signature modified


It appears that Xcode is never signing the code (which makes sense --  
I've never specified my certificate anywhere).  Something that py2app  
does, however, appears to make Leopard think the resulting application  
has been signed.  I'm not deeply familiar enough with Leopard's  
codesigning, however, to be able to tell where this extraneous  
signature is coming from.  (I'm assuming that py2app is not implicitly  
signing the code somewhere with a hidden certificate, since that would  
be pretty whack.)

--------
setup.py (from CocoaRegexMaker)
--------

from distutils.core import setup
import py2app

setup(
     app=['CocoaRegexMaker.py'],
     data_files=['MainMenu.nib'],
)


--
That's the trouble with computers -- always thinking in black and white.
No aquamarines, no blues, no imagination.
                     -- The (Fourth) Doctor