Re: [115236] trunk/dports/gnome/gtk-doc/Portfile
On 12/29/13 11:48 PM, Jeremy Huddleston Sequoia wrote: I strongly suggest either reverting this or fixing openjade to build with clang. As it is, this blocks a decent number of ports from building on Mavericks =(. --Jeremy On Dec 29, 2013, at 12:34, dev...@macports.org wrote: The build of gtk-doc was successful on the Mavericks buildbot after this change. It was able to successfully activate a previously built openjade. Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [115236] trunk/dports/gnome/gtk-doc/Portfile
On Dec 30, 2013, at 00:21, David Evans dev...@macports.org wrote: On 12/29/13 11:48 PM, Jeremy Huddleston Sequoia wrote: I strongly suggest either reverting this or fixing openjade to build with clang. As it is, this blocks a decent number of ports from building on Mavericks =(. --Jeremy On Dec 29, 2013, at 12:34, dev...@macports.org wrote: The build of gtk-doc was successful on the Mavericks buildbot after this change. It was able to successfully activate a previously built openjade. Oh, I see the problem. I had an opensp which was built with clang and thus using libc++ before it was blacklisted (without a revbump). Thus I have a *correct* opensp on my system which causes openjade to fail to link. The builders have a bad version of opensp which allowed a bad version of openjade to build. I've addressed this by un-blacklisting clang in opensp and revbumping to force everyone to rebuild and aborting in openjade until the blocking issue (not building with clang) is addressed. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [115236] trunk/dports/gnome/gtk-doc/Portfile
On 12/30/13 12:39 AM, Jeremy Huddleston Sequoia wrote: On Dec 30, 2013, at 00:21, David Evans dev...@macports.org wrote: On 12/29/13 11:48 PM, Jeremy Huddleston Sequoia wrote: I strongly suggest either reverting this or fixing openjade to build with clang. As it is, this blocks a decent number of ports from building on Mavericks =(. --Jeremy On Dec 29, 2013, at 12:34, dev...@macports.org wrote: The build of gtk-doc was successful on the Mavericks buildbot after this change. It was able to successfully activate a previously built openjade. Oh, I see the problem. I had an opensp which was built with clang and thus using libc++ before it was blacklisted (without a revbump). Thus I have a *correct* opensp on my system which causes openjade to fail to link. The builders have a bad version of opensp which allowed a bad version of openjade to build. I've addressed this by un-blacklisting clang in opensp and revbumping to force everyone to rebuild and aborting in openjade until the blocking issue (not building with clang) is addressed. --Jeremy Ok, have removed the openjade dependency from gtk-doc in r115257. Also rev bumped openjade in r115255 to override the improperly built archive on Mavericks. Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [115236] trunk/dports/gnome/gtk-doc/Portfile
On Dec 30, 2013, at 01:03, David Evans dev...@macports.org wrote: Ok, have removed the openjade dependency from gtk-doc in r115257. Also rev bumped openjade in r115255 to override the improperly built archive on Mavericks. Ah yes, thanks for noticing that. smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27
Hi Craig, after deinstallation of mythtv-core.27 I realised on 10.9 that Myth_Filldatabase and Myth_Frontend stay behind in one of LauchPad’s MacPorts application folders although they are invalid links. Is this normal behaviour or a glitch in the deinstallation phase? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27
Hi Marko: Yes, that would be expected behaviour. MacPorts has no way of knowing that the link was created so it ends up pointing to a now-deleted file after an uninstall. The real question is: why would you want to uninstall?!? ;) Craig At 3:19 PM +0100 12/30/13, mk-macpo...@techno.ms wrote: Hi Craig, after deinstallation of mythtv-core.27 I realised on 10.9 that Myth_Filldatabase and Myth_Frontend stay behind in one of LauchPad's MacPorts application folders although they are invalid links. Is this normal behaviour or a glitch in the deinstallation phase? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27
Hi Craig, On 30 Dec 2013, at 15:57 , Craig Treleaven ctrelea...@cogeco.ca wrote: Yes, that would be expected behaviour. MacPorts has no way of knowing that the link was created so it ends up pointing to a now-deleted file after an uninstall. ah, okay. I wasn’t sure, that’s why I asked. I thought there were even more links to other applications brought in by mythtv which had vanished correctly. But perhaps I was mistaken there... The real question is: why would you want to uninstall?!? ;) Well, for my use case it was too much, due to all the hardware support etc. I needed something much smaller like minidlna. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27
On Dec 30, 2013, at 9:57 AM, Craig Treleaven ctrelea...@cogeco.ca wrote:
Yes, that would be expected behaviour. MacPorts has no way of knowing that
the link was created so it ends up pointing to a now-deleted file after an
uninstall.
Where do the links come from? Are they created by MythTV at runtime?
If MacPorts' MythTV creates symlinks in ${applications_dir} at runtime, you
should add a post-deactivate phase that deletes the symlinks.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114830] trunk/dports/gnome/metacity
On 12/30/13 5:46 AM, Ryan Schmidt wrote: On Dec 16, 2013, at 17:52, dev...@macports.org wrote: Revision 114830 Author dev...@macports.org Date 2013-12-16 15:52:51 -0800 (Mon, 16 Dec 2013) Log Message metacity: apply upstream patches through 20131011, enable debuging code. Modified Paths • trunk/dports/gnome/metacity/Portfile Added Paths • trunk/dports/gnome/metacity/files/patch-thru-7539045-20131011.diff Remember that all users, even those who will not install metacity, will be downloading this patch and keeping it on their disks. The patch is 1MB, which is quite a lot larger than the average patch. If there is no server from which this patch could be downloaded only when needed, then consider gzip-compressing the patch in the files directory; the MacPorts patch phase is able to handle compressed patchfiles automatically. Fixed in r115303. Thanks for the reminder. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27
At 5:06 PM -0500 12/30/13, Lawrence Velázquez wrote:
On Dec 30, 2013, at 9:57 AM, Craig Treleaven ctrelea...@cogeco.ca wrote:
Yes, that would be expected behaviour.
MacPorts has no way of knowing that the link
was created so it ends up pointing to a
now-deleted file after an uninstall.
Where do the links come from? Are they created by MythTV at runtime?
If MacPorts' MythTV creates symlinks in
${applications_dir} at runtime, you should add a
post-deactivate phase that deletes the symlinks.
Hmmm, Marko said LaunchPad but I was thinking of
one of the third party launching utilities. I
don't actually use Apple's LaunchPad.
http://support.apple.com/kb/HT5548
Myth installs double-clickable Applescript
helpers that you can drag to the Dock--which
auto-magically creates a link. What I've
experienced is that when Myth is uninstalled, the
link on the Dock remains. Perhaps LaunchPad is
doing the same. The Myth ports DO clean up after
themselves.
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27
On Dec 30, 2013, at 7:11 PM, Craig Treleaven ctrelea...@cogeco.ca wrote: Myth installs double-clickable Applescript helpers that you can drag to the Dock--which auto-magically creates a link. What I've experienced is that when Myth is uninstalled, the link on the Dock remains. Perhaps LaunchPad is doing the same. In my (admittedly limited) experience, Launchpad updates itself based on the live contents of /Applications (and maybe ~/Applications, but I don't use that). vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Oldish devel versions of Emacs
On Dec 24, 2013, at 9:10 AM, Akim Demaille wrote: Is it really useful to keep these obsolete « devel » versions of Emacs? emacs-app-devel, emacs-snapshot, emacs-w3m-devel Probably not. I know originally the stable release's Cocoa support was nonexistent. I think once the build systems changed and development picked up, the emacs-app-devel port became obsolete. Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
