from:"MK\-MacPorts"

On 02 May 2014, at 21:12 , Clemens Lang  wrote:
> Maybe it depends on the comment content? 

I couldn’t figure it out where it was, but it must have been some invisible 
character which wasn’t really deleted.

The only idea how it might have happened is that I had tried to input a “TM" 
symbol at some stage and then deleted it again, but obviously left some traces 
of it in there…

I had to rewrite what I wanted to post initially and then the comment could be 
posted eventually.

Thanks Shree and Clemens.

Greets,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: trac is currently having a problem: adding comments isn't possible

On 02 May 2014, at 21:12 , Clemens Lang  wrote:
> Maybe it depends on the comment content? Did you try adding a comment with
> a different text?
Ha, thanks, why didn’t I think of that now…
It worked.
So, I have to rewrite my message and see.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

trac is currently having a problem: adding comments isn't possible

Hmmm, you could add a comment? I see you could...

Well, yes, I was logged on with my handle. Used Safari and Firefox and both 
gave and still give me this error!

Greets,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

trac is currently having a problem: adding comments isn't possible

Hi Shree,

when I tried to add a comment to a ticket [1] I just got the response “Trac 
Error” from MacPorts trac.

Since this happened a couple of times within the last 2 hrs or so I guess 
something is wrong on the server side, because switching to another web client 
didn’t help either.

Greets,
Marko


[1] https://trac.macports.org/ticket/43539#trac-add-comment


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [119589] trunk/dports/graphics

Hi Frank,

thanks for pointing that out. I wasn’t aware of the stub! 

I’ve reopened the ticket and am awaiting input from the portfile author.

Thanks again,
Marko


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

2014-04-30 Thread MK-MacPorts

I am not sure whether it had been already said, but I think it would be nice to 
let query list also generate links to the port’s home URL, which holds just as 
well for the MacPorts port list!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [119488] trunk/dports/kde

2014-04-28 Thread MK-MacPorts

Dear Ryan,

thanks for your attentive eye, as always!

I am sorry I committed such messy ports with rkward(-devel), but I just 
committed what I got from the original authors. I see now that the discussion 
you had back then in [1] didn’t produce a fully MacPorts-satisfying portfile.

Well, I’ll try to work it out with them bit by bit. Unfortunately my provider 
bounces all messages to the MacPorts mailing lists at the moment, which is why 
I am not sure whether I can post to the list at all, so I send this also CC to 
you directly.

Greets,
Marko



[1] https://lists.macosforge.org/pipermail/macports-dev/2014-April/date.html
[2] https://trac.macports.org/ticket/32837
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

2014-04-14 Thread MK-MacPorts

Hi Joshua,

On 14 Apr 2014, at 10:56 , Joshua Root  wrote:
> Dependents are precisely those ports that are needed at runtime. We
OK, it’s not inconsistent, I see that now.
Good, have to check on this again, once kdelibs4’s dependency on nepomuk and 
thus openssl is gone.

> You maybe want something like 'port echo installed and depends:someport'
> except recursive? That's probably going to be slow as things stand.
Oh, that’s a nice command: I haven’t much used such logic yet.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Questions re CI on Macports and KDE

On 14 Apr 2014, at 02:09 , Ryan Schmidt  wrote:
> These answers are in the OS X Mavericks software license agreement:
Thanks so much for your citation. I have stolen them right away and replanted 
them on [1] 

>>   - How can he get in contact with the MacPorts CI guys?
> admin at macosforge dot org
I guess that will be the next step once we’ve figured out which requirements 
are there.

Greets,
Marko

[1] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI#OSXvirtualisation
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: tiff revbump?

On 14 Apr 2014, at 02:07 , Brandon Allbery  wrote:
> rev-upgrade catches these silent errors and corrects them.

I know that it does that. I’ve often run into traps like that in the past and 
it’s so much better now with rev-upgrade in place taken care of all of that. :-)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

On 14 Apr 2014, at 01:52 , Ryan Schmidt  wrote:
> By definition, a build dependency isn’t needed at runtime, so you wouldn’t 
> distribute it, so you wouldn’t care about build dependencies’ 
> distributability, would you?

Hmmm, you’ve got your point.
When I was writing those lines I awaited this kind of a response… I am paddling 
back. :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: tiff revbump?

Hi Ryan,

On 14 Apr 2014, at 01:51 , Ryan Schmidt  wrote:
> If a binary on our packages server is mislinked (i.e. linked with a previous 
> version of a dependency’s library) such that rev-upgrade decides to rebuild 
> it, we should revbump to fix the binary package.
OK.

> However, I looked at one of the binary packages 
> (tiff-4.0.3_2.darwin_10.x86_64.tbz2) and did not see any obvious mislinking. 
> Do you know why rev-upgrade decided to rebuild tiff on your system?
I have no clue.
The only idea I had was that I started the whole MacPorts installation from 
scratch and it ran perhaps for 4 hrs (with a 1h of short interruptions) and 
somewhere in between I saw rev-upgrade rebuilding tiff… So, I thought that some 
other dependency of tiff must have changed in the meantime.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Questions re CI on Macports and KDE

Hi Ian,

I just want to add something as well as answer some of your questions (with 
what I found via Google).

On 13 Apr 2014, at 23:06 , Ian Wadham  wrote:
> Ben is not sure what would be required to set up CI of KDE in an Apple
> OS X envirionment.  His immediate questions are to do with Apple OS X
> installation, but I am sure he has many more.
In [1] he specified more of the requirements for a CI on OSX in more detail...

