Opened 8 years ago

Closed 8 years ago

#31739 closed update (fixed)

AppKiDo: upgrade to 0.986sp4, fetch from git

Reported by: mklein-de (Michael Klein) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: maintainer haspatch Cc: ryandesign (Ryan Schmidt)
Port: AppKiDo

Description

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

Attachments (7)

Portfile.diff (1.2 KB) - added by mklein-de (Michael Klein) 8 years ago.
Portfile patch
0001-compile-fixes-for-Xcode-3.1.3.patch (2.4 KB) - added by mklein-de (Michael Klein) 8 years ago.
Compile fix for Xcode 3.1 on Leopard
Portfile.distfiles-from-github.diff (1.6 KB) - added by mklein-de (Michael Klein) 8 years ago.
AppKiDo-ryandesign.diff (1.4 KB) - added by ryandesign (Ryan Schmidt) 8 years ago.
fixed patch
Portfile.2.diff (1.6 KB) - added by mklein-de (Michael Klein) 8 years ago.
Portfile.3.diff (1.7 KB) - added by mklein-de (Michael Klein) 8 years ago.
Portfile.4.diff (1.8 KB) - added by ryandesign (Ryan Schmidt) 8 years ago.

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by mklein-de (Michael Klein)

Attachment: Portfile.diff added

Portfile patch

Changed 8 years ago by mklein-de (Michael Klein)

Compile fix for Xcode 3.1 on Leopard

comment:1 Changed 8 years ago by ryandesign (Ryan Schmidt)

Keywords: maintainer hapatch added; patch removed

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?

comment:2 Changed 8 years ago by ryandesign (Ryan Schmidt)

Keywords: haspatch added; hapatch removed

comment:3 in reply to:  1 Changed 8 years ago by 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.

Changed 8 years ago by mklein-de (Michael Klein)

Changed 8 years ago by ryandesign (Ryan Schmidt)

Attachment: AppKiDo-ryandesign.diff added

fixed patch

comment:4 Changed 8 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

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)

comment:5 in reply to:  4 ; Changed 8 years ago by 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?

Changed 8 years ago by mklein-de (Michael Klein)

Attachment: Portfile.2.diff added

comment:6 in reply to:  5 ; Changed 8 years ago by ryandesign (Ryan 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).

Changed 8 years ago by mklein-de (Michael Klein)

Attachment: Portfile.3.diff added

comment:7 in reply to:  6 Changed 8 years ago by 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 ;-)

comment:8 in reply to:  5 Changed 8 years ago by ryandesign (Ryan 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.

comment:9 Changed 8 years ago by ryandesign (Ryan 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)'

Changed 8 years ago by ryandesign (Ryan Schmidt)

Attachment: Portfile.4.diff added

comment:10 in reply to:  9 Changed 8 years ago by mklein-de (Michael Klein)

possibly a duplicate of #28543?

comment:11 Changed 8 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.