AppKiDo: upgrade to 0.986sp4, fetch from git

[mklein-de (Michael Klein)]

AppKiDo is currently at 0.986sp4, also sources have moved to git

[mklein-de (Michael Klein)]

Portfile patch

[mklein-de (Michael Klein)]

Compile fix for Xcode 3.1 on Leopard

[ryandesign (Ryan Carsten Schmidt)]

It is too bad that the developer is no longer providing distfiles, and has not created any tags in the github repository, since github would automatically create distfiles for tags (I think). We would greatly prefer to fetch from proper distfiles. Have you asked the developer if he can continue to provide them?

If we're going to fetch from git, then master_sitses should be removed.

Instead of those pre-build and pre-destroot blocks, why not just build.dir ${worksrcpath}/src?

[mklein-de (Michael Klein)]

Replying to ryandesign@…:

It is too bad that the developer is no longer providing distfiles, and has not created any tags in the github repository, since github would automatically create distfiles for tags (I think).

Can you point me to an example Portfile that fetches distfiles from github?

For testing purposes I forked the AppKiDo repository and created a tag, The download URL for the tarball is then https://github.com/mklein-de/appkido/tarball/0.986sp4. Now I have two problems:

• /usr/bin/curl on Leopard is outdated and doesn't seem to know github.com's CA (this can be worked around by downloading from ​http://nodeload.github.com instead)

• The downloaded archive has no suffix. Of course it's possible to set extract.suffix to empty, but somehow this feels wrong.

We would greatly prefer to fetch from proper distfiles. Have you asked the developer if he can continue to provide them?

Will do that!

If we're going to fetch from git, then master_sitses should be removed.

Instead of those pre-build and pre-destroot blocks, why not just build.dir ${worksrcpath}/src?

yes, build.dir ${worksrcpath}/src works too.

[ryandesign (Ryan Carsten Schmidt)]

fixed patch

[ryandesign (Ryan Carsten Schmidt)]

Sorry to hear Leopard's curl is too old to deal with github's CA. I recommend installing the MacPorts curl port to work around that.

I've attached a diff showing how I'd do it. We have many other ports doing something similar.

It doesn't build though. On Snow Leopard with Xcode 3.2.6 I get:

GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file main.m)

[mklein-de (Michael Klein)]

Replying to ryandesign@…:

Sorry to hear Leopard's curl is too old to deal with github's CA. I recommend installing the MacPorts curl port to work around that.

I already have it installed, but Pextlib.dylib is (deliberatly?) linked to Leopard's curl lib:

# otool -L /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib
/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib:
	Pextlib.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.9.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)

I've attached a diff showing how I'd do it. We have many other ports doing something similar.

Thanks, after adding fetch.ignore_sslcert yes, fetching works.

It doesn't build though. On Snow Leopard with Xcode 3.2.6 I get:

GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file main.m)

Can you try with configure.compiler gcc-4.0, attached below?

[ryandesign (Ryan Carsten Schmidt)]

Replying to michael.klein@…:

I already have it installed, but Pextlib.dylib is (deliberatly?) linked to Leopard's curl lib:

Oh right.

Thanks, after adding fetch.ignore_sslcert yes, fetching works.

Ok. Like I said we have many many ports fetching via https from github; they're probably all affected by this. And if Leopard's curl is too old, I'll bet Tiger's is even older. (In other words, I wouldn't use a platform darwin 9 block.)

Can you try with configure.compiler gcc-4.0, attached below?

I'll bet that would work for me. But for one thing Xcode 4.2 (available for Snow Leopard and Lion) does not include any version of gcc so this will break there. Anyway, we'd rather use the correct compiler. There's no reason to be using the 10.4 SDK here. Just use no SDK. Or more precisely, use ${configure.sdkroot} (which will be empty everywhere except on 10.4 PPC).

[mklein-de (Michael Klein)]

Replying to ryandesign@…:

Thanks, after adding fetch.ignore_sslcert yes, fetching works.

Ok. Like I said we have many many ports fetching via https from github; they're probably all affected by this. And if Leopard's curl is too old, I'll bet Tiger's is even older. (In other words, I wouldn't use a platform darwin 9 block.)

Ok, removed. The https fetch from github thing should generally affect only Port maintainers, because the distfiles are typically available on one of the macports mirrors anyway, right?

Can you try with configure.compiler gcc-4.0, attached below?

I'll bet that would work for me. But for one thing Xcode 4.2 (available for Snow Leopard and Lion) does not include any version of gcc so this will break there. Anyway, we'd rather use the correct compiler. There's no reason to be using the 10.4 SDK here. Just use no SDK. Or more precisely, use ${configure.sdkroot} (which will be empty everywhere except on 10.4 PPC).

Ok, next attempt ;-)

[ryandesign (Ryan Carsten Schmidt)]

Replying to michael.klein@…:

Thanks, after adding fetch.ignore_sslcert yes, fetching works.

Now that we have a github portgroup to encapsulate the details of fetching from github, we can make this change there to fix this problem for all ports that use the portgroup; fixed there in r89060.

[ryandesign (Ryan Carsten Schmidt)]

Sorry for forgetting about this ticket. I'm attaching a new diff which compiled successfully for me. The arguments you added to the Xcode build phase also needed to be added to the destroot phase. The problem now is that although this builds and installs, both installed apps crash when run with:

*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFArray removeObjectAtIndex:]: index (4294967295) beyond bounds (6)'

[mklein-de (Michael Klein)]

possibly a duplicate of #28543?

[ryandesign (Ryan Carsten Schmidt)]

Yes, thanks. Now it crashes differently, but I committed this update in r89158 and can file a new ticket for the new crash.