... however the infrastructure we have for our Linux builds
should be nearly completely portable to OSX without too much trouble
(in theory at least - i've never done any compilation on OSX).

and in my first reply [2] to his post I went through his list of tools and I 
think MacPorts has everything in stock for the KDE CI system.

>- Can he virtualise Mac OS X legally on a Linux machine?
No. [3]

>- Must he invest in Apple hardware?
Yes, or he can ask e.g. Brad whether he could support him with some virtual 
servers, because on Apple hardware you can legally run up to two OSX guest 
virtual machines since OSX Lion (10.7) [4].

>- Does OS X licensing forbid installation on non-Apple hardware?
Yes.

Please, let me know if the information I gave to Ben [2] or what I’ve found 
about OSX virtualization via Google [3,4] isn’t correct.

Greets,
Marko

[1] http://lists.kde.org/?l=kde-devel&m=139738494320784&w=2
[2] http://lists.kde.org/?l=kde-devel&m=139738958421627&w=2
[3] 
http://bmspeak.businessmann.dk/2014/03/10/virtualize-os-x-using-vsphere-on-mac-hardware/
[4] http://wp.libpf.com/?p=744
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

On 13 Apr 2014, at 21:12 , Joshua Root  wrote:
> What would this warning say, and where would it go? And have you read
> the help for port rdeps?

Ah, sorry, now I see that there is indeed an option "--no-build" there.

But still, one could make use of an option like “--with-build” for the 
rdependents command! :-)

A use case:

If one tries to figure out whether a certain port tree is fully 
distributable
one doesn’t want to be surprised by a suddenly non-distributable 
build-dependency somewhere in there.

That is why I am so pernickety. :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

License handling

Hi devs,

I have found [1-6] discussing how licenses are being handled on MacPorts.
Browsing our Guide I couldn’t find any section containing license rules.
According to [7] we’ve got only port_binary_distributable.tcl [8] as some sort 
of license documentation.

Shouldn’t we have more that our Guide’s "license keyword syntax section" [9] in 
Guide, Wiki or manpages?

Greets,
Marko

[1] https://lists.macosforge.org/pipermail/macports-dev/2011-July/015228.html
[2] 
https://lists.macosforge.org/pipermail/macports-dev/2012-December/021267.html
[3] 
https://lists.macosforge.org/pipermail/macports-dev/2012-December/021263.html
[4] https://lists.macosforge.org/pipermail/macports-dev/2013-April/022698.html
[5] https://lists.macosforge.org/pipermail/macports-dev/2013-May/022802.html
[6] https://lists.macosforge.org/pipermail/macports-dev/2013-October/024710.html
[7] 
https://lists.macosforge.org/pipermail/macports-dev/2013-November/025091.html
[8] 
http://svn.macports.org/repository/macports/trunk/base/portmgr/jobs/port_binary_distributable.tcl
[9] http://guide.macports.org/#reference.keywords

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

On 13 Apr 2014, at 19:08 , Jeremy Lavergne  wrote:
> Using verbose (port -v) might list out the types of dependencies.

The only difference I can see here is that the -v version puts “port:” in front 
of the port names…
What am I missing?
—
$ port deps gtk2
Full Name: gtk2 @2.24.23_0+x11
Extract Dependencies: xz
Build Dependencies:   gtk-doc, pkgconfig, perl5, autoconf, automake, libtool
Library Dependencies: atk, pango, gdk-pixbuf2, gobject-introspection, 
xorg-libXi, xorg-libXrandr,
  xorg-libXcursor, xorg-libXinerama, xorg-libXdamage, 
xorg-libXcomposite,
  xorg-libXfixes
Runtime Dependencies: shared-mime-info, hicolor-icon-theme
$ port -v deps gtk2
Full Name: gtk2 @2.24.23_0+x11
Extract Dependencies: bin:xz:xz
Build Dependencies:   port:gtk-doc, port:pkgconfig, port:perl5, port:autoconf, 
port:automake,
  port:libtool
Library Dependencies: port:atk, path:lib/pkgconfig/pango.pc:pango, 
port:gdk-pixbuf2,
  port:gobject-introspection, port:xorg-libXi, 
port:xorg-libXrandr,
  port:xorg-libXcursor, port:xorg-libXinerama, 
port:xorg-libXdamage,
  port:xorg-libXcomposite, port:xorg-libXfixes
Runtime Dependencies: port:shared-mime-info, port:hicolor-icon-theme
—
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

On 13 Apr 2014, at 18:01 , Brandon Allbery  wrote:
> Well, this is still highlighting an inconsistency.
Yes, right you are, otherwise I wouldn’t have stumbled over it.

> In this case, I think it's between the actual record of dependencies in the 
> package registry (produced by actually installing something) and the 
> pre-recorded list of dependencies in the package index (usually downloaded 
> along with the port tree)? That, or rdeps just ignores anything that isn't a 
> runtime dependency.
Well, that should be clarified, I think, otherwise it might lead over and over 
again to posts like mine. :-)
Perhaps a warning message would be nice and perhaps an option to enable/disable 
searching for only-runtime deps.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

tiff revbump?

Yesterday I noticed - while installing a MacPorts from scratch - that after all 
the port tiff got rebuild by rev-upgrade.

Looks like tiff would need a revbump right?


How is the policy regarding such cases??

Shall one simply commit a revbump whenever one spots a port like that
or
do we rely fully on rev-upgrade doing its job?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Puzzling inconsistency regarding dep

On 13 Apr 2014, at 17:46 , Brandon Allbery  wrote:
> Looks like it's because it's a build dependency --- so, while the gtk2 port 
> is what pulled it in, it is not needed at runtime. 
Ahhh, I see.
Thanks for solving this mystery! :-)
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Puzzling inconsistency regarding dep

Hi,

port gtk-doc puzzled me just now, since it doesn’t seem to have dependent ports.
—
$ port rdependents gtk-doc
gtk-doc has no dependents.
—

But if I let port show me all kmymoney4-devel deps it gets listed:
—
$ port rdeps kmymoney4-devel
...
  kde4-runtime
kdelibs4
  soprano
libiodbc
  gtk2
gtk-doc
…
—

So, the question is, why the rdependants command didn’t spot this in the first 
place?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Is there a way to figure out which deps would have to be build from sources

2014-04-12 Thread MK-MacPorts

Hi Eric,

> #!/bin/sh
> for depport in `port -q rdeps $1`; do
>   sh /path/to/mp-distributable.sh ${depport}
> done

that worked like a breeze. I should have been able to create in on my own. :-)

Thanks!

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Is there a way to figure out which deps would have to be build from sources

