[MacRuby-devel] Appstore rules on symlinks Macruby

Rob Ista rob.ista at me.com
Mon Jun 11 08:17:54 PDT 2012 

Thanks Mark (and the full team for finalizing 0.12 as well :)), I've seen in the NB 0.13 that there is a framework that should pass the review (I assume that Apple is not complaining against "0.13" in stead of "A"). I already had a review pending but i'l give it a try the next time. One question though, the existence of the dylib and the symlinks in /lib suggest that there are references to them? Is that true or is at the end of the day a Macruby binary sufficient? I just opened a ticket for a possible bug of popen3 in 1.9.2 but I'll open another ticket for the code signing "materializing" thing. 
keep up the good work, Rob   


On 9 Jun 2012, at 16:00 , macruby-devel-request at lists.macosforge.org wrote:

> Send MacRuby-devel mailing list submissions to
> 	macruby-devel at lists.macosforge.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> or, via email, send a message with subject or body 'help' to
> 	macruby-devel-request at lists.macosforge.org
> 
> You can reach the person managing the list at
> 	macruby-devel-owner at lists.macosforge.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MacRuby-devel digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Appstore rules on symlinks Macruby (Mark Rada)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 8 Jun 2012 21:59:28 -0400
> From: Mark Rada <mrada at marketcircle.com>
> To: "MacRuby development discussions."
> 	<macruby-devel at lists.macosforge.org>
> Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby
> Message-ID: <34A5CD21-9CE9-40CC-8AE6-5A2DE4303667 at marketcircle.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Rob,
> 
> Someone else opened a ticket on Github that describes the same problem that you were having (https://github.com/MacRuby/MacRuby/issues/101).
> 
> I've taken a stab at fixing the issue and the nightly build of MacRuby seems to have gotten past this problem. Granted, I did the minimum amount work to get things working. I have not gone through to make sure MacRuby.framework is "by the books", and the symlink materialization problem is something that still needs to be dealt with, but for the time being a stock MacRuby installation should now be passing app store automatic validation.
> 
> Opening tickets on github for some of the things you've outlined here would help out.
> 
> Thanks,
> 	Mark
> 
> 
> On 2012-06-04, at 9:08 AM, rob ista wrote:
> 
>> Hi, obviously filing a bug has a broken link now so ...
>> 
>> - Apple indeed wants the Version to be A (or B) so macruby_deploy has to be changed. All exactly like Apple wants it to.
>> - I personally didn't succeed in doing so, so i decided to leave that to the pro's and have built a "by-the book ready-to-go" MacRuby-framework including the Headers and all. Significant detail is that I removed all the .dylibs (I didn't have seen a malfunction for that thus far) including their symlinks and only have a MacRuby binary (a copy of the dylib) where it shoud be including a symlink on top-level because
>> - codesigning "materializes" all symlinks into real binaries. E.g. you'll end up with 3 fullsize binary dylibs in the /lib folder with an exploded app-size as a result
>> - that's why you shouldn''t codesign a xyz.framework itself but the real Version(s) ("A", "B" etc.) because it would "materialize" all symlinks it can find including the one pointing to the main binary
>> - codesigning .rb files is not necessary anymore, only the .rbo's and the .bundle's
>> - so, i just deploy an app, remove the macruby framework which was built by macruby deploy, replace it with my "by-the-book ready-to-go" one, run my post-compile script which "hacks" the binaries again with the Version (it should work with Current as well i guess), remove the Header-stuff and codesigns everything in the right order (first the rbo's etc., then the framework Version, then the app)
>> - and .... no errors or even warnings when uploading to the store. The app even works and is accepted :) 
>> 
>> Personally i think it's more convenient to have that "ready-to-go"' framework in the nightly builds and copy it during deployment. Hacking a framework together is a bit fuzzy and lookes like everything is still in beta. Well, even if it is, i think we should avoid it :). May be it's then even possible to avoid having to hack the binaries as well and only codesign the details before uploading.
>> 
>> cheers, Rob
>> 
>> 
>> On 10 May, 2012,at 04:00 PM, macruby-devel-request at lists.macosforge.org wrote:
>> 
>>> Send MacRuby-devel mailing list submissions to
>>> macruby-devel at lists.macosforge.org
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> or, via email, send a message with subject or body 'help' to
>>> macruby-devel-request at lists.macosforge.org
>>> 
>>> You can reach the person managing the list at
>>> macruby-devel-owner at lists.macosforgeorg
>>> 
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of MacRuby-devel digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>> 1. Re: Appstore rules on symlinks Macruby framework changed ?
>>> (Rob Ista)
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> Message: 1
>>> Date: Wed, 09 May 2012 16:44:01 +0200
>>> From: Rob Ista <rob.ista at me.com>
>>> To: macruby-devel at lists.macosforge.org
>>> Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby
>>> framework changed ?
>>> Message-ID: <B1B2E2DD-95D9-44D3-81F1-2BFF161EAD7F at me.com>
>>> Content-Type: text/plain; charset=windows-1252
>>> 
>>> Yes, i have seen that .. i will do some tests to see if i can get a working app with a symlink although a manual change did not succeed thus far .. either it cannot find macgems (if i hack the binary with "A") or it just crashes because it can not find "Current" through the simlink any more 
>>> 
>>> and yes, it seems that apple is really stretching their rules to the limits .. i sensed some disturbance in the python community as well with similar issues the last few days ? the response from the review team was :
>>> - - - - -
>>> Dear developer,
>>> 
>>> We have discovered one or more issues with your recent delivery for "SubtitleReSync". To process your delivery, the following issues must be corrected:
>>> 
>>> Malformed Framework - The framework bundle MacRuby (SubtitleReSync.app/Contents/Frameworks/MacRuby.framework) 'Versions' directory must contain a symbolic link 'Current' resolving to a specific version directory. Refer to the Anatomy of Framework Bundles for more information.
>>> - - - - -
>>> 
>>> The funny thing is that i have another framework but didn't bother to create a "cute" one so i just dumped the .dylib into Frameworks. That seems to be allowed and ok :) 
>>> 
>>> I will file a bug report as well
>>> 
>>> cheers, Rob
>>> 
>>>> 
>>>> macruby_deploy fiddles with the version symlinks on purpose. We changed it in the past for app store guidelines at some point; you should be able to see it in the history of macruby_deploy. 
>>>> 
>>>> It would be fastest to just revert that change and see if that fixes things. Though if Apple really wants the version to be A then we will need to do a bit more work. 
>>>> 
>>>> macruby_deploy is fairly straightforward, so it is easy to go through and find what needs to be changed. 
>>>> 
>>>> 
>>>> Sent from my iDevice
>>>> 
>>>> On 2012-05-07, at 9:38, Joshua Ballanco <jballanc at gmail.com> wrote:
>>>> 
>>>>> Hi Rob,
>>>>> 
>>>>> I haven't had time to look into it, but hopefully Apple is not looking to restrict versions within framework bundles to "A", "B", "C", etc. As for "Current" not being a symlink, that does seem like a bug. Would you mind filing it as such so that we don't loose track of it?
>>>>> 
>>>>> - Josh
>>>>> On Saturday, May 5, 2012 at 8:27 PM, Rob Ista wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> it seems that the Appstore validation has sharpened its control (again) ? submitting an app now is rejected because the Macruby framework does not comply to the official Anatomy of Framework Bundles ? There should be a symbolic "Current" resolving to "A" ... in the Macruby Framework this is now a fixed "Current" .. does anyone have seen this before and is there a workaround for the time being ?
>>>>>> 
>>>>>> Secondly, the code signing of the bundle contents is still a bit shaky although it seems to work on Lion .. on SL the .rb files create an "argument list too long" message (see below) .. commenting out the .rb files in macruby_deploy for codesigning makes the deploy come to a proper end but of course now the .rb are not signed. Daniel has done some great work on this already but are there any other ideas?
>>>>>> 
>>>>>> rgrds, Rob
>>>>>> 
>>>>>> /Users/robista/Library/Developer/Xcode/DerivedData/SubtitleReSyncBasic-ayrbtqtujxpvspgaanykiwlaojxy/ArchiveIntermediates/Deployment/BuildProductsPath/Release/SubtitleReSyncBasic.app/Contents/Frameworks/MacRuby.framework/Versions/Current/usr/lib/ruby/1.9.2/abbrev.rb: Argument list too long
>>>>>> _______________________________________________
>>>>>> 
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> 
>>> 
>>> End of MacRuby-devel Digest, Vol 51, Issue 14
>>> *********************************************
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120608/7d020226/attachment-0001.html>
> 
> ------------------------------
> 
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> 
> End of MacRuby-devel Digest, Vol 52, Issue 3
> ********************************************

More information about the MacRuby-devel mailing list