Dear Josh,
Thank you for your reply.
> However the reporter is building with +universal, which you can see later in
> the log means x86_64 and i386.
I didn’t notice this.
> All compilers will define __LP64__ if and only if compiling for a 64-bit
> target. This is correct.
This means that __L
On 2016-3-19 15:18 , Takeshi Enomoto wrote:
Hi,
I’m trying to fix the problem reported for gmt5.
gmt5 fails due to the incompatibility of pointer type
on a call to dsyev_ of CLPACK in Accelerate.
The reporter runs Mavericks on an i386 machine
(I didn’t know that i386 is supported).
I don&#
Hi,
I’m trying to fix the problem reported for gmt5.
gmt5 fails due to the incompatibility of pointer type
on a call to dsyev_ of CLPACK in Accelerate.
The reporter runs Mavericks on an i386 machine
(I didn’t know that i386 is supported).
According to the error message in main.log, int * is
delete
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.6' on the
> Mavericks slave as well?
Instead of advocating deleting individual files and possibly missing some, why
don't we advocate forcing the activation, then deactivating?
sudo port -f activate python26
sudo por
Oh, we took care of a conflict in /Applications/MacPorts/Python 2.6
already, but I guess there are more of python26's files still lying around.
Henry (or whoever's reading this), could you please delete
'/opt/local/Library/Frameworks/Python.framework/Versions/2.6' on the
Mav
ivate python26' to force the activation.
> Begin forwarded message:
>
> Date: March 31, 2015 at 12:50:28 PM EDT
> Subject: buildbot failure in MacPorts on buildports-mavericks-x86_64
> From: nore...@macports.org
> To: bl...@macports.org, dl...@geeklair.net, dl...@macpor
OK; good to know this is a known issue and is being actively addressed.
Thanks! - MLD
On Tue, Feb 17, 2015, at 09:53 AM, Ryan Schmidt wrote:
> On Feb 17, 2015, at 8:37 AM, Michael Dickens wrote:
> >
> > Looks like the Mavericks buildbot is hosed; can someone
On Feb 17, 2015, at 8:37 AM, Michael Dickens wrote:
>
> Looks like the Mavericks buildbot is hosed; can someone kick it? - MLD
>
> {{{
> Building ports
> Building uhd (1 of 1)...Error: Port uhd not found
> [snip]
> touch: /var/tmp/failcache/uhd: No such file or directory
Looks like the Mavericks buildbot is hosed; can someone kick it? - MLD
{{{
Building ports
Building uhd (1 of 1)...Error: Port uhd not found
[snip]
touch: /var/tmp/failcache/uhd: No such file or directory
}}}
- Original message -
From: nore...@macports.org
To: michae...@macports.org
Perfect that solved the linking issue.
Thanks
On Dec 3, 2014 5:42 PM, "Clemens Lang" wrote:
> Hi,
>
> - On 4 Dec, 2014, at 00:20, Jeremy Whiting jpwhit...@kde.org wrote:
>
> > nm on the .dylib shows the symbols that the linker says are missing.
> file on the
> > dylib says it's x86_64 format
Hi,
- On 4 Dec, 2014, at 00:20, Jeremy Whiting jpwhit...@kde.org wrote:
> nm on the .dylib shows the symbols that the linker says are missing. file on
> the
> dylib says it's x86_64 format. otool -L shows it is linking against libc++ so
> I'm not sure what else would cause this.
I'll bet th
Hello list,
In discussion with Marko Käning I've been trying to get kde frameworks (aka
kf5) to build on mac osx mavericks by using kdesrc-build which is a perl
script that runs cmake, make and make install with some additional options
specified. With the help of macports for most depende
leaven wrote:
At 2:39 PM -0700 10/14/14, nore...@macports.org wrote:
The Buildbot has detected a failed build on builder
buildports-mavericks-x86_64 while building MacPorts.
Full details are available at:
http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702
Can some kind
nto an error.
So basically its a bug in the code which should be reported upstream to
get fixed.
Chris
On 15/10/14 02:22, Craig Treleaven wrote:
At 2:39 PM -0700 10/14/14, nore...@macports.org wrote:
The Buildbot has detected a failed build on builder
buildports-mavericks-x86_64 while build
On Oct 14, 2014, at 9:22 PM, Craig Treleaven wrote:
> Mavericks Clang errors out with the following:
>
> test_dr.c:49:3: error: comparison of constant 12 with expression of type
> 'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare
I’d assume (even though I’m not that Jeremy) that the clang on mavericks is
newer and simply has more warnings as errors. The warning flags in the brackets
are what were triggered: do they exist on the older compiler version and if so
are they active? That’s probably all it is.
On Oct 14, 2014
On 11 Sep 2014, at 20:50 , Andreas Kusalananda Kähäri
wrote:
> Did you try building it from source? Because when I installed it my machines
> just now, it installed from ready built binaries (with no errors).
Yes, I didn’t force the build, but it happened to be a build from sources.
Don’t know
Did you try building it from source? Because when I installed it my machines
just now, it installed from ready built binaries (with no errors).
--
Andreas Kusalananda Kähäri
System Developer at BILS
Uppsala University, Sweden
On 11 Sep 2014, at 20:35, Marko Käning wrote:
> Hi Lawrence,
Hi Lawrence,
> FWIW, I successfully installed clang-3.5 on 10.9.4 a few days ago.
interesting…
Wondering what went wrong in my case. I’ll deal with the related ticket later.
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Hi,
I am surprised to see clang 5.3 failing to build on OSX 10.9.4, as I thought it
is stable.
Greets,
Marko
[1] https://trac.macports.org/ticket/44937
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailm
Clemens
Didn’t see anything odd so I restarted it. Let me know if it hangs again.
-Shree
On Aug 19, 2014, at 5:10 PM, Clemens Lang wrote:
> Hi,
>
> it seems the Mavericks base builbot locks up while trying to check
> out an SVN working copy. It currently hangs:
Hi,
it seems the Mavericks base builbot locks up while trying to check
out an SVN working copy. It currently hangs:
https://build.macports.org/builders/buildbase-mavericks-x86_64/builds/460/steps/svn/logs/stdio
and will eventually time out as it has before:
https://build.macports.org
Hi,
the Mavericks buildbot seems to be stuck. Can you take a look?
In general, the buildbots seems to hang a lot at the moment. E.g., the
tests for some of the base buildbots get aborted because they hang
without output for more than 1200 seconds.
--
Clemens Lang
On Jun 28, 2014, at 2:00 PM, Brandon Allbery wrote:
>
> Every link-time shared object contains a canonical name telling the dynamic
> loader how to find the runtime version of the shared object. On OS X with
> Mach-O, it's called "install_name" and is a full pathname; there is nothing
> like E
On Jun 28, 2014, at 5:58 PM, Brandon Allbery wrote:
>
> On Sat, Jun 28, 2014 at 4:30 PM, Mark Brethen wrote:
> @MAC_FRAMEWORK_TRUE@cd
> $(DESTDIR)$(MAC_FRAMEWORK_PREFIX)/$(MAC_FRAMEWORK_NAME).framework && ln -sf
> Versions/Current/$(MAC_FRAMEWORK_NAME) $(MAC_FRAMEWORK_NAME) &&
> install
On Jun 28, 2014, at 5:58 PM, Brandon Allbery wrote:
>
> On Sat, Jun 28, 2014 at 4:30 PM, Mark Brethen wrote:
> @MAC_FRAMEWORK_TRUE@cd
> $(DESTDIR)$(MAC_FRAMEWORK_PREFIX)/$(MAC_FRAMEWORK_NAME).framework && ln -sf
> Versions/Current/$(MAC_FRAMEWORK_NAME) $(MAC_FRAMEWORK_NAME) &&
> install
On Sat, Jun 28, 2014 at 4:30 PM, Mark Brethen
wrote:
> @MAC_FRAMEWORK_TRUE@cd
> $(DESTDIR)$(MAC_FRAMEWORK_PREFIX)/$(MAC_FRAMEWORK_NAME).framework && ln -sf
> Versions/Current/$(MAC_FRAMEWORK_NAME) $(MAC_FRAMEWORK_NAME) &&
> install_name_tool -id
> $(MAC_FRAMEWORK_NAME).framework/Versions/$(MA
On Jun 28, 2014, at 1:44 PM, Brandon Allbery wrote:
>
> On Sat, Jun 28, 2014 at 2:23 PM, Mark Brethen wrote:
> So either the coin or soqt framework is bundled incorrectly? How would check
> which is the culprit? I just installed coin +aqua and soqt +aqua using
> '--without-framework' and did
On Jun 28, 2014, at 1:44 PM, Brandon Allbery wrote:
>
> On Sat, Jun 28, 2014 at 2:23 PM, Mark Brethen wrote:
> So either the coin or soqt framework is bundled incorrectly? How would check
> which is the culprit? I just installed coin +aqua and soqt +aqua using
> '--without-framework' and did
On Sat, Jun 28, 2014 at 2:23 PM, Mark Brethen
wrote:
> So either the coin or soqt framework is bundled incorrectly? How would
> check which is the culprit? I just installed coin +aqua and soqt +aqua
> using '--without-framework' and did not get any link errors.
The implication from what I've se
On Jun 28, 2014, at 1:00 PM, Brandon Allbery wrote:
>
> On Sat, Jun 28, 2014 at 1:45 PM, Mark Brethen wrote:
> Those are the install_names at build time of each respective port.
>
> I think you're confused about install_name means.
>
> Every link-time shared object contains a canonical name
On Sat, Jun 28, 2014 at 1:45 PM, Mark Brethen
wrote:
> Those are the install_names at build time of each respective port.
I think you're confused about install_name means.
Every link-time shared object contains a canonical name telling the dynamic
loader how to find the runtime version of the
On Jun 28, 2014, at 3:23 AM, Ryan Schmidt wrote:
>
> On Jun 27, 2014, at 8:49 PM, Mark Brethen wrote:
>
>>
>> On Jun 27, 2014, at 9:22 AM, Joshua Root wrote:
>>
>>> On 2014-6-27 23:30 , Mark Brethen wrote:
On Jun 27, 2014, at 12:45 AM, Ryan Schmidt wrote:
>
> On
On Jun 27, 2014, at 8:49 PM, Mark Brethen wrote:
>
> On Jun 27, 2014, at 9:22 AM, Joshua Root wrote:
>
>> On 2014-6-27 23:30 , Mark Brethen wrote:
>>>
>>> On Jun 27, 2014, at 12:45 AM, Ryan Schmidt wrote:
>>>
On Jun 27, 2014, at 12:38 AM, Joshua Root wrote:
> On 2014-6
On Jun 27, 2014, at 9:22 AM, Joshua Root wrote:
> On 2014-6-27 23:30 , Mark Brethen wrote:
>>
>> On Jun 27, 2014, at 12:45 AM, Ryan Schmidt wrote:
>>
>>>
>>> On Jun 27, 2014, at 12:38 AM, Joshua Root wrote:
>>>
On 2014-6-27 14:03 , Mark Brethen wrote:
> After installing Coin, I get
On 2014-6-27 23:30 , Mark Brethen wrote:
>
> On Jun 27, 2014, at 12:45 AM, Ryan Schmidt wrote:
>
>>
>> On Jun 27, 2014, at 12:38 AM, Joshua Root wrote:
>>
>>> On 2014-6-27 14:03 , Mark Brethen wrote:
After installing Coin, I get the following error with SoQt:
---> Found 1 broken
On Jun 27, 2014, at 12:45 AM, Ryan Schmidt wrote:
>
> On Jun 27, 2014, at 12:38 AM, Joshua Root wrote:
>
>> On 2014-6-27 14:03 , Mark Brethen wrote:
>>> After installing Coin, I get the following error with SoQt:
>>>
>>> ---> Found 1 broken file(s), matching files to ports
>>>
>>>
>>> Erro
On Jun 27, 2014, at 12:38 AM, Joshua Root wrote:
> On 2014-6-27 14:03 , Mark Brethen wrote:
>> After installing Coin, I get the following error with SoQt:
>>
>> ---> Found 1 broken file(s), matching files to ports
>>
>>
>> Error: Port SoQt is still broken after rebuilding it more than 3 times
On 2014-6-27 14:03 , Mark Brethen wrote:
> After installing Coin, I get the following error with SoQt:
>
> ---> Found 1 broken file(s), matching files to ports
>
>
> Error: Port SoQt is still broken after rebuilding it more than 3 times.
> Error: Please run port -d -y rev-upgrade and use th
After installing Coin, I get the following error with SoQt:
---> Found 1 broken file(s), matching files to ports
Error: Port SoQt is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Running port -d -y rev-upgra
py-graph-tool for over 26 hours.
>>
>> <https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3062>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
>
Rebooting please standby.
Shree
On Apr 22, 2014, at 5:22 PM, Joshua Root wrote:
> It's been working on py-graph-tool for over 26 hours.
>
> <https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3062>
___
macpo
It's been working on py-graph-tool for over 26 hours.
<https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3062>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listin
Can Java please be installed on the Mavericks build slave? The others might
need it too. The buildbot failed to build sleuthkit [1] because of this.
checking if java works... configure: error: The Java VM java failed (see
config.log, check the CLASSPATH?)
Cheers!
Frank
[1]
<ht
Hi,
it seems there is no JVM/JDK but only the java(c) shims installed on the
mavericks buildbot:
https://build.macports.org/builders/buildports-mavericks-x86_64/builds/1031/steps/compile/logs/stdio
(...)
---> Building hamcrest-core
DEBUG: Environment: CPATH='/opt/local
On 14 Jan 2014, at 03:02 , Ryan Schmidt wrote:
> Perhaps you could contribute to resolving the MacPorts VirtualBox ticket
> then.
I am afraid my knowledge about setting up a proper virtualbox installation is
not sufficient for this endeavour.
I tried a while ago though.
Ticket #41392 hangs aro
On Jan 13, 2014, at 12:33, mk-macpo...@techno.ms wrote:
> Well, I wanted to avoid using the upstream binaries, because I like to make
> sure that nothing stays behind on my system once I upgrade or remove the
> software. That’s why I like MacPorts. :-)
> BUT, I guess, this is my only option lef
n support.
… but well, the missing hardware virtualisation is enough reason to stop this
endeavour.
> By the way, the VirtualBox binaries from
> upstream work just fine on Mavericks.
Well, I wanted to avoid using the upstream binaries, because I like to make
sure that nothing stays behind on
ite slow as it does not get any
virtualization support. By the way, the VirtualBox binaries from
upstream work just fine on Mavericks.
Rainer
[1] http://grml.org
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On 12 Jan 2014, at 23:59 , Clemens Lang <> wrote:
> I've that a few times now and it seems to be a problem with permissions on
> the cache directory mentioned in the error message. Unfortunately it doesn't
> abort but it seems it can still lead to miscompiled code and performance
> degradation.
On 12 Jan 2014, at 22:41 , Chris Murphy wrote:
> Maybe. Try adding -usbdevice tablet to the qemu command line.
That made my trackpad almost unusable. :-(
But it didn’t change anything.
No progress during the system probe step.
___
macports-dev mailing
On Jan 12, 2014, at 2:29 PM, mk-macpo...@techno.ms wrote:
> OK, now I found out using “info usb” that USB support is NOT enabled by
> default.
> So, perhaps that is the problem?
Maybe. Try adding -usbdevice tablet to the qemu command line.
http://wiki.qemu.org/download/qemu-doc.html#pcsys_005f
OK, now I found out using “info usb” that USB support is NOT enabled by default.
So, perhaps that is the problem?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On 12 Jan 2014, at 21:50 , Chris Murphy wrote:
> When I say USB device, I meant the interface in qemu that presents USB within
> the guest. Clearly the linux kernel is finding a USB bus.
The command line to start up the VM is
—
qemu-system-x86_64 -m 2G -cdrom openSUSE-13.1-NET-x86_64.iso -vga st
On Jan 12, 2014, at 12:44 PM, mk-macpo...@techno.ms wrote:
> On 12 Jan 2014, at 20:31 , Chris Murphy wrote:
>> So I think you need to remove the USB device in the qemu guest and see if
>> that works.
>
> Chris, so far I am not trying to use any USB device.
When I say USB device, I meant the
Hi devs,
I am trying to build some software using standard clang on Mavericks and I see
errors due to denied permissions like this:
—
:info:build libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H
-DBUILDING_AQDATABASE -DLOCALEDIR=\"/opt/local/share/locale\"
-DAQDATABASE_PLUGINS=\&
On 12 Jan 2014, at 20:31 , Chris Murphy wrote:
> So I think you need to remove the USB device in the qemu guest and see if
> that works.
Chris, so far I am not trying to use any USB device. I am just trying to
install OpenSUSE using an ISO file…
Well, and the installation procedure is searchin
On Jan 12, 2014, at 12:26 PM, mk-macpo...@techno.ms wrote:
> Hi Josh,
>
> On 12 Jan 2014, at 19:47 , Joshua Root wrote:
>> Well, it is going to be a lot slower than VirtualBox, as qemu is an
>> emulator under these circumstances. Though there could also be issues
>> with the USB support.
> it’s
Hi Josh,
On 12 Jan 2014, at 19:47 , Joshua Root wrote:
> Well, it is going to be a lot slower than VirtualBox, as qemu is an
> emulator under these circumstances. Though there could also be issues
> with the USB support.
it’s an emulator, because it cannot make use of kvm...
>> P.S.: qemu likes t
On 2014-1-13 05:19 , mk-macpo...@techno.ms wrote:
> I wanted to give qemu a shot - as an alternative for the currently
> non-functioning virtual box [1] …
>
> Anyone out there who’s successfully using qemu on Mavericks?
>
> The small test linux image supplied by the qem
I wanted to give qemu a shot - as an alternative for the currently
non-functioning virtual box [1] …
Anyone out there who’s successfully using qemu on Mavericks?
The small test linux image supplied by the qemu folks is running fine, but I am
stuck installing OpenSUSE 13.1...
Either
On 2014-1-2 21:04 , Ryan Schmidt wrote:
>
> On Jan 1, 2014, at 19:00, Blair Zajac wrote:
>
>> On Jan 1, 2014, at 3:31 PM, Ryan Schmidt wrote:
>>
>>> On Jan 1, 2014, at 16:27, Blair Zajac wrote:
>>>
I guess a better way is to ensure the build doesn’t pick up stuff in
$prefix/include.
>>
On Jan 1, 2014, at 19:00, Blair Zajac wrote:
> On Jan 1, 2014, at 3:31 PM, Ryan Schmidt wrote:
>
>> On Jan 1, 2014, at 16:27, Blair Zajac wrote:
>>
>>> I guess a better way is to ensure the build doesn’t pick up stuff in
>>> $prefix/include.
>>
>> Does the patch from #40656 help?
>
> No, it
On 2014-1-2 12:00 , Blair Zajac wrote:
>
> On Jan 1, 2014, at 3:31 PM, Ryan Schmidt wrote:
>
>>
>> On Jan 1, 2014, at 16:27, Blair Zajac wrote:
>>
>>> I guess a better way is to ensure the build doesn’t pick up stuff in
>>> $prefix/include.
>>
>> Does the patch from #40656 help?
>
> No, it doe
On Jan 1, 2014, at 3:31 PM, Ryan Schmidt wrote:
>
> On Jan 1, 2014, at 16:27, Blair Zajac wrote:
>
>> I guess a better way is to ensure the build doesn’t pick up stuff in
>> $prefix/include.
>
> Does the patch from #40656 help?
No, it doesn’t. Comparing the 'clang -E’ output between a good
On Jan 1, 2014, at 16:27, Blair Zajac wrote:
> I guess a better way is to ensure the build doesn’t pick up stuff in
> $prefix/include.
Does the patch from #40656 help?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.ma
On Jan 1, 2014, at 1:55 PM, Blair Zajac wrote:
> [cc’ing and.dam...@macports.org for db_select]
>
> On Jan 1, 2014, at 1:30 PM, Ryan Schmidt wrote:
>
>> On Jan 1, 2014, at 15:15, Blair Zajac wrote:
>>>
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_relea
[cc’ing and.dam...@macports.org for db_select]
On Jan 1, 2014, at 1:30 PM, Ryan Schmidt wrote:
> On Jan 1, 2014, at 15:15, Blair Zajac wrote:
>>
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump18
On Jan 1, 2014, at 15:15, Blair Zajac wrote:
>
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:228:24:
> error: no member named 'seq' in 'struct __db'
Same problem reported here:
Hi Jeremy,
I’m now getting this compile failure on the db46 port.
Regards,
Blair
/usr/bin/clang++ -c -I.
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/..
-I/opt/local/include -pipe -Os -arch x86_64
/op
On Tue, Dec 17, 2013 at 9:53 PM, Ryan Schmidt wrote:
> Yes, that should be it, just like that. When I add this platform darwin 8
> block to ports, I update the ticket reference to the ticket specific to this
> port, or, since I don’t think there is one for this port, you could just
> remove th
On Dec 17, 2013, at 21:45, Adam Mercer wrote:
> On Tue, Dec 17, 2013 at 9:32 PM, Ryan Schmidt wrote:
>
>> Any time you add gobject-introspection support, you have to switch the build
>> command to gmake and add a gmake build dependency on Tiger, because the
>> version of make its Xcode ships
On Tue, Dec 17, 2013 at 9:32 PM, Ryan Schmidt wrote:
> Any time you add gobject-introspection support, you have to switch the build
> command to gmake and add a gmake build dependency on Tiger, because the
> version of make its Xcode ships with is too old. See any other port using
> gobject-in
On Tue, Dec 17, 2013 at 9:32 PM, Ryan Schmidt wrote:
> Any time you add gobject-introspection support, you have to switch the build
> command to gmake and add a gmake build dependency on Tiger, because the
> version of make its Xcode ships with is too old. See any other port using
> gobject-in
On Dec 17, 2013, at 21:09, Adam Mercer wrote:
> I was helping a colleague debug a build issue this afternoon and I
> found what seemed to be the problem. He had installed gstreamer010, on
> his Mavericks system, using the binary package and was getting a build
> error:
>
> Cou
Hi
I was helping a colleague debug a build issue this afternoon and I
found what seemed to be the problem. He had installed gstreamer010, on
his Mavericks system, using the binary package and was getting a build
error:
Couldn't find include 'Gst-0.10.gir' (search path: ['
I'm getting the following back when it tries to build a port that
depends on dbus:
{{{
Error: org.macports.activate for port dbus returned: could not set owner
for file "/opt/local/var/run/dbus": user "messagebus"; does not exist
}}}
The dbus port contains the following code:
{{{
set dbus_user
ce recipe for detecting a java install on Mavericks yet?
>>>
>>> I'd like the subversion-javahlbindings port to be able to warn people and
>>> exit early if the appropriate java bits aren't present and I imagine other
>>> ports might want the same th
Am 16.11.13 22:46, schrieb Ryan Schmidt:
> On Nov 15, 2013, at 14:04, Daniel J. Luke wrote:
>
>> Before I do more work on #41378, I figured that I'd ask and see if anyone
>> has worked up a nice recipe for detecting a java install on Mavericks yet?
>>
>> I&#
On Nov 15, 2013, at 14:04, Daniel J. Luke wrote:
> Before I do more work on #41378, I figured that I'd ask and see if anyone has
> worked up a nice recipe for detecting a java install on Mavericks yet?
>
> I'd like the subversion-javahlbindings port to be able to warn pe
On Nov 15, 2013, at 3:04 PM, "Daniel J. Luke" wrote:
> Before I do more work on #41378, I figured that I'd ask and see if anyone has
> worked up a nice recipe for detecting a java install on Mavericks yet?
>
> I'd like the subversion-javahlbindings port to be
Before I do more work on #41378, I figured that I'd ask and see if anyone has
worked up a nice recipe for detecting a java install on Mavericks yet?
I'd like the subversion-javahlbindings port to be able to warn people and exit
early if the appropriate java bits aren't presen
On 2013-11-2 14:41 , Blair Zajac wrote:
> On 11/01/2013 08:39 PM, Joshua Root wrote:
>> Probably because rsync's -C option gets used at one point. But a half
>> meg file in the ports tree isn't a great idea to begin with. Is it
>> really impossible to build from source *and* unavailable for downloa
On 11/01/2013 08:39 PM, Joshua Root wrote:
Probably because rsync's -C option gets used at one point. But a half
meg file in the ports tree isn't a great idea to begin with. Is it
really impossible to build from source *and* unavailable for download
anywhere?
I agree. Where is the source? Whe
:56 PM, MacPorts wrote:
>> #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
>>
>> OK; thanks. The file libWebKitSysteminterfaceMavericks.a is indeed not part
>> of the rsync tarball. I'll query the list as to what
On Nov 1, 2013, at 22:00, Michael Dickens wrote:
> < https://trac.macports.org/ticket/40852#comment:101 >
>
> Does anyone know why the binary library isn't part of the rsync tarball?
> It's coming in through SVN just fine ... Do I need to have a separate
> download for it, not just a patchfile?
, MacPorts wrote:
> #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
>
> OK; thanks. The file libWebKitSysteminterfaceMavericks.a is indeed not part
> of the rsync tarball. I'll query the list as to what the best way is to get
> binary files
On 2013-10-25 01:44 , Julien Salort wrote:
> Joshua Root wrote:
>
>>> Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported
>>> on Mavericks.
>>
>> People keep saying that, but what are the actual problems with 2.2?
>
> I hav
Joshua Root wrote:
> > Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported
> > on Mavericks.
>
> People keep saying that, but what are the actual problems with 2.2?
I have just installed a fresh MacPorts 2.2.0 on Mavericks. So far, no
problem. Except
On 2013-10-25 01:05 , Daniel J. Luke wrote:
> Moved to DEV
>
> On Oct 23, 2013, at 9:24 PM, Ryan Schmidt wrote:
>> At this time, MacPorts does not offer a pre-compiled release for Mavericks.
>> You can build MacPorts trunk from source and it appears to work on
>> Mav
On Thu, Oct 24, 2013 at 10:05:50AM -0400, Daniel J. Luke wrote:
> so, you've been telling a bunch of people to use trunk - what's fixed
> in trunk that's broken in the latest release?
http://trac.macports.org/changeset/110985
That's pretty much the only change related t
Moved to DEV
On Oct 23, 2013, at 9:24 PM, Ryan Schmidt wrote:
> At this time, MacPorts does not offer a pre-compiled release for Mavericks.
> You can build MacPorts trunk from source and it appears to work on Mavericks.
> We will try to make a new release soon.
so, you've been t
used this technique
> multiple times to reproduce issues users experienced with older versions of
> Xcode clang and to develop fixes.
>
>
> Also I would like for llvm-3.2 to exist on Mavericks because my port pure
> requires it; pure does not work properly on OS X when using l
er versions of
Xcode clang and to develop fixes.
Also I would like for llvm-3.2 to exist on Mavericks because my port pure
requires it; pure does not work properly on OS X when using llvm-3.3 and after
discussion with the developer we decided to leave MacPorts pure at llvm-3.2.
https://groups
On Oct 23, 2013, at 23:46, Ryan Schmidt wrote:
> Why are clang-3.2 and earlier not supported on Mavericks? This is
> inconvenient. It was very convenient to be able to install all versions of
> clang from 2.9 thru current on Mountain Lion, so that when bugs were reported
> on
Why are clang-3.2 and earlier not supported on Mavericks? This is inconvenient.
It was very convenient to be able to install all versions of clang from 2.9
thru current on Mountain Lion, so that when bugs were reported on older Xcode
versions I could simulate their environment without needing
On Wed, Oct 23, 2013 at 07:00:46AM -0500, Ryan Schmidt wrote:
> > People keep saying that, but what are the actual problems with 2.2?
>
> Well, there’s the gnutar-does-not-exist problem. I thought perhaps
> this was people installing the Mountain Lion binary on Mavericks, but
On 2013-10-23 23:00 , Ryan Schmidt wrote:
>
> On Oct 23, 2013, at 05:25, Joshua Root wrote:
>
>>> #40843: Cannot install ncurses with OS X mavericks
>>> -+---
>>> Reporter: feranick@… | Owner: jmr@…
>>&g
On Oct 23, 2013, at 05:25, Joshua Root wrote:
>> #40843: Cannot install ncurses with OS X mavericks
>> -+---
>> Reporter: feranick@… | Owner: jmr@…
>> Type: defect | Status: new
>> Prior
> #40843: Cannot install ncurses with OS X mavericks
> -+---
> Reporter: feranick@… | Owner: jmr@…
> Type: defect | Status: new
> Priority: Normal | Milestone:
> Component: ports |Version:
1 - 100 of 123 matches
Mail list logo