2014-04-12 Thread MK-MacPorts

Hi devs,

I just wonder whether someone out there
has already written some script
which can determine for any given port A
whether non-binary ports B1-Bn are to be build during 
port A's installation.

Greets,
Marko

P.S.: I do know that there is mp-distributable.sh in order to determine whether 
a port is binary-distributable.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Where do I find a good example of a "tests" variant (which is really installing the tests on the system)?

2014-04-11 Thread MK-MacPorts

Hi Eric,

thanks for letting me know about those two tickets, to which I CC’ed myself 
just now. :-)

I am not so sure that you can actually INSTALL all tests with any software… 
independent on whether you actually might now want to do that. The 
two-step-install I use with "kmymoney4-devel +tests" is perhaps not so nice 
during install, but at least it does what I intended to do.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Where do I find a good example of a "tests" variant (which is really installing the tests on the system)?

2014-04-11 Thread MK-MacPorts

On 21 Mar 2014, at 00:14 , Ryan Schmidt  wrote:
> I’m not aware of any ports that do that, or any tests that are designed to 
> work that way.

Only recently I came across the "test phase” which can be defined in a portfile.

I’ve introduced properly running tests for kmymoney4-devel with r118839.
The user can build and run the tests by using this sequence:
—
$ sudo port test kmymoney4-devel +tests
—

Afterwards the user could proceed with
—
$ sudo port install kmymoney4-devel +tests
—
without the tests actually being installed in the system, which the “tests” 
variant might imply.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to preserve patches to MacPorts base during "sudo port selfupdate"?

2014-04-10 Thread MK-MacPorts

On 10 Apr 2014, at 22:09 , Jeremy Lavergne  wrote:
> You probably need add a local repo with higher priority, such as:
Looks like it. :)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

How to preserve patches to MacPorts base during "sudo port selfupdate"?

2014-04-10 Thread MK-MacPorts

Hi MP devs,

currently I have to have patch [1] in place to be able to successfully install 
qmake-based ports.

The problem is now that during "sudo port selfupdate” all these changes get 
reverted.

How can I keep my needed patches for MacPorts base without the need to re-patch 
base after the selfupdate call?
 
Greets,
Marko



[1] https://trac.macports.org/ticket/41321
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: New MacPorts web site

2014-04-07 Thread MK-MacPorts

Hi Ryan,

I do like your work very much! This looks really cool!!!

A few remarks:

1) Perhaps the icons at least could be blue to match the mandatory 
good-old MacPorts icon, which definitely needs to appear here instead of the 
new “macports”. :)

2) I think that the headline is pretty large. I wouldn’t mind it to be 
30-50% smaller.

3) Apart from that I have to say that the site even looks great on a 
smartphone, which was my first way to check it out. :-)


Great job. Thanks for giving the MacPorts site a fresh look. At the beginning 
of the discussion I was sceptical, but now I see that it indeed can be made 
much nicer than it currently is.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Problem updating git-core

2014-03-31 Thread MK-MacPorts

I also had problems with the git upgrades every now and then. Just a give it 
some time and then all will run smoothly.
(Have no idea why it happens, though. Perhaps an issue with some mirrors… )
I usually tried some hours later once again. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDE community seeks cooperation with MacPorts enthusiasts by inviting them to come to Randa (Switzerland) in August 2014

Hi Brad,

On 27 Mar 2014, at 00:14 , Bradley Giesbrecht  wrote:
> Marko, do you have a link to the KDE-MAC mailing list subscription page?
> I was unaware that KDE had a Mac specific list.

Unfortunately it’s a VERY LOW VOLUME mailing list:

https://mail.kde.org/mailman/listinfo/kde-mac

:-/

KDE-DEVEL makes more sense:

https://mail.kde.org/mailman/listinfo/kde-devel

Greets,
Marko

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: month-old CMake update to 2.8.12.2 with side-effects for Qt?

On 27 Mar 2014, at 00:26 , Ryan Schmidt  wrote:
> https://trac.macports.org/ticket/41321

Thanks, Ryan, for pointing this out.

I see the post is already 4 months old… So, I was obviously just lucky that I 
hadn’t run into this earlier already.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: month-old CMake update to 2.8.12.2 with side-effects for Qt?

I have built kmymoney4-devel’s sources without using ports, but simply did a
“cd kmymoney; mkdir build; cd build; cmake ..; make” and it turned out that
cmake ran through with a few warnings and the build finished successfully after
all.

So, that the build without “sudo port build” does not work can only mean that
my port file is not properly configuring something, right?

—
$ cmake ..
.
.
.
Good - your configure finished.
Now type 'make' to build KMyMoney. For more help, consult README.cmake

-- Configuring done
CMake Warning (dev) in kmymoney/widgets/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

Target "kmm_widgets" has an INTERFACE_LINK_LIBRARIES property which differs
from its LINK_INTERFACE_LIBRARIES properties.

INTERFACE_LINK_LIBRARIES:

KDE4__kdeui;Qt4::QtGui;Qt4::QtCore;KDE4__kdecore

LINK_INTERFACE_LIBRARIES:

This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) in kmymoney/mymoney/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

Target "kmm_mymoney" has an INTERFACE_LINK_LIBRARIES property which differs
from its LINK_INTERFACE_LIBRARIES properties.

INTERFACE_LINK_LIBRARIES:

KDE4__kdeui;Qt4::QtGui;Qt4::QtXml;Qt4::QtCore;KDE4__kdecore;KDE4__kio;/opt/local/lib/libgmp.dylib;/opt/local/lib/libalkimia.dylib;kmm_storage

LINK_INTERFACE_LIBRARIES:

This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) in kmymoney/plugins/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

Target "kmm_plugin" has an INTERFACE_LINK_LIBRARIES property which differs
from its LINK_INTERFACE_LIBRARIES properties.

INTERFACE_LINK_LIBRARIES:

KDE4__kdeui;KDE4__kio;KDE4__kutils;/opt/local/lib/libgmp.dylib;/opt/local/lib/libalkimia.dylib

