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-requ...@lists.macosforge.org wrote: > Send MacRuby-devel mailing list submissions to > macruby-devel@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-requ...@lists.macosforge.org > > You can reach the person managing the list at > macruby-devel-ow...@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 <mr...@marketcircle.com> > To: "MacRuby development discussions." > <macruby-devel@lists.macosforge.org> > Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby > Message-ID: <34a5cd21-9ce9-40cc-8ae6-5a2de4303...@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-requ...@lists.macosforge.org >> wrote: >> >>> Send MacRuby-devel mailing list submissions to >>> macruby-devel@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-requ...@lists.macosforge.org >>> >>> You can reach the person managing the list at >>> macruby-devel-owner@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.i...@me.com> >>> To: macruby-devel@lists.macosforge.org >>> Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby >>> framework changed ? >>> Message-ID: <b1b2e2dd-95d9-44d3-81f1-2bff161ea...@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 <jball...@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@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@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@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > End of MacRuby-devel Digest, Vol 52, Issue 3 > ******************************************** _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
