On Saturday August 20 2016 23:11:30 Marko Käning wrote:
>did you see this post of mine back then?
>Wondering whether Rainer’s notes make sense...
Yes, I saw it, and IIRC I even reacted to it one way or another. So it was
Rainer who asked not to install all of Qt into its own prefix, just like I
On Friday December 11 2015, MacPorts wrote regarding "Re: [MacPorts] #49303:
qt4-mac: Update to 4.8.7_2 Breaks CMake"
> * cc: rjvbertin@… (added)
Sigh.
To date I have seen exactly 1 "core MacPorts dev" react to the underlying issue
and say "please don't ins
I think I'm preparing to propose another revbump of the kde4 ports...
I've started continuing Marko's work on KF5 ports (the frameworks, for now, 2-3
a day :)). I don't know yet to what extent KF5 and KDE4 can co-exist (KDE4
applications *can* run on/under a KF5 desktop, so clearly some form of
René J. V. Bertin wrote:
> I'll be having a look myself too, this
> weekend. Debian also installs the generator and qs_eval binaries, btw, which
> suggests they might be useful if not needed.
Done; modifications pushed to my repo (github.com/RJVB/macstrop)
R.
___
Michael Dickens wrote:
> I'll try your patches & see what comes of it.
While you're at it and if you have time: Debian/Ubuntu apply a number of other
patches to the code to bring it up to date. They're in my port repository
(devel/qtscriptgenerator/files). I'll be having a look myself too, this
IIRC: "LIBS += FOO" adds FOO to LIBS without checking for duplicates,
while "*=" adds only after checking that FOO isn't already there.
And, yes, an INCLUDEPATH is also required. Just replicate what QCA does
in its mkspec file ("s/QCA/phonon/g"). That said ...
Further (from another part of this e
Michael Dickens wrote:
> correctly do "LIBS *=..." no matter where Phonon is installed. That
BTW, what's the difference with "LIBS += ..."?
Are you sure a matching INCLUDEPATH expression isn't required?
R.
___
macports-dev mailing list
macports-dev@li
Michael Dickens wrote:
> What I'm planning on doing for Phonon is modifying its mkspec file to
> correctly do "LIBS *=..." no matter where Phonon is installed. That
> seems like a nice robust solution.
Yes - as long as it doesn't introduce artefacts or other side-effects.
In the meantime, I mana
Michael Dickens wrote:
> Yes, I'm sure. Using the stock phonon mkspec file and commenting in some
> of the debug "#"s from qt_functions.prf, I see the following. Fixing
> qt_phonon.pri to "do the right thing" adds LIBS and INCLUDEPATH for
> wherever phonon is installed. All of the various QtFOO li
On Fri, Oct 30, 2015, at 12:37 PM, René J. V. Bertin wrote:
> René J. V. Bertin wrote:
>
> > Michael Dickens wrote:
> >
> >> The error you show below with qtscriptgenerator is because it does not
> >> find phonon
> >
> > Are you sure? When I remove the typesystem_phonon line from generator.qrc
René J. V. Bertin wrote:
> Michael Dickens wrote:
>
>> The error you show below with qtscriptgenerator is because it does not
>> find phonon
>
> Are you sure? When I remove the typesystem_phonon line from generator.qrc and
> rebuild I still get the same error.
In fact, I think the issue on my e
test out this theory before pushing changes into
> > phonon. - MLD
>
> I was under the impression you knew better than I, but there's the list
> of all ports that declare a dependency on phonon in their Portfile
> (excluding qt4-mac and qt4-x11):
>
> %> fgrep -i
Michael Dickens wrote:
> The error you show below with qtscriptgenerator is because it does not
> find phonon
Are you sure? When I remove the typesystem_phonon line from generator.qrc and
rebuild I still get the same error.
Adding `LIBS += -L/opt/local/lib` to qtsg.pro doesn't make a differenc
n. What other projects use qmake and require
> phonon? I'd like to test out this theory before pushing changes into
> phonon. - MLD
I was under the impression you knew better than I, but there's the list of all
ports that declare a dependency on phonon in their Portfile (excluding
onon I installed that uses qmake finds phonon
> just
> fine with libphonon in ${prefix}/lib and the Qt4 frameworks in
> ${prefix}/libexec/qt4/Library/Frameworks and .dylib symlinks pointing to
> those
> framework binaries in ${prefix}/libexec/qt4/lib . And as far as I can
> t
f phonon I installed that uses qmake finds phonon just
fine with libphonon in ${prefix}/lib and the Qt4 frameworks in
${prefix}/libexec/qt4/Library/Frameworks and .dylib symlinks pointing to those
framework binaries in ${prefix}/libexec/qt4/lib . And as far as I can tell,
that
is *not* because I
Michael Dickens wrote:
> qmake PortGroups, just needed a rev-bump. Some ports such as phonon
> install files that =assume= the same install prefix as Qt, and so when
> they are installed elsewhere everything breaks down for ports that
> depend on them (e.g., using qmake to find phonon fails unless
Here's my take: Qt4 needed to be moved out of the way to be installable
in parallel with Qt5, and, by moving everything into a location where
you have to know where it is, we really test the build systems for those
ports that use Qt4/5. Many ports, generally those that use the qt4 or
qmake PortGrou
Ohoh, so this is finally where I get to say "I told you so"?
@Michael Dickens wrote:
> qtscriptgenerator is having issues with locating phonon now that it's
> not co-located with the qt4 install. Like QCA, it might make sense to
> just co-locate phonon into the new qt4 install prefix.
Yeah, and
On Thu, Oct 29, 2015 at 6:02 PM, Rainer Müller wrote:
> On 2015-10-29 17:05, Mojca Miklavec wrote:
>>
>> When 10.11 came out (where Qt 4 no longer worked), the
>> switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
>> hurry, so the maintainer decided for the easier path to simply put
>
On 2015-10-29 17:05, Mojca Miklavec wrote:
> This special layout is something that René has been working on for
> months, but nobody looked into his work for a very long time (and
> nobody felt the pressing need to fix the situation with conflicting
> Qt4 and Qt5).
This is true what you say about
On Thu, Oct 29, 2015 at 4:09 PM, Rainer Müller wrote:
> On 2015-10-27 22:24, Marko Käning wrote:
>> Hi Nicolas,
>>
>> while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
>> have rebumped ports kate, libkgapi and konversation.
>>
>> For instance, the latter tried to find lib
> On Oct 29, 2015, at 11:09 AM, Rainer Müller wrote:
>
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
>
> I only noticed this now, but it seems this change will cause problems:
>
> * binaries in ${prefix}/
On 2015-10-27 22:24, Marko Käning wrote:
> Hi Nicolas,
>
> while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
> have rebumped ports kate, libkgapi and konversation.
>
> For instance, the latter tried to find libqca in it’s old location
> ---
> Dyld Error Message:
> Lib
Hello,
>>
>> No. All ports need to be revbumped (preferrably as soon as possible).
>> It's just that there were sooo many ports that revbumping all
>> could not be easily done by a single person.
>
> OK, thanks for reassuring me here.
Yes, I had started listing all the KDE ports which need
qtscriptgenerator is having issues with locating phonon now that it's
not co-located with the qt4 install. Like QCA, it might make sense to
just co-locate phonon into the new qt4 install prefix. I'm looking into
it. - MLD
On Tue, Oct 27, 2015, at 05:48 PM, Marko Käning wrote:
> Answering my own qu
On Oct 27, 2015, at 6:07 PM, Marko Käning wrote:
>
> (When will Apple’s new admin have all those issues fixed I wonder…)
I am in communication with the admin and his manager about these issues. I
don't know how many details I should share right now but I hope to be able to
announce a solution
Hi Mojca,
On 27 Oct 2015, at 23:30 , Mojca Miklavec wrote:
> On Tue, Oct 27, 2015 at 11:03 PM, Marko Käning wrote:
>> Should we forget about revbumping everything and simply rely on that the
>> sanity of our users’ MacPorts installations
>> will be taken care of by rev-upgrade?
>
> No. All por
On Tue, Oct 27, 2015 at 11:03 PM, Marko Käning wrote:
> On 27 Oct 2015, at 22:48 , Marko Käning wrote:
>
>> Answering my own question now, at least partially, since a rev-upgrade just
>> gave me this much longer list:
>
> Should we forget about revbumping everything and simply rely on that the
>
On 27 Oct 2015, at 22:48 , Marko Käning wrote:
> Answering my own question now, at least partially, since a rev-upgrade just
> gave me this much longer list:
Should we forget about revbumping everything and simply rely on that the sanity
of our users’ MacPorts installations
will be taken care
Answering my own question now, at least partially, since a rev-upgrade just
gave me this much longer list:
---
---> Found 38 broken port(s), determining rebuild order
---> Rebuilding in order
qtscriptgenerator @0.2.0
kdenlive @0.9.10
kdiff3 @0.9.98
litecoin @0.8.7.4
cerv
Hi Nicolas,
while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
have rebumped ports kate, libkgapi and konversation.
For instance, the latter tried to find libqca in it’s old location
---
Dyld Error Message:
Library not loaded: /opt/local/lib/libqca.2.dylib
Referenced
On Sunday October 18 2015 22:50:55 Marko wrote:
Hi,
>Also Q>TDIR is set to '/opt/local' only!
Hmmm, that variable hasn't been used by Qt for a long time, at least not
officially. Are we sure it's required?
>So, it looks like that - although my additional sources where disabled:
>---
>MVM7:char
eploy Qt applications with MacPorts port qt4-mac
>>
+-
>>
Reporter: clemens.brunner@… | Owner: michaelld@…
>>
Type: defect | Status: new
>>
Priority: Normal | Milestone:
>>
This change does not change current behavior, and fixes an issue that
would have effected future behavior. Thanks for checking! - MLD
On Sun, Jul 5, 2015, at 08:03 PM, Ryan Schmidt wrote:
>
> On Jul 5, 2015, at 12:49 PM, Brandon Allbery wrote:
> >
> > On Sun, Jul 5, 2015 at 1:43 PM, Michael Dic
On Jul 5, 2015, at 12:49 PM, Brandon Allbery wrote:
>
> On Sun, Jul 5, 2015 at 1:43 PM, Michael Dickens wrote:
>> Maybe the comment might have been more clear; hopefully it's good enough
>> with this side commentary.
>
> People were confused on IRC also, which is why I recognized it and jumped
On Sun, Jul 5, 2015 at 1:43 PM, Michael Dickens
wrote:
> Maybe the comment might have been more clear; hopefully it's good enough
> with this side commentary.
People were confused on IRC also, which is why I recognized it and jumped
in. The comment could definitely use some work. :)
--
brando
onality. Most ports work with just a rev-bump;
but maybe 1 in 10 I come upon one that doesn't. So, I fix it to work
with qt4-mac installed into ${prefix} or into the new location, figuring
a generic fix is the best. This specific fix came from me fixing py-
pyqt4 (to be checked in Monday, most li
On Sat, Jul 4, 2015 at 11:51 PM, Ryan Schmidt
wrote:
> > + fix correcting of .pc files for any install location, not just when in
> ${prefix}.
>
> When would it not be in prefix?
>
When it's in a subdirectory of $prefix, so it can be installed at the same
time as qt5. Note that that is also the
> On Jul 3, 2015, at 3:45 PM, michae...@macports.org wrote:
>
> Revision
> 138275
> Author
> michae...@macports.org
> Date
> 2015-07-03 13:45:51 -0700 (Fri, 03 Jul 2015)
> Log Message
>
> qt4-mac:
> + fix homepage;
> + fix correcting of .pc files for
Hi,
- On 19 Jun, 2015, at 19:50, René J.V. Bertin rjvber...@gmail.com wrote:
> That's a huge list. I downloaded it and removed the initial (?i) and (?!) and
> replaced the \. with a regular dot, then did a case-insensitive fgrep of each
> line in both patches. No hits, as expected given the
On Friday June 19 2015 19:35:07 Clemens Lang wrote:
Hi Clemens,
>Check whether those patches contain any substring that would match an entry
>on the http://trac.macports.org/wiki/BadContent page. That would explain
>why you cannot attach them. If that's the case, we should remove the
>offending e
Hi René,
- On 19 Jun, 2015, at 17:23, MacPorts nore...@macports.org wrote:
> #46239: qca and qca-ossl adaptations to qt4-mac +concurrent
> ---+-
> Reporter: rjvbertin@… | Owner: michaelld@…
> Type: enhancement
trac is still acting up...
I should have checked the other qca plugins ...
I'll need a bit more time to test qca-tls: it seems it hasn't been updated
since qt3 ...
R.___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosfo
t "version preference") that
> control building behaviour, as a compromise. I'm aware that may not be as
> trivial as it sounds.
That sounds like variants to me. A port could offer qt4 and qt5 variants. The
user can indicate their preferred default by editing variants.conf.
On Jun 10, 2015, at 5:07 PM, René J.V. Bertin wrote:
> On Wednesday June 10 2015 13:31:11 Ryan Schmidt wrote:
>
>> You are correct, we don't want ports building themselves differently based
>> on what other ports are installed.
>
> I think one could and probably should allow for global settings
t's what I have been saying maybe even before Mojca opened the ticket, and I
have spent about 6 months or so making this possible. I've even implemented a
subport that allows to update qt4-mac to a co-installable version without
requiring an immediate rebuild of all the dependents, and ha
east disturbingly for users having installed qt4-mac
>> ports?!
>>
>> I - for my part - am still having a fully qt4-mac-based MacPorts system for
>> production, which is why I don’t want such automagic transitions to Qt5,
>> unless all dependent ports have also migrated
Marko Käning wrote:
> How to transition from Qt4 to Qt5 more smoothly?? This is going to happen for
> many ports in the future, so, perhaps this is a port where one could try to
> exercise how to do it least disturbingly for users having installed qt4-mac
> ports?!
>
> I - for
are dependent on gpsbabel:
qlandkartegt
---
How to transition from Qt4 to Qt5 more smoothly?? This is going to happen for
many
ports in the future, so, perhaps this is a port where one could try to exercise
how
to do it least disturbingly for users having installed qt4-mac ports?!
I - for my
On Tuesday June 02 2015 09:46:13 Ryan Schmidt wrote:
>A user who tries to use qt4-mac with libjpeg-turbo will get a crashing
>program, if they got a binary of qt4-mac from the packages server, which was
>build with jpeg.
No, I don't think so. The binary package from the buildbots
ith already using a path:libjpeg.dylib dependency?
Because the path:-style dependency is to be used if all the ports providing the
specified file are equivalent, but they are not, due to the differing library
version numbers.
A user who tries to use qt4-mac with libjpeg-turbo will get a crashing p
"port:jpeg".
It's okay. Installing jpeg-turbo is not feasable for users currently anyway
because all other ports are still hard-depending upon jpeg, so changing qt4-mac
won't change anything, really.
Also, Mike put jpeg as the default port, which avoids rebuilds due to
rev-up
On Tuesday June 02 2015 09:38:42 Ryan Schmidt wrote:
>Can't do that right now; they don't have the same library version. You should
>put it back to "port:jpeg".
What's wrong with already using a path:libjpeg.dylib dependency?
R
___
macports-dev mailin
> On Jun 2, 2015, at 8:48 AM, michae...@macports.org wrote:
>
> Revision
> 137005
> Author
> michae...@macports.org
> Date
> 2015-06-02 06:48:05 -0700 (Tue, 02 Jun 2015)
> Log Message
>
> qt4-mac:
> + update to 4.8.7, removing patches and relat
FYI,
I just submitted standalone tickets for variants and patches included in my
qt4-mac concurrent ticket but not related to making Qt4 co-installable :
#46606: qt4-mac "noexceptions" variant
Ticket URL: <https://trac.macports.org/ticket/46606>
#46607: qt4-mac +KDE variant.
Ti
could try this, esp. those doing work on Qt5/KF5
...
One test that could indicate whether indeed this
allows concurrency is to install
qt4-mac+concurrent (*not* qt4-mac-transitional)
and the current, unmodified qt5-mac .
I think that ought to work.
a) Traditionally you can install new or
On Jan 1, 2015, at 11:32 AM, René J.V. Bertin wrote:
> Hi
>
> Trac appears to be down or is inaccessible to me, so here's a correction for
> my port:qt4-mac modifications.
> To be precise, this corrects an issue when building with the proposed
> +noexceptions variant (which builds only the re
On 15/12/2014, at 9:46 AM, René J.V. Bertin wrote:
> 'evening!
>
> I finally got around to finishing up (or almost) my draft version for a
> qt4-mac port that can live alongside other (future) Qt port versions
> installed with the same approach: see https://trac.macpo
'evening!
I finally got around to finishing up (or almost) my draft version for a qt4-mac
port that can live alongside other (future) Qt port versions installed with the
same approach: see https://trac.macports.org/ticket/46238 .
Related submissions:
https://trac.macports.org/ticket/
me and the subport
> > declaration ends up having the wrong name.
>
> Mmmm, nope. ${name} is the top-level portname. ${subport} is the subport
> name. It's perfectly normal to declare a subport as "subport
> ${name}-something"; I do it all the time.
Indeed, repla
On Dec 12, 2014, at 11:08 AM, Brandon Allbery wrote:
> On Fri, Dec 12, 2014 at 12:05 PM, René J.V. wrote:
subport ${name}-transitional {
>
> I have yet to figure out the rules here, but one thing I tripped over when I
> was experimenting with subports is that this can be recursive. That is, if
On Friday December 12 2014 12:08:28 Brandon Allbery wrote:
> I have yet to figure out the rules here, but one thing I tripped over when
> I was experimenting with subports is that this can be recursive. That is,
> if you select the subport, then $name is the subport name and the subport
> declarat
On Dec 12, 2014, at 12:31 PM, René J.V. Bertin wrote:
> On Friday December 12 2014 12:21:54 Lawrence Velázquez wrote:
>
>> Does the variable "qt4_is_concurrent" exist? If not, the portfile itself
>> throws an error and won't index.
>
> Yes, it exists, and portindex doesn't throw an error...
P
On Dec 12, 2014, at 12:05 PM, René J.V. Bertin wrote:
> So I'm trying to convert my +libsymlinks convenience variant into a ditto
> subport, qt4-mac-transitional (better name suggestions still welcome).
>
> I'm stuck at the stage where I simply have
>
> subport ${n
On Fri, Dec 12, 2014 at 12:05 PM, René J.V. wrote:
>
> subport ${name}-transitional {
>
I have yet to figure out the rules here, but one thing I tripped over when
I was experimenting with subports is that this can be recursive. That is,
if you select the subport, then $name is the subport name an
By "popular request" I'm taking this to the dev ML...
So I'm trying to convert my +libsymlinks convenience variant into a ditto
subport, qt4-mac-transitional (better name suggestions still welcome).
I'm stuck at the stage where I simply have
subport ${name}-transition
Hi Nicos and Michael,
making oxygen-icons not depending on qt4-mac would be a good idea in the light
of the existence of qt5-mac.
I am still not using applications based on qt5-mac, but it is going to come
soon.
On the other hand I have an OSX/CI system running, which uses a custom-built
qt5
You only need a stub if you’re renaming/replacing a variant to chain the
requirement: it doesn’t really matter if it’s going away unless there is an
active_variant dependent, in which case simply fix that first and wait two
weeks.
On Jul 1, 2014, at 2:48, Marko Käning wrote:
> The question is
Hi all,
> At the risk of variant bloat we could also s/replace/add/ +debug_${name} and
> +docs_${name}.
The question is whether variants in general can be added temporally in order to
get rid of
them once we've got MacPort changed according to Michael's proposal wrt +debug?
Is it actually allo
Hi Michael,
> Actually, I was going for the more general approach: Any port can have a
> +debug option.
...
> One can always use "enforce variants" to get as many dependencies as possible
> using +debug.
oh, I see, that would mean that the debug option would get a different handling
than a nor
On Jun 30, 2014, at 3:30 PM, Marko Käning wrote:
> Is qt5-mac not binary distributable? I had expected the buildbots to serve it
> just like qt4-mac...
I did not see the buildbot logs for qt5-mac, but it does seem to be
distributable:
$ ~/macports/base/portmg
On 6/30/14 1:26 PM, MacPorts wrote:
> (2) I would say that using a private prefix for Qt 5 is "good enough" for
> now unless the software would link against Qt 4 by accident (just because
> `-I${prefix}/include` contains Qt 4 for example).
This is definitely a possibility. A current example is
On Jun 29, 2014, at 8:46 PM, Ian Wadham wrote:
> On 29/06/2014, at 7:52 PM, Marko Käning wrote:
>> on the kde-mac ML the question came up whether the necessity to install
>> qt4-mac in its
>> debug variant - when one simply needs KDE ports installed in their debug
>&g
g forward to learn from its setup for the KDE/CI system which
> I am currently working on [1].
> Thanks so much for bringing qt5 now MacPorts'ish to OSX!!!
Yes, yes it is. I give full credit to mcalhoun!
> Re qt5-mac I am wondering whether coinstallability with qt4-mac will be
&
Hi Ian,
> I would also like us to consider something similar for +docs, especially with
> KDE.
> Also a +docs_kde would not have to be a different binary package - just a
> downloading
> and "compiling" of docs subdirectories with meinproc4, which will be already
> installed.
yes, that sounds
debug_kde which you're talking about, right?
> qt4-mac (and, now qt5-mac), are notorious for being enormous
> time consuming compiles, for which having a pre-compiled binary for
> "most users" is a big win.
That's the idea. :)
> Anyway, I hope I interpreted your
On 29/06/2014, at 7:52 PM, Marko Käning wrote:
> on the kde-mac ML the question came up whether the necessity to install
> qt4-mac in its
> debug variant - when one simply needs KDE ports installed in their debug
> variant - is only
> due to MacPorts' way of handling port
ded. Since +debug is generally not the default, this would help speed
up those installs using +debug which would be compiled from source
locally. qt4-mac (and, now qt5-mac), are notorious for being enormous
time consuming compiles, for which having a pre-compiled binary for
"most users" is a
Hi Qt4-affine devs,
on the kde-mac ML the question came up whether the necessity to install qt4-mac
in its
debug variant - when one simply needs KDE ports installed in their debug
variant - is only
due to MacPorts' way of handling port variants...
If that's indeed the case, it may se
The fact of
> removing kde4
> may be more trouble than it is worth.
I see your point there!
I wanted to abuse it for the KDE/CI system which I am trying to set up using
MacPorts.
(There I need just the icons without qt4-mac or anything else.)
It would have been nice if the icons wouldn’
t;> Why do the oxygen-icons actually require ports qt4-mac and phonon
>> installed?
>>
>> ---
>> $ port deps oxygen-icons
>> Full Name: oxygen-icons @4.12.5_0
>> Extract Dependencies: xz
>> Build D
wrote:
> Why do the oxygen-icons actually require ports qt4-mac and phonon
> installed?
>
> ---
> $ port deps oxygen-icons
> Full Name: oxygen-icons @4.12.5_0
> Extract Dependencies: xz
> Build Dependencies: cmake, pkgconfig, automoc
Why do the oxygen-icons actually require ports qt4-mac and phonon installed?
---
$ port deps oxygen-icons
Full Name: oxygen-icons @4.12.5_0
Extract Dependencies: xz
Build Dependencies: cmake, pkgconfig, automoc
Library Dependencies: qt4-mac, phonon
Hi Michael,
On 07 May 2014, at 02:51 , Michael Dickens wrote:
> Given the ticket's info that you provided it will definitely be fixed
> in the Qt 4.8.6 release
yes, I know. That was the first thing I tested and which made me write my post
in the first place. ;-)
Thanks again,
Marko
__
You're welcome, Marko. I do what I can in the time I can make available.
I hope that the 4.8.6 upgrade is relatively smooth. After struggling
with +cxx11 using libc++ for a few days on 10.9 (creating patch after
patch after patch), I gave up -- as evidenced by the pre-fetch error in
that variant. I
Hi Michael and contributors,
thanks so much for this upgrade!!! It’s awesome how you take care of Qt4!
I appreciate that so much, because it is an essential library for KDE as well,
which I am interested in.
This surely not only resolved long lived little annoyance [1].
Thanks again,
Marko
om source *and* unavailable for download
>> anywhere?
>
> I agree. Where is the source? Where and how was it built? Maybe it
> needs its own port that qt4-mac can depend upon for 10.9.
And also very importantly, what license is it under? I don't see any
copyright notices being r
the source? Where and how was it built? Maybe it
needs its own port that qt4-mac can depend upon for 10.9.
Blair
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
ports.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? - MLD
>
> On Fri, Nov 1, 2013, at 10
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 Sun, Sep 1, 2013 at 4:01 AM, Mark Anderson wrote:
> I have access, and I can't really discuss problems here because of the
> strict NDA. I've been trying to find solutions, but I'm on my own. That
> said, a lot of changes will need to be made for Mavericks, but that's
> nothing new. Every update
I have access, and I can't really discuss problems here because of the
strict NDA. I've been trying to find solutions, but I'm on my own. That
said, a lot of changes will need to be made for Mavericks, but that's
nothing new. Every update is like this.
Mark
—Mark
___
Mark E. A
If this were actually a concern for Apple they would address it.
On Aug 31, 2013, at 2:36 PM, Ryan Schmidt wrote:
>> Do we, as MacPorts developers, get any access to Mavericks before it comes
>> out so that we can work on fixing issues such as this?
>
__
On Aug 31, 2013, at 13:34, Michael Dickens wrote:
> Do we, as MacPorts developers, get any access to Mavericks before it comes
> out so that we can work on fixing issues such as this?
No
> Do we have to be Apple developers (and pay $) for this privilege?
Yes
> I have been an Apple developer
in the past few years in this regard (and,
thus, what I knew from before cannot be applied). Thanks for the info.
- MLD
Log Message
qt4-mac: Error out early on Mavericks
Modified Paths
* [1]trunk/dports/aqua/qt4-mac/Portfile
References
1. file://localhost/tmpfs/linkstmp/KfePdewda6
hat helps clarify the situation a bit. - MLD
Hi,
Sorry for digging such an old thread, however after my searches it is the
most relevant to my problem. I would like to use phonon to play videos with
Qt 4.8. I installed these ports:
- phonon
- qt4-mac
- Qt4-creator-mac
My program compiles fine, b
On Jul 22, 2013, at 14:12, michae...@macports.org wrote:
> Revision: 108402
> https://trac.macports.org/changeset/108402
> Author: michae...@macports.org
> Date: 2013-07-22 12:12:19 -0700 (Mon, 22 Jul 2013)
> Log Message:
> ---
> qt4-mac:
> * "
.5; I'm running 10.8). If nobody complains, or, even better, if
> someone with a 10.5 box verifies that their change works, then I'll
> remove these (silently; or at some upcoming update to qt4-mac). - MLD
Did you just need to know whether qt4-mac @4.8.5_0 builds on Mac OS X 10.5? It
1 - 100 of 257 matches
Mail list logo