LINK_INTERFACE_LIBRARIES:

This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) in libkdchart/src/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

Target "kmm_kdchart" has an INTERFACE_LINK_LIBRARIES property which differs
from its LINK_INTERFACE_LIBRARIES properties.

INTERFACE_LINK_LIBRARIES:

Qt4::QtSvg;Qt4::QtXml;Qt4::QtGui;Qt4::QtCore

LINK_INTERFACE_LIBRARIES:

This warning is for project developers. Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to:
/Users/okram/WC/GIT/kmymoney.online-balance_highlighting_extended/build

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

KDE community seeks cooperation with MacPorts enthusiasts by inviting them to come to Randa (Switzerland) in August 2014

Dear devs, maintainers, users,

I want to cite an invitation from Mario Fux from the KDE community posted on 
the KDE-MAC mailing list:




Mario Fux wrote:

... I'm currently organizing the next edition of the Randa Meetings. The dates 
are set: Saturday, 9th to Friday, 15th of August. But we're still setting 
together the groups that come to Randa.

The main focus this year shall be KF5, more platforms and a KDE SDK. So we 
definitely need some KDE/Mac people. Anybody here interested? Do you have 
questions? Ideas?

Best regards,
Mario


http://www.randa-meetings.ch/
http://randa-meetings.ch/2014/02/19/randa-meetings-2014-the-date-is-set-please-register/




---


In various discussion threads during the last weeks the KDE community expressed 
that they would welcome anyone willing to do some bridge-building between KDE 
on Linux and OSX/MacPorts! KDE is considering to also get a CI system based on 
OSX up and running which shall improve code quality notably.

In the past years there has been a lot of trouble porting KDE to MacPorts 
(which has luckily become much smoother lately) and it would be worthwhile to 
have more people active in this field.

This is especially true for the upcoming KF5 which needs a MacPorts-Qt5 - for 
which an experienced maintainer is necessary.

Anyone out there interested to improve the MacPorts’ contact to KDE on Linux?

Anyone willing to contribute and support the Randa meeting in summer?

I could imagine that the KDE guys would be interested in how MacPorts’ core 
team has set up MacPorts' buildbot infrastructure with respect to hard/software 
and its maintenance requirements.



Get in touch! :-)


Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

month-old CMake update to 2.8.12.2 with side-effects for Qt?

I hadn’t built kmymoney4-devel for a while since there had been little progress 
in development.

But now that I tried it again I had to realise that it suddenly doesn’t build 
anymore.
Obviously it doesn’t even configure properly...
Here is what I saw:

—
.
.
.
:info:configure -- Results of Search for Phonon
:info:configure --  -> PHONON_VERSION is 4.7.1
:info:configure --  -> PHONON_INCLUDE_DIR is /opt/local/include
:info:configure --  -> PHONON_LIBRARY is /opt/local/lib/libphonon.dylib
:info:configure Change Dir: 
/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4-devel/kmymoney4-devel/work/build/CMakeFiles/CMakeTmp
:info:configure
:info:configure Run Build Command:/opt/local/bin/gmake 
"cmTryCompileExec446391939/fast"
:info:configure /opt/local/bin/gmake -f 
CMakeFiles/cmTryCompileExec446391939.dir/build.make 
CMakeFiles/cmTryCompileExec446391939.dir/build
:info:configure gmake[1]: Entering directory 
'/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4-devel/kmymoney4-devel/work/build/CMakeFiles/CMakeTmp'
:info:configure /opt/local/bin/cmake -E cmake_progress_report 
/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4-devel/kmymoney4-devel/work/build/CMakeFiles/CMakeTmp/CMakeFiles
 1
:info:configure Building CXX object 
CMakeFiles/cmTryCompileExec446391939.dir/check_qt_visibility.cpp.o
:info:configure /usr/bin/clang++-pipe -Os -arch x86_64 -stdlib=libc++  
-fno-common -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align 
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security 
-Woverloaded-virtual -fno-common -fvisibility=hidden -Werror=return-type 
-fvisibility-inlines-hidden -Wno-return-type-c-linkage  -arch x86_64 
-I/opt/local/include/QtXmlPatterns -I/opt/local/include/QtXml 
-I/opt/local/include/QtWebKit -I/opt/local/include/QtUiTools 
-I/opt/local/include/QtTest -I/opt/local/include/QtSvg 
-I/opt/local/include/QtSql -I/opt/local/include/QtScriptTools 
-I/opt/local/include/QtScript -I/opt/local/include/QtOpenGL 
-I/opt/local/include/QtNetwork -I/opt/local/include/QtMultimedia 
-I/opt/local/include/QtHelp -I/opt/local/include/QtDesigner 
-I/opt/local/include/QtDeclarative -I/opt/local/include/QtDBus 
-I/opt/local/include/Qt3Support -I/opt/local/include/QtGui 
-I/opt/local/include/QtCore -I/opt/local/include 
-I/opt/local/share/qt4/mkspecs/default-o 
CMakeFiles/cmTryCompileExec446391939.dir/check_qt_visibility.cpp.o -c 
/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4-devel/kmymoney4-devel/work/build/CMakeTmp/check_qt_visibility.cpp
:info:configure clang: error: invalid deployment target for -stdlib=libc++ 
(requires OS X 10.7 or later)
:info:configure CMakeFiles/cmTryCompileExec446391939.dir/build.make:60: recipe 
for target 'CMakeFiles/cmTryCompileExec446391939.dir/check_qt_visibility.cpp.o' 
failed
:info:configure gmake[1]: *** 
[CMakeFiles/cmTryCompileExec446391939.dir/check_qt_visibility.cpp.o] Error 1
:info:configure gmake[1]: Leaving directory 
'/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4-devel/kmymoney4-devel/work/build/CMakeFiles/CMakeTmp'
:info:configure Makefile:117: recipe for target 
'cmTryCompileExec446391939/fast' failed
:info:configure gmake: *** [cmTryCompileExec446391939/fast] Error 2
:info:configure
:info:configure CMake Error at 
/opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:1377 (message):
:info:configure   Qt compiled without support for -fvisibility=hidden.  This 
will break
:info:configure   plugins and linking of some applications.  Please fix your Qt 
installation
:info:configure   (try passing --reduce-exports to configure).
:info:configure Call Stack (most recent call first):
:info:configure   /opt/local/share/cmake-2.8/Modules/FindKDE4.cmake:95 
(find_package)
:info:configure   CMakeLists.txt:56 (FIND_PACKAGE)
:info:configure
:info:configure
:info:configure -- Configuring incomplete, errors occurred!
:info:configure See also 
"/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4
-devel/kmymoney4-devel/work/build/CMakeFiles/CMakeOutput.log".
:info:configure See also 
"/opt/local/var/macports/build/_Users_okram_WC_MacPorts_ports_kde_kmymoney4
-devel/kmymoney4-devel/work/build/CMakeFiles/CMakeError.log".
—

