Hello,
I've taken my courage with 3 hands, and started working on a +concurrent
variant for qt4-mac, as a prerogative to having a ditto variant for qt5-mac
(which won't even build when qt4-mac is installed).
Still with me?
So rather than using a new port, I went with a variant that is actually
Cheers,
R.
On Oct 10, 2014, at 00:41, René J.V. Bertin wrote:
> Hello,
>
> I'm having some trouble port:kdepim-runtime4 (currently still at 4.12.5)
> against port:kdepimlibs4 and kdepimlibs4-kioslaves (currently at 4.13.3) when
> port:libkgapi is also installed, and the
Hello,
I'm having some trouble port:kdepim-runtime4 (currently still at 4.12.5)
against port:kdepimlibs4 and kdepimlibs4-kioslaves (currently at 4.13.3) when
port:libkgapi is also installed, and the akonadi_google_calendar is thus built.
This *could* be an issue with clang-3.0 (sadly I forgot w
A tiny bit of good news on the Qt4 front:
Begin forwarded message:
> From: "Qt Continuous Integration System (Code Review)"
>
> Date: October 09, 2014 13:05:33 CEST
> To: Shawn Rutledge , René J.V. Bertin
>
> Cc: Morten Johan Sørvig , Qt Sanity Bot
> ,
On Sep 08, 2014, at 10:26, Albert Astals Cid wrote:
> Isn't this something that we should aim to fix at the Qt level rather than at
> the KDE level since Qt-only apps will have the same problem?
Can "we" fix things in Qt?
I don't know if you saw my remarks, but Qt already has some support for
On Sep 04, 2014, at 20:32, Lawrence Velázquez wrote:
> You can specify a new depth for all histories with "git fetch --depth",
> though.
I'd have to have a look at that, thanks.
> MacPorts doesn't do anything smart with VCS fetching at the moment; the fetch
> phase always just does a full chec
On Sep 04, 2014, at 17:47, Lawrence Velázquez wrote:
> The only difference between that and what base does when ${git.branch} is
> empty is that you get all the remote HEADs instead of just the primary one.
> You still have all the non-reproducibility problems I mentioned initially.
Never clai
Hello all,
Re: https://trac.macports.org/ticket/44473
Here's something I hadn't done before, seeing how the SecKeychain API hasn't
changed from 10.6 to 10.9: test my patches under 10.9. I thought I'd give it a
try today, and fired up my 10.9 VM.
Turns out something doesn't work right, but sinc
On Aug 22, 2014, at 22:59, Clemens Lang wrote:
> binary archives. In fact, since it picked up an unfinished build and
> continued it, this may well be the reason for not using binaries.
Yes, I should have looked more closely at that log before uploading it. I
surely must have relaunched the upgr
Hi,
On Aug 21, 2014, at 12:17, Clemens Lang wrote:
>> I think my macports.conf file fulfils those conditions, but just in case you
>> forgot something, I've attached it.
>
main.log.bz2
Description: BZip2 compressed data
> I couldn't see anything that would prevent the use of binary archives
On Aug 21, 2014, at 00:37, Ryan Schmidt wrote:
>
> On Aug 20, 2014, at 4:05 AM, René J.V. Bertin wrote:
>
>> In fact, is there a way to get those installed manually, should `port` not
>> pick them up for whatever reason? For ports that take as long to build as
>> g
On Aug 21, 2014, at 02:00, Brandon Allbery wrote:
> So, for what it's worth, just did a selfupdate and upgrade outated.
>
> It built libgcc from source, without even checking for an archive. I do not
> force source builds or use nonstandard prefixes, and in fact I do get many
> things from arc
Hi,
Doing a belated selfupdate, I see that libgcc has been bumped to 4.9x (and
fails to build with Apple's gcc-4.2). However, I'm still using gcc48, with no
intention to upgrade it just now. Am I obliged to use a 4.9 libgcc - is that
even possible with gcc-4.8?
R.
_
I know opinions differ on the use of a symlink as/in /opt/local to trick
MacPorts into installing in a custom location. I'm in the camp that considers
that such a symlink ought to be transparent, to the extent possible given that
OS X will do link resolution before storing dependencies ("rpaths"
On Aug 16, 2014, at 20:39, Lawrence Velázquez wrote:
> No, just a normal /path/like/this. A file:///path/like/this will work, but
> Git will revert to using its usual transport — which would still be faster
> than network fetching, but you'd lose hardlinking. (There are use cases for
> this, bu
On Aug 16, 2014, at 20:39, Lawrence Velázquez wrote:
>
> The problem is that a head can point to one commit on one day and another
> commit on another day, while ${version} doesn't change.
Well, that's an accurate representation of development practice ... with the
version typically being "the
Hi,
I'm whipping up a portfile for kdevplatform-devel and kdevelop-devel, aiming to
follow the git repo. KDevplatform has a rather big repo, which is re-fetched
each time I modify the portfile. It'd be useful to do a `git clone --depth=1`
to avoid downloading the entire commit history for what
I'm at 0.19.2_0+universal, which works rather obviously. That's not the current
version, then (I'm reluctant to do a selfupdate if there's indeed a problem
with such a central port).
R.
On Aug 14, 2014, at 15:16, John Ruschmeyer wrote:
> Is there an eta for when the Universal variant of gettex
On Aug 12, 2014, at 17:42, Nicolas Pavillon wrote:
> Hello,
>
> As for me, I never noticed this variable. However, I assume that it is off by
> default, as I don’t it is set in any place to my recollection. It is thus not
> sure of how well this works, and which exact functionality it provide
On Aug 04, 2014, at 11:28, Ryan Schmidt wrote:
> Normally, if a state file exists, MacPorts compares the checksum of the
> portfile with the checksum previously stored in the state file, and if they
> don't match, it cleans the work directory first. "-o" means don't do that, so
> if anything it
Suppose one is working on adapting an OS project to become a port. You've done
a `port destroot` and then realise you want to try some small change in the
build. Rather than doing the whole build all over again, you do a `make` in the
build directory ... and then what? I just discovered that rem
Hi,
I've had selfupdate failures too, from 2.2.x to 2.3.0 and later from 2.3.0 to
2.3.1 . I never mentioned them because in both cases the error had seemed to
resolve itself after issuing the selfupdate command a 2nd time.
R.
On Aug 01, 2014, at 01:12, Lars Sonchocky-Helldorf wrote:
> Hi,
>
>
On Jul 29, 2014, at 13:51, Mojca Miklavec wrote:
> The problem probably affected *every single port* during an *upgrade*
> from an icompatible API change.
I was only saying *I* didn't run into any issues that (with hindsight) must
have been caused by the change.
> You usually have to explicitly
On Jul 29, 2014, at 12:54, Eric Gallager wrote:
> This reminds me, the configure script for subversion checks for both kwallet
> support and for OSX KeyChain support... is there any point in configuring it
> with both if kwallet is just using the system keychain as a backend in the
> first pla
Morning!
On Jul 29, 2014, at 10:01, Frank Osterfeld wrote:
>
> On 28 Jul 2014, at 23:30, René J.V. Bertin wrote:
>>
>> I just stumbled across a Cmake variable/flag, MAC_USE_OSXKEYCHAIN :
>>
>>> option(MAC_USE_OSXKEYCHAIN "On OS X, use the keychain a
On Jul 29, 2014, at 10:51, Mojca Miklavec wrote:
> You "reversed" the direction of the commit
Indeed ...
> (http://trac.macports.org/changeset/121112), but adding
> configure.cppflags is certainly not acceptable as it causes way too
> many headaches.
Really? How long had it been there (i.e. the
MinSizeRel (-Os -DNDEBUG), and
This ought at least explain the failures to find headerfiles in
/opt/local/include mentioned by b...@ithryn.net .
R.
On Jul 28, 2014, at 21:58, René J.V. Bertin wrote:
> On Jul 28, 2014, at 20:33, b...@ithryn.net wrote:
>
>> The log file complains of
Hi Ian,
On Jul 29, 2014, at 00:33, Ian Wadham wrote:
> Might I suggest something that expresses what you are getting
> with the proposed variant name. You cannot use +debug, because
> it is already taken by MacPorts. So how about +symbols?
Not bad...
>
> There are two flavours in CMake, RelWi
On Jul 28, 2014, at 20:33, b...@ithryn.net wrote:
> The log file complains of a linking error, specifically it can't find
> -lakonadi-calendar. This library does exist, however the link command does
> not have -L/opt/local/lib so it cannot find the library. If i edit the link
> command by hand,
Well "mystère et boules de gomme" as we say here ... it seems all of a
sudden my little script started having the hoped-for effect, judging from a
number of apps in /Applications/MacPorts/KDE4 now having an icon that I cannot
recall copying myself via the Finder's GetInfo inspector!
icon
On Jul 28, 2014, at 18:52, Mihai Moldovan wrote:
>> - can one have local portgroup definitions/overrides?
>
> I wouldn't know what speaks against that.
Neither do I, nor do I know how to go about them. Add a registry directory
under the directory that holds my local port files?
>> but that's
Hello,
I've found and had a peek at the cmake portgroup definition file. Seems easy
enough to add a variant to it.
Questions:
- can one have local portgroup definitions/overrides?
- what would be a good variant name to enable the RelWithDebInfo (release with
debug info) cmake type? I currently
I can understand that one cannot run several (un)installations in parallel, but
is there a reason one cannot do a port destroot or even port build when the
registry is locked?
R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https
On Jul 26, 2014, at 12:14, Ryan Schmidt wrote:
> * don't use the +debug variant of qt4-mac, and
Forgot. It might be useful to add a variant to the KDE portgroup (or the cmake
portgroup, to extend the feature beyond KDE) that uses
-DCMAKE_TYPE:STRING=RelWithDebInfo . Possibly attempting to make
> Have you seen this http://qt-project.org/doc/qt-4.8/debug.html ?
Of course.
> Since the release and debug libraries are inside the framework, the app is
> simply linked against the framework. Then when you run in the debugger, you
> will get either the release version or the debug version, dep
After installing the qt4-mac debug variant and rebuilding/upgrading a number of
ports, I'm facing issues with the _debug libraries. As long as I keep the debug
variant activated there are errors about symbols being present twice (in the
regular and _debug libraries) and the only way to prevent (
On Jul 22, 2014, at 11:42, Ian Wadham wrote:
> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/KDE4Macros.cmake
> Look for KDE4_ADD_APP_ICON. Gd luck!!!
There doesn't appear to be anything in there that explains why the process
doesn't complete
On Jul 20, 2014, at 11:15, Marko Käning wrote:
> BTW, René, did you see this b.k.o. ticket:
> https://bugs.kde.org/show_bug.cgi?id=333050 ?
>
> Wondering whether this could be related.
In the sense that it gives a hint where to look for the scripting code that is
responsible for generating an
Anyone interested in testing a patch to use native file dialogs with KDE apps?
https://bugs.kde.org/show_bug.cgi?id=337356
Portfile diff:
8<--
---
/opt/local/var/macports/sources/rsync.macports.org/release/ports/kde/kdelibs4/Portfile
2014-06-24 18:30:27.0 +0200
+++
On Jul 07, 2014, at 12:39, Ian Wadham wrote:
Now why did I misread and wonder why Apple would have a Real Men column on a
site called Activity Monitor? :)))
> FWIW, and this is perhaps completely off-topic, I find that Clang performs
No, I think it's perfectly on topic.
> well enough almost al
On Jul 06, 2014, at 23:56, Mojca Miklavec wrote:
>> universal_variant no
>
> I don't agree with this change. The "universal_variant no" is there
> for ports that are not capable of being built as universal.
It was just a suggestion, but semantically speaking the expression just
indicates that t
On Jul 06, 2014, at 23:30, Brandon Allbery wrote:
> I do not always understand the reasoning Canonical applies. But they use
> Debian as their upstream, so in this case that's where the policy comes from.
That's not exactly true, AFAIK they evolve independently (= much faster)
nowadays and just
On Jul 06, 2014, at 21:31, Brandon Allbery wrote:
> public forums), but given that Debian distributes git and they're usually
> pretty good at being a stickler for license terms, I would expect the
> exemption exists and we just have to confirm it and add it to the Portfile.
I suppose Canonica
On Jul 06, 2014, at 12:30, Ryan Schmidt wrote:
> $ ~/macports/base/portmgr/jobs/port_binary_distributable.tcl -v git
> "git" is not distributable because its license "gpl" conflicts with license
> "OpenSSL" of dependency "openssl"
Yay ...
That's got nothing to do with Apple-specific policies,
On Jul 05, 2014, at 22:39, Clemens Lang wrote:
> You need an Info.plist file in the Contents folder of the app bundle. It needs
> to be an Apple property list file and contain the key CFBundleIconFile at the
> top dict level, where the corresponding value is the path of the icon file
> relative t
On Jul 05, 2014, at 22:05, Marko Käning wrote:
> On 05 Jul 2014, at 21:50 , René J.V. Bertin wrote:
>> Sadly that doesn't teach me anything new ... The last icon (icns) related
>> message is that the .icns file was saved in the build directory.
>
> so, if you know wh
On Jul 05, 2014, at 16:56, Jeremy Lavergne wrote:
> Using trace mode might help in spotting what it is trying to find (port -t
> ...)
Sadly that doesn't teach me anything new ... The last icon (icns) related
message is that the .icns file was saved in the build directory.
R.
_
Anyone know where icon generation is handled in cmake-based ports? I whipped up
a replacement for the iconutil command using png2icns. The command is picked up
(if it's in /usr/bin ..) and icns files are generated, but they're not copied
into the target appbundles, let alone installed as app ico
In hope it's not completely out of place to discuss this here, but has anyone
else noticed that clang's supposedly better build performance (as opposed to
gcc) is no longer an accurate selling argument, at least for version 3.4?
Comparing build times of a port I'm working on, KDE's rekonq so mo
On Jul 03, 2014, at 13:43, Mojca Miklavec wrote:
> On Thu, Jul 3, 2014 at 11:45 AM, "René J.V. Bertin" wrote:
>> Quick question: I have the universal cmake variant installed, and I fail to
>> see the interest of that. Is there any way it could have been installed
>
I'm also a bit troubled installed my weekly bunch of upgrades: it seems there
are much less binary packages available. I cannot remember having had to wait
for the git port to build, for instance - it's completely gone from the
mirrors. And it isn't even (L)GPL-3 licensed, so what's the reason f
Quick question: I have the universal cmake variant installed, and I fail to see
the interest of that. Is there any way it could have been installed because
another universal variant's build dependencies?
___
macports-users mailing list
macports-users@li
On Jul 02, 2014, at 05:25, Ian Wadham wrote:
>
> Please feel free to join us on kde-mac as Marko has suggested. Maybe you
> would like to skim the recent archives there and on kde-devel [1] and [2].
> What Boudewijn Rempt, a seasoned KDE developer, has to say is rather
> interesting.
Lots of th
On Jun 26, 2014, at 23:44, Ryan Schmidt wrote:
> And is your configured MacPorts prefix /opt/local or
> /Volumes/Debian/MacPorts? Because we previously had a bug when your
> configured
The former.
> prefix is a symlink to somewhere else, which was supposed to have been
> solved, but maybe t
On Jun 26, 2014, at 23:17, Ryan Schmidt wrote:
>> NB: if like me you get registry errors ("file name too long") since having
>> upgraded to MacPorts 2.3.0, you'll have noticed as I that those sort
>> themselves out, possibly requiring you to repeat certain commands.
>
> This is the first I've h
I've created an enhancement ticket with freetype, fontconfig and cairo ports
providing a +infinality variant:
https://trac.macports.org/ticket/44148
Let me know how they work out!
R.
___
macports-users mailing list
macports-users@lists.macosforge.org
On Jun 24, 2014, at 19:36, Jeremy Huddleston Sequoia wrote:
> If this is a real improvement, I'd be glad to take these patches into XQuartz
> in its next release.
As to that, I can only suggest you see for yourself, peruse bohoomil.com and
see what others say on the subject. That's how I found
On Jun 24, 2014, at 11:14, René J.V. Bertin wrote:
So creating a freetype+infinality variant was rather straightforward once I
obtained the right patchfiles from bohoomil's github repo.
I didn't think of making a screenshot before installing the variant, but I
don't think it
On Jun 23, 2014, at 23:45, Jeremy Huddleston Sequoia wrote:
> What is infinality?
They're a set of patches that aim to improve font rendering quality. With them,
quality is at least as good as it is under MS Windows or Mac OS X, possibly
even better (with the usual personal taste caveats).
http
On Jun 23, 2014, at 20:45, Brandon Allbery wrote:
> On Mon, Jun 23, 2014 at 2:42 PM, "René J.V. Bertin"
> wrote:
> You mean for getting additional patches and patches to the Portfile accepted?
>
> Yes.
Why would that be any different than proposing a regular portfi
On Jun 23, 2014, at 19:59, Brandon Allbery wrote:
> That's not the problem. The problem is that Jeremy maintains XQuartz and
> MacPorts xorg (and Homebrew's xorg, I believe) from the same sources
> currently. You'll need to work something out with him if you want to add
> Infinality to the MacP
What libfreetype do X11 applications under MacPorts use, with which
anti-aliasing settings?
Supposing it's the freetype port that determines the display quality of fonts
(and not the one that ships with XQuartz), what are the chances that the
Infinality patches would provide the same benefits as
On Jun 21, 2014, at 13:43, Nicolas Pavillon wrote:
> Hello,
>
> As kbuildsycoca4 must be run each time a new KDE port is installed, and this
> at user level so that Macports can’t do it during a
Doh, of course...
> post-install procedure, it was considered that users would not want to have
On Jun 21, 2014, at 11:46, Nicolas Pavillon wrote:
> Hello,
>
>> Turns out all that was (apparently) needed was a kbuildsycoca4 incantation.
>> Guess that could be listed as a post-install in the Portfile or something.
>
> It is. See ‘port notes kdelibs4’.
"Notes kdelibs4" doesn't mention kb
Hello,
On Jun 21, 2014, at 06:49, Nicolas Pavillon wrote:
> I can’t say about the detection of photos, but kipi-plugins should be
> available, as there are existing in Macports (libkipi) and are listed as a
> dependency of digikam.
>
Turns out all that was (apparently) needed was a kbuildsy
I've had to get my hands dirty to do today's upgrade on my 10.9.2 VM. This is
just a report as I think that ultimately the error was mine, though it'd have
been nice if port had corrected the effects of the error (and known how to
upgrade an existing webkit-gtk3(-2.0) install!!).
> sudo port se
On Jun 11, 2014, at 14:15, Ryan Schmidt wrote:
> On Jun 10, 2014, at 8:16 AM, Mark Brethen wrote:
>
>> Response from z88 developers below. I followed up with the suggested fixes
>> already mentioned in this group.
>>
>> Begin forwarded message:
>>
>>> From: Z88Aurora Support
>>> Subject: AW:
On Jun 05, 2014, at 13:19, Gustavo Seabra wrote:
>> Gnucash yes, oxygen-gtk, no. I'm throwing together a portfile for that, but
>> it was a straight install. Just point the install prefix to /opt/local, and
>> invoke MacPort's cmake command.
>
> So, you mean downloading the source files (maybe
On Jun 05, 2014, at 12:19, Gustavo Seabra wrote:
> Thanks! Can you elaborate on that a bit? Did you build it out of Macports?
Build what, gnucash or oxygen-gtk? Gnucash yes, oxygen-gtk, no. I'm throwing
together a portfile for that, but it was a straight install. Just point the
install prefix
On Jun 04, 2014, at 20:21, Eric Gallager wrote:
> Wow, that looks a lot simpler than I thought that it would be... I was
> expecting something like this would have to be fixed upstream by gcc, because
> that is how they handle the GNU vs. NeXT Objective C runtime issues, but if
> all it takes
On Jun 04, 2014, at 20:51, Eric Gallager wrote:
> Isn't 236.3_1 the broken one that failed to build? How did you manage to get
> it installed in the first place?
I had an exchange (on here or via the bug tracker) and had even prepared my own
patched portfile that version-locked to 136 on 10.6,
On Jun 04, 2014, at 20:05, Nicolas Pavillon wrote:
>
> I don’t think I could do that in this case. I had typically missed the use of
> kioslaves in kdepim* ports, so that I disabled them to enable the binary
> distribution, at the cost of usability of some programs as you pointed out
> later.
On Jun 04, 2014, at 14:53, Nicolas Pavillon wrote:
> I had a quick look at the Portfile, and apart some small things which could
> be simplified, it seems fine to me. One thing missing though are the
> maintainers. Should I put you, René, as you proposed it, or should I take it
> as an additio
Hi Marko,
On Jun 03, 2014, at 20:38, Marko Käning wrote:
> Feel free to post a port file for it and will commit it for you.
This one seems to do the trick - tested on 10.6.8 and 10.9.2 .
I'm not sure I understood the livecheck.regex magic completely, though.
It'd be nice if kdepim4-runtime cou
On OS X 10.6.8:
{{{
$ port installed ld64
The following ports are currently installed:
ld64 @236.3_1+llvm34 (active)
$ port outdated
ld64 236.3_1 < 136_2 (epoch 0 < 1)
}}}
Why revert to 136_2 instead of remaining at 236.3_1 if the current version
doesn't build on 1
On Apr 04, 2014, at 18:28, René J.V. Bertin wrote:
>
> For the google contacts and calendar resources, this is required:
> # Libkgapi2
> find_package(LibKGAPI2 1.9.81 QUIET CONFIG)
> set_package_properties(LibKGAPI2 PROPERTIES DESCRIPTION "KDE-based library
> for a
Hello,
2 quick questions:
1) Why is it that the KDE wallet always opens behind (all) other windows,
instead of in front? Any chance to make it come to the front?
2) I have the Akonadi Google contact and calendar daemons on my 10.6 machine
(installed together with the other daemons), but not on
On May 31, 2014, at 20:51, René J.V. Bertin wrote:
> Is there anything that must be set up differently on 10.9 compared to 10.6?
As a matter of fact, yes. Looking closer at system.log, I saw mention of
missing PAM modules - and if even 1 (non crucial) module listed in
/etc/pam.d/imap
Hello,
On May 29, 2014, at 10:38, Nicolas Pavillon wrote:
>
> As mentioned by René, this has been already patched in KDE 4.13 branch, and
> the issue seemed more general than just OS X.
>
Clearly it is; the solution came from a FreeBSD context.
> I had a look, but the small issue is that the
Hello,
>From what I see, there is no lldb port in MacPorts. I've tried to build it (on
>OS X 10.6.8) following the instructions at http://lldb.llvm.org/build.html,
>but that didn't get me anywhere. Is that the underlying reason there is no
>lldb port - too hard or impossible to get the code to
On May 26, 2014, at 18:32, René J.V. Bertin wrote:
> How should I proceed with this?
I spoke too soon:
http://mail.kde.org/pipermail/kde-freebsd/2014-May/017494.html
Turns out this tweak resolved my issue too.
___
macports-users mailing l
th that.
R.
On May 23, 2014, at 17:06, René J.V. Bertin wrote:
> Hello,
>
> On May 23, 2014, at 14:13, Nicolas Pavillon wrote:
>
>>> I notice that the default is now to use a mariadb backend, but even if I
>>> install that akonadi variant, how am I to reconfi
Hello,
On May 23, 2014, at 14:13, Nicolas Pavillon wrote:
>> I notice that the default is now to use a mariadb backend, but even if I
>> install that akonadi variant, how am I to reconfigure the server if I cannot
>> get to the server configuration dialog (which I only know how to open
>> thro
I'm not sure exactly which of the recent KDE updates messed things up, but I
can no longer use any KDE application that relies on Akonadi on my 10.6 machine.
I'm convinced that I had configured the server to use sqlite (as I do under
Linux), but the 1st error I noticed (and finally corrected) was
I'm currently experiencing a build failure with the i386 branch of the
universal pcrexx variant. As can be seen from the log, the demo code is
compiled without the double -arch options, and thus gives "simple", 64bit
object files that will not link (because the link command is executed correctly
Among my weekly updates, I encountered several build failures for ld64 236.2
which lead me to believe no one tested this version on OS X versions without
libc++ ... or a version cap (to/at 136.2) was forgotten.
The first, a patch reject on order.cpp was easy to correct (the diff, based on
versi
On May 05, 2014, at 14:52, Brandon Allbery wrote:
> On Mon, May 5, 2014 at 7:17 AM, Julien T wrote:
> If it's really the case, it means launchd is starting before other volumes
> are mounted, even for the local one ... :(
>
> launchd is the process that starts the system; the only mounted volu
Of course all permissions/ownerships are correct on both the Launch*
directories and the plist, and the directories are on a volume that's mounted
when the system tries to launch tasks at boot (which in my experience requires
that they reside on the boot volume)?
R.
On May 05, 2014, at 06:28
NB!
The current patch avoids the use of O_CLOEXEC even on systems that have it,
which is not the solution that has been suggested on the dbus trac. I've
modified the ticket to include a patch that only modifies the code path on
systems without O_CLOEXEC.
https://trac.macports.org/ticket/43203
On Apr 04, 2014, at 01:03, Ryan Schmidt wrote:
>
> On Apr 3, 2014, at 17:51, René J.V. Bertin wrote:
>
>> On Apr 04, 2014, at 00:33, Ryan Schmidt wrote:
>>>>
>>>> What are the options here? I'm a bit amazed that this flag wasn't passed
&
On Apr 06, 2014, at 23:48, Eric Gallager wrote:
> You can try looking at the cross-gcc PortGroup:
> https://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl
Thanks - but could you give me some pointers what to do with this information?
> As far as your specific
Hello,
I'd be very interested in having a cross-compiler for x86_64-elf-linux-gnu on
OS X. Since there's no such cross-compiler in MacPorts, I'm trying to build one
myself, following these instructions:
http://wiki.osdev.org/GCC_Cross-Compiler#The_Build
This gave me a working binutils install,
On Apr 04, 2014, at 18:28, René J.V. Bertin wrote:
> For the google contacts and calendar resources, this is required:
> # Libkgapi2
> find_package(LibKGAPI2 1.9.81 QUIET CONFIG)
> set_package_properties(LibKGAPI2 PROPERTIES DESCRIPTION "KDE-based library
> for accessing var
On Apr 04, 2014, at 12:25, René J.V. Bertin wrote:
> Hello,
>
> Any idea why ktimetracker and the Google contacts/calendar akonadi resources
> are missing from MacPorts? The latter are part of kdepim-runtime, the former
> of kdepim, both of which I have installed. Judging from
On Apr 04, 2014, at 17:26, Eric A. Borisch wrote:
I must confirm Ryan's observation:
1.784_portia_936# time bzip2 -dc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
> /dev/null
39.516 user_cpu 0.198 kernel_cpu 0:39.75 total_time 99.8%CPU {0W
I have a whole bunch of p5.12* ports installed, most all dependencies of things
that ought to depend on a more recent version of perl by now. Is there a way to
clean this up, without having to figure out the depending ports and reinstall
those?
BTW, the build failure is because
/opt/local/va
Hello,
Any idea why ktimetracker and the Google contacts/calendar akonadi resources
are missing from MacPorts? The latter are part of kdepim-runtime, the former of
kdepim, both of which I have installed. Judging from the Portfile no
parts/modules of said packages are deactivated, so why am I mi
Upgrading kdeartwork I got the following error for the kscreensaver target:
/opt/local/include/QtGui/qlabel.h:45:10: fatal error: 'QtGui/qframe.h' file not
found
/opt/local/include/QtGui is a symlink to the header folder in the QtGui
framework, and qframe.h is there. The problem is that /opt/lo
On Apr 04, 2014, at 10:19, Ryan Schmidt wrote:
> While waiting minutes for clang-3.5 to install (compress) and then activate
> (decompress) a 600MB archive, I wondered why I was sitting here waiting for a
> single-threaded process to complete when I have a multi-core Mac.
Is that 600MB raw, or
https://bugs.freedesktop.org/show_bug.cgi?id=77032
I checked the source for the version currently in Debian/Testing: O_CLOEXEC is
not passed to open() there.
> Nope, as you can see:
>
> ...
> +startupitem used to be the default, but no longer is.
What I meant and thought to understand is that
1 - 100 of 163 matches
Mail list logo
