CodeSign error: a valid provisioning profile is required problem in XCode

The above error pop-ups when you try to build iPhone application for the device. It means that the provision name in XCode project settings does not match .provision file installed in XCode Organizer (device manager). Usually this happens when you have downloaded XCode project created by someone else.

It should be possible just to go to XCode -> Project -> Project settings and chose a valid code signing profile (Code signing -> Code signing identity drop down should have been populated from the choices available in XCode organizer). However, it seems that there is a bug and always changing this setting does not have effect. Based on reports, it looks XCode project setting updater is confused about something and does not update the setting correctly.

The hardcode workaround is to edit your XCode project .xcodeproj file manually. You do not need to close down XCode for this (it will automatically ask to reload after the file is saved). You may see duplicate entries of  XCBuildConfiguration. You need to hunt down one with old (incorrect) values and manually copy-paste in correct values. You can get the correct values from XCode organizer.

For example, I had to edit in :

	CODE_SIGN_IDENTITY = "iPhone Developer: Mikko Ohtamaa (XXXYYY)";
	"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Mikko Ohtamaa (XXXXYYY)";
...
                PROVISIONING_PROFILE = "7572BAC6-4F0C-46D3-B96F-XXXXXYYY";
	"PROVISIONING_PROFILE[sdk=iphoneos*]" = "7572BAC6-4F0C-46D3-B96F-XXXXXYYYY";

manually to the file, replacing the old values for these settings. Note that values may be in many lines.

Hope this helps someone.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Python Interest Group Finland (PIG FI) – join now

I have started a mailing list / Google group for Python Finnish community.

http://groups.google.com/group/pigfi

As far as I know such thing didn’t exist before. We discussed about the establishment of Python Finnish user group with several Python activists in Sauna Sprint few days ago (the event arranged by EESTEC and Plonistans, mid term report, final report). There used to exist Plone-related mailing list, but that’s pretty much dead now. If there are other parallel efforts I am not aware of them, but I really like to merge with the existing work whether it exists. I know at least Nokia, Finnish universities and several small enterprises are very active Python users in Finland.

Our goal is to establish a vibrant, self-sustaining, Python community of Finland. We want to promote the sharing of Python knowledge across organizational borders, the adoption of Python in corporate and hobbyist cultures and have jolly good time with other Python enthusiasts. This probably means discussion (in Finnish), events and  lots of, lots of, sauna. After all, the community will take the shape what suits it for the best, it is not forced externally.

The short term goal is to gather enough participants to have a meaningful community. So, Join now!. You can use web interface, email or RSS to follow the discussion. Spread the word to make sure that the message reaches everyone. Tweet it. IRC it. Email it to your friends. SMS it to your parents. Go to streets and cry aloud “Rakastan Pythonia.”

For most of us being Python programmer is a choice you have made  or would like to take. Let’s together create an environment where this choice is fun and will generate great personal wealth for all of us.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Applying monkey patches in Django middleware layer

Monkey patching is a technique to modify module functions or class methods in Python and other dynamic languages run-time. It differs from the traditional source code patching that it does not need separate utility or compilation process to become effective. This means that you can deploy patches to codebase not under your control with your application without extra effort. Monkey patching has been made famous by Plone/Zope community where there is even collective.monkeypatcher add-on for managed monkey patching.

Because monkey patches do not need a compilation stage, the patch will work with the future versions of the application, assuming the patched function or method is not changed. So you can “safely” update the patched software and the patch will apply to the new version without need to go to command-line to perform some cumbersome commands. However, it is the best practice of open source community to report the bugs and submit the fixing patches, as source code patch, in the corresponding issue trackers.

In Django context, you can use monkey patching to

  • Fix bugs or modify features of Django core without touching the source code
  • Fix bugs or modify features of Django plug-ins (TinyMCE, filebrowser, Django CMS) without touching the source code

Patches are usually applied when Python does module imports. You have a special module called “monkeypatches.py” and when that is imported, it applies the patches when the module body level code runs. However, it is difficult to find stable import point in Django to run monkey patching. Django does some really evil magic to initialize INSTALLED_APPS, database models and stuff and doing any kind of work during import causes headache.

So I figured out that you can apply monkey patches using middleware. Middleware applies the monkey patch when the first HTTP request hits the process (note that if you run preforked web server like FCGI every process has its own run-time code in memory). This technique, of course, cannot be used to monkey-patch things that happen before middleware processing, but it is not often needed.

Below is an example how to monkey-patch Django CMS to normalize its unicode output. There was an issue with unicode characters and this is a stop-gap measure to fix it. (I think the proper fix would be fix related Cufon font renderin Javascript library).

We add our monkey patcher to loaded middleware in settings.py.

MIDDLEWARE_CLASSES = (
    ...
    'foobar.middleware.FixCufonUnicodeNormalization',
)

The actual monkey patching happens by fiddling with the class code in process_request(). Note that in this particular case we only need to transform the output of the original function, we can simply hold a reference into it, call it and perform our transformation on the result. This way our monkey patch do not hinder the orignal function and is update safe (it does not matter if the code of PlaceholderNode.render method changes).

import unicodedata

# Orignal function we monkey-patched away
_orignal_render = None

def _patched_render(self, context):
    """ Normalize all unicode output of Placeholder nodes in Django templates """

    content = _orignal_render(self, context)

    # http://docs.python.org/library/unicodedata.html
    return unicodedata.normalize("NFC", content)

class FixCufonUnicodeNormalization(object):
    """ Fix issue with Cufon, user-generated HTML and unicode decomposed characters.

    http://github.com/sorccu/cufon/issues/issue/133 

    """ 

    def process_request(self, request):
        """ Install monkey-patch on demand.

        If monkey-patch has not been run in for this process (assuming multiple preforked processes),
        then do it now.

        """
        from cms.templatetags.cms_tags import PlaceholderNode

        global _orignal_render, _patched_render

        if not _orignal_render:
            # replace one of the class's method with own fixed version
            _orignal_render = PlaceholderNode.render
            PlaceholderNode.render = _patched_render

As far as I know, monkey patching is something PHP cannot do 🙂

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+