Any idea what’s going there about "invalid deployment target for -stdlib=libc++ 
(requires OS X 10.7 or later)” ?

I am puzzled…

Could this be related to the cmake upgrade a month ago?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: debug variants built by buildbots as well?

2014-03-22 Thread MK-MacPorts

On 22 Mar 2014, at 18:01 , Ryan Schmidt  wrote:
> On Mar 22, 2014, at 11:51, mk-macpo...@techno.ms wrote:
>> do MacPorts’ buildbots also build all debug variants of the various ports, 
>> or only the default variant of every port?
> Only default variants.
I was afraid to hear that. :-)
Had some hope that things had changed since I was last busy on that front.

This means, I’d have to go back to build from scratch most of the stuff if I 
want debug variants of certain ports…
Sniff.

Would be cool if there was a buildbot which would build all the debug variants… 
:-D
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

debug variants built by buildbots as well?

2014-03-22 Thread MK-MacPorts

HI devs,

do MacPorts’ buildbots also build all debug variants of the various ports, or 
only the default variant of every port?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Where do I find a good example of a "tests" variant (which is really installing the tests on the system)?

2014-03-20 Thread MK-MacPorts

On 21 Mar 2014, at 00:14 , Ryan Schmidt  wrote:
> I’m not aware of any ports that do that, or any tests that are designed to 
> work that way.

OK, in just now I have made it work by simply chown'ing the port’s work 
directory and executing ctest by the logged in user.
That finally did the job.

(And yes, you are right, the tests wouldn’t work if one would install the tests 
someplace.
The test apps need to sit in the build directory in order to access additional 
files outside it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Where do I find a good example of a "tests" variant (which is really installing the tests on the system)?

2014-03-20 Thread MK-MacPorts

I would like to introduce a tests variant for a port.

Can someone point me to a port which successfully installs a test variant?

I know that I can build and run tests when building ports (i.e. when I only run 
“sudo port build; cd build; ctest …”).

But I want that all needed test files get actually installed in the system and 
not only built and removed again.
So, I’d like to know where to place which files below ${destroot}.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Arrival of new MacPorts version including mpstats

2014-03-20 Thread MK-MacPorts

Hi MacPorts devs,

how is the schedule for release of the next MP release which will - I gather - 
include the opt-in-able mpstats?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

On 16 Mar 2014, at 21:07 , Rainer Müller  wrote:
> I am afraid of the increased complexity of git and the changing workflow for 
> other
> developers.
> 
> We cannot simply swap out Subversion and bless a git mirror as the new
> main ports tree, a new way of working with git has to be worked out first.
Yes, absolutely!

> Coming from the Linux kernel, pure git expects a pull-based workflow.
> One central instance pulls up changes from many other repositories into
> the main repository. I would rule out such a person-based pull model for
> MacPorts, as who would take the responsibility for all the merges?
Well, that would also be my reservation against git...

> At the moment, the MacPorts project gives out commit access to a central
> repository. Transferring that to git, that would mean giving everyone
> push access.
I’d prefer Mercurial, but I am afraid it could be just as dangerous.

But it’s not so much whether one uses git or mercurial, it’s rather the
infrastructure around it which defines how the port tree is maintained.
Your refs [1-4] are good ways to find new workflows!!!
I do like the review-based workflow.
That’s actually what Ryan does for probably half of all port commits already 
now! ;-)

> With this point you make the assumption we would use GitHub. How do you
That was also my thought. Why to get dependent on GitHub?
There are Open Source alternatives, but they need hosting, maintenance,
development, administration, etc…

> And for some others it will be more work to learn git only to get an
> update to MacPorts…
Yep, even Mercurial would be equally complicated for a newbee.

> Just in case you did not know that, you can already add any git ports
> tree to your sources.conf and start using it. The official tree is the
> only way to use ports and if someone wants to experiment with it you can
> already create overlays that only contain new or updates to existing ports.
I do this - using Mercurial - since years.

So, I would really like a DVCS for MacPorts, and I am hoping for what
Sean will come up with soon using Mercurial+evolve+hgsubversion.
I think that could offer the chance of a smoother transition, because one
could work in parallel with SVN and Mercurial for quite a while. Devs and
port maintainers could slowly migrate while learning how to work Mercurial
bit by bit without being forced to toss SVN from a certain date on.

Would be cool to get news from your very ambitious project, Sean!!!

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Move part of macports infrastructure to GitHub

On 16 Mar 2014, at 19:42 , Sean Farley  wrote:
> I would suggest Mercurial.

+1

But, in order to avoid any flamewars: I’d be going for git as well, if it would 
win in an election. :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

Hi Clemens,

thanks for the quick response.

I have done as requested, but that seems to lead to another problem:
—
$ ./testgraphical
file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
 File not found 
Killed: 9
—

But I guess that could be due to the application itself?!

I am new to this, so I don’t understand for a start why a URL is being 
displayed with this app.
I figure I need to consult KDE’s developer mailing list regarding this one, 
right?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

Hi Clemens,

thanks for the quick response.

I have done as requested, but that seems to lead to another problem:
—
$ ./testgraphical
file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
 File not found 
Killed: 9
—

But I guess that could be due to the application itself?!

I am new to this, so I don’t understand for a start why a URL is being 
displayed with this app.
I figure I need to consult KDE’s developer mailing list regarding this one, 
right?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

Hi,

I am testing KDevelop a little.

After a short hiccup I was able to get a scaffold for a “graphical app” 
automagically built fine! :)

But the real problem starts when trying to run the app:
—
$ ./testgraphical.shell
dyld: Symbol not found: __cg_jpeg_resync_to_restart
  Referenced from: 
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /opt/local/lib/libJPEG.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
./testgraphical.shell: line 4: 59742 Trace/BPT trap: 5   
DYLD_LIBRARY_PATH=/Users/marko/projects/TestGraphical/build/lib/./:/opt/local/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
 
"/Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/testgraphical"
 "$@"
—

So, does this mean, that a system framework tries to use a library supplied by 
MacPorts?

This is what otool tells me:
—
$ otool -L testgraphical
testgraphical:
/opt/local/lib/libkdeui.5.dylib (compatibility version 5.0.0, current 
version 5.12.2)

/opt/local/Library/Frameworks/QtDeclarative.framework/Versions/4/QtDeclarative 
(compatibility version 4.8.0, current version 4.8.5)
/opt/local/lib/libkdecore.5.dylib (compatibility version 5.0.0, current 
version 5.12.2)
/opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus 
(compatibility version 4.8.0, current version 4.8.5)
/opt/local/Library/Frameworks/QtCore.framework/Versions/4/QtCore 
(compatibility version 4.8.0, current version 4.8.5)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 157.0.0)
/opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui 
(compatibility version 4.8.0, current version 4.8.5)
/opt/local/Library/Frameworks/QtSvg.framework/Versions/4/QtSvg 
(compatibility version 4.8.0, current version 4.8.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1197.1.1)
—

Any hint on how to locate the culprit for the crash?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: Running KDE apps on Apple OS X

2014-03-11 Thread MK-MacPorts

From: mk-li...@email.de
Subject: Re: Running KDE apps on Apple OS X
Date: 11 Mar 2014 23:05:09 GMT+1
To: KDE-devel Mailing-List 
Cc: KMyMoney KDE Development List , Developer-MacPorts 
Mailing-List 

Hi Ian,

thanks for your initiative!!!

I am not a software engineer - but just a Linux/MacOSX hobby-coder - and since 
4 years I am trying to keep KMyMoney (KMM) alive on MacOSX via MacPorts during 
my spare time [0]. That’s how the two of us initially got to know each other! 
:-)

— INSET — 
Well, here I simple MUST mention that I always had A LOT OF GREAT SUPPORT from 
the KMM developers whenever I ran into trouble getting KMM to build on 
MacPorts. For the last four years I was running MacOSX 10.6.x and since a 
quarter of a year I am using MacOSX 10.9.x - successfully building KMM 4.6.x 
and almost always at master’s HEAD! :-)

When I started using MacOSX four years ago there was KMM 1.0.3 available (still 
using KDE3) since someone else had created a functional port for it on 
MacPorts. :)
That and the KMM devs helped me a lot setting up a new port for KMM 4.5 in Nov 
2010! :-D
After a while I switched over to keep my finances under control only by KMM 4.x!
— INSET — 

Well, but just you, mention there are again and again little problems with the 
underlying KDE framework.
Luckily there were and up to now are very active MacPorts maintainers who 
tried/try to keep kdelibs3 and kdelibs4 afloat on MacOSX via the MacPorts port 
system. Thank god!!!
To my horror I’ve seen already two maintainers give up on kdelibs4 in the past 
four years, which is a shame and very sad.
I - personally - would find it very sad if KMM would disappear because of KDE 
dropping support for MacOSX!!!

So, I hope that this initiative might be a spark which motivates more people to 
get involved here.

I have - just like you, Ian - tried TO FIND help here on KDE-DEVEL (as well as 
on KDE-MAC) all these years and I was grateful for every hint I got - given the 
low number of MacOSX users to be found in there.

Whenever I find a bug in KMM or KDE I DO TRY TO PIN IT DOWN as much as possible 
and address it to the relevant bug reporters on https://bugs.kde.org (e.g. open 
[2,3]) or https://bugreports.qt-project.org (e.g. open [4,5]).

A most annoying bug is related to meinproc4 [6] (as you, Ian, already 
mentioned) which is bugging me on MacPorts with KMM and other KDE-apps since 
years. But unfortunately it shows a very indeterministic behaviour and I 
couldn’t come forward there. Only in Dec 2013 / Jan 2014 there was finally 
movement, but I haven’t yet followed that up…
I could grab my own nose and try to investigate what had been changed there to 
find out whether other apps would build without this annoyance from now on, 
like e.g. KMM! :-/  ——>>> Would be a good thing to start with, I guess. 8-)

— NOTE — 
I am deliberately listing all those references to show that there are people 
trying their best, and I am not the only one on MacPorts, Homebrew, Fink, etc. 
That shall be enough in response to what has been uttered in this list’s thread 
“What to test for 4.13" and I don’t want to put more oil into the fire but 
rather like to calm the waves and come to a constructive level. I - for my part 
- will always try to contribute as best as I can and as I have done in the past 
to KDE, KMM and also wxWidgets as another example [7].
— NOTE — 

On 11 Mar 2014, at 04:15 , Ian Wadham  wrote:
> I need some ongoing help, advice and mentoring from time to
> time as I investigate why some KDE apps run OK on Apple
> OS X and others do not.  The problem is simply stated.
So would I.

> Most KDE apps build and run well in Apple OS X.  The difficult
> ones are the more complex ones --- and the ones that are in
> demand from Apple users --- such as Digikam, Kdenlive,
> KDevelop and Amarok.
I have recently only tested kdenlive myself - and it works!!! :-) 

> The case of kbuildsysoca4 is a good example.
Yes, indeed, luckily the kdelibs4 port since then installs a user launch agent 
which takes care of running kbuildsyscoca4 periodically to avoid most of the 
trouble.

> But I need help, guidance and mentoring as I dive into
> KDE internals.  Any offers will be gratefully accepted.
Dito.

For completeness I want to add, that I try with scrooge to maintain also 
another alternative financial KDE-application on MacPorts [8].

Best regards to all devs on this list,
Marko

———

 References

 [0] http://www.macports.org/ports.php?by=name&substr=kmymoney
 [1] Thread "[Kmymoney2-developer] SUCCESS: v4.5 runs on Mac OS X” @ 2 Nov 2010
 [2] https://bugs.kde.org/show_bug.cgi?id=279194
 [3] https://bugs.kde.org/show_bug.cgi?id=316404
 [4] https://bugreports.qt-project.org/browse/QTBUG-19873
 [5] https://bugreports.qt-project.org/browse/QTBUG-32943
 [6] https://bugs.kde.org/show_bug.cgi?id=261509
 [7] http://trac.wxwidgets.org/ticket/15345
 [8] http://www.macports.org/ports.php?by=name&substr=skrooge

___

Re: Atlas update

2014-02-22 Thread MK-MacPorts

Hi Vincent,

I am myself waiting for a fix for this since a while.

Can you perhaps make your updated Portfile public, e.g. below [1] or [2].
I am willing to test (by building the port for a few hours) whether the upgrade 
works seamlessly on my end before rolling it out to everyone.

Greets,
Marko


[1] https://trac.macports.org/ticket/42160
[2] https://trac.macports.org/ticket/42404
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to seamlessly switch from a standard MacPorts install to trunk?

Hi Josh,

On 17 Feb 2014, at 07:35 , Joshua Root  wrote:
> You don't have to sync your ports tree with svn just because you're
> using the trunk version of base.
Oh, I see!
:)

That means I misunderstood Clemens’ statement:

On 10 Feb 2014, at 12:01 , Clemens Lang  wrote:
> … Note that selfupdate will no longer do anything once you installed trunk. 
> If you want to update your MacPorts installation you need to svn up your 
> working copy of trunk and run the install process again.

So, he was only referring to macports base and NOT the whole MacPorts 
installation then.

Thanks for clarifying this.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to seamlessly switch from a standard MacPorts install to trunk?

Hi Ryan,

On 17 Feb 2014, at 05:10 , Ryan Schmidt  wrote:
> What risk are you envisioning?
I fear the risk of switching to an SVN port tree and having to go back to an 
rsync’ed one in case I need to...
Or would that be piece of cake?
Well, I can imagine that it could be troublesome to perform this stunt! No?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

> At that point, it might take as long as a reboot depending on your build: but 
> you should achieve the same outcome.

I guess you’re right. :)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

On 16 Feb 2014, at 22:25 , Jeremy Lavergne  wrote:

> You could reboot after each switch: anything that’s no longer linked into 
> /opt/local won’t load, and everything else will launch the appropriate 
> version.

Yes, that’s possible, but to "M$ Windows"-like! ;-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

There is still one big problem with all of this, which is that a ton of daemons 
and agents might be running as root or as another user for a given MacPorts 
installation.

In case I want to swap in another installation, say a debug installation, I 
would have to make sure that all these services would be restarted gracefully! 
That means I would have to search using launchctl for all those services, 
cancel them with the correct credentials and then restart all of them 
accordingly.

What a project. :-/

Wondering whether this is actually doable just using launchctl as root…

(In the past I hadn’t been careful enough regarding all this, which lead to 
quite a bit of trouble with dbus mostly!)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

On 16 Feb 2014, at 21:46 , Jeremy Lavergne  wrote:
> But I am assuming macports can handle being inside a symlink since I recall 
> it can operate across drives.

Thanks, Jeremy.

That seems to be a good approach.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

Thanks, Sean!

On 16 Feb 2014, at 21:29 , Sean Mehta  wrote:
>   $ ./configure --prefix=$MP_PREFIX
>   --with-applications-dir=$MP_PREFIX/Applications \
>   --with-tclpackage=$MP_PREFIX/Library/Tcl
I knew that this trick would work, because I used that in the past with my 
parallel installs… The thing is now that I don’t want to use anything else than 
/opt/local for all my parallel installs, in order to be able to use binary 
installs!

BUT now I see that it should also work in this situation, you are right!

By using explicitly the above for every installation I should be able to make 
sure that no file lands outside /opt/local !

Of course I have to assume that there are no rogue ports.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Wouldn't it be better to make sure a MacPorts installation always stays within /opt/local?

I just wanted to set up a 2nd parallel MacPorts install - as I used to have it 
before moving to Mavericks…

Now I realise that it is probably not a good idea to have a setup like that 
after all.

Some applications install themselves into /Applications and have settings in 
/Library…

Assuming I have two MP installs setup as

/opt/local
and
/opt/local.trunk

I would have to be very careful when renaming those in such a way that I could 
use the installation in /opt/local.trunk!!!

I thought about simply renaming /opt/local to /opt/local.default and then have 
/opt/local.trunk renamed as /opt/local, but this is highly dangerous given the 
high likelihood which which installed files might reside outside /opt/local...

So, I guess, such a setup is rather to be avoided?!

I could redefine applications_dir as
---
 applications_dir/opt/local/Applications/MacPorts
---
but the question is how can I trust every port that nothing else would be 
installed outside /opt/local?

I looks like though that it should be enough to have startupitem_install set to 
“no” in order to avoid messing with /Library/Launch(Daemons|Agents).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to seamlessly switch from a standard MacPorts install to trunk?

Hi Clemens,

On 10 Feb 2014, at 12:01 , Clemens Lang  wrote:
> You can just install trunk right over your old installation… Note that 
> selfupdate will no longer do anything once you installed trunk. If you want 
> to update your MacPorts installation you need to svn up your working copy of 
> trunk and run the install process again.
The latter is something I don’t really want to risk...
So, I guess I simply wait for the release of the new MP version and try mpstats 
out then. :)
Thanks for response!
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

How to seamlessly switch from a standard MacPorts install to trunk?

Hi,

I would like to try MacPorts’ current trunk version.

How do I do this seamlessly, i.e. is it necessary to reinstall MacPorts from 
scratch, or can I somehow manage to keep all installed ports in place while 
just switching from my existing installation to trunk??

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

On 09 Feb 2014, at 22:12 , Clemens Lang  wrote:
> but it's really the port that's to blame here.

I see your point, but that’s probably something which might occur more often 
than we think now, effectively making it impossible to find actually existing 
ports. Probably it would make sense to handle cases like that differently?!

And, do I need trunk to be able to run mpstats?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

> The problem here is that the aqbanking Portfile violates lint:
Oh, good to know.
Can be fixed. :)
Will do so right away.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

Hi Clemens,

I am seeing a page stating this:

—
The page you were looking for doesn't exist.
You may have mistyped the address or the page may have moved.
—

in case I try to search for a non-existing or replaced_by port, e.g. [1].

I guess one could rather state on this page that the port is replaced_by or 
simply non-existing?!

Greets,
Marko



[1] http://stats.macports.neverpanic.de/ports/search/name/aqbanking
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

On 09 Feb 2014, at 20:42 , Jeremy Lavergne  wrote:
> You probably need to run trunk for access to POST, which isn’t available in a 
> release yet.
Ooops, I see. I wasn’t aware of that trunk is a must for this feature.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Call for Testers: MacPorts Statistics

Hi Clemens,

I installed mpstats but when trying to submit my installation details I got 
this error thrown:
—
$ /opt/local/libexec/mpstats submit
Submitting to http://stats.macports.neverpanic.de/submissions
Error: bad option "post": must be fetch, isnewer, or getsize
while executing
"curl post "submission\[data\]=$json" $stats_url"
—

What can be done about this?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qemu on Mavericks?

2014-01-13 Thread MK-MacPorts

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 around since 2 months already…
I guess I should retry it. :)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qemu on Mavericks?

2014-01-13 Thread MK-MacPorts

On 13 Jan 2014, at 09:54 , Rainer Müller  wrote:
> You need -usb to activated USB support as it is not a default option. I
Oh, I wasn’t aware of that!
But well, this didn’t change anything with OpenSUSE 13.1…

> Yes, QEMU on Mac OS X is quite slow as it does not get any
> virtualization 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 my system once I upgrade or remove the 
software. That’s why I like MacPorts. :-)
BUT, I guess, this is my only option left now. :-/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: permission denied errors during building with clang on Mavericks

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.
> 
> I recommend you delete the cache directory entirely
> 

Thanks, Clemens, for the hint.
I did so and it has solved the issue:
markos-imac:5396pzbj3gq7s1hwf2shczvmgq marko$ l
total 0
drwxr-xr-x  4 macports  macports  136 Jan 13 00:04 ./
drwxr-xr-x  3 root  wheel 102 Jan 13 00:04 ../
drwx--  6 macports  macports  204 Jan 13 00:05 C/
drwx--  5 macports  macports  170 Jan 13 00:04 T/

Before I had the user root set for the subfolder T, which obviously caused the 
issue.

Greets,
Marko___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qemu on Mavericks?

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 list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qemu on Mavericks?

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

Re: qemu on Mavericks?

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 std -boot 
order=dcn os13.1-basis.img
—
and there are two USB devices present after booting up.
Both devices I CAN NOT remove using “usb_del” !!
( Interesting also that qemu actually hands over the machine's eyetv stick to 
the VM!!! ) 
Back to square one.
:-(

>> Well, and the installation procedure is searching for USB devices FOREVER, 
>> unfortunately.
> I'd expect this. Delete the USB interface for the virtual machine you've 
> created with qemu.
It’s to be expected?
Oh…

>> So, I guess qemu isn’t a true alternative to virtualbox on MacOSX, due to 
>> the missing kvm implementation.
> I see it uses Xen or KVM, but the fact you're getting this far, well past the 
> kernel and initramfs being loaded, seems like it is working.
Well, a lot seems to work, indeed. But unfortunately I can’t get beyond the USB 
device recognition step.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

permission denied errors during building with clang on Mavericks

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=\"/opt/local/lib/aqdatabase/plugins/0\" 
-DAQDATABASE_DATA_DIR=\"/opt/local/share/aqdatabase\" 
-DCOMPILE_DATETIME=\"20140112203526\" -I. -I../.. -I../.. 
-I/opt/local/include/gwenhywfar4 -I/opt/local/include -L/opt/local/lib -pipe 
-Os -L/opt/local/lib -arch x86_64 -g -Wall -c aqdb_db.c
:info:build clang: error: couldn't create cache file 
'/var/folders/wy/5396pzbj3gq7s1hwf2shczvmgq/T/xcrun_db-CfooCvW7' 
(errno=Permission denied)
:info:build clang: warning: argument unused during compilation: 
'-L/opt/local/lib'
:info:build clang: warning: argument unused during compilation: 
'-L/opt/local/lib’
:info:build In file included from aqdb_db.c:14:
:info:build In file included from ./aqdb_db_p.h:14:
:info:build ./aqdb_db_be.h:14:10: fatal error: 'aqdatabase/aqdb_db.h' file not 
found
:info:build #include 
:info:build  ^
:info:build 1 error generated.
:info:build make[3]: *** [aqdb_db.lo] Error 1
—

I figure that these missing cache files don’t stop clang from working 
correctly, but I wonder why this permission error occurs. Is my portfile 
wrongly set up for clang for some reason?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qemu on Mavericks?

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 searching for USB devices FOREVER, 
unfortunately.

So, I guess qemu isn’t a true alternative to virtualbox on MacOSX, due to the 
missing kvm implementation.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qemu on Mavericks?

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 to use kvm under Linux... Is this not supplied on MacOSX?
> Nope, that's a Linux kernel thing.
;-/

Well, I waited for ages, but OpenSUSE’s USB probing never came back. :(

When I booted using its rescue system and carried out lsusb I got this message:
—
$ lsusb
unable to initialize libusb: -99
—
Don’t know though whether this was due to the rescue system itself or due to a 
the qemu emulation.

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

qemu on Mavericks?