Re: Test to @lists.macosforge.org

[Craig Treleaven]

Notice the bounce message—my first attempt was sent to the new address.

Craig

> On Apr 19, 2017, at 5:19 PM, Peter Danecek <peter.dane...@ingv.it> wrote:
> 
> Dear Craig,
> 
> I also had some problems, maybe our problem is similar. Try to use the new 
> `lists.macports.org` domain instead of the old `lists.macosforge.org`. 
> 
> So use this email: MacPorts Development <macports-...@lists.macports.org>
> 
> Cheers,
> ~petr
> 
> 
>> On 19 Apr 2017, at 21:45, Craig Treleaven <ctrelea...@macports.org> wrote:
>> 
>> Still having trouble getting messages to the list:
>> 
>> ==
>> 
>> The following message to <macports-...@lists.macports.org> was undeliverable.
>> The reason for the problem:
>> 5.4.7 - Delivery expired (message too old) [Default] 450-'4.7.1 
>> : Helo command rejected: Host not found'
>> Reporting-MTA: dns; fvipsab03.cogeco.net
>> 
>> Final-Recipient: rfc822;macports-...@lists.macports.org
>> Action: failed
>> Status: 5.0.0 (permanent failure)
>> Remote-MTA: dns; [136.243.18.213]
>> Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old) [Default] 
>> 450-'4.7.1 : Helo command rejected: Host not found' 
>> (delivery attempts: 10)
>> ==
>> 
>> 
>> Craig
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 

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

Test to @lists.macosforge.org

[Craig Treleaven]

Still having trouble getting messages to the list:

==

The following message to  was undeliverable.
The reason for the problem:
5.4.7 - Delivery expired (message too old) [Default] 450-'4.7.1 
: Helo command rejected: Host not found'
Reporting-MTA: dns; fvipsab03.cogeco.net

Final-Recipient: rfc822;macports-...@lists.macports.org
Action: failed
Status: 5.0.0 (permanent failure)
Remote-MTA: dns; [136.243.18.213]
Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old) [Default] 
450-'4.7.1 : Helo command rejected: Host not found' 
(delivery attempts: 10)
==


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

Re: Moving to GitHub: Status Update, Action Required

[Craig Treleaven]

> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
> ...
> Migration Timeline
> ==
> The switch to Git will happen on the weekend of October 29th/30th. ...

Is this still on track?

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

For pixilla

[Craig Treleaven]

HI

Sorry to clutter the list but emails have bounced three times now (Host not 
found) trying to reply to pixilla:

Bradley:

Ticket is:

https://trac.macports.org/ticket/52144

I don’t have a current diff either. 

Craig

(Do you have another email address that I can try?)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Autotools help

[Craig Treleaven]

> On Oct 22, 2016, at 11:35 AM, Craig Treleaven <ctrelea...@macports.org> wrote:
> 
> Hi:
> 
> I’m working on an update to Lirc and the build system has changed to 
> Autotools--which I know very little about.
> 
> It seems that Lirc will now opportunistically link with Alsa

Argh, nevermind.  I was thinking of pulseaudio but that is different from alsa.

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

Autotools help

[Craig Treleaven]

Hi:

I’m working on an update to Lirc and the build system has changed to 
Autotools--which I know very little about.

It seems that Lirc will now opportunistically link with Alsa and there is no 
configure flag to disable such behaviour.  I want to make Alsa support a 
non-default variant.  Is my best option to patch the configure.ac file?

I believe the relevant portion of configure.ac is:

dnl audio_alsa driver requires ALSA library installed and some linker flags
have_alsa=no
AC_CHECK_HEADERS(alsa/asoundlib.h,[
  AC_CHECK_LIB(asound, snd_pcm_open,[
AM_CONDITIONAL([BUILD_LIBALSA],[true])
AC_DEFINE(HAVE_LIBALSA)
have_alsa=yes
],[
AM_CONDITIONAL([BUILD_LIBALSA],[false])],
)
],[
AM_CONDITIONAL([BUILD_LIBALSA],[false])]
)

From:
https://sourceforge.net/p/lirc/git/ci/lirc-0_9_4c/tree/configure.ac

What exactly would I patch in to ignore Alsa?

Many thanks,

Craig

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

Re: Moving to GitHub: Status Update, Action Required

[Craig Treleaven]

> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
> 
> Hello MacPorts users and developers,
> 
> ... Please read through
> https://trac.macports.org/wiki/WorkingWithGit
> which contains a number of guidelines for working with the MacPorts Git
> repositories.
> 
The Working with Git page is pretty good.  There is a lot of good background 
and explanation of why and how Git is different from svn.

However, would it be possible to add a tangible example of updating a port to 
that page?  

I know a little bit about Subversion and less about Git.  I would like to see a 
soup-to-nuts example of cloning the ports tree, updating a Portfile, maybe 
deleting an old patch and adding a new one, and getting the updated port into 
MacPorts (direct commit v. pull request).  It would be helpful if one-time 
requirements (setting name and email address) were clearly separated from 
repetitive steps (pulling changes from master?).  Otherwise, it is going to be 
a wee bit nerve-wracking the first few times...

Also, is the consensus that a graphical user interface over git more likely to 
be harmful than helpful?  The Tools section at the bottom of the page doesn’t 
give any kind of recommendation.

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

Re: advanced bash-ing for long compiles

[Craig Treleaven]

> On Oct 14, 2016, at 7:37 PM, Clemens Lang  wrote:
> - On 15 Oct, 2016, at 01:05, Fred Wright f...@fwright.net wrote:
> ...
>> One can also accomplish this via:
>> 
>>  sudo touch /opt/local/var/macports/build/.metadata_never_index
>> 
>> Though I don't know if this works across all OS versions.
> 
> Do you have documentation on this? The only documentation I could find
> back then suggested that Spotlight will ignore hidden directories, so
> that's why we made it hidden.
> 
Yes, this came up more than 2 years ago.  I couldn’t find official docs at that 
point.  

http://www.mail-archive.com/macports-dev@lists.macosforge.org/msg26538.html

Only a discussion on apple-stackexchange:

http://apple.stackexchange.com/questions/92784/preventing-spotlight-from-indexing-files-folders

Right now, searches on Apple’s Developer site are just endlessly spinning.

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

Re: Working with Git

[Craig Treleaven]

> On Oct 7, 2016, at 12:16 PM, Sterling Smith  wrote:
> 
> 
> On Oct 7, 2016, at 7:20AM, Chris Jones  wrote:
>> 
>> My point still stands though, you have to actively try the things you need 
>> to do, to get used to them.
> +1

Yabut, then you hear things like “use —force when you need”, except then you 
hear “—force can really screw things up”.  I’m a little gunshy of that 
screw-things-up part!

Craig


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

Re: Could not open Portfile

[Craig Treleaven]

> On Sep 16, 2016, at 10:04 AM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-09-16 14:20, Craig Treleaven wrote:
>> I’ve hit this scenario a couple of times.  Am I doing something wrong with 
>> svn patch?
> 
> What is your umask set to? From the permissions it looks like this is
> with umask 0077.
> 
> I encountered the same problem before. svn patch does not preserve the
> permissions of the existing files. Actually this behavior is not even
> specific to svn patch, other commands such as svn revert behave the same
> way. svn creates a new temporary file with umask applied, deletes the
> existing file and moves the new file in place.
> 
> Personally, I use ACLs on my ports directory to automatically grant read
> permissions to everyone on new files. This also resolves this problem
> with svn patch for me.
> 
> chmod -R +a "group:everyone allow
> read,execute,list,search,file_inherit,directory_inherit" ~/ports
> 
> It would be nice to have a better solution for this problem, but the
> actual bug is in Subversion.
> 
Thanks Rainer!  I thought maybe I was just missing a step, somewhere.  I found 
a ‘sudo chmod 0666’ on the affected Portfiles allowed me to go ahead.  

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

Re: Goodbye Mac OS Forge, hello GitHub

[Craig Treleaven]

> On Aug 20, 2016, at 2:07 AM, Lawrence Velázquez  wrote:
> 
>> On Aug 19, 2016, at 8:18 PM, Ryan Schmidt  wrote:
>> 
>> And our new buildbot automated build system announced earlier this month is
>> being hosted by me on my hardware, outside of Apple, and will just need
>> minor changes to monitor GitHub instead of Subversion.
> 
> FYI I've made some progress on this tonight and hope to make initial commits 
> tomorrow or Sunday.

Where does the migration stand now?

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

Could not open Portfile

[Craig Treleaven]

Hi:

Fresh install of MacPorts on a new VM with an svn checkout of trunk, I get this 
error:

$ sudo port install mariadb-server
Password:
Error: Unable to execute port: Could not open file: 
/Users/macmyth/mp/trunk/dports/databases/mariadb/Portfile

I had applied a patch to mariadb, ala:

$ svn patch 
/Volumes/Clooney/Test_installers/patch_port_mariadb-server_startupitem_and_pkg_2016Sep14.diff
 
U Portfile
A files/org.macports.mariadb-server.plist
A files/postinstall
A files/preinstall

The permissions before running the patch were:

$ pwd
/Users/macmyth/mp/trunk/dports/databases/mariadb
$ ls -l
total 24
-rw-r--r--  1 macmyth  staff  10021 16 Sep 07:32 Portfile
drwxr-xr-x  7 macmyth  staff238 16 Sep 07:32 files

After the patch:

$ ls -l
total 24
-rw---   1 macmyth  staff  11885 16 Sep 08:02 Portfile
drwxr-xr-x  10 macmyth  staff340 16 Sep 08:02 files

I did update sources.conf to include:

file:///Users/macmyth/mp/trunk/dports [default]
rsync://rsync.macports.org/release/tarballs/ports.tar

I’ve hit this scenario a couple of times.  Am I doing something wrong with svn 
patch?

Craig

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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Craig Treleaven]

> On Sep 5, 2016, at 4:09 PM, Bradley Giesbrecht <pixi...@macports.org> wrote:
> 
>> On Sep 5, 2016, at 8:03 AM, Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>>> On Sep 5, 2016, at 8:42 AM, Craig Treleaven <ctrelea...@macports.org> wrote:
>>> 
>>> Not to belabour the issue, but should it not be the impact to port users 
>>> that determines whether a change is “minor” or not?
>> 
>> I believe the "minorness" of the change is wholly up to the maintainer.
>> 
>>> The number of lines, by itself, doesn’t necessarily determine that impact. 
>>> For example, a 1 or 2 line change in one of the database ports might make a 
>>> new database engine the default.
>> 
>> It is certainly true that a small change with great impact is not minor, but 
>> a large change with little impact is also not minor. As an extreme example, 
>> I would not appreciate a commit to one of my ports that had no impact on the 
>> installation yet completely rearranged the portfile. I'd have to waste time 
>> reading and understanding the committer's code, looking for edge cases and 
>> failure modes, reworking local commits that no longer apply, etc.
>> 
>> (This situation can already happen via timeout, but in that case there is a 
>> clear, objective policy that maintainers implicitly agree to when they take 
>> up maintainership.)
>> 
>> My rule of thumb is that fixing typos and broken builds is almost always 
>> okay under openmaintainer. Many maintainers also permit minor version bumps 
>> and bug fixes, but some don't. In all cases, it's safest to wait out the 72 
>> hours.
> 
> I was going to add to the ticket but maybe this is a better place to discuss 
> for now.
> 
> I have attempted to keep the mysql ports similar to make maintaining them 
> easier.
> 
> I have a few questions regarding these changes.
> 
> 1. Will "port load mariadb-server" work?

Good point, I don’t know.  I’ll try it.

BTW, this afternoon I noticed that I’m not respecting the “startupitem.install” 
setting.  I’ll change the patch so if the user has modified macports.conf with 
‘startupitem.install no’, we don’t put anything in /Library/LaunchDaemons.

> 2. Has this been tested on older systems?

Not yet.  It has been a lot of time and work to get this far.  What is the 
earliest OS that you test with the server ports?  The new version of my MythTV 
ports are not going to support anything before 10.9!  The best I can do is 10.6 
on X86_64.

> 3. Can the pkg run concurrently with the port? I assume pkg installs into 
> $prefix, am I right?

Correct, the pkg installs in the same prefix it was built in.  For development, 
I build mpkgs on my main system (10.10) and test installation on a VM (10.11).  
(Later, I’ll build the mpkg for distribution on a VM with a non-default 
prefix.)  

> 4. Is there any reason the same changes would not work for the mysql*-server, 
> mariadb*-server and persona-server ports?

I know almost nothing about percona but I think it ought to work with the 
different versions of mysql and mariadb.  The launchd plist was introduced in 
MySQL 5.7.8.

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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Craig Treleaven]

> On Sep 4, 2016, at 8:54 PM, Lawrence Velázquez  wrote:
> 
>> On Sep 4, 2016, at 8:32 PM, MacPorts  wrote:
>> 
>> #52144: mariadb: support for mpkg / mdmg
>> -+---
>> Reporter:  ctreleaven@…|  Owner:  pixilla@…
>> Type:  enhancement | Status:  new
>> Priority:  Normal  |  Milestone:
>> Component:  ports   |Version:
>> Resolution:  |   Keywords:
>> Port:  mariadb-server  |
>> -+---
>> 
>> Comment (by ctreleaven@…):
>> 
>> [snip]
>> 
>> Barring objections, I plan commit these changes under openmaintainer in
>> the next few days.  I feel the startupitem to launchd plist changes are
>> relatively low risk.  I'll try to handle anything that might crop up.
> 
> This is the MacPorts Guide’s description[*] of the openmaintainer policy:
> 
>   If a port's maintainer contains the address
>   , this means that the author
>   allows minor updates to the port without contacting him first.
>   But permission should still be sought for major changes.
> 
> While limited in scope, your changes are anything but minor (the patch
> is 181 lines!), and committing them would clearly violate the spirit of
> the openmaintainer guideline.
> 
> You’d be better off invoking the 72-hour maintainer timeout policy.
> 
> [*] 
> https://guide.macports.org/chunked/project.update-policies.html#project.update-policies.nonmaintainer
> 
You’re right, I should have referenced maintainer timeout.  I tried to contact 
Bradley a week ago today with no response.

Not to belabour the issue, but should it not be the impact to port users that 
determines whether a change is “minor” or not?  The number of lines, by itself, 
doesn’t necessarily determine that impact.   For example, a 1 or 2 line change 
in one of the database ports might make a new database engine the default.  
That would be much more signficant that what I’ve proposed.  At the heart of 
it, the proposed changes are:

1) Use an upstream launchd plist.

2) Enable packaging where it has never worked before.

Nonetheless, whether this is “maintainer timeout” or “openmaintainer”, I don’t 
want to create problems with the port.  I welcome any and all feedback.

Craig

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

Re: Permission denied, "pkg" phase

[Craig Treleaven]

> On Aug 26, 2016, at 6:46 AM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-08-26 05:09, Craig Treleaven wrote:
>> I’ve tried adding:
>> 
>> pkg.asroot  yes
>> 
>> to my portfile but that seems to be unrecognized.
>> 
>> Is there a way around this?
> 
> Not without patching base. I have no experience with creating pkgs, so I
> don't know if it makes sense to allow running this as root at all.
> 
> Rainer
> 

Thank you, Rainer!

Your patch allowed the pkg/mpkg commands to work.  I do notice that the owner 
of certain files has changed from macports to root, however.  I’ll test 
deploying the installer and see if the result works OK.  I’ll try producing an 
mdmg, as well.

If those work out OK, is this something that would be an acceptable change to 
base for distribution?

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

Permission denied, "pkg" phase

[Craig Treleaven]

How do I get elevated privileges in a “pre-pkg” block?

In a thread a couple of days ago, it was pointed out that “pkg” and “mpkg” are 
phases and that one can have a pre-pkg or post-mpkg block.  I want to include a 
copy of daemondo in an mpkg and it looks like all I need to do is copy the 
executable into the destroot.  The pkg phase will then then create an installer 
component including it and mpkg will add that to the meta package.  I’ve been 
testing this with the gforth port just to work out the concept.

The offending block is:

pre-pkg {
  xinstall -m 644 ${prefix}/bin/daemondo ${destroot}${prefix}/bin/
}

resulting in:

Error: org.macports.pkg for port gforth returned: xinstall: Unable to create 
new file for: 
/opt/local/var/macports/build/_Users_craigtreleaven_mp_ports_lang_gforth/gforth/work/destroot/opt/local/bin//daemondo,
 Permission denied
DEBUG: Error code: NONE

I’ve tried adding:

pkg.asroot  yes

to my portfile but that seems to be unrecognized.

Is there a way around this?

Craig


Please excuse typos--sent from my iPhone.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

port install v port mpkg | mdmg

[Craig Treleaven]

Hi:

Is it possible for a port to take different actions depending on whether the 
user has initiated ‘port install’ v. 'port mpkg’ (or ‘port mdmg’)?

My mythtv-pkg.27 is intended to be used to create an all-in-one installer 
package for MythTV.  I have a VM with a custom prefix for this.  The resulting 
mpkg needs daemondo, so I created the nasty hack in MacPorts_daemondo.  
However, mythtv-pkg.27 could be a nice shortcut for a MacPorts user that wants 
to install a complete MythTV system in one go.  In such case, they don’t need 
MacPorts_daemondo.

So, can the port detect ‘port mpkg’ or ‘port mdmg’ and only add the dependency 
on MacPorts_daemondo in such cases?

Thanks,

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

Re: Determine before installation whether a port can be installed

[Craig Treleaven]

> On Jul 27, 2016, at 12:09 AM, Ryan Schmidt  wrote:
> 
> I would like MacPorts to be extended so that it can be determined in advance, 
> from the command line, before running "port install", whether a port can be 
> installed (barring unexpected build failures and bugs). Currently, MacPorts 
> assumes any port can be installed on any system, which is not the case. Many 
> ports cannot be built on certain versions of macOS. Some require libc++. Some 
> require dependencies to be installed with a nondefault variant. Some have 
> other requirements. Some ports, like p5-graveyard or other ports that serve 
> as placeholders designed to inform the user of the discontinuation of a port, 
> are designed to fail. Being able to determine in advance whether a port is 
> supposed to be installable will let us skip those ports when triggering 
> builds on the buildbot. This will cut down on unnecessary work performed by 
> the buildbot, and will avoid unnecessary emails sent to maintainers who 
> already know the port will fail in those circumstances.
> 
> How can we accomplish this? We currently use "return -code error" to trigger 
> these kinds of error messages from ports, but we do so within a phase, such 
> as pre-configure or pre-fetch, but that means that code doesn't run until 
> those phases are running, and I want to know before those phases run, indeed 
> even before dependencies are calculated and installed.
> 
> One solution that occurs to me is to define a new "preflight" phase, to be 
> run before dependencies are computed. Ports can override that phase and do 
> whatever checks they need and exit with "return -code error" if needed. This 
> seems like the most straightforward and flexible solution.
> 
> Another possible solution could be to define a new Boolean variable 
> "installable" to indicate if the port is installable, which would default to 
> "yes". If a port sets this to "no", MacPorts could print a generic failure 
> message. There could be a second variable which the port developer could set 
> to a custom failure message.
> 
> A third possibility could be to codify each of the reasons why a build might 
> fail, and introduce new variables for each reason. For example, a variable to 
> indicate the supported C++ libraries, or a variable to indicate the supported 
> macOS versions. There might be some advantage to this, in that it could be 
> used to programmatically answer questions like what C++ libraries or macOS 
> versions a port supports, but it is the least flexible and most complicated 
> solution.

Could I submit that there may be two issues being conflated?

1) Some ports are known to crap out on our buildbots.

2) It is known that some ports cannot be installed on particular system 
configurations.

For 1), I think we should simply add a keyword to the portfile that tells the 
buildbot not to attempt to build this port.  “mp_buildbot_skip” or some such.  
Add this to the p5-graveyard and all other ports that we know the buildbot 
cannot or should not attempt to build.

For 2), we already have a series of tools that provide information about the 
environment and let the port do the right thing.  I like the idea of a 
preflight phase—a number of ports ‘abuse’ the pre-fetch phase to essentially do 
this.  However I’m not sure how prevalent or serious the problem is in 2) that 
we’re trying to solve.

Craig
(And there is the -y flag to ‘dry-run’ the installation.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Universal install script

[Craig Treleaven]

But we didn’t make the list.  ;

http://xkcd.com/1654/

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

Trac down?

[Craig Treleaven]

It seems that  https://trac.macports.org  is unreachable.

Craig

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

launchd plist -- userid, home directory

[Craig Treleaven]

Hi:

I was looking at modifying the buildbot / buildbot-slave ports to include a 
sample launchd plist.  I would like to be able to default the UserName and 
WorkingDirectory keys for the userid that is installing the port.

UserName
@someusername@
WorkingDirectory
/Users/@someusername@/buildarea

For example, if I’m installing the port and my userid is ‘wct’, I’d like to 
s/@someusername@/wct’/g .  

Within the portfile, how can I determine the userid that invoked ‘port install 
…'?

Craig

(I realize that some folks may want a different userid to run this system.  
This is going to be a _sample_ plist; the user will always have to fill in the 
directory name for the master or slave.)

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

Re: launchd plist -- userid, home directory

[Craig Treleaven]

> On Feb 4, 2016, at 9:41 AM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-02-04 15:15, Craig Treleaven wrote:
>> I was looking at modifying the buildbot / buildbot-slave ports to include a 
>> sample launchd plist.  I would like to be able to default the UserName and 
>> WorkingDirectory keys for the userid that is installing the port.
>> 
>> UserName
>> @someusername@
>> WorkingDirectory
>> /Users/@someusername@/buildarea
>> 
>> For example, if I’m installing the port and my userid is ‘wct’, I’d like to 
>> s/@someusername@/wct’/g .  
>> 
>> Within the portfile, how can I determine the userid that invoked ‘port 
>> install …'?
> 
> I would advise against doing this. The installed sample files would
> change depending on the user that ran the port command. The contents of
> all files installed by a port should be reflected by the canonical
> identifier of name/version/revision/epoch/variants.
> 
> Also this would not help if the user installs the port with a binary
> archive from one of our buildbots, they would always get a pre-defined
> username.
> 
> Wouldn't it make more sense to create a dedicated user to run the
> buildbot daemon? See add_users in portfile(7) and grep for examples in
> the ports tree. If you use some working directory in ${prefix}/var/ it
> could even be used out of the box without further configuration.
> 
> Rainer
> 
> [1] https://trac.macports.org/wiki/ReproducibleBuilds

Ah, yes, good points.  I wasn’t thinking of reproducible buids or the binary 
packages.  I was hoping to make it a little easier for a user to install a 
basic working buildslave*.   After the install, our user must run the 
‘buildslave create …’ command (with parameters we can’t determine ahead of 
time) to initialize the the files that the plist will be pointed to.  All that 
is beyond the scope of the portfile so I guess just providing a template of the 
plist is a reasonable approach.

Craig

*Our buildbot port is currently non-functional as we have a newer version of 
sqlalchemy-migrate than it can use.  Being looked at upstream:

http://trac.buildbot.net/ticket/3425#ticket

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

Re: VLC cannot play MKV files?

[Craig Treleaven]

> On Jan 23, 2016, at 8:48 AM, Vincent Habchi  wrote:
>> Might I suggest that you download the latest VLC player from videolan.org 
>> directly, and see if that one gives the same error? If it doesn't, you can 
>> then probably simply uninstall the one from MacPorts.
> 
> Yep, I could do that, but I would have to uninstall all the libraries I’ve 
> installed to save space, and that wouldn’t be fun.
> 

You might want to look at the following to clean up those libraries:

$ port info port_cutleaves
port_cutleaves @0.1.4 (sysutils, macports)

Description:  Inspired by FreeBSD's pkg_cutleaves, port_cutleaves is an 
interactive script that eases the uninstallation of leaves - installed ports 
that are unrequested and have no dependents.
Homepage: 
http://svn.macports.org/repository/macports/contrib/port_cutleaves/

Platforms:darwin
License:  unknown
Maintainers:  pe...@macports.org, openmaintai...@macports.org


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

Re: VLC cannot play MKV files?

[Craig Treleaven]

> On Jan 23, 2016, at 9:36 AM, Vincent Habchi  wrote:
> I compiled VLC 2.2.1 using Macports and still have the same error :(
> Seems something is wrong in the MacPorts librairies, but where? ...
> 
> VLC media player 2.2.2 Weatherwax (revision 2.2.1-21-g2502874)
> …

> [7f9f92e60978] avformat demux debug: detected format: matroska,webm
> …

> [7f9f92e60978] ps demux warning: found sync code
> [7f9f92e60978] ps demux warning: garbage at input, trying to resync…

Do other mkv files play OK?

You may also want to install mediainfo and check the contents of the problem 
file:

$ port info mediainfo
mediainfo @0.7.72 (multimedia)
Variants: universal

Description:  MediaInfo supplies technical and tag information about a 
video or audio file
Homepage: http://mediaarea.net

Library Dependencies: zlib, curl
Platforms:darwin
License:  LGPL-3+
Maintainers:  nomaintai...@macports.org

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

Re: VLC cannot play MKV files?

[Craig Treleaven]

> On Jan 23, 2016, at 12:33 PM, Vincent Habchi  wrote:
> 
>> … If you only installed those libraries for VLC then you shouldn't lose 
>> much. You would however have more definite proof whether your issue is due 
>> to something with the MacPorts build or in VLC itself. If the latter, you 
>> should take it up on the VLC bug tracker.
> 
> The pre-packaged VLC works fine. It’s definitely something wrong with 
> MacPorts somewhere.

Interesting…I downloaded a sample .mkv file [1].  I can’t get the 
MacPorts-built version to play it at all.  Tried Opening the file in VLC.app, 
etc.  No error message reported.  The Media Info window does identify that it 
has a bunch of streams.  Also tried playing it as rene suggest.  Results are 
below—no idea how to interpret them!!

Just a few days ago, I was using this version of VLC to play video streamed 
from my HDHomerun tuner box.  (North American broadcast OTA MPEG2 with AC-3 
sound.  Note that I have to build with +dvb to make this work.)  Worked fine.

If you get the same results, I think you should file a bug.

[1] https://mkvtoolnix.download/samples/

Craig

$ /Applications/MacPorts/VLC.app/Contents/MacOS/VLC 
/Users/craigtreleaven/Movies/mkv_tests/vsshort-aac.mkv 
VLC media player 2.1.5 Rincewind (revision 2.1.4-49-gdab6cb5)
[0x7f9bc0f744f0] main interface error: no suitable interface module
[0x7f9bc0f79fd0] main demux meta error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc0f03d00] main libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[matroska,webm @ 0x7f9bc1809400] EBML header parsing failed
[0x7f9bc0f8c590] main demux meta error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc0f8c590] main art finder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc351ed60] main probe error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc0c9eca0] main generic error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc0e0d890] macosx interface error: Unable to load extensions module
[0x7f9bc3501fb0] mkv demux error: cannot find KaxSegment or missing mandatory 
KaxInfo
[matroska,webm @ 0x7f9bc1830600] EBML header parsing failed
[0x7f9bc3501fb0] avcodec demux error: Could not open 
/Users/craigtreleaven/Movies/mkv_tests/vsshort-aac.mkv: Unknown error: 
1094995529
[0x7f9bc3501fb0] main demux error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc5b10630] main demux meta error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/lua/liblua_plugin.dylib
[0x7f9bc18306b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc10730b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc20fa2b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc18392b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc184b6b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc105fcb0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc18bc8b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc18e54b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc10736b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc20e22b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc10a58b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc18ea6b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc1086ab0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc211f6b0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc10a8cb0] main decoder error: corrupt module: 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/codec/liblibass_plugin.dylib
[0x7f9bc10ad6b0] main decoder error: corrupt module: 

Re: pkg-config v. -I/opt/local/include

[Craig Treleaven]

> On Jan 13, 2016, at 2:19 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote:
>> On Jan 12, 2016, at 4:09 AM, Ryan Schmidt wrote:
>>> On Jan 11, 2016, at 9:03 AM, Craig Treleaven wrote:
>>>> I’m having buiild failures due to includes pointing to old/other headers 
>>>> installed in /opt/local/include.
>>>> 
>>>> As I understand it, 'pig-config —cflags’ returns an empty string when a 
>>>> header is installed in /usr/include.  The port I’m working on, MythTV 
>>>> 0.28-pre, uses pkg-config to check for several dependencies.  Under 
>>>> MacPorts, I end up with '-I/opt/local/include’ early in the compiler 
>>>> arguments and thus picks up old or unintended versions of headers.  Under 
>>>> Linux, no problem.
>>>> 
>>>> Is there some way I can coerce pkg-config to treat /opt/local/include like 
>>>> it does /usr/include?  I’ve looked at the man page for pkg-config and 
>>>> tried using some of the environment variables but without success.
>>>> 
>>>> Eg, with MacPorts:
>>>> $ pkg-config --cflags x264
>>>> -I/opt/local/include ## want to make this disappear!
>>>> 
>>>> is there a magic recipe?
>>> 
>>> You should not want to make -I/opt/local/include disappear. It is where the 
>>> headers of dependencies are installed, so it is needed. If it is causing 
>>> problems, it is likely because your project's build system does not place 
>>> the include flags in the correct order. The correct order is (relative) 
>>> project include paths first, (absolute) dependency include paths second. If 
>>> you cannot fix the build system to do that, you can use your sed trick to 
>>> replace -I/opt/local/include with -isystem/opt/local/include which will 
>>> have the same effect.
>>> 
>> 
>> Hi Ryan:
>> 
>> I asked over on the pkg-config mailing list and got:
>> 
>>> This isn't documented (should be), but you can override pkg-config's notion 
>>> of the system include path with the environment variable 
>>> PKG_CONFIG_SYSTEM_INCLUDE_PATH. If that's not set, it uses the compiled in 
>>> defaults. That's been in pkg-config for a long time, so it should work with 
>>> the version you have. This should be in the form of a path style variable 
>>> with : separators.
> 
> I didn't know about that variable. Thanks for finding out about that.
> 
> 
>> This is exactly what I wanted:
>> 
>> $ pkg-config --cflags-only-I libass
>> -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include 
>> -I/opt/local/include/libpng16 -I/opt/local/include 
>> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
>> -I/opt/local/lib/glib-2.0/include -I/opt/local/include 
>> -I/opt/local/include/freetype2 
>> 
>> $ PKG_CONFIG_SYSTEM_INCLUDE_PATH=/opt/local/include pkg-config 
>> --cflags-only-I libass
>> -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
>> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
>> -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 
>> 
>> Adding 'configure.env-append
>> PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’  makes the MythTV build 
>> work the way it does on Linux (aka “successfully”).
> 
> But is that because -I/opt/local/include then gets inserted into the correct 
> place in the compile line, or because -I/opt/local/include is omitted from 
> the compile line and it only works because MacPorts also happens to set 
> CPATH=/opt/local/include and you're using a newer compiler that supports 
> that? (Granted, only very old versions of clang don't support CPATH.)

There is no '-I/opt/local/include' anywhere in my compiler args now so I assume 
CPATH is used.  

BTW, you made me curious.  A recent Fedora23 compile log from a Myth’s buildbot 
is at:

https://code.mythtv.org/buildbot/builders/master-f23-64bit/builds/104/steps/compile%20core/logs/stdio

If you search for “-I/usr/include “, the only hits are invocations of Qt’s mod! 
 Never appears in the compiler args.  So I’m now building the “Myth-blessed” 
way!  ;)

> 
>> As to whether this is the “right” thing to do, you have far more knowledge 
>> and experience than me.  I think Myth’s configure is relying on a quirk of 
>> pkg-config.  I would think that other folks that are cross-compiling--or 
>> even just using a different prefix—must be hitting this problem.  I get very 
>> little traction with the Myth devs.  They writeoff stuff like this as a 
>> “MacPorts problem”.
> 
> Yeah they would be incorrect to blame bugs in their build system on us just 
> because we use their build system in a slightly different way than they 
> apparently do.

Agreed.

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

Re: pkg-config v. -I/opt/local/include

[Craig Treleaven]

> On Jan 12, 2016, at 4:09 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Jan 11, 2016, at 9:03 AM, Craig Treleaven wrote:
>> I’m having buiild failures due to includes pointing to old/other headers 
>> installed in /opt/local/include.
>> 
>> As I understand it, 'pig-config —cflags’ returns an empty string when a 
>> header is installed in /usr/include.  The port I’m working on, MythTV 
>> 0.28-pre, uses pkg-config to check for several dependencies.  Under 
>> MacPorts, I end up with '-I/opt/local/include’ early in the compiler 
>> arguments and thus picks up old or unintended versions of headers.  Under 
>> Linux, no problem.
>> 
>> Is there some way I can coerce pkg-config to treat /opt/local/include like 
>> it does /usr/include?  I’ve looked at the man page for pkg-config and tried 
>> using some of the environment variables but without success.
>> 
>> Eg, with MacPorts:
>> $ pkg-config --cflags x264
>> -I/opt/local/include ## want to make this disappear!
>> 
>> is there a magic recipe?
> 
> You should not want to make -I/opt/local/include disappear. It is where the 
> headers of dependencies are installed, so it is needed. If it is causing 
> problems, it is likely because your project's build system does not place the 
> include flags in the correct order. The correct order is (relative) project 
> include paths first, (absolute) dependency include paths second. If you 
> cannot fix the build system to do that, you can use your sed trick to replace 
> -I/opt/local/include with -isystem/opt/local/include which will have the same 
> effect.
> 

Hi Ryan:

I asked over on the pkg-config mailing list and got:

> This isn't documented (should be), but you can override pkg-config's notion 
> of the system include path with the environment variable 
> PKG_CONFIG_SYSTEM_INCLUDE_PATH. If that's not set, it uses the compiled in 
> defaults. That's been in pkg-config for a long time, so it should work with 
> the version you have. This should be in the form of a path style variable 
> with : separators.

This is exactly what I wanted:

$ pkg-config --cflags-only-I libass
-I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include 
-I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/fribidi 
-I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include 
-I/opt/local/include -I/opt/local/include/freetype2 

$ PKG_CONFIG_SYSTEM_INCLUDE_PATH=/opt/local/include pkg-config --cflags-only-I 
libass
-I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
-I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
-I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 

Adding 'configure.env-append
PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’  makes the MythTV build work 
the way it does on Linux (aka “successfully”).

As to whether this is the “right” thing to do, you have far more knowledge and 
experience than me.  I think Myth’s configure is relying on a quirk of 
pkg-config.  I would think that other folks that are cross-compiling--or even 
just using a different prefix—must be hitting this problem.  I get very little 
traction with the Myth devs.  They writeoff stuff like this as a “MacPorts 
problem”.

Craig

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

pkg-config v. -I/opt/local/include

[Craig Treleaven]

Hi:

I’m having buiild failures due to includes pointing to old/other headers 
installed in /opt/local/include.

As I understand it, 'pig-config —cflags’ returns an empty string when a header 
is installed in /usr/include.  The port I’m working on, MythTV 0.28-pre, uses 
pkg-config to check for several dependencies.  Under MacPorts, I end up with 
'-I/opt/local/include’ early in the compiler arguments and thus picks up old or 
unintended versions of headers.  Under Linux, no problem.

Is there some way I can coerce pkg-config to treat /opt/local/include like it 
does /usr/include?  I’ve looked at the man page for pkg-config and tried using 
some of the environment variables but without success.

Eg, with MacPorts:
$ pkg-config --cflags x264
-I/opt/local/include ## want to make this disappear!

is there a magic recipe?

Thanks,

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

Re: pkg-config v. -I/opt/local/include

[Craig Treleaven]

> On Jan 11, 2016, at 10:03 AM, Craig Treleaven <ctrelea...@macports.org> wrote:
> I’m having buiild failures due to includes pointing to old/other headers 
> installed in /opt/local/include.
> 
> As I understand it, 'pig-config —cflags’ returns an empty string when a 
> header is installed in /usr/include.  The port I’m working on, MythTV 
> 0.28-pre, uses pkg-config to check for several dependencies.  Under MacPorts, 
> I end up with '-I/opt/local/include’ early in the compiler arguments and thus 
> picks up old or unintended versions of headers.  Under Linux, no problem.
> 
> Is there some way I can coerce pkg-config to treat /opt/local/include like it 
> does /usr/include?  I’ve looked at the man page for pkg-config and tried 
> using some of the environment variables but without success.
> 
> Eg, with MacPorts:
> $ pkg-config --cflags x264
> -I/opt/local/include ## want to make this disappear!
> 
> is there a magic recipe?

Didn’t find a magic recipe but I did come up with a workaround.  I overrode the 
pkg-config command used by configure ala:

set pkg_config_cmd  "${prefix}/bin/pkg-config $@ | sed 's|-I${prefix}/include 
||g’”

and added --pkg_config="${pkg_config_cmd}” to the configure arguments.  I get 
one no-harm warning but that is much better than random build failures!

I’m still open to better solutions.

Craig


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

Re: Broken links detected...to ApplicationServices ?

[Craig Treleaven]

> On Jan 10, 2016, at 12:18 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Jan 9, 2016, at 9:33 PM, Craig Treleaven wrote:
> 
>> I’m working on a new version of MythTV (0.28) and I’m stymied on the 
>> following.  Every program (23), and every library and filter (28) is 
>> reported by MacPorts to have a linking error similar to the following:
>> 
>> --->  Scanning binaries for linking errors
>> …
>> Incompatible library version: /opt/local/bin/mythavtest requires version 
>> 64.0.0 or later, but 
>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>  provides version 1.0.0
>> DEBUG: Marking /opt/local/bin/mythavtest as broken
>> 
>> Web searches and whatnot have not turned up any promising leads so I beg the 
>> indulgence of those more experienced than I.  
>> 
>> I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools.  
> 
> What do you get when you run:
> 
> otool -L 
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  
> 
> On my 10.10 and 10.11 systems, the first two lines are:
> 
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices:
>   
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  (compatibility version 1.0.0, current version 48.0.0)
> 
> So, the OS provides ApplicationServices version 48.0.0 which is 
> backward-compatible with 1.0.0. I'm not sure where you would have encountered 
> a version 64.0.0 of ApplicationServices; it doesn't appear Apple has released 
> any version that high yet.
> 

I get the same as you:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 (compatibility version 1.0.0, current version 48.0.0)

Perhaps it is just a coincidence, but I noticed the next line, CoreGraphics, 
references “version 64.0.0”:

/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 
(compatibility version 64.0.0, current version 600.0.0)


> Also, what do you get when you run:
> 
> otool -L /opt/local/bin/mythavtest
> 

It links to 61 libraries/frameworks.  I’ll try attaching a file.
/opt/local/bin/mythavtest:
/opt/local/lib/libmythswscale.dylib (compatibility version 3.0.0, 
current version 3.1.101)
/opt/local/lib/libmythavformat.dylib (compatibility version 56.0.0, 
current version 56.40.101)
/opt/local/lib/libmythswresample.dylib (compatibility version 1.0.0, 
current version 1.2.101)
/opt/local/lib/libmythavutil.dylib (compatibility version 54.0.0, 
current version 54.31.100)
/opt/local/lib/libmythavcodec.dylib (compatibility version 56.0.0, 
current version 56.60.100)
/opt/local/lib/libmythtv-0.28.0.dylib (compatibility version 0.28.0, 
current version 0.28.0)
/opt/local/lib/libmythupnp-0.28.0.dylib (compatibility version 0.28.0, 
current version 0.28.0)
/opt/local/lib/libmythbase-0.28.0.dylib (compatibility version 0.28.0, 
current version 0.28.0)
/opt/local/lib/libmythui-0.28.0.dylib (compatibility version 0.28.0, 
current version 0.28.0)
/opt/local/lib/libmyth-0.28.0.dylib (compatibility version 0.28.0, 
current version 0.28.0)
/opt/local/lib/libmythmetadata-0.28.0.dylib (compatibility version 
0.28.0, current version 0.28.0)
/opt/local/lib/libmythservicecontracts-0.28.0.dylib (compatibility 
version 0.28.0, current version 0.28.0)
/opt/local/lib/libmythprotoserver-0.28.0.dylib (compatibility version 
0.28.0, current version 0.28.0)
/opt/local/lib/libmythfreemheg-0.28.0.dylib (compatibility version 
0.28.0, current version 0.28.0)
/opt/local/lib/libmythhdhomerun-0.28.0.dylib (compatibility version 
0.28.0, current version 0.28.0)
/opt/local/lib/libtag.1.dylib (compatibility version 1.0.0, current 
version 1.14.0)
/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 1256.1.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 
(compatibility version 1.2.0, current version 1.11.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 
(compatibility version 1.2.0, current version 1.5.0)

/System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation 
(compatibility version 1.0.0, current version 2.0.0)
/System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia 
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/

Re: Broken links detected...to ApplicationServices ?

[Craig Treleaven]

> On Jan 10, 2016, at 9:02 AM, Craig Treleaven <ctrelea...@macports.org> wrote:
> 
>> On Jan 10, 2016, at 12:18 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> 
>> On Jan 9, 2016, at 9:33 PM, Craig Treleaven wrote:
>> 
>>> I’m working on a new version of MythTV (0.28) and I’m stymied on the 
>>> following.  Every program (23), and every library and filter (28) is 
>>> reported by MacPorts to have a linking error similar to the following:
>>> 
>>> --->  Scanning binaries for linking errors
>>> …
>>> Incompatible library version: /opt/local/bin/mythavtest requires version 
>>> 64.0.0 or later, but 
>>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>>  provides version 1.0.0
>>> DEBUG: Marking /opt/local/bin/mythavtest as broken
>>> 
>>> Web searches and whatnot have not turned up any promising leads so I beg 
>>> the indulgence of those more experienced than I.  
>>> 
>>> I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools.  
>> 
>> What do you get when you run:
>> 
>> otool -L 
>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>  
>> 
>> On my 10.10 and 10.11 systems, the first two lines are:
>> 
>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices:
>>  
>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>  (compatibility version 1.0.0, current version 48.0.0)
>> 
>> So, the OS provides ApplicationServices version 48.0.0 which is 
>> backward-compatible with 1.0.0. I'm not sure where you would have 
>> encountered a version 64.0.0 of ApplicationServices; it doesn't appear Apple 
>> has released any version that high yet.
>> 
> 
> I get the same as you:
> 
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices:
>   
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  (compatibility version 1.0.0, current version 48.0.0)
> 
> Perhaps it is just a coincidence, but I noticed the next line, CoreGraphics, 
> references “version 64.0.0”:
>   
> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 
> (compatibility version 64.0.0, current version 600.0.0)
> 
> 
>> Also, what do you get when you run:
>> 
>> otool -L /opt/local/bin/mythavtest
>> 
> 
> It links to 61 libraries/frameworks.  I’ll try attaching a file.
> 
>> Maybe you have DYLD_LIBRARY_PATH set to a value that is causing the wrong 
>> libraries to be used.
>> 
> Don’t think so:
> 
> $ printenv |grep -i LIB
> PATH=/opt/local/bin:/opt/local/sbin:/opt/local/lib/mariadb/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
> 

Aha!  Did some careful checking and it appears that '-framework 
ApplicationServices’ was missing from the linker flags.  Adding that appears to 
have cured the problem.

Sorry for th noise.

Craig


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

Re: [144442] trunk/dports/aqua/qt5

[Craig Treleaven]

> On Jan 8, 2016, at 6:50 PM, mcalh...@macports.org wrote:
> 
> Revision
> 12 Author
> mcalh...@macports.org Date
> 2016-01-08 15:50:05 -0800 (Fri, 08 Jan 2016)
> Log Message
> 
> qt5-qtbase: respect macosx_deployment_target and configure.cxx_stdlib values 
> in build
> Modified Paths
> 
> trunk/dports/aqua/qt5/Portfile 
> Added Paths
> 
> trunk/dports/aqua/qt5/files/patch-mkspecs.diff 
> Hi:

I take it this change caused qt5-qtwebkit (and others) to fail to build?

https://build.macports.org/builders/buildports-yosemite-x86_64/builds/7308/steps/status/logs/portstatus
 


Do you have an ETA for a fix?  I’m tyring to work on a new version of MythTV 
and need this.

Thanks,

Craig

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

Re: [144442] trunk/dports/aqua/qt5

[Craig Treleaven]

Thanks for the quick followup.  That got me going on Yosemite although I see 
the buildbots aren’t too happy.  ;)

Craig

> On Jan 9, 2016, at 12:22 PM, Marcus Calhoun-Lopez <mcalh...@macports.org> 
> wrote:
> 
> r15 (https://trac.macports.org/changeset/15 
> <https://trac.macports.org/changeset/15>) is the change that broke things.
> Hopefully, it is fixed in r144467 (https://trac.macports.org/changeset/144467 
> <https://trac.macports.org/changeset/144467>).
> 
> Sorry for the inconvenience.
> 
> -Marcus
> 
> 
>> On Jan 9, 2016, at 8:25 AM, Craig Treleaven <ctrelea...@macports.org 
>> <mailto:ctrelea...@macports.org>> wrote:
>> 
>>> On Jan 8, 2016, at 6:50 PM, mcalh...@macports.org 
>>> <mailto:mcalh...@macports.org> wrote:
>>> 
>>> Revision
>>> 12 <https://trac.macports.org/changeset/12>Author
>>> mcalh...@macports.org <mailto:mcalh...@macports.org>Date
>>> 2016-01-08 15:50:05 -0800 (Fri, 08 Jan 2016)
>>> Log Message
>>> 
>>> qt5-qtbase: respect macosx_deployment_target and configure.cxx_stdlib 
>>> values in build
>>> Modified Paths
>>> 
>>> trunk/dports/aqua/qt5/Portfile 
>>> Added Paths
>>> 
>>> trunk/dports/aqua/qt5/files/patch-mkspecs.diff 
>>> Hi:
>> 
>> I take it this change caused qt5-qtwebkit (and others) to fail to build?
>> 
>> https://build.macports.org/builders/buildports-yosemite-x86_64/builds/7308/steps/status/logs/portstatus
>>  
>> <https://build.macports.org/builders/buildports-yosemite-x86_64/builds/7308/steps/status/logs/portstatus>
>> 
>> Do you have an ETA for a fix?  I’m tyring to work on a new version of MythTV 
>> and need this.
>> 
>> Thanks,
>> 
>> Craig
> 

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

Broken links detected...to ApplicationServices ?

[Craig Treleaven]

Hi:

I’m working on a new version of MythTV (0.28) and I’m stymied on the following. 
 Every program (23), and every library and filter (28) is reported by MacPorts 
to have a linking error similar to the following:

--->  Scanning binaries for linking errors
…
Incompatible library version: /opt/local/bin/mythavtest requires version 64.0.0 
or later, but 
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 provides version 1.0.0
DEBUG: Marking /opt/local/bin/mythavtest as broken

Web searches and whatnot have not turned up any promising leads so I beg the 
indulgence of those more experienced than I.  

I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools.  

Thanks for any suggestions or help,

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

Re: Survey: How do you commit?

[Craig Treleaven]

> On Jan 2, 2016, at 12:43 AM, Ryan Schmidt  wrote:
> 
> Quick survey for committers:
> 
> How do you commit to the MacPorts Subversion repository?
> 
> Using a Subversion working copy and "svn commit”?

Yes

> Using a Git clone and git-svn?
> Some other method?
> 
> Do you have any complaints about that method or are you happy with it?

No.

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

Re: New Mac OS Forge administrator

[Craig Treleaven]

> On Nov 19, 2015, at 9:49 PM, Ryan Schmidt  wrote:
> 
> Dear MacPorts users and developers,
> 
> I'm pleased finally to be able to tell you that I have been hired to be your 
> new Mac OS Forge administrator. I have been involved in improving MacPorts 
> for years as a committer and as a manager, and now as a Mac OS Forge 
> administrator I will work on ensuring our infrastructure runs smoothly too.
> 
> I apologize for the downtime we've experienced in the past months. My 
> priority right now is to resolve the existing issues, as I become familiar 
> with the systems.
> 
> Please continue to report new problems with MacPorts infrastructure (server 
> not working) as you have before, using the server/hosting component in Trac 
> or via email to admin at macosforge dot org. And continue to report MacPorts 
> administrative issues (mailing list issues, commit access requests) to 
> portmgr at macports dot org.
> 
> Thanks for your patience and support and thank you for using MacPorts.

Congratulations on the new gig!  That is certainly good news for MacPorts and I 
wish you every success.

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

Re: All KDE ports need a major revbump, due to recent changes to qt4-mac

[Craig Treleaven]

> 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}/libexec/qt4/bin are inaccessible and not in PATH
> * pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
>  found by default (needs additional PKG_CONFIG_PATH)
> * cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
>  by default (needs additional CMAKE_MODULE_PATH)
> 
> The same seems to apply to qt5-mac as well. Also, the choice of
> ${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
> 
> Please do not simply drop everything related to Qt into its own prefix.
> At least keep the files mentioned above in the default locations where
> they can be found and used by other build systems.

Something I wondered about was the choice of ${prefix}/libexec/blah .  The 
other example of co-installable versions/forks that I’m familiar with is mysql. 
 Those ports install the binaries into ${prefix}/lib/blah (e.g.. 
/opt/local/lib/mariadb/bin/ ).  I have no idea if one approach is “right”—just 
that the mysql structure has been around longer and could be considered a 
precedent.

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

Dist file mirror selection

[Craig Treleaven]

Hi:

What order does MacPorts use for fetching dist files?  My impression was that 
MacPorts would try to:

1) use a ‘close by’ mirror (based on ping times)
2) fetch from the main MacPorts dist file server 
(http://distfiles.macports.org/)
3) fall back to the master_site (GitHub, in my case[a])

That didn’t happen, at least for one user, viz:

--->  mythtv-e9b577d3.tar.gz doesn't seem to exist in 
/opt/local/var/macports/distfiles/mythtv-core.27
--->  Attempting to fetch mythtv-e9b577d3.tar.gz from 
https://github.com/MythTV/mythtv/tarball/e9b577d3

Why did it go GitHub rather than one of our mirrors (or the main site)?

Craig

[a] See ticket 48987 if you want the details.  I believe a git hook is run when 
the snapshot is being prepared and it behaves differently at different times. 
I’m trying to work with upstream to figure out when and why it changes.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: SVN authorization

[Craig Treleaven]

 On Aug 6, 2015, at 9:44 AM, Rainer Müller rai...@macports.org wrote:
 
 Hello Craig,
 
 On 2015-08-06 14:52, Craig Treleaven wrote:
 On Aug 5, 2015, at 11:20 PM, Mihai Moldovan io...@macports.org wrote:
 
 On 06.08.2015 02:53 AM, Craig Treleaven wrote:
 I vaguely recall running an svn command to add MacPorts as a trusted 
 server (or some-such) but I don’t recall the details.  
 
 Could someone point me in the right direction?
 
 Refer to https://trac.macports.org/wiki/howto/SyncingWithSVN and 
 specifically to
 Step 3 under Configuration”.
 
 Thanks for the pointer.  As I read the page, I only need to do the second 
 part--storing the certificate file in 
 [blah]/.subversion/auth/svn.ssl.server.  However, trying to selfupdate, I 
 still get:
 
 ---  Updating the ports tree
 Synchronizing local ports tree from file:///Users/craigtreleaven/mp/ports
 Updating '.':
 svn: E175002: Unable to connect to a repository at URL 
 'https://svn.macports.org/repository/macports/trunk/dports'
 svn: E175002: OPTIONS of 
 'https://svn.macports.org/repository/macports/trunk/dports': Server 
 certificate verification failed: issuer is not trusted 
 (https://svn.macports.org)
 Command failed: /usr/bin/svn update --non-interactive 
 /Users/craigtreleaven/mp/ports
 Exit code: 1
 
 
 I wonder if it is the ownership/permissions of the certificate file.  The 
 wiki page doesn’t say so, but I had to use ‘sudo’ to create the directory 
 and write the certificate file to it. 
 
 $ sudo ls -al /opt/local/var/macports/home/.subversion/auth/svn.ssl.server
 total 8
 drwxr-xr-x  3 root  admin   102  6 Aug 08:27 .
 drwx--  6 root  admin   204  5 Aug 20:19 ..
 -rw-r--r--  1 root  admin  1806  6 Aug 08:27 9368d05e066fecedad33aa815bbaf7cc
 
 Only root will be able to read this file (due to permissions on ..).
 MacPorts automatically runs the update command as the user owning the
 Subversion working copy, so you need to configure it for that user. The
 instructions in the wiki assume the ports tree will be owned by the
 macports user.
 
 Finally, I checked a backup of my 10.6 volume and I didn’t even have a 
 '/opt/local/var/macports/home/.subversion/auth/svn.ssl.server’ directory?
 
 Back then, /usr/bin/svn was still able to verify SSL certificates for
 HTTPS. Apple broke this with OS X 10.7 Lion and never fixed it.
 /usr/bin/svn does not have any list of trusted authorities and
 therefore always display this certificate warning requiring manual
 acknowledgement to continue.
 
 Side note: if you install the subversion port and either curl-ca-bundle
 or certsync, certificate verification for HTTPS should just work using
 /opt/local/bin/svn.
 
 I prefer to keep the ports tree in my home directory, where I also keep
 everything else I am working on. As MacPorts automatically switches to
 the user owning the ports tree, this works just fine and also uses my
 configuration of Subversion. But I need to ensure that the macports
 user is able to read the Portfiles (and accompanying patches). My setup
 is as follows:
 
 In my /opt/local/etc/macports/sources.conf I have the following entry:
 file:///Users/raimue/src/macports/trunk/dports/ [default]
 
 The permissions on this path are the following, especially I need the
 x-bit to allow any user to traverse through my home directory:
  drwxr-xr-x6 rootadmin   204 Feb 21 21:32 /Users
  drwxr-xr-x+ 227 raimue  staff  7718 Aug  6 15:26 /Users/raimue
   0: group:everyone deny delete
  drwx--x--x  117 raimue  staff  3978 Jul 27 10:54 /Users/raimue/src
  drwxr-xr-x   23 raimue  staff   782 Jun  7 13:03 /Users/raimue/src/macports
  drwxr-xr-x+  12 raimue  staff   408 Mar  7 16:21 
 /Users/raimue/src/macports/trunk
   0: group:everyone allow list,search,file_inherit,directory_inherit
  drwxr-xr-x+  52 raimue  staff  1768 Aug  5 15:14 
 /Users/raimue/src/macports/trunk/dports
   0: group:everyone allow list,search,file_inherit,directory_inherit
 
 These additional ACL entries make sure that the macports user is able
 to read Portfiles in the ports tree (not sure why I have that one on
 $HOME itself, is it default?). I could have made them less permissive,
 but the tree should not contain anything private anyway. They ensure
 that all newly created files get the correct permissions. Only when
 moving files from somewhere else into the ports tree I need to be more
 cautious and apply the ACL rules once again.
 
 The command to set these ACLs would be:
 chmod -R +a group:everyone allow 
 read,execute,list,search,file_inherit,directory_inherit DIR
 
 Hopefully that helps you with your own setup.

Thanks Rainer!  I installed subversion, logged out and back in to clear the 
hash, and then needed to run svn upgrade in my ports directory.  That cleared 
the remaining hurdles and my tree is now updating!

Thanks again.

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

SVN authorization

[Craig Treleaven]

Hi:

I migrated from 10.6 to 10.10 recently and I now want to do some work on the 
ports I maintain but I’ve run into a snag.  

Trying to run 'sudo port -v selfupdate’ results in:

…
---  Updating the ports tree
Synchronizing local ports tree from file:///Users/craigtreleaven/mp/ports
Updating '.':
svn: E175002: Unable to connect to a repository at URL 
'https://svn.macports.org/repository/macports/trunk/dports'
svn: E175002: OPTIONS of 
'https://svn.macports.org/repository/macports/trunk/dports': Server certificate 
verification failed: issuer is not trusted (https://svn.macports.org)
Command failed: /usr/bin/svn update --non-interactive 
/Users/craigtreleaven/mp/ports
Exit code: 1
…

I vaguely recall running an svn command to add MacPorts as a trusted server (or 
some-such) but I don’t recall the details.  

Could someone point me in the right direction?

Thanks,

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

Re: startupitem issue with unmounted volume (non-default prefix)

[Craig Treleaven]

 On Jul 24, 2015, at 10:48 PM, Joshua Root j...@macports.org wrote:
 
 On 2015-7-25 09:59 , Ryan Schmidt wrote:
 
 On Jul 21, 2015, at 9:04 PM, Daniel J. Luke wrote:
 On Jul 21, 2015, at 7:27 PM, Ryan Schmidt wrote:
 ok, so we should probably be copying the plist (instead of symlinking it 
 - which is a lesson we should have already learned from back in the 
 ‘images’ days) - and we likely also want something like the above.
 
 I don't remember: any reason why we need a copy/symlink there? Why can't 
 we just put the plist there (and only there)?
 
 I believe it was a desire to have everything in $prefix (and maybe to 
 facilitate when people have more than one install in different prefixes?)
 
 But if you have multiple installs, you already have to set 
 startupitem_install no and startupitem_type none in macports.conf on all 
 but one of them. There would be no significant difference if we were to 
 change MacPorts to install the plist file to its final destination directly, 
 rather than to put a symlink there.
 
 What we should do is:
 * Never put anything in /Library/LaunchDaemons at destroot time
 * If $startupitem_install is true at activate time, hard-link or copy
 (depending on if the volumes differ) the plist to /Library/LaunchDaemons
 * Record that we did that so it can be removed at deactivate time
 
 - Josh
From a selfish point of view, I would like to see this work better in case of 
mdmv/mpkg installers.  Currently, my installer for MythTV includes launchd 
plists for MythTV, MariaDB and logrotate.  The dmg installer doesn’t put the 
plist in the right place for any of those.  (There are no activate or 
deactivate stages in such cases.)  My workaround depends on running a script 
after the install.

Craig

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

Package delivery without XCode

[Craig Treleaven]

Background - So I was following a discussion on another site about 
Apple's Aperture being replaced.  Many people are looking for 
alternatives and there has been essentially no mention of open source 
alternatives (like DarkTable, LightZone or DigiKam).  Most of these 
folks are photographers and would never consider installing MacPorts 
and XCode in order to get an application they might otherwise find 
interesting.


1) How much work would it take to have a mode in MacPorts where it 
only installs pre-compiled packages?  Is the assumption that XCode is 
present so deeply ingrained that Macports-base would have to be 
extensively re-designed?


For example, I would think 'port search' would need to be modified to 
only show the pre-compiled packages (available for that platform) and 
somehow indicate that only the default variants are available.


Perhaps a fork of Pallet could be so modified?

2) Are there a worthwhile number of packages that would then be 
available?  I know my own MythTV ports run into the OpenSSL conflict 
and therefore aren't available as binaries.  From 
http://packages.macports.org/ it appears we don't have binary 
packages for DarktTable or DigiKam (and no port of LightZone).


OTOH, someone posted some information several weeks ago explaining 
how to determine if that licence conflict really applies or not. 
(Involves inspecting library linkages, as I recall.)  I get the 
impression that our current policy is quite conservative and that a 
number of packages (many?) may actually qualify for binary 
distribution with some analysis and verification.


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

Re: Package delivery without XCode

[Craig Treleaven]

At 8:45 AM -0700 5/18/15, David Evans wrote:

On 5/18/15 8:01 AM, Craig Treleaven wrote:
Background - So I was following a discussion on another site about 
Apple's Aperture being replaced.  Many people are looking for 
alternatives and there has been essentially no mention of open 
source alternatives (like DarkTable, LightZone or DigiKam).  Most 
of these folks are photographers and would never consider 
installing MacPorts and XCode in order to get an application they 
might otherwise find interesting.


1) How much work would it take to have a mode in MacPorts where it 
only installs pre-compiled packages?  Is the assumption that XCode 
is present so deeply ingrained that Macports-base would have to be 
extensively re-designed?


For example, I would think 'port search' would need to be modified 
to only show the pre-compiled packages (available for that 
platform) and somehow indicate that only the default variants are 
available.


Perhaps a fork of Pallet could be so modified?

2) Are there a worthwhile number of packages that would then be 
available?  I know my own MythTV ports run into the OpenSSL 
conflict and therefore aren't available as binaries.  From 
http://packages.macports.org/ it appears we don't have binary 
packages for DarktTable or DigiKam (and no port of LightZone).


OTOH, someone posted some information several weeks ago explaining 
how to determine if that licence conflict really applies or not. 
(Involves inspecting library linkages, as I recall.)  I get the 
impression that our current policy is quite conservative and that a 
number of packages (many?) may actually qualify for binary 
distribution with some analysis and verification.




Have you looked at the various binary packaging targets available 
with MacPorts?


mpkg or mdmg  might provide a mechanism to do what you want.  Just 
would need a way to distribute the results providing the licensing 
issues could be worked out.


See https://guide.macports.org/#using.binaries


I am intimately familiar with mpkg/mdmg -- I provide an all-in-one 
installer for Myth[1].  For that, I use Parallels to maintain an 
isolated prefix for building (and others for testing.  It occurred to 
me that the existing infrastructure of MacPorts provides _most_ of 
what would be needed for delivering pre-built packages to 
less-sophisticated users.


[1] https://sourceforge.net/projects/macportsmythtvinstaller/

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

Re: Package delivery without XCode

[Craig Treleaven]

At 11:56 AM -0400 5/18/15, Brandon Allbery wrote:
On Mon, May 18, 2015 at 11:01 AM, Craig Treleaven 
mailto:ctrelea...@macports.orgctrelea...@macports.org wrote:

...
OTOH, someone posted some information several weeks ago explaining 
how to determine if that licence conflict really applies or not. 
(Involves inspecting library linkages, as I recall.)  I get the 
impression that our current policy is quite conservative and that a 
number of packages (many?) may actually qualify for binary 
distribution with some analysis and verification.


But someone needs to put in that time --- and time is always a 
problem in a volunteer-run project.


Understood, I'm trying to gauge whether there is interest in taking 
MacPorts in this direction.  Right now, as I see it, MacPorts is 
pretty much geared to coders and sophisticated users (system/network 
administrators, etc).  There exists a wider group of folks who just 
want to run a specific application or two (say Darktable and Gimp, 
just for instance).  If such users could just install Pallet-lite 
and then be able to install any of a few dozen major open-source 
applications, that might be pretty popular.


In some ways, it might be the Mac App Store for open source.

Craig

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

Re: MacPorts hosted mdmg

[Craig Treleaven]

At 12:15 PM +0100 3/15/15, Marko Käning wrote:

On 15 Mar 2015, at 00:02 , Bradley Giesbrecht pixi...@macports.org wrote:
...Imagine you want to ship, say, one of these 
KDE games. They are nice and small, but need the

whole background of KDE4/KF5 libs for them to function - of course.

Instead of shipping KDE or KF5 as a whole with 
each and every little game, it would be very
nice to have a means to redistributeably install 
a meta-port like kde4-workspace (as discussed
in the before-mentioned parallel thread) which 
then would include everything needed for properly

running any KDE4 application.

One would then have to ship only the meta-port 
mdmv package and the several mdmg packages for

the whatever KDE4 application.

All these would - IDEALLY - have to be built in 
such a way that they can coexist with an
existing MacPorts installation, I suppose. This 
does not only mean that the PREFIX shouldn't
be /opt/local, but merely also that the 
application's configuration data needs to be put 
in
location(s) separate from the standard ones used 
by a normal MacPorts installŠ Think about


/Library/Launch(Agents|Daemons)
[~]/Library/Application Support
~/Library/Preferences/KDE
~/Library/Caches
~/.config
~/.(cache|config)

and possibly quite a few others.

Since this is even more complicated, for a start 
I think, one would surely like to avoid such
a coinstallable approach. However, not having it 
would make testing pretty hard (if not even

close to impossible), I am afraid.


I don't think there is any realistic way to do 
'additive' installers (ie install a bunch of base 
libraries with one installer and then install one 
or more apps that use those libraries).  I think 
it would be all too common for the user to 
install the base and one app at one time and 
then, months or years later, install another app 
only to find that it is broken due to base 
upgrades in between.


Another wrinkle that occurred to me is that mdmg 
installers sometimes need to be built with 
non-default variants.  For example, my standard 
invocation for Myth is:


sudo port -f mpkg mythtv-pkg.27 
+mariadb+mariadb55+python27+perl5_16+startupitem


I _have_  to specify 
+mariadb+mariadb55+startupitem or the MythTV 
package will be non-functional.  The 
+python27+perl5_16 ensures that I don't get 
copies of other versions of perl and python--thus 
reducing the size of the installer by about 20% 
(which is still ~400 MB).


I have to use the -f flag to make the horrendous 
hack in MacPort_daemondo succeed.  I'm hoping a 
GSOC student will figure out a clean fix for the 
issue.


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

Re: MacPorts hosted mdmg

[Craig Treleaven]

At 4:02 PM -0700 3/14/15, Bradley Giesbrecht wrote:

On Mar 14, 2015, at 2:26 PM, Marko Käning mk-macpo...@techno.ms wrote:
...
 Installing all these dependencies is only 
acceptable for techies like us, but a normal

 user will never bother to deal with all the hassle.


I think we have an opportunity to extend what 
MacPorts does well to include relocatable 
packages or mdmg packages in a way that third 
parties can build distributable packages 
untethered from MacPorts and Xcode. Gimp, 
Kdenlive, digiKam, Octave and many KDE things 
would sing praises to MacPorts.


I created mythtv-pkg.27 solely to facilitate 
creating an installer package.  Currently, 
MacPorts makes it possible to do something that 
would otherwise be much more difficult.  As 
Clemens pointed out, it would be really nice if 
post-activate actions were automatically 
converted to postflight scripts.  Better handling 
of launchd stuff would also be nice.  Neither of 
these things are show-stoppers, though.  One just 
has to provide clear user instructions for the 
bits that have to be done manually.


If we wanted to use the buildbots to assist with 
such packaging, I would think that we should add 
a directive to the appropriate portfiles that 
cause them to be packaged.  Packaging individual 
libraries would be of no value.  Packaging is 
valuable for those user-facing applications where 
upstream doesn't regularly produce dmg's.


Right now, I use Parallels to maintain several OS 
X environments to test building and deploying my 
Myth package.  Putting some of that load on the 
buildbots would be darn nice.  Especially making 
installers for each major OS version.  But I 
would still want to test on a virgin system 
before inflicting it on unsuspecting users.


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

Re: MacPorts forum(s)? (was: Re: memberlist)

[Craig Treleaven]

At 5:45 PM -0500 2/10/15, Lawrence Velázquez wrote:
Having both forums and mailing lists would be 
harmful to the community. We'd end up with two 
bubbles (one much smaller, probably) that don't 
interact with each other.


The only way forums would work is if we migrated *all* discussion there.


The MythTV project set up an online forum a year 
ago in addition to the mythtv-users mailing list. 
I'd say the experience there is that the two 
bubbles that don't interact much...but that is 
not a bad thing.


Mailing list volume is basically unchanged since 
the forum went live.  The forum is still growing 
every month and now gets several thousand 
visitors per month.  The biggest volume of 
MythTV-via-Macports support that I do is via the 
forum.  But I still follow the mythtv-users 
mailing list and answer questions there, as well.


As I see it, there are folks who ONLY do mailing 
lists and folks who ONLY do forums.  (And a few 
of us gluttons that do both.)  I suspect that a 
MacPorts forum would be viable if a few of the 
usual suspects would answer questions on it.  A 
forum would provide a venue for folks that are 
not comfortable with subscribing to a mailing 
list.


Forums do offer a couple of advantages over 
mailing lists.  The key one is: images inline 
with text.  A user can post screen shots together 
with a description of their issue.  Obviously 
there are ways to achieve much the same result 
with mailing lists but the integration on a forum 
thread is very nice.


OTOH, a forum takes work to set up and maintain. 
I'm not volunteering to do it.But if a forum 
is created, I'll add it to the list that I check 
and probably answer questions when I can.


Overall, the MythTV experience shows a forum 
would not be harmful to the community NOR that 
we'd have to migrate all discussion there.


Craig
PS Some forums can be set up to send you an email 
when a sub-forum or topic is updated (after your 
last visit).  I don't know of any that allow you 
to send an email that becomes a posting, however.


PPS One could argue that IRC and mailing lists 
serve basically the same purpose and it is 
redundant to have both!

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

Re: co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent

[Craig Treleaven]

At 10:56 AM +0100 12/20/14, René J.V. Bertin wrote:

On Saturday December 20 2014 17:44:30 Ian Wadham wrote:

Morning Ian!


It is a great start !!!  Thanks very much René!


You are welcome (and I and the rest of us...) Someone had to do this...

I was hoping a few other MacPorts/KDE-Mac users 
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 
development versions of Qt somewhere else
and point to your test or development 
version via environment variable $QTDIR.
Does this presuppose a fixed hierarchy 
of directories and names under $QTDIR?

If so, changing that hierarchy may cause problems.


I think that nowadays the QTDIR trick is 
mostly to use a test version in a different tree 
with applications that were already linked to 
your usual version. If so, that means that QTDIR 
must point to a complete directory and as long 
as that's the case you should be fine.

QTDIR is not (no longer?) required for running.

  b) Shifting Qt libraries from ${prefix}/lib 
to ${prefix}/libexec/${qt_name}/lib might be
   a no-op.  In the lib subdir 
(/opt/local/lib on my system), Qt libraries are 
installed
   as links.  For example, libQtCore.dylib, 
libQtCore.4.dylib, libQtCore.4.8.dylib and
   libQtCore.4.8.6.dylib all point to 
/opt/local/Library/Frameworks/QtCore.framework/QtCore,
   which in turn points to 
Versions/4/QtCore and THAT is actually a file 
described as
   Versions/4/QtCore: Mach-O 64-bit x86_64 
dynamically linked shared library.


Maybe I am missing something.


Yes, you are :) Those frameworks have been moved too.
qt4-mac and qt5-mac use a sneaky trick to 
provide a combined framework and traditional 
build, based on the fact that an OS X framework 
is nothing but a shared library (without the 
usual extension) combined with all associated 
stuff bundled in a specific way. You can get 
very close by using 
--prefix=/Library/Frameworks/foo/Versions/${MAJOR_VERSION} 
and then setting up a couple of symlinks to 
disclose certain things a bit more directly.
So symlinking framework binaries as you saw 
makes the link editor can find them ... it 
already knows how to handle them.


All that to say that no, the qt_libs_dir shift 
is not a no-op. Try it :) and if you didn't 
install qt4-mac-transitional in the same command 
you'll get errors from rev-upgrade. Or else 
you'll see that re-built Qt or KDE applications 
now link to stuff in /opt/local/libexec/qt4 .


Related to the proposed Charm port:

https://trac.macports.org/ticket/46575

If I understand correctly, Charm will create subports ala:

qt5-charm
charm

Is this supposed to be a model for going forward? 
I find the qt5- prefix objectionable.


Going forward, I believe we will have the following cases:
1) Projects that work with Qt4 but not Qt5
2) Projects that work with Qt5 but not Qt4
3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
4) Projects that work with the same with Qt4 or Qt5

Assuming we have co-installable Qt4 and Qt5 via 
MacPorts, cases 1), 2) and 4) are 
straightforward:  'port:' style dependencies for 
1) and 2) and 'path:' style for 4).


In case 3), I think the upstream development plan 
is important.  If upstream is moving to 
supporting Qt5 and the current differences are 
due to incomplete support, I think it would be 
more appropriate to create a '-devel' version of 
the port until the Qt5 conversion is complete. 
OTOH, there might be rare cases where users might 
need to choose between the Qt4 version (more 
compatible, say) and a Qt5 version (new 
features).  Qt4/Qt5 variants would then be 
appropriate.


FWIW, the project I'm most concerned with, 
MythTV, has had a working build with Qt5 for a 
long time and is encouraging testing but it is 
not recommended for casual users.  AIUI, it was 
not particularly difficult to add Qt5 support 
even though Myth uses Qt extensively for user 
interface (including video rendering) and OS 
abstraction.  When upstream is closer to another 
release (0.28), I plan to create a -devel version 
using Qt5.  Barring show-stoppers, I expect to 
transition to Qt5 exclusively.


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

Re: qt5- prefix

[Craig Treleaven]

At 4:11 PM +0100 1/16/15, René J.V. Bertin wrote:

On Friday January 16 2015 08:27:18 Craig Treleaven wrote:

IIUC, your post isn't related to Qt4/5 
co-installability, but to how Qt-specific 
versions of ports distinguish themselves.



 https://trac.macports.org/ticket/46575

 If I understand correctly, Charm will create subports ala:

 qt5-charm
 charm


Yes.


 Is this supposed to be a model for going forward?


No idea.

I only picked the qt5- prefix because there's 
some precedence, though admittedly Qt Creator 
has a qt4- prefix for the Qt4 version.
Similarly, GTk ports indeed have -gtk2 or -gtk3 
suffixes ... though there it might be more usual 
to have a GTk2 dependency be the implicit 
default.



 I find the qt5- prefix objectionable.


Frankly, I don't know and I don't have a real 
preference: I'm open to suggestions.
We do have the likely situation where more and 
more ports will transition to, or at least add 
support for, Qt5. As long as MacPorts doesn't 
provide a mechanism to signal a port name change 
and thus let user installations go from, say, 
QtCurve to qt4-QtCurve automatically, I don't 
see another solution of the kind I've adopted in 
my 2 proposals (Charm and QtCurve).


The replaced_by keyword (and obsolete PortGroup) support what you've described:

https://guide.macports.org/#development.practices.rename-replace-port



  Going forward, I believe we will have the following cases:

 1) Projects that work with Qt4 but not Qt5
 2) Projects that work with Qt5 but not Qt4
 3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
 4) Projects that work with the same with Qt4 or Qt5

 Assuming we have co-installable Qt4 and Qt5 via
 MacPorts, cases 1), 2) and 4) are
 straightforward:  'port:' style dependencies for
 1) and 2) and 'path:' style for 4).


AFAIC, case 4) ports will either impose a choice 
(port: style dependency) or leave choice to the 
user, as I did with Charm.


As port maintainers, I believe we _should_ make 
choices on behalf of users.  Case by case, 
revision by revision, if there is a choice 
between Qt4 and Qt5, the port maintainer should 
evaluating whether to stay with Qt4 or jump to 5. 
At some point, I suspect security problems with 
Qt4 (or just bit rot) are going to push projects 
to give up on Qt4.  IOW, sub-ports or variants 
for Qt4/Qt5 should be unusual exceptions rather 
than the norm.  Pick the right time and make the 
move.  Use a -devel port if experimentation is 
required in the interim.


There is something to say with providing a 
version-agnostic Qt PortGroup that could even 
include the version-specific PortGroup, though.


Could you clarify what you mean here?


  OTOH, there might be rare cases where users might

 need to choose between the Qt4 version (more
 compatible, say) and a Qt5 version (new
 features).  Qt4/Qt5 variants would then be
 appropriate.


If you accept that detection of the installed 
version is done automatically, yes. But when you 
do that, how do you handle the case the user has 
both Qt versions installed? Even if you as a 
port developer (knowing the port and all) have a 
preference, the user might not agree.


To be blunt, tough.  If a user really wants 
another configuration, they can create a modified 
portfile for themselves.  The port maintainer 
ought to pick one variant as the default.  My 
impression is that the vast majority of installs 
use only the default variants.  We shouldn't shy 
away from the doing the right thing for (the 
majority of) our users.


I see the Qt5 supports OS X 10.7 and later ('best 
efforts' for 10.6, if I read it right):


http://doc.qt.io/qt-5/osx.html

For some ports, if the maintainer wants to keep 
it running on old OS X versions, they might use 
Qt4 for older OS environments and Qt5 for newer. 
Not a variant, just do the right thing in the 
environment.


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

Re: How to specify commandline options to git for the fetch phase of a port?

[Craig Treleaven]

At 3:35 PM + 11/12/14, William Gallafent wrote:
On 12 November 2014 15:26, Daniel J. Luke 
mailto:dl...@geeklair.netdl...@geeklair.net 
wrote:
  On Nov 12, 2014, at 5:45 AM, William 
Gallafent 
mailto:will...@gallaf.netwill...@gallaf.net 
wrote:
 According to 
https://guide.macports.org/#reference.phases.fetch.githttps://guide.macports.org/#reference.phases.fetch.git 
I am able to set the url and tag to fetch Š but 
for a particular port I'm playing with I also 
need to add the --recursive option in order 
to get the submodules in place. Alternatively, 
I would need to run git submodule update 
--init --recursive immediately after the fetch.


 Any thoughts or advice?


First, be sure you actually need to use git to 
fetch the source (it's /much/ better to pull a 
tarball than to pull source from 
git/mercurial/svn/cvs/whatever).


Fair point! The only links given to source for 
this project are to git repositories, 
unfortunately - 
http://www.linphone.org/technical-corner/linphone/downloadshttp://www.linphone.org/technical-corner/linphone/downloads 
Š if there's a location from which I may 
download source tarballs, then so much the 
better, but I haven't found one yet!


What's wrong with:

http://download-mirror.savannah.gnu.org/releases/linphone/3.7.x/sources/linphone-3.7.0.tar.gz

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

Re: svn conflict

[Craig Treleaven]

At 12:45 PM +0200 10/18/14, Peter Danecek wrote:

On 18 Oct 2014, at 02:55, Craig Treleaven ctrelea...@macports.org wrote:

  I've ended up with an svn conflict--just in the capitalization of 
the directory name, if I'm reading this right.


 SixBare:mp-trunk-ports craigtreleaven$ svn status
 ?   sysutils/MacPorts_daemondo
 ! C sysutils/macports_daemondo
 local add, incoming add upon update


Might this be, because the underlaying FS is not case-sensitive 
(only case-preserving) so the two names would identify basically the 
same directory?


Have you used `svn mv` to capitalise the name? Or how did you get 
into the current state?


I don't know how it got out of sync.  I thought I committed it with 
uppercase in the directory name.  Anyway, I just changed the local 
directory name to lowercase, did 'svn update' and the conflict is 
gone.  I can live with the lowercase directory name.


Thanks,

Craig

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

Re: svn conflict

[Craig Treleaven]

At 10:59 AM -0500 10/18/14, Ryan Schmidt wrote:

On Oct 18, 2014, at 8:22 AM, Craig Treleaven wrote:

 At 12:45 PM +0200 10/18/14, Peter Danecek wrote:

 On 18 Oct 2014, at 02:55, Craig Treleaven wrote:

 I've ended up with an svn conflict--just in the capitalization 
of the directory name, if I'm reading this right.


 SixBare:mp-trunk-ports craigtreleaven$ svn status
 ?   sysutils/MacPorts_daemondo
 ! C sysutils/macports_daemondo
 local add, incoming add upon update


 Might this be, because the underlaying FS is not case-sensitive 
(only case-preserving) so the two names would identify basically 
the same directory?


 Have you used `svn mv` to capitalise the name? Or how did you get 
into the current state?


 I don't know how it got out of sync.  I thought I committed it 
with uppercase in the directory name.  Anyway, I just changed the 
local directory name to lowercase, did 'svn update' and the 
conflict is gone.


You probably had the directory MacPorts_daemondo on disk, but ran 
svn add macports_daemondo which scheduled it for addition in the 
all-lowercase version. Subversion is always case-sensitive, even on 
case-insensitive-but-case-preserving filesystems.



 I can live with the lowercase directory name.


Note:

$ port lint MacPorts_daemondo
---  Verifying Portfile for MacPorts_daemondo
Warning: Line 2 is missing RCS tag ($Id$)
Error: Portfile directory macports_daemondo does not match port name 
MacPorts_daemondo

---  1 errors and 1 warnings found.


I'm an svn newbie, where/how does the RCS tag get set?  I thought it 
was something that was automatically added by svn.


Should I now do 'svn move sysutils/macports_daemondo 
sysutils/MacPorts-daemondo' ?  Don't want to screw this up more...


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

Re: svn conflict

[Craig Treleaven]

At 11:24 AM -0500 10/18/14, Ryan Schmidt wrote:

On Oct 18, 2014, at 11:18 AM, Craig Treleaven wrote:


 At 10:59 AM -0500 10/18/14, Ryan Schmidt wrote:


 $ port lint MacPorts_daemondo
 ---  Verifying Portfile for MacPorts_daemondo
 Warning: Line 2 is missing RCS tag ($Id$)
 Error: Portfile directory macports_daemondo does not match port 
name MacPorts_daemondo

 ---  1 errors and 1 warnings found.


 I'm an svn newbie, where/how does the RCS tag get set?  I thought 
it was something that was automatically added by svn.


You manually put the line # $Id$ as the second line of the 
portfile, after the modeline. Subversion fills in the details.


https://guide.macports.org/chunked/development.creating-portfile.html


 Should I now do 'svn move sysutils/macports_daemondo 
sysutils/MacPorts-daemondo' ?  Don't want to screw this up more...


Yes, you should fix the case of the directory. Since you have a 
case-insensitive filesystem, you'll need to do the move in the 
repository, rather than in your working copy:


https://subversion.apache.org/faq.html#case-change


In case anyone else is following along at home...

I did the move on the repository but still had a conflict as svn 
locally believed the directory had the old name.  So I deleted 
sysutils/MacPorts-daemondo locally and checked-out a new copy from 
the server.  All seems well, now.


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

Re: [126918] trunk/dports/sysutils

[Craig Treleaven]

At 3:25 PM -0500 10/17/14, Ryan Schmidt wrote:

  On Oct 17, 2014, at 12:04 PM, ctrelea...@macports.org wrote:


 Revision
 126918
 Author
 ctrelea...@macports.org
 Date
 2014-10-17 10:04:38 -0700 (Fri, 17 Oct 2014)
 Log Message

 MacPorts_daemondo: New port to allow including daemondo in mpkg's
 Added Paths

* trunk/dports/sysutils/macports_daemondo/
* trunk/dports/sysutils/macports_daemondo/Portfile
 Diff

 Added: trunk/dports/sysutils/macports_daemondo/Portfile (0 = 126918)

 --- trunk/dports/sysutils/macports_daemondo/Portfile 
(rev 0)
 +++ trunk/dports/sysutils/macports_daemondo/Portfile	2014-10-17 
17:04:38 UTC (rev 126918)


 @@ -0,0 +1,35 @@

 +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: 
nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4

 +
 +PortSystem  1.0
 +
 +nameMacPorts_daemondo
 +version 1.1
 +revision20141017
 +categories  sysutils
 +platforms   darwin
 +supported_archs x86_64
 +license BSD
 +maintainers cogeco.ca:ctreleaven openmaintainer
 +
 +description HACK to get daemondo into mpkg
 +long_descriptionNasty ${description}. \
 +When using MacPorts to create an mpkg, any 
daemons requiring daemondo \
 +would fail.  Adding this port as dependency 
permits them to work.

 +
 +homepage   
 http://www.macports.org/


 +master_sites
 +
 +universal_variant   no
 +
 +fetch {}
 +checksum {}
 +extract {}
 +use_configure no
 +build {}
 +
 +destroot {
 +file copy ${prefix}/bin/daemondo ${destroot}${prefix}/bin/
 +}
 +
 +# We'll force the install and overwrite daemondo...with itself!
 +# But now we can add this as a dependency to the mpkg


Uh I agree, this is very nasty.


See:

https://trac.macports.org/ticket/43648

I've left the ticket open hoping that someone more clever than I 
(me?) can develop a more elegant solution.


Craig
--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054  ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

svn conflict

[Craig Treleaven]

Hi:

I've ended up with an svn conflict--just in the capitalization of the 
directory name, if I'm reading this right.


SixBare:mp-trunk-ports craigtreleaven$ svn status
?   sysutils/MacPorts_daemondo
! C sysutils/macports_daemondo
 local add, incoming add upon update

I tried:

$ svn resolve --accept theirs-conflict sysutils/MacPorts_daemondo

but the conflict remains.

How do I resolve this?

Craig

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

CFPreferences warnings

[Craig Treleaven]

Hi:

I'm working on a new version of MythTV and building in a non-standard 
prefix (/opt/dvr).  I'm getting hundreds of warning messages like the 
following:


2014-10-16 10:43:03.178 osacompile[23932:90b] CFPreferences: user 
home directory at file://localhost/opt/local/var/macports/home/ is 
unavailable. User domains will be volatile.



2014-10-16 10:43:02.413 qmake[23922:903] CFPreferences: user home 
directory at file://localhost/opt/local/var/macports/home/ is 
unavailable. User domains will be volatile.


Note that there is no /op/local hierachy on this 'machine'; only 
/opt/dvr.  This is an OS X 10.6.8 Server virtual machine under 
Parallels Desktop with XCode 3.2.6.


So far, the build seems to have finished successully but I'm not at 
the stage of testing functionality, yet.


I have no idea where these messages are coming from.  They reference 
qmake and osacompile.  Are these harmless?  Have I missed a setting? 
A few months ago, I built I built a copy of Myth in a similar 
(non-standard) prefix and didn't experience these warnings.


Full build log attached for the terminally curious.  Messages start 
at line 3426.


Craig

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

Re: CFPreferences warnings

[Craig Treleaven]

At 6:12 PM +0200 10/16/14, Rainer Müller wrote:

On 2014-10-16 17:30, Craig Treleaven wrote:

 I'm working on a new version of MythTV and building in a non-standard
 prefix (/opt/dvr).  I'm getting hundreds of warning messages like the
 following:


 2014-10-16 10:43:03.178 osacompile[23932:90b] CFPreferences: user home
 directory at file://localhost/opt/local/var/macports/home/ is
 unavailable. User domains will be volatile.




 2014-10-16 10:43:02.413 qmake[23922:903] CFPreferences: user home
 directory at file://localhost/opt/local/var/macports/home/ is
 unavailable. User domains will be volatile.


The path probably comes from the home directory of the macports user
that is used for privilege separation in several phases of the build
process of a port.

$ dscl . -read /Users/macports NFSHomeDirectory
NFSHomeDirectory: /opt/local/var/macports/home


Yes, that's it!


You macports user was added by a previous installation in the default
prefix. I suppose these messages are harmless, but you could change it
to the home directory in the prefix you are using.


Shoot, that's right.  I brainlessly ran the .dmg 
installer for MacPorts and immediately realized 
my error and deleted the /opt/local hierarchy. 
The macports user survived, however.


Did the following to change the value:

$ sudo dscl . -change /Users/macports 
NFSHomeDirectory /opt/local/var/macports/home 
/opt/dvr/var/macports/home


Hopefully that will quiet the blather!

Craig
(Keynote time, now.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)

[Craig Treleaven]

Thanks, all.  A conditional patch (... ${os.major} = 13 ...) and at 
least it builds.  I will follow up upstream.


Craig

At 8:43 AM +0100 10/15/14, Chris Jones wrote:
The warning is correct. If s_decoded.name is a boolean then 
s_decoded.name = 12 is always true. OSX10.9 has a newer clang, 
which issues a warning in this case 
(-Wtautological-constant-out-of-range-compare), older OSes have 
older clang versions that do not. Finally -Werror turns it into an 
error.


So basically its a bug in the code which should be reported upstream 
to get fixed.

On 15/10/14 02:22, Craig Treleaven wrote:

At 2:39 PM -0700 10/14/14, nore...@macports.org wrote:

The Buildbot has detected a failed build on builder
buildports-mavericks-x86_64 while building MacPorts.
Full details are available at:
 http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702


Can some kind person (Jeremy?) help me understand why the version of
Clang on the Mavericks buildbot is falling over while the Lion and
MtnLion versions don't even spit a warning?

Mavericks Clang errors out with the following:

test_dr.c:49:3: error: comparison of constant 12 with expression of type
'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
   BOZO_end_boolean(b_multiple_frame_rate)
   ^~~
./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean'
 } while(!i_err  (s_decoded.name = 12));  \
~~ ^  ~~
(Complete log from the Mavericks buildbot attached.)

If I understand correctly (always dicey given I'm not a C developer),
this is a unit test with (I guess) an awkward construct. The thing is,
Clang on MtnLion doesn't complain at all on the same code.

What would be the best way to get past this?

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

Re: [126702] trunk/dports/devel/libdvdread/Portfile

[Craig Treleaven]

At 9:37 PM -0500 10/13/14, Ryan Schmidt wrote:

  On Oct 13, 2014, at 9:33 PM, ctrelea...@macports.org wrote:
[...]
  -configure.cmd   ./autogen.sh

 +configure.args-append   --disable-silent-rules


Since you're no longer using configure.cmd ./autogen.sh, do you 
still need depends_build port:autoconf port:automake port:libtool?



Good point, I'll test tomorrow...

Craig

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

Re: [MacPorts] #45311: Error: org.macports.build for port ttf2pt1 returned: command execution failed

[Craig Treleaven]

At 2:08 PM + 10/9/14, MacPorts wrote:

#45311: Error: org.macports.build for port ttf2pt1 returned: command execution
failed
-+
  Reporter:  asnedden@Š  |  Owner:  macports-tickets@Š
  Type:  defect  | Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |Version:  2.3.1
Resolution:  |   Keywords:  tt2pt1
  Port:  tt2pt1  |
-+

Comment (by asnedden@Š):

 I guess this may be useless since there isn't a maintainer...

--
Ticket URL: https://trac.macports.org/ticket/45311#comment:1


Plus upstream hasn't had a release since 2003!!

However, if there is any hope of addressing this, 
we'll need a clean build log.  Enter:


sudo port clean ttf2pt1  sudo port install ttf2pt1

If it fails again, the last few lines of output 
will tell you the location of the build log.


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

Re: MacPorts-MySQL Dictator wanted, prefer benevolent

[Craig Treleaven]

At 3:07 PM -0500 9/30/14, Ryan Schmidt wrote:

On Sep 30, 2014, at 10:37 AM, Craig Treleaven wrote:
  By way of background, my MythTV ports depend on p5.16-dbd-mysql, 
py27-mysql and php-5-mysql.  Previously, all of these defaulted to 
the now-obsolete mysql5 variant.  Now, py-mysql defaults to 
mariadb55.  p516-dbd-mysql offers a mariadb variant; not 
mariadb55.  php5-mysql defaults to mysqlind (MySQL native 
driver) and offers a mariadb variant; again not mariadb55. 
p5.16-dbd-mysql still defaults to mysql5.


 The subtle variance in naming the variants creates confusion.  The 
range of defaults can lead to bloat and confusion.


 Initially, I found there was a ticket related to py-mysql database 
variants [1] and I filed additional tickets for php5-mysql [2] and 
p5-dbd-mysql [3].  Since then, I thought to search for other ports 
that offer variants related to MySQL ('port echo 
variant:mysql*')--a total of 89 ports, of which about 20 are 
subports.




I've refined my list a little and I've found 83 ports that offer 
variants related to MySQL-compatible databases, see attached pdf. 
The chart lists all the current variant names; a 1 indicates that a 
particular port offers that a variant with that name.


  The tickets have been open for 6 weeks or more with no movement. 
I've started to do some analysis on this (with another thread asking 
for help) to see if we can standardize on a list of MySQL-related 
variant names and maybe even agree on a common default.

 
 That's where the dictator comes in.  At the moment, I would say 
the obvious choices for a default MySQL variant would be mysql55, 
mariadb55 or, maybe, mysql56.  AFAICT there is no clear-cut, 
compelling reason to choose one over the others (technical, legal, 
religious, whatever).  Other threads have touched on this issue, 
recently, with no clear consensus developed.  Nonetheless, I think 
the MacPorts project would be better served by blessing one that 
can hold us for a few years rather than have various ports going in 
all different directions.


 Is this something that the PortMgr group could take the lead on?


Indeed we have discussed this before, and it was proposed that the 
latest stable MariaDB version should be the default variant of ports 
that have MySQL support.


I don't think we can or should select a default to last us for 
years. We don't want to stagnate like we did with the +mysql5 
variant. Rather, we should let the latest stable version be the 
default, and update ports as needed.


Currently, the latest stable version of MariaDB is 10.0.


Really?  Has MariaDB 10.0 really been sufficiently exercised in the 
OS X environment to become the default?  Currently, not a single port 
that I've identified even offers mariadb-10.0 as a variant.  Only 4 
ports in my list currently default to mariadb or mariadb55:


PortDefault Variant
akonadi mariadb55
amarok  mariadb55
py24-mysql  mariadb55
py25-mysql  mariadb55
py26-mysql  mariadb55
py27-mysql  mariadb55
qore-mysql-module   mariadb


The question is what to name the variants. This has also been 
brought up for discussion before. My most recent thread on the topic 
from 2 weeks ago got no replies on the list; perhaps I was too wordy.


My suggestion was that using dots in version numbers, but no 
underscores, would be the cleanest and most informative, which would 
make the complete list of proposed MySQL variant today: +mariadb5.5, 
+mariadb10.0, +mariadb10.1, +mysql5.1, +mysql5.5, +mysql5.6, and 
+percona5.6.


Adopting this format means renaming every variant of every affected port.

This may also break the upgrade path for existing installs, no?  We 
really should keep legacy-named variants for a period of time along 
with the new standard which leads to an explosion of variants for 
some ports.  For example, apr-util currently has mariadb, mysql5, 
mysql51, mysql55, mysql56, and percona variants related to db 
selection.  We'd have to keep those 6 and add at least 6 more (maybe 
8 if maridb10.0 and mariadb10.1 are supported).


Perhaps we* could control the explosion of variants by creating a new 
Portfile contruct:  legacy-variant.  It might act just like the 
current variant declaration except that it would be invisible to 
'port info' and 'port variants'.  Users wouldn't normally see the 
legacy-variants thus reducing the temptation to keep using them.  If 
necessary, perhaps they could be displayed by passing the -v or -d 
flags to port.


Craig

* By we, I mean someone more clever than me!

MacPorts_MySQL_Variants_2014Oct1.xlsx.pdf
Description: Binary data
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

MacPorts-MySQL Dictator wanted, prefer benevolent

[Craig Treleaven]

By way of background, my MythTV ports depend on p5.16-dbd-mysql, 
py27-mysql and php-5-mysql.  Previously, all of these defaulted to 
the now-obsolete mysql5 variant.  Now, py-mysql defaults to 
mariadb55.  p516-dbd-mysql offers a mariadb variant; not 
mariadb55.  php5-mysql defaults to mysqlind (MySQL native driver) 
and offers a mariadb variant; again not mariadb55. 
p5.16-dbd-mysql still defaults to mysql5.


The subtle variance in naming the variants creates confusion.  The 
range of defaults can lead to bloat and confusion.


Initially, I found there was a ticket related to py-mysql database 
variants [1] and I filed additional tickets for php5-mysql [2] and 
p5-dbd-mysql [3].  Since then, I thought to search for other ports 
that offer variants related to MySQL ('port echo variant:mysql*')--a 
total of 89 ports, of which about 20 are subports.


[1] https://trac.macports.org/ticket/39068
[2] https://trac.macports.org/ticket/44481
[3] https://trac.macports.org/ticket/44484

The tickets have been open for 6 weeks or more with no movement. 
I've started to do some analysis on this (with another thread asking 
for help) to see if we can standardize on a list of MySQL-related 
variant names and maybe even agree on a common default.


That's where the dictator comes in.  At the moment, I would say the 
obvious choices for a default MySQL variant would be mysql55, 
mariadb55 or, maybe, mysql56.  AFAICT there is no clear-cut, 
compelling reason to choose one over the others (technical, legal, 
religious, whatever).  Other threads have touched on this issue, 
recently, with no clear consensus developed.  Nonetheless, I think 
the MacPorts project would be better served by blessing one that can 
hold us for a few years rather than have various ports going in all 
different directions.


Is this something that the PortMgr group could take the lead on?

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

OT: sed/awk pointers needed

[Craig Treleaven]

tl;dr version:
How do I transform a listing like this:

$ port variants php53-mysql php54-mysql |grep -v conflicts |grep -e 
mariadb -e mysql -e percona | cut -d : -f 1

php53-mysql has the variants
   mariadb
   mysql4
   mysql5
   mysql51
   mysql55
   mysql56
[+]mysqlnd
   percona
php54-mysql has the variants
   mariadb
   mysql4
   mysql5
   mysql51
   mysql55
   mysql56
[+]mysqlnd
   percona

into:

php53-mysql   mariadb N
php53-mysql   mysql4 N
php53-mysql   mysql5 N
php53-mysql   mysql51 N
php53-mysql   mysql55 N
php53-mysql   mysql56 N
php53-mysql   mysqlnd Default
php53-mysql   percona N
php54-mysql   mariadb N
php54-mysql   mysql4 N
php54-mysql   mysql5 N
php54-mysql   mysql51 N
php54-mysql   mysql55 N
php54-mysql   mysql56 N
php54-mysql   mysqlnd Default
php54-mysql   percona N


I have only rudimentary acquaintance with sed and less with awk.  I'd 
like to learn more and this seemed like an opportunity to do so. 
From some reading [1], I think sed's Hold buffer is the way to 
extract the port name and insert it onto the line with each of the 
variants.  But the tutorial only uses the hold buffer for full lines; 
not just, say, the first word of the line.  Is this possible?  How 
does one do that?


[1] http://www.grymoire.com/Unix/Sed.html#uh-52

Or maybe I'm barking up the wrong tree?  Is there another 
tool/technique that is better suited?


Thanks in advance,

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

Re: OT: sed/awk pointers needed

[Craig Treleaven]

At 2:27 PM -0400 9/30/14, Lawrence Velázquez wrote:

On Sep 30, 2014, at 12:00 PM, Brandon Allbery allber...@gmail.com wrote:

 On Tue, Sep 30, 2014 at 11:44 AM, Craig 
Treleaven ctrelea...@macports.org wrote:
 I have only rudimentary acquaintance with sed 
and less with awk.  I'd like to learn more and 
this seemed like an opportunity to do so. From 
some reading [1], I think sed's Hold buffer is 
the way to extract the port name and insert it 
onto the line with each of the variants.  But 
the tutorial only uses the hold buffer for 
full lines; not just, say, the first word of 
the line.  Is this possible?  How does one do 
that?


 Very, very painfully. I think I could do it, 
with a LOT of fiddling, but would very much 
prefer to use a more appropriate tool. awk is 
somewhat better, but I'd reach for 
perl/python/ruby first.


Yup. Sed is not a great tool for this sort of 
thing; the functionality it provides is 
ill-suited for complex conditionals and 
branching. You'll regret writing the script as 
soon as you go to read/edit it in a week or 
month.


vq

--8--

That being said, I have masochistic tendencies.

% port variants php53-mysql php54-mysql | sed -nf variants.sed
php53-mysql mariadb N
php53-mysql mysql4  N
php53-mysql mysql5  N
php53-mysql mysql51 N
php53-mysql mysql55 N
php53-mysql mysql56 N
php53-mysql mysqlnd Default
php53-mysql percona N
php54-mysql mariadb N
php54-mysql mysql4  N
php54-mysql mysql5  N
php54-mysql mysql51 N
php54-mysql mysql55 N
php54-mysql mysql56 N
php54-mysql mysqlnd Default
php54-mysql percona N
%


Attachment converted: Macintosh HD:variants.sed (/) (0342ACEF)


Thank you!  Off list, I was pointed to a sample 
Awk program* that reformats a 'billing report'. 
That helped; you've given me a complete solution!


* http://www.programmingforums.org/post226750.html

APL used to have the reputation as a write-only 
language.  This script is pretty close to that 
ideal.  ;)


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

Re: OT: sed/awk pointers needed

[Craig Treleaven]

At 2:27 PM -0400 9/30/14, Lawrence Velázquez wrote:

On Sep 30, 2014, at 12:00 PM, Brandon Allbery allber...@gmail.com wrote:
  On Tue, Sep 30, 2014 at 11:44 AM, Craig 
Treleaven ctrelea...@macports.org wrote:
  I have only rudimentary acquaintance with 
sed and less with awk.  I'd like to learn more 
and this seemed like an opportunity to do so. 
[...]

 
  Very, very painfully. I think I could do it, 
with a LOT of fiddling, but would very much 
prefer to use a more appropriate tool. awk is 
somewhat better, but I'd reach for 
perl/python/ruby first.


[vq's sed version deleted ...]


As I said, it was a learning exercise and I've 
got a working version with gawk.  (Awk lacks the 
sub()/gsub() string functions.)


My version is:

-cut from here---
# identify port name lines by the phrase  has the variants
/ has the variants/ {
 portname = $1
 next
}

# deal with the default variant lines, they start with [+]
# (which is a crazy string to match with a regex)
# note that the regex in the pattern match and the sub() function are
# (must be) wildly different!
/^\[+./ {
  sub(\\[\\+.,)
  print portname ,   $1 ,  Default
  next
}

# All the other variant lines start with 3 spaces, followed by a lower case
# variant name
/^   [a-z]/ {
  print portname ,   $1 ,  N
  next
}
-to here

And it works as follows:
$ port variants php53-mysql php54-mysql |grep -v 
conflicts |grep -e mariadb -e mysql -e percona | 
cut -d : -f 1 | gawk -f rejig.awk -

php53-mysql, mariadb, N
php53-mysql, mysql4, N
php53-mysql, mysql5, N
php53-mysql, mysql51, N
php53-mysql, mysql55, N
php53-mysql, mysql56, N
php53-mysql, mysqlnd, Default
php53-mysql, percona, N
php54-mysql, mariadb, N
php54-mysql, mysql4, N
php54-mysql, mysql5, N
php54-mysql, mysql51, N
php54-mysql, mysql55, N
php54-mysql, mysql56, N
php54-mysql, mysqlnd, Default
php54-mysql, percona, N

Now to see if I can actually run this against the 
89 ports that appear to have mysql-related 
variants...


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

Re: Configuration and environment check command (was: Re: [124047] trunk/base)

[Craig Treleaven]

 On Aug 25, 2014, at 6:35 AM, Rainer Müller rai...@macports.org wrote:
 
 However, I am not too happy with naming the command 'port doctor'. Many
 other commands used with port(1) are verbs, but using this as a verb
 carries the wrong message.
 
 I know where the naming comes from, but there is no need to match any
 other terminology and we should rather define our own coherent names.
 
 My proposal would be to rename this to 'port selfcheck' instead.
 
 I second the proposal. Selfcheck is a bit awkward, but it does parallel 
 selfupdate nicely.
 
 Anything would be better than doctor, which is transparently derivative.

'port selfexam' ?
'port sefldiagnose' ?

Just kidding, but they play on the medical theme...

Craig

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

Re: Perl changes (+ please wait a bit with commits in perl modules if possible)

[Craig Treleaven]

At 8:32 AM -0700 8/12/14, David Evans wrote:

On 8/12/14 8:23 AM, Ryan Schmidt wrote:

 On Aug 12, 2014, at 10:20 AM, David Evans dev...@macports.org wrote:

 On 8/12/14 8:06 AM, Ryan Schmidt wrote:

 On Aug 12, 2014, at 9:56 AM, Mojca Miklavec mo...@macports.org wrote:

 Now about 5.8-5.16: my idea was to initially set the INC path for
 those versions in such a way that it would include
 5.16.3/darwin-thread-multi-2level 5.16.3
 5.16.1/darwin-thread-multi-2level 5.16.1
 5.16.0/darwin-thread-multi-2level 5.16.0 as well as the plain
 something/5.16/something without the subrelease. That means that
 there would initially be no urgent need to revbump all the  1000
 ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
 would make sure to revbump all p5.18-foo ports.)

 But I'm unable to figure out how to patch Perl to do that. The INC
 path additions seem to be ignored.

 Why handle = 5.16 differently than = 5.18?



 Because we want them to go away? Or is the effort to do them all
 relatively trivial?


 My assumption was that since a patch is already in place for 
perl5.20 and perl5.18 it could be backported to earlier versions 
with minimal effort, and that since Mojca plans a revbump of all 
perl modules anyway, before that mass revbumping would be the ideal 
time to do that.




Agreed.  If the effort is trivial it doesn't make much difference.  But
if we want to drop some branches then why bother with them?  For
instance, IMO we could drop 5.8 and 5.10.  And 5.12 as soon as the
remaining ports that depend on it are fixed.  Then 5.14.  I don't think
we can get rid of 5.16 until either 5.18 5.20 or both have the same
coverage and we're ready to switch to a new default.

But again this depends on where we are going?

Ryan, as a member of the executive branch ;-), do you have a method to
come up with a final decision on the direction for perl?  I think it's
all been discussed more than enough.


Is there data coming in through mpstats that could help with this 
decision?  What is the distribution of perl installs by version?


Craig

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

Database bindings

[Craig Treleaven]

Hi:

My myth* ports need Perl, Python and Php bindings to the database. 
Up to now, I've used mysql5 for the database and the relevant ports 
for the bindings defaulted to the same--life was good!  But all good 
things change and we want to phase out mysql5.  Now...life is a 
little less good.


The 'binding' ports are:

py27-mysql
variants  [+]mariadb55, mysql4, mysql51, mysql55, mysql56, percona55

p5.16-dbd-mysql
variants  mariadb, mysql4, [+]mysql5, mysql51, mysql55, percona

php54-mysql
variants  mariadb, mysql4, mysql5, mysql51, mysql55, mysql56, 
[+]mysqlnd, percona


Issues:
py-mysql and p-dbd-mysql default to different databases.

There are inconsistencies in the naming of the maria and percona 
variants:  mariadb55 v. mariadb and percona55 v. percona.


p5-dbd-mysql doesn't offer a mysql56 variant.

Now that we have maria10.0 and maria10.1 ports, should we not have 
matching variants -- maria, maria10.0 and maria10.1?



From my point of view, it would be ideal if these bindings were 
subports instead of variants so that I can ensure that users get the 
right bindings.  Either that or MacPorts needs to pick one database 
and version as THE ONE.  I know this has been debated but (to my 
knowledge) not resolved.


Thoughts?

Craig
PS I think Ruby has similar issues; maybe others.  Thank God I don't 
have any more bindings to mess with.

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

Re: [121029] trunk/dports/multimedia

[Craig Treleaven]

+platform darin {


Both audacious-core and audacious-plugins contain this line.  I think 
you darwin.


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

Re: Permissions change with MacPorts 2.3?

[Craig Treleaven]

At 11:02 PM +0200 6/3/14, Clemens Lang wrote:

Hi,


 I sometimes use EasyFind to search in portfiles.  I noticed today
 that the macports folder under ${prefix}/var is no longer visible.  I
 would guess this happened after I upgraded to MacPorts 2.3 but I
 can't be certain.  Using the command line, I see the following:
 [Š]
 Was it an intended change to hide this directory?  Or a glitch on my system?


That was intentional. In specific, it's this Changelog entry:

  Disable Spotlight indexing on build directories, distfiles,
  registry, log files, archives, base source and the default ports
  tree. (cal in r113649)

You can avoid this by manually reverting the change and touching a file
named .nohide in the directory. See
  http://trac.macports.org/changeset/113649


Thanks.  I noticed that in the change log but 
didn't see how it was implemented.


Based on some searching (ie no hands-on 
experience!), it seems that it might be simpler 
to create a .metadata_never_index file [1] 
inside that folder to encourage Spotlight to 
leave it alone.  Alternatively, we could add 
.noindex to the folder name to achieve the same 
effect.


Wouldn't one of these be a better solution?

Craig

[1] 
http://apple.stackexchange.com/questions/92784/preventing-spotlight-from-indexing-files-folders

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

mpkg missing daemondo?

[Craig Treleaven]

Hi:

I'm testing building a installer using 'port mpkg blah' where blah 
has a depends_run on mysql5-server.  The /Library/LaunchDaemons 
/org.macports.mysql5.plist soft link is present but 
${prefix}/bin/daemondo is not.  Obviously, launchctl can't start the 
database without it.


Have I done something wrong or is this a bug in mpkg?

Craig

--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054  ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpkg missing daemondo?

[Craig Treleaven]

At 4:41 PM +0200 5/9/14, Clemens Lang wrote:

Hi,


 I'm testing building a installer using 'port mpkg blah' where blah
 has a depends_run on mysql5-server.  The /Library/LaunchDaemons
 /org.macports.mysql5.plist soft link is present but
 ${prefix}/bin/daemondo is not.  Obviously, launchctl can't start the
 database without it.

 Have I done something wrong or is this a bug in mpkg?


Bug in mpkg, daemondo is installed by MacPorts base and not packaged
with mpkg.


Ticket created:  https://trac.macports.org/ticket/43648

Is there any workaround for the time being?

Craig

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

Re: compiler.blacklist

[Craig Treleaven]

At 10:28 PM -0500 5/3/14, Ryan Schmidt wrote:

On May 3, 2014, at 07:28, Craig Treleaven wrote:

 At 8:34 PM -0500 5/2/14, Ryan Schmidt wrote:

 On May 2, 2014, at 20:20, Craig Treleaven wrote:


 For my mythtv-core.xx ports, I want to blacklist clang prior to 
XCode 5, so I added:


 compiler.blacklist-append { clang = 500.2.79 } \

 macports-clang*


 That doesn't work when I build on Lion with XCode 4.3.3 (clang 
318.0.61)--it tries to build with clang and falls over.


 That sounds like you may not have included the 
compiler_blacklist_versions 1.0 portgroup. If you do that, it 
should do what you say: blacklist all MacPorts clangs, and Xcode 
clangs less than 500. So on Macs with Xcode 4 or earlier, you'll 
be building with llvm-gcc-4.2 or gcc-4.2. Is that really what you 
want? If Xcode 5's clang is ok, presumably MacPorts clang 3.5 
would work too, maybe even 3.4, and those would probably be 
preferable to the old llvm-gcc or gcc.


 You are indeed correct; the line to add the 
compiler_blacklist_versions portgroup got dropped somewhere along 
the way.  And the buildbots were down when the change was committed.


 Is this something that lint could be made to pick up?  ie a 
compiler version comparison used but required PortGroup missing?


Good idea. Done in r119714.

Ultimately the workings of the compiler_blacklist_versions portgroup 
should be incorporated into base instead.



 Pre-XCode 5, Myth builds and runs fine with gcc and llvm-gcc.  The 
the upstream project only recently put in some fixes that allow it 
to build with later versions of clang.


 Re MacPorts-supplied versions of clang, I simply haven't tried to 
build with them.  I cribbed that section from qt4-mac port since it 
had the same issue with LIBRARY_PATH that I had.  The 
'macports-clang*' exclusion is probably extraneous but I wanted to 
be sure to use know-working compilers, only.


There may be some small difference between MacPorts clang and Xcode 
clang, but the primary difference is the version numbering.


According to our XcodeVersionInfo wiki page, Xcode 5.0 came with 
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn). 
LLVM 3.3svn means that this version corresponds to some version of 
LLVM that is greater than 3.3 and less than 3.4. So if you already 
know that Xcode 5's clang works, and earlier Xcodes' clangs don't 
work, then you also know that MacPorts clang 3.3 and earlier won't 
work either, and MacPorts clang 3.4 and later should work.


Thanks, I'll add this to the list of things to test.  I'm a bit 
gunshy about compilers.  After XCode 4.4 came out, the port would 
compile with certain compilers but threw runtime failures (seemingly 
deep in libunwind).  I never did find the cause of the problem, but 
with help, we found certain combinations that worked and stuck with 
them.  Don't want to re-awaken the monsters!  ;)


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

Re: compiler.blacklist

[Craig Treleaven]

At 8:34 PM -0500 5/2/14, Ryan Schmidt wrote:

On May 2, 2014, at 20:20, Craig Treleaven wrote:


 For my mythtv-core.xx ports, I want to blacklist clang prior to 
XCode 5, so I added:


 compiler.blacklist-append { clang = 500.2.79 } \

 macports-clang*


 That doesn't work when I build on Lion with XCode 4.3.3 (clang 
318.0.61)--it tries to build with clang and falls over.


That sounds like you may not have included the 
compiler_blacklist_versions 1.0 portgroup. If you do that, it should 
do what you say: blacklist all MacPorts clangs, and Xcode clangs 
less than 500. So on Macs with Xcode 4 or earlier, you'll be 
building with llvm-gcc-4.2 or gcc-4.2. Is that really what you want? 
If Xcode 5's clang is ok, presumably MacPorts clang 3.5 would work 
too, maybe even 3.4, and those would probably be preferable to the 
old llvm-gcc or gcc.


You are indeed correct; the line to add the 
compiler_blacklist_versions portgroup got dropped somewhere along the 
way.  And the buildbots were down when the change was committed.


Is this something that lint could be made to pick up?  ie a compiler 
version comparison used but required PortGroup missing?


Pre-XCode 5, Myth builds and runs fine with gcc and llvm-gcc.  The 
the upstream project only recently put in some fixes that allow it to 
build with later versions of clang.


Re MacPorts-supplied versions of clang, I simply haven't tried to 
build with them.  I cribbed that section from qt4-mac port since it 
had the same issue with LIBRARY_PATH that I had.  The 
'macports-clang*' exclusion is probably extraneous but I wanted to be 
sure to use know-working compilers, only.


Thanks again,

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

compiler.blacklist

[Craig Treleaven]

Hi:

For my mythtv-core.xx ports, I want to blacklist clang prior to XCode 
5, so I added:


compiler.blacklist-append { clang = 500.2.79 } \
macports-clang*

That doesn't work when I build on Lion with XCode 4.3.3 (clang 
318.0.61)--it tries to build with clang and falls over.


Looking at a bunch of Portfiles that use compiler blacklist, there 
seem to be two approaches used about equally:


{clang  425} eg webkit-gtk, and

{clang  425.0.24} eg mpd

If I change my test to { clang  500 }, is it going to work right?

Thanks,

Craig
(Yes, I'm rather TCL-challenged.  ;)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Buildbots offline?

[Craig Treleaven]

For about 24 hours, I get a 503 Service Temporarily Unavailable 
message trying to access https://build.macports.org/


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

Re: [119433] trunk/dports/devel/akonadi/Portfile

[Craig Treleaven]

 mysql55 mysql56 mariadb percona \
+   conflicts mysql51 mysql55 mysql56 mariadb55 percona55 \
description {Use sqlite backend instead of MySQL} {

depends_lib-append  port:qt4-mac-sqlite3-plugin 
@@ -175,9 +171,9 @@

 }

 if {![variant_isset mysql5]  ![variant_isset mysql51]  
![variant_isset mysql55] \
- ![variant_isset mysql56]  ![variant_isset mariadb]  
![variant_isset percona] \
+ ![variant_isset mysql56]  ![variant_isset mariadb55]  
![variant_isset percona55] \

  ![variant_isset sqlite]} {
-default_variants +mysql5
+default_variants +mariadb55
 }

 post-patch {


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



--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054  ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [119433] trunk/dports/devel/akonadi/Portfile

[Craig Treleaven]

But mysql5-server and mysql51-server use different directories for 
their data, respectively:


/opt/local/var/db/mysql5
/opt/local/var/db/mysql51

I guess it then depends on which copy of mysqld the user is running 
and how the app communicates with the database?


Craig
(Early on, I ended up with both mysql5 and mysql51 installed.  I was 
thoroughly confused by the subtle difference.)


At 12:10 AM +0900 4/26/14, Nicolas Pavillon wrote:

Hello,

I think there is a small misunderstanding about what I committed. 
You have a fully valid point, which has been discussed briefly in 
the ticket, but users will not be forced to change database at this 
stage with this commit. While the new default variant is mariadb (so 
that new installs will go with it), users with an existing port with 
the +mysql5 variant are upgraded with the mysql51 variant, which 
implies that the database stays the same.


Cheers,

Nicolas

On Apr25, 2014, at 22:31, Craig Treleaven ctrelea...@cogeco.ca wrote:

 Since you've gone first, could I ask what are you doing for legacy 
data?  Perhaps I'm missing something, but someone that has been 
using akonadi with mysql5 and then upgrades the port will then get 
mariadb installed and akonadi configured to use that, instead.  No? 
But mariadb will not contain the user's (presumably) valuable 
data--which is pretty jarring.


 The user will need to:

 1) use  /opt/local/lib/mysql5/bin/mysqldump,
 2) shut down the mysql5 server,
 3) (a) initialize and, (b) start up the mariadb server, and
 4) use mariadb's utility to load the data.
 5) Possibly have to reapply any database config tweaks they 
previously set up.


 I know that the legacy mysql5 port needs to be retired but it 
seems like we're going to make existing users jump through a bunch 
of hoops to get there.


 I'm not trying to pick on nicos...just trying to see that the 
implications are understood.  In a lot of ways, the akonadi port is 
similar to my situation with the mythtv* ports.  Most users don't 
care what database is used.  They installed the port because it 
does something useful.  Forcing them to upgrade their database 
doesn't enhance that utility; it just creates work to get back to 
where they were before.


 Craig


 At 5:47 AM -0700 4/25/14, ni...@macports.org wrote:

 Revision

 https://trac.macports.org/changeset/119433119433
 Author

 ni...@macports.org
 Date

 2014-04-25 05:47:30 -0700 (Fri, 25 Apr 2014)

 Log Message

 akonadi: upgrade to 1.12.1
 make variant mysql5 obsolete (replaced by mysql51)
 make mariadb55 default variant
 rename mariadb and percona variants with numbers (ticket #43431)

 Modified Paths

 trunk/dports/devel/akonadi/Portfile
 Diff

 Modified: trunk/dports/devel/akonadi/Portfile (119432 = 119433)


 --- trunk/dports/devel/akonadi/Portfile	2014-04-25 12:08:04 
UTC (rev 119432)
 +++ trunk/dports/devel/akonadi/Portfile	2014-04-25 12:47:30 
UTC (rev 119433)

 @@ -6,7 +6,7 @@
 PortGroup   compiler_blacklist_versions 1.0

 nameakonadi
 -version 1.12.0
 +version 1.12.1
 categories  devel kde kde4
 maintainers nicos openmaintainer
 license LGPL-2+
 @@ -18,8 +18,8 @@
 master_siteskde:stable/${name}/src/
 use_bzip2   yes

 -checksums   rmd160  bc47b87f8f228d0a8cf8d180d742c65ed1ce4dd0 \
 -sha256 
35243793b73e8028973c101c68ef80a8a54be0fe9aa562c9473e73b4657fea26

 +checksums   rmd160  6e486f4a39948af6f470b652bf3223de75af5e53 \
 +sha256 
a073228fda8bdbcf836af32d4b4c44dcbe58a3eac6da4e5a286b42ace9d83145


 depends_lib-append  port:soprano \
 port:boost \
 @@ -105,18 +105,10 @@
 destroot.violate_mtree  yes
 }

 -variant mysql5 \
 -   conflicts sqlite mysql51 mysql55 mysql56 mariadb percona \

  -   description {build with mysql5 port} {
 +variant mysql5 requires mysql51 description {Legacy 
compatibility variant} {}


 -   depends_lib-append  port:qt4-mac-mysql5-plugin
 -   depends_run-append  port:mysql5-server
 -   configure.args-append   -DDATABASE_BACKEND=MYSQL \
 -   -DMYSQLD_EXECUTABLE=${prefix}/libexec/mysqld
 -}
 -
 variant mysql51 \
 -   conflicts sqlite mysql5 mysql55 mysql56 mariadb percona \
 +   conflicts sqlite mysql55 mysql56 mariadb55 percona55 \
description {build with mysql51 port} {

depends_lib-append  port:qt4-mac-mysql51-plugin
 @@ -126,7 +118,7 @@
 }

 variant mysql55 \
 -   conflicts sqlite mysql5 mysql51 mysql56 mariadb percona \
 +   conflicts sqlite mysql51 mysql56 mariadb55 percona55 \
description {build with mysql55 port} {

depends_lib-append  port:qt4-mac-mysql55-plugin
 @@ -136,7 +128,7 @@
 }

 variant mysql56 \
 -   conflicts sqlite mysql5 mysql51 mysql55 mariadb percona \
 +   conflicts sqlite mysql51 mysql55 mariadb55 percona55 \
description {build with mysql56 port} {

depends_lib-append  port:qt4-mac-mysql56-plugin
 @@ -145,8 +137,10

Re: New MacPorts web site

[Craig Treleaven]

At 10:01 AM -0500 4/7/14, Ryan Schmidt wrote:

Dear fellow MacPorts developers and enthusiasts,

I've been working on a new MacPorts web site for some time, and I 
would like to share with you my work so far:


url: http://macports.ryandesign.com:8080
username: mp
password: 333

It is not yet complete but I hope it gives an idea of the direction 
I'm going, and I very much hope that you like it.


In some areas I tried multiple different page designs; on those 
pages you'll see a widget for selecting among them.


Gentle feedback about what works and what doesn't (both functionally 
and conceptually) and what else you think should be there would be 
helpful; with any luck I'll agree with you. But let's distinguish 
between features which are essential to get to a functional first 
version that we can publish, and those features that would be nice 
to have eventually but which can be postponed until later so as not 
to delay the initial release.


My focus so far has been on the following areas:

 * Make the homepage simple and inviting


Very nice!

Possible tweaks:  The first section of the page takes up half a 
screen on my Mac.  I think it could be a little more compact.  I 
agree that the Lean More and Contribute sections should move to their 
own pages.  Personally, I think the recent port updates section 
should be more prominent.  Shows that the project is active and gives 
a flavour for the software that MacPorts actually provides.


 * Make the install page as simple as possible, providing 
instructions specific to each OS X version


Well done, enormous improvement.

 * Provide a page for each port, containing helpful information 
extracted from the Portfile, logically and attractively presented

 * News
 * Site infrastructure
 * Database

Further work to be done, in no particular order and not necessarily 
before the first release:


 * Further database and import script overhauls (maybe later)
 * Port search, at least equivalent to what ports.php on the current 
web site can do (essential)


Agreed.


 * Port pages:
   * Variants (essential)
   * Licenses (essential)
   * Subports (essential)
   * Distributability and binary package availability (nice to have; 
pretty easy)

   * Version and revision history (nice to have; difficult)


Agreed.


 * Maintainer info pages (later)
 * Category info pages (later)


15 ports per page is too little.  Perhaps make it user-selectable? 
I'd think 25 is the absolute minimum.


However, no one is going to browse the 3,500+ ports in devel.  In the 
badge view it says 2,072.  Does that mean 2,072 where the first 
category is devel; 3,520, have devel somewhere in the list of 
categories?


I think we should have sub-category pages for the high-volume 
categories.  For example, libhttpd has categories {devel www}.  So 
the devel page could lead to a devel/www sub-category with a much 
narrowed list.  Same for perl, python, php,


As ports are updated, we can try to add/modify categories.  There are 
20+ categories with 10 or fewer ports according to the badge view. 
All of these should be pruned.  I'm sure others could be combined, as 
well.


I think each category page could also show the most-requested ports, 
perhaps the top 25.


 * Learn how the new statistics-gathering code in base works and 
integrate with it


To me, the number of reported installs (split between requested and 
installed as a dependency) is interesting.  Perhaps comparing last 
week, last month and last year.  I think there should be a separate 
page with more detailed statistics for each port (by OS, by version, 
etc).




Thanks for all your efforts; it is a huge improvement.

Craig

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

Re: git.macports.org not syncing since 11 March

[Craig Treleaven]

$ telnet git.macports.org 9418
Trying 17.251.224.219...
Connected to git.macports.org.
Escape character is '^]'.
^CConnection closed by foreign host.


At 8:54 AM -0700 4/2/14, Shreeraj Karulkar wrote:
That is odd, we have one Firewall Rule from the 
Internet to git.macports.org for git and it was 
tested successfully.


Can anyone run the following command and send me 
the output. Needs to be done without VPN to any 
of our internal networks.


$ telnet git.macports.org 9418

Shree




On Apr 2, 2014, at 8:48 AM, William Siegrist wsiegr...@apple.com wrote:


 Shree?

 -Bill


 On Apr 2, 2014, at 7:41 AM, David Röthlisberger da...@rothlis.net wrote:


 FYI the git mirror at git.macports.org isn't syncing with the svn
 repository since 11 March. There's a 9-day-old ticket with no activity
 at https://trac.macports.org/ticket/43058

 The last commit is:
 http://svn.macports.org/repository/macports/trunk@117767

 Cheers,
 Dave.

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




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



--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054  ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Error installing MacPorts to alternate prefix

[Craig Treleaven]

At 7:24 PM +0200 4/2/14, Clemens Lang wrote:

...

 Possibly being reckless, I went ahead with the make install...which
 wandered off into the weeds, muttering:

 /opt/local/bin/tclsh src/images_to_archives.tcl
 /opt/dvr/share/macports/Tcl
 can't find package msgcat
  while executing
 package require msgcat
  (file /opt/dvr/share/macports/Tcl/registry2.0/registry.tcl line 40)
  invoked from within
 source /opt/dvr/share/macports/Tcl/registry2.0/registry.tcl
  (package ifneeded registry 1.0 script)
  invoked from within
 package require registry 1.0
  (file src/images_to_archives.tcl line 10)
 make: *** [install] Error 1


That suggests you are building against Tcl 8.6, possibly because you have the
Tcl port installed and didn't remove $prefix from your $PATH while
configuring MacPorts. MacPorts currently doesn't support Tcl 8.6.


Yes, thanks, that would be it.  Perhaps the install instructions [1] 
might mention this?


Craig

[1] http://guide.macports.org/#installing.macports
OR  http://www.macports.org/install.php

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

Re: MacPorts Statistics

[Craig Treleaven]

Branching the subject a little, perhaps, but...

Looking at the statistics page for a particular port, say libpng:

http://stats.macports.neverpanic.de/categories/22/ports/2455

This has a lot of information that a user might be interested in 
before installing a port.  Right now, the port search page on the web 
leads to the Portfile, eg:


https://trac.macports.org/browser/trunk/dports/graphics/libpng/Portfile

which isn't the prettiest advertisement for a piece of software.

To me, the web search should give the potential user enough 
information to decide if whether to install the package or not.  A 
rough draft would be:


=
From Portfile:
-port/subport name  (link to Portfile)
-categories
-version/revision
-long_description
-variants (list with descriptions)
-homepage (as link)
-license
-platforms
-supported_archs
-dependencies (as links to other port pages; bonus marks if it could
link to an rdeps graph!)

From statistics:

# reported installs

-requested/   last week, 1 month ago, 1 year ago
-installed as dependency  /   last week, 1 month ago, 1 year ago
-rank of reported installs, requested, last week:  xxx of 18,312
-link to page with more detailed statistics

From buildbots or package server (if possible):

Dates of most recent builds

-version built   /   Mavericks,  Mtn Lion,  Lion,  Snow Leopard
Eg:
1.2.3_4  yesterday   yesterday  failed unsupported
(indicator if unsuccessful, not supported on that OS)
=

I don't know if the last section is even possible.  Would likely 
require the buildbots to update a database at the end of each build?


Thoughts?

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

Re: [MacPorts] #43088: mysql5 @5.1.72 uses /tmp for socket

[Craig Treleaven]

At 3:03 PM -0700 3/26/14, Bradley Giesbrecht wrote:

On Mar 26, 2014, at 1:44 PM, MacPorts nore...@macports.org wrote:


 Any suggestions on how to get the older machine to behave like the new
 one?  ;)



I would guess you have directives in a my.cnf file somewhere. To 
test this do the following.


sudo port unload mysql5-server
sudo mv /opt/local/etc/mysql5/my{,-old}.cnf


A stray my.cnf was the problem; ticket updated.

Thanks

Craig

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

Re: [116552] trunk/dports/genealogy/gramps/Portfile

[Craig Treleaven]

Thanks for the update!

Would you consider using the app portgroup as in:

https://trac.macports.org/ticket/41681 ?

I find it convenient to have the Gramps launcher on the Dock for 
quick access...


Craig

At 6:06 AM -0800 1/28/14, dev...@macports.org wrote:

Revision

https://trac.macports.org/changeset/116552116552
Author

dev...@macports.org
Date

2014-01-28 06:06:20 -0800 (Tue, 28 Jan 2014)

Log Message

gramps: update to version 3.4.7, update intltool.m4 and autoreconf, notes.

Modified Paths

trunk/dports/genealogy/gramps/Portfile
Diff

Modified: trunk/dports/genealogy/gramps/Portfile (116551 = 116552)


--- trunk/dports/genealogy/gramps/Portfile	2014-01-28 12:52:49 
UTC (rev 116551)
+++ trunk/dports/genealogy/gramps/Portfile	2014-01-28 14:06:20 
UTC (rev 116552)

@@ -4,7 +4,7 @@
 PortSystem  1.0

 namegramps
-version 3.4.6
+version 3.4.7
 license GPL-2
 categories  genealogy python
 platforms   darwin
@@ -21,13 +21,9 @@
 homepagehttp://www.gramps-project.org/
 master_sitessourceforge:gramps

-checksums   rmd160  c73185c34b4bc19b4a3183f916bf7e9908435267 \
-sha256 
50c9020b50dd1e235856254f4f939a5dbf923f5cbce82b45285e31773a27a427

+checksums   rmd160  e7095ce672576698094905296d482b3e87d6d5a8 \
+sha256 
8492c76c7bb6ac1b72684f475d53cb1557b72dc7f1b5666f8b19491e2709a521


-patchfiles  patch-configure.diff
-
-configure.args  --disable-mime-install
-
 depends_build   port:pkgconfig \
 port:intltool \
 port:gnome-doc-utils
@@ -40,6 +36,19 @@
 port:desktop-file-utils \
 path:bin/dot:graphviz

+patchfiles  patch-configure.diff
+
+# update intltool.m4 and autoreconf
+
+post-patch {
+copy -force ${prefix}/share/aclocal/intltool.m4 ${worksrcpath}/m4
+}
+
+use_autoreconf  yes
+autoreconf.args -fvi
+
+configure.args  --disable-mime-install
+
 variant python26 conflicts python27 description {Use python 2.6} {
 depends_lib-append  port:py26-gtkspell \
 port:py26-enchant \
@@ -76,7 +85,7 @@
 When using GRAMPS, be sure to backup your data regularly! GRAMPS 
backups are in XML format.
 XML is machine- and human-readable. It is completely 
self-sufficient. It is also small.


-The following are good practices of backups:
+The following are good backup practices:

 Backup to XML from time to time, especially after large edits.
 Backup to XML before making big changes, such as importing new 
data into an existing database from e.g. GEDCOM,



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



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

Re: [116552] trunk/dports/genealogy/gramps/Portfile

[Craig Treleaven]

Gramps stores everything in its internal database (in ~/.gramps).  No 
double-clickable files.


Craig

At 9:40 AM -0500 1/28/14, Jeremy Lavergne wrote:
If Gramps lets the user tell it which files to open, it might end up 
being more frustrating for users to double click a file and not have 
the application launch.


If it doesn't allow arbitrary files and always stores things on its 
own than this should be fine.


On Jan 28, 2014, at 9:33, Craig Treleaven ctrelea...@cogeco.ca wrote:


 Thanks for the update!

 Would you consider using the app portgroup as in:

 https://trac.macports.org/ticket/41681 ?

 I find it convenient to have the Gramps launcher on the Dock for 
quick access...



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

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

[Craig Treleaven]

Hi Marko:

Yes, that would be expected behaviour.  MacPorts has no way of 
knowing that the link was created so it ends up pointing to a 
now-deleted file after an uninstall.


The real question is:  why would you want to uninstall?!?  ;)

Craig

At 3:19 PM +0100 12/30/13, mk-macpo...@techno.ms wrote:

Hi Craig,

after deinstallation of mythtv-core.27 I realised on 10.9 that 
Myth_Filldatabase and Myth_Frontend stay behind in one of LauchPad's 
MacPorts application folders although they are invalid links.


Is this normal behaviour or a glitch in the deinstallation phase?

Greets,
Marko



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

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

[Craig Treleaven]

At 5:06 PM -0500 12/30/13, Lawrence Velázquez wrote:

On Dec 30, 2013, at 9:57 AM, Craig Treleaven ctrelea...@cogeco.ca wrote:

 Yes, that would be expected behaviour. 
MacPorts has no way of knowing that the link 
was created so it ends up pointing to a 
now-deleted file after an uninstall.


Where do the links come from? Are they created by MythTV at runtime?

If MacPorts' MythTV creates symlinks in 
${applications_dir} at runtime, you should add a 
post-deactivate phase that deletes the symlinks.


Hmmm, Marko said LaunchPad but I was thinking of 
one of the third party launching utilities.  I 
don't actually use Apple's LaunchPad.


http://support.apple.com/kb/HT5548

Myth installs double-clickable Applescript 
helpers that you can drag to the Dock--which 
auto-magically creates a link. What I've 
experienced is that when Myth is uninstalled, the 
link on the Dock remains.  Perhaps LaunchPad is 
doing the same.  The Myth ports DO clean up after 
themselves.


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

Fwd: [114693] trunk/dports/sysutils/macportsscripts/Portfile

[Craig Treleaven]

Hi Eric:

I gave the new version of port-depcheck.sh a try...with VLC, see 
following.  Very different results from the prior version.  As I've 
said, I'm not a C/C++ developer--the prior version reported a bunch 
of false positives due to over-linking?  In layman's terms, what's 
that?


Craig

$ port-depcheck.sh VLC
Finding MacPorts libraries that VLC links against...
/opt/local/Library/Frameworks/BGHUDAppKit.framework/Versions/A/BGHUDAppKit 
is provided by: BGHUDAppKit

/opt/local/lib/libFLAC.8.dylib is provided by: flac
/opt/local/lib/libSDL-1.2.0.dylib is provided by: libsdl
/opt/local/lib/libSDL_image-1.2.0.dylib is provided by: libsdl_image
/opt/local/lib/libX11.6.dylib is provided by: xorg-libX11
/opt/local/lib/libXau.6.dylib is provided by: xorg-libXau
/opt/local/lib/libXdmcp.6.dylib is provided by: xorg-libXdmcp
/opt/local/lib/libXext.6.dylib is provided by: xorg-libXext
/opt/local/lib/libXrandr.2.dylib is provided by: xorg-libXrandr
/opt/local/lib/libXrender.1.dylib is provided by: xrender
/opt/local/lib/liba52.0.dylib is provided by: a52dec
/opt/local/lib/libass.4.dylib is provided by: libass
/opt/local/lib/libavahi-client.3.dylib is provided by: avahi
/opt/local/lib/libavahi-common.3.dylib is provided by: avahi
/opt/local/lib/libavcodec.55.dylib is provided by: ffmpeg
/opt/local/lib/libavformat.55.dylib is provided by: ffmpeg
/opt/local/lib/libavutil.52.dylib is provided by: ffmpeg
/opt/local/lib/libbluray.1.dylib is provided by: libbluray
/opt/local/lib/libbz2.1.0.dylib is provided by: bzip2
/opt/local/lib/libcddb.2.dylib is provided by: libcddb
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
/opt/local/lib/libdc1394.22.dylib is provided by: libdc1394
/opt/local/lib/libdca.0.dylib is provided by: libdca
/opt/local/lib/libdirac_decoder.0.dylib is provided by: dirac
/opt/local/lib/libdirac_encoder.0.dylib is provided by: dirac
/opt/local/lib/libdvdnav.4.dylib is provided by: libdvdnav
/opt/local/lib/libdvdread.4.dylib is provided by: libdvdread
/opt/local/lib/libenca.0.dylib is provided by: enca
/opt/local/lib/libexpat.1.dylib is provided by: expat
/opt/local/lib/libfaad.2.dylib is provided by: faad2
/opt/local/lib/libfontconfig.1.dylib is provided by: fontconfig
/opt/local/lib/libfreetype.6.dylib is provided by: freetype
/opt/local/lib/libfribidi.0.dylib is provided by: fribidi
/opt/local/lib/libgcrypt.11.dylib is provided by: libgcrypt
/opt/local/lib/libgmp.10.dylib is provided by: gmp
/opt/local/lib/libgnutls.28.dylib is provided by: gnutls
/opt/local/lib/libgpg-error.0.dylib is provided by: libgpg-error
/opt/local/lib/libhogweed.2.dylib is provided by: nettle
/opt/local/lib/libiconv.2.dylib is provided by: libiconv
/opt/local/lib/libidn.11.dylib is provided by: libidn
/opt/local/lib/libintl.8.dylib is provided by: gettext
/opt/local/lib/libixml.2.dylib is provided by: libupnp
/opt/local/lib/libjpeg.9.dylib is provided by: jpeg
/opt/local/lib/liblua.dylib is provided by: lua
/opt/local/lib/liblzma.5.dylib is provided by: xz
/opt/local/lib/libmad.0.dylib is provided by: libmad
/opt/local/lib/libmodplug.1.dylib is provided by: libmodplug
/opt/local/lib/libmp3lame.0.dylib is provided by: lame
/opt/local/lib/libmpcdec.5.dylib is provided by: libmpcdec
/opt/local/lib/libmpeg2.0.dylib is provided by: libmpeg2
/opt/local/lib/libncurses.5.dylib is provided by: ncurses
/opt/local/lib/libnettle.4.dylib is provided by: nettle
/opt/local/lib/libogg.0.dylib is provided by: libogg
/opt/local/lib/libopenjpeg.1.dylib is provided by: openjpeg15
/opt/local/lib/libopus.0.dylib is provided by: libopus
/opt/local/lib/liborc-0.4.0.dylib is provided by: orc
/opt/local/lib/libp11-kit.0.dylib is provided by: p11-kit
/opt/local/lib/libpng15.15.dylib is provided by: libpng
/opt/local/lib/libpostproc.52.dylib is provided by: ffmpeg
/opt/local/lib/libsamplerate.0.dylib is provided by: libsamplerate
/opt/local/lib/libschroedinger-1.0.0.dylib is provided by: schroedinger
/opt/local/lib/libspeex.1.dylib is provided by: speex
/opt/local/lib/libspeexdsp.1.dylib is provided by: speex
/opt/local/lib/libssh2.1.dylib is provided by: libssh2
/opt/local/lib/libssl.1.0.0.dylib is provided by: openssl
/opt/local/lib/libswscale.2.dylib is provided by: ffmpeg
/opt/local/lib/libtag.1.dylib is provided by: taglib
/opt/local/lib/libtheoradec.1.dylib is provided by: libtheora
/opt/local/lib/libtheoraenc.1.dylib is provided by: libtheora
/opt/local/lib/libthreadutil.2.dylib is provided by: libupnp
/opt/local/lib/libtiff.5.dylib is provided by: tiff
/opt/local/lib/libtwolame.0.dylib is provided by: twolame
/opt/local/lib/libupnp.3.dylib is provided by: libupnp
/opt/local/lib/libusb-1.0.0.dylib is provided by: libusb
/opt/local/lib/libvlc.5.dylib is provided by: VLC
/opt/local/lib/libvlccore.7.dylib is provided by: VLC
/opt/local/lib/libvorbis.0.dylib is provided by: libvorbis
/opt/local/lib/libvorbisenc.2.dylib is provided by: libvorbis
/opt/local/lib/libx264.136.dylib is provided by: x264
/opt/local/lib/libxcb.1.dylib is 

XCode 5 and c++ libs

[Craig Treleaven]

Hi:

Yet again, I'm well out of my depth and I wonder if those more 
experienced with C++ could further my education.  This is in 
reference to MythTV 0.27 failing to build on Mavericks due to (I 
believe) the switch in standard C++ libraries in XCode 5.


http://trac.macports.org/ticket/41371

Initially, the failure was in one of Myth's internal libs.  Some web 
searching suggested that perhaps adding '-stdlib=libstdc++' to the 
linker flags might help.  Doing that, however, leads to the build 
failing while linking Myth's version of the qjson library, as follows:


/usr/bin/clang++ -headerpad_max_install_names -stdlib=libstdc++ 
-Wl,-dynamic,-search_paths_first -arch x86_64 -single_module 
-dynamiclib -compatibility_version	0.7 -current_version	0.7.1 
-install_name	/opt/local/lib/libmythqjson.0.dylib -Xarch_x86_64 
-mmacosx-version-min=10.9 -o libmythqjson.0.7.1.dylib json_parser.o 
json_scanner.o parser.o parserrunnable.o qobjecthelper.o 
serializer.o serializerrunnable.o moc_parserrunnable.o 
moc_serializerrunnable.o  -F/opt/local/Library/Frameworks 
-F/opt/local/lib  -L/opt/local/lib -F/opt/local/Library/Frameworks 
-F/opt/local/lib -framework QtCore 
Undefined symbols for architecture x86_64:

  std::__1::locale::use_facet(std::__1::locale::id) const, referenced from:
  std::__1::basic_ostreamchar, std::__1::char_traitschar  
std::__1::operatorstd::__1::char_traitschar (std::__1::basic_ostreamchar, 
std::__1::char_traitschar , char const*) in json_parser.o

couple dozen similar lines of errors omitted

I vaguely understand the issue based on a posting by Ryan the other day:

At 6:42 PM -0600 11/26/13, Ryan Schmidt wrote:
What version of OSX? If Mavericks, you may be having the problem 
that you cannot mix software compiled with libc++ (i.e. anything 
compiled with clang) with software compiled with libstdc++ (i.e. 
anything compiled with FSF GCC).


Myth links with 13 libraries provided by MacPorts[1] and includes its 
own copies of 7 other libraries[2].  The error message above relates 
to Myth's copy of qjson which only links with qt4-mac (AFAIK).


Does this mean that if there is a mismatch in the standard C++ libs 
anywhere in the chain of recursive dependencies, it is going to go 
boom?!?  If so, that is an enormous problem for any sizable project, 
no?


Please help me understand this issue better.  Bonus points if you can 
point me towards a solution for Myth!


Craig

[1] Dependencies provided by MacPorts:
 bzip2
 faac
 freetype
 lame
 libass
 libcdio
 libiconv
 libxml2
 openssl
 qt4-mac
 taglib
 x264
 zlib

[2] Dependencies provided with Myth
FFmpeg
libhdhomerun
libmythbluray
libsamplerate
nzmqt
qjson
zeromq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Vote: mysql5 replaced_by ?

[Craig Treleaven]

At 11:02 AM -0800 11/20/13, Bradley Giesbrecht wrote:

On Nov 19, 2013, at 4:58 PM, Ryan Schmidt wrote:



 On Nov 19, 2013, at 15:15, Joshua Root wrote:

 On 2013-11-20 07:45 , Bradley Giesbrecht wrote:

 Popular choices:
 mysql55
 mysql56
 mariadb
 mariadb55 (mariadb replaced_by mariadb55)


 My vote:
 +1 mariadb55


 mysql5 is 5.1, so really the only option is to replace it with mysql51.


 Agreed because the whole reason why we have separate ports for 
different versions of database servers is so that users can do it 
at a time of their choosing, since doing so may necessitate 
upgrading the database structure and/or changing the user's code 
which uses the database.


Ok, just to be clear, replacing mysql5 with mysql51 will likely 
require users to move there database files and config files.


I was going to stay out of this, but...

If mysql5 is going away and work has to be done to affect the change, 
it makes no sense to me to _not_ go with a 5.5 or even 5.6 version 
(be that MySQL or Maria).


Could we not find a way to have a 'mysql-current*'?  There have got 
to be a number of ports that currently depend on MySQL but have no 
fundamental problem with newer versions.  (My mythtv-core.xx ports 
fall in that group.)  The mysql-current port would just provide a way 
of finding the version-specific binaries and libraries. 
mysql-current might point to mysql55 right now and later be updated 
to maria56, or whatever, while being as transparent as possible.


I think the current situation with mysql-compatible databases is a 
support nightmare.  For my ports, I want/need to give users 
cookbook-style instructions for installing Myth.  They have to do 6 
steps to install, initialize, load and prep the database.  If I were 
to support mysql, maria and percona, those instructions would be 
oh-so-subtly-different for each variant.  Already, I get quite a few 
questions where folks mucked up or missed a step.  I don't want to 
compound those issues several-fold!


Craig

*Yes, bad name.  Could be 'mysql-stable', 'mysql-blessed', 
'mysql-with-a-bullet', ...  ;)

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

Re: [113155] trunk/dports/multimedia

[Craig Treleaven]

At 8:47 PM -0600 11/10/13, Ryan Schmidt wrote:

On Nov 10, 2013, at 19:54, pixi...@macports.org wrote:


 Revision
 113155
 Author
 pixi...@macports.org
 Date
 2013-11-10 17:54:29 -0800 (Sun, 10 Nov 2013)
 Log Message

 multimedia/mythweb.27:
 - New port for mythweb.27.

 Added Paths

* trunk/dports/multimedia/mythweb.27/
* trunk/dports/multimedia/mythweb.27/Portfile
* trunk/dports/multimedia/mythweb.27/files/
* trunk/dports/multimedia/mythweb.27/files/patch-mythweb.conf.diff
 Diff

 Added: trunk/dports/multimedia/mythweb.27/Portfile (0 = 113155)



 +depends_run port:php5-mysql


php5- ports have been deprecated for a long time. Could you please 
use php53-mysql, php54-mysql or php55-mysql instead, or even offer 
php53, php54 and php55 variants to let the user choose?


I'm the maintainer; pixilla pointed this out to me as well.  The 
project plans to do away with MythWeb and replace it with a modern 
web frontend an internal http server, hopefully for the next release. 
I will look at updating php in the meantime.


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

Re: Questions on dependencies

[Craig Treleaven]

At 11:48 AM -0500 11/9/13, Jeremy Lavergne wrote:
Myth includes Perl and Python bindings that need a number of 
dependencies to work (eg port:${pymodver}-mysql, 
port:${perlmodver}-dbd-mysql, etc).  I have these listed as 
depends_lib but no Myth binaries link directly to them.  Is it 
advantageous to list them instead as depends_run?


The packages aren't guaranteed to be available during build time if 
it's only a depends_run. You might need them listed in both 
depends_build and depends_run, if the bindings aren't always built.


egall's script says that Myth does not link directly to 
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. 
Again, are there advantages to showing qt4-mac as a depends_lib but 
the plugin as a depends_run?


Again, qt4-mac should definitely be listed as depends_lib, but the 
plugin might need both _run and _build.


Try setting the plugin dependency to _run and deactivate it, then 
build and see if your package still uses it. If so, then the plugin 
isn't needed during _build. If it doesn't work then you need it in 
both _build and _run.


So, in a way, we all use depends_lib for certain things as a 
short-hand for listing stuff as both depends_build and depends_run, 
no?  For example, I was looking at some of the perl modules.  My port 
uses p5.12-libwww-perl which relies on a list of other perl modules. 
Using port-depcheck confirms that no compiled library links.  Of the 
rdeps for p5.12-libwww-perl, only a couple of lower level modules 
appear to link directly to a compiled library, eg p5.12-net-ssleay.


In a perfect world, maybe we should have a depends_mod for 
indicating a dependency on an interpreted module (perl, python, php, 
ruby, ...)?  It would express the relationship more precisely, I 
think.  OTOH, I don't see any particular advantage other than that 
and it would be a tremendous amount of work to got through all 
existing ports and split depends_mod out from depends_lib as 
necessary.  Perhaps just the documentation for depends_lib should be 
expanded to say that it indicates both compiled and interpreted 
linkages?


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

Re: [113128] trunk/dports/multimedia

[Craig Treleaven]

At 8:57 PM -0600 11/9/13, Ryan Schmidt wrote:

On Nov 9, 2013, at 17:29, pixi...@macports.org wrote:


 Revision
 113128
 Author
 pixi...@macports.org
 Date
 2013-11-09 15:29:02 -0800 (Sat, 09 Nov 2013)
 Log Message

 multimedia/mythtv-core.27:
 - New port.



 --- 
trunk/dports/multimedia/mythtv-core.27/files/Myth_Frontend.applescript 
	(rev 0)
 +++ 
trunk/dports/multimedia/mythtv-core.27/files/Myth_Frontend.applescript 
	2013-11-09 23:29:02 UTC (rev 113128)


 @@ -0,0 +1,38 @@

 +(*  Applescript to run 'Unix' version of mythfronted
 +For use with MacPorts install of Myth
 +Author:  Craig Treleaven, ctreleaven at
 cogeco.ca

 +Version: 0.27.0
 +Modified: 2012May15
 +  2012Nov20 -- handle 'thread not shut down error' on 
exit, add --quiet to prevent
 +console output from being returned to AppleScript, 
allow experimental AirPlay
 +  2013Sep25 -- revert logserver stuff, remove AirPlay 
setting that is now unnecessary

 +
 +*)
 +property MFEappPath : /opt/local/bin/mythfrontend


You shouldn't assume the prefix is /opt/local.


Not sure how that one crept in...I'll get a revision put through.

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

Re: Questions on dependencies

[Craig Treleaven]

At 4:27 PM +0100 11/1/13, Clemens Lang wrote:

On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote:

 If they are needed at build time and runtime, use depends_lib. If they
 are only needed at runtime, use depends_run.


is there any difference between listing a package in both depends_build
and depends_run compared to just listing it in depends_lib, e.g. in how
licensing stuff propagates?

Since MacPorts ensures depends_run dependencies are installed before
attempting to build a package, we usually do not notice a depends_run
dependency that should rather be depends_build.

I'm currently trying to improve trace mode to a point where every
package I have installed builds fine using trace mode and I've come
across the gcc ports, which set
  depends_run port:ld64 port:cctools
but fail to configure when trace mode (correctly) hides files installed
by these ports. I wonder whether the correct fix would be to convert
those into depends_lib, or just add them as depends_build, too.


I was playing with egall's port-depcheck.sh script:

https://github.com/cooljeanius/macportsscripts/blob/v0.1.4/port-depcheck.sh

It identified several interesting things in my MythTV ports that I 
hadn't known before--including a couple more opportunistic links 
(Myth is so promiscuous!).


A couple of questions for the more-experienced here.

Myth includes Perl and Python bindings that need a number of 
dependencies to work (eg port:${pymodver}-mysql, 
port:${perlmodver}-dbd-mysql, etc).  I have these listed as 
depends_lib but no Myth binaries link directly to them.  Is it 
advantageous to list them instead as depends_run?


egall's script says that Myth does not link directly to 
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac.  Again, 
are there advantages to showing qt4-mac as a depends_lib but the 
plugin as a depends_run?


I'm not a professional developer; just trying to understand a little more.

Thanks,

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

Re: Compile/Link 101

[Craig Treleaven]

At 11:03 PM -0400 10/4/13, Lawrence Velázquez wrote:

On Oct 4, 2013, at 9:39 PM, Craig Treleaven ctrelea...@cogeco.ca wrote:

 I actually don't know how the test _can 
succeed_ with XCode 5?  There is no '-L' flag 
to indicate that the library is under 
/opt/local/lib.


MacPorts sets the LIBRARY_PATH environment 
variable in the configure phase, which 
sufficiently recent compilers take into account 
when linking. I don't know exactly when Clang 
started respecting it.


Thank you!  From some searching, I found a bug 
report [1] for Qt4-mac related to this problem. 
One comment suggested that XCode = 4.5 and 
clang = 3.1 will respect LIBRARY_PATH.  Can 
someone confirm?


[1] https://trac.macports.org/ticket/37878

BTW, I realize I could set a -L flag in LDFLAGS 
but Myth includes modified versions of FFMPEG, 
dvdnav and a few other libraries.  The contents 
of LDFLAGS gets included early in the link line 
and therefore will try to link against any 
MacPorts-installed versions of these libraries. 
Not surprisingly, that never works out well.  ;)


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

Re: Compile/Link 101

[Craig Treleaven]

Sorry, I'd had a few different tabs open and must 
have pasted the link from the wrong one.


I've bent Michael's ear on this before, but 
Myth's build system is extremely hard for me to 
follow particularly due to QMake.  Different 
platforms get different qmkspec files--which are 
actually a chain of nested include files 
sometimes overriding each other.  I asked about 
this case because none of that was involved...and 
I still didn't understand why XCode 5.0 succeeded 
and XCode 4.3 failed.  At least now, I've got a 
clue.


OTOH, I checked the clang man page under XCode 5 
and it still doesn't mention the LIBRARY_PATH 
environment variable.


Craig

At 3:27 PM -0400 10/5/13, Michael Dickens wrote:

I think Craig is referring to the comment within the Portfile for
qt4-mac, about 2/5 of the way down under Block various compilers.
MacPorts' build of Qt4 requires the use of CPATH and LIBRARY_PATH, and
post-configure I remove any -I${prefix}/lib entries to keep them from
appearing at inappropriate ordering during the build stage. So, I
blacklist all known compilers with this issue; it's the compiler that
makes the difference, much more than the version of XCode (though they
are related). And, during configuration Qt4 checks this property too.  I
think MythTV doesn't do path ordering carefully, but it's been a bit
since I looked at that project. - MLD

On Sat, Oct 5, 2013, at 03:09 PM, Joshua Root wrote:

 On 2013-10-6 00:53 , Craig Treleaven wrote:
  At 11:03 PM -0400 10/4/13, Lawrence Velázquez wrote:
  MacPorts sets the LIBRARY_PATH environment variable in the configure
  phase, which sufficiently recent compilers take into account when
  linking. I don't know exactly when Clang started respecting it.
 
  Thank you!  From some searching, I found a bug report [1] for Qt4-mac
  related to this problem. One comment suggested that XCode = 4.5 and
  clang = 3.1 will respect LIBRARY_PATH.  Can someone confirm?
 
  [1] https://trac.macports.org/ticket/37878

 To which comment are you referring? AFAICT, all that ticket says
 regarding Xcode versions supporting LIBRARY_PATH is that it doesn't work
 with 4.3.3.

 My somewhat hazy recollection is that it might have started working in
 4.4. Unfortunately I don't have that version handy to check.



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

Re: Compile/Link 101

[Craig Treleaven]

At 4:06 PM -0500 10/5/13, Ryan Schmidt wrote:

  My somewhat hazy recollection is that it might have started working in

 4.4. Unfortunately I don't have that version handy to check.


http://trac.macports.org/ticket/36339#comment:3 says 4.4.1's clang 
doesn't support LIBRARY_PATH either. 4.5's does. So since the build 
system is so finicky you can blacklist macports-clang-2.9 
macports-clang-3.0 and {clang  421}


Thanks Ryan.  I'll have a go at that.

BTW, version information w.r.t. XCode 4.4 and 4.4.1 seems to be 
absent from the wiki page.  Anyone have to details?


https://trac.macports.org/wiki/XcodeVersionInfo

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

Compile/Link 101

[Craig Treleaven]

Could someone please explain some very basic stuff about 
compiling/linking C and C++ code?  For a new version of Myth, the 
configure script succeeds with XCode 5 on Mtn Lion and _fails_ with 
XCode 4.3 on Lion.  The bit that I'm looking at just tests whether 
certain libraries (faac in this case) are installed and, if so, 
enables additional features in the package.  The 'config.ep' file 
(btw, is that a Unix/Linux standard thingy?) shows how it tried to do 
the test:


BEGIN 
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c

1   #include stdint.h
2   #include faac.h
3   long check_faacEncGetVersion(void) { return (long) faacEncGetVersion; }
4   int main(void) { return 0; }
END 
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
/usr/bin/clang -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -D_DARWIN_C_SOURCE -DPIC -pipe -std=c99 
-fomit-frame-pointer -fPIC -c -o 
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.CaP65ZOS.o 
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
/usr/bin/clang -Wl,-dynamic,-search_paths_first -o 
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.7NGrnBrt 
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.CaP65ZOS.o 
-lfaac -lm -lbz2 -lz

ld: library not found for -lfaac
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

ERROR: libfaac not found


faac _is_ installed:

MediaMini:~ mytthtv$ port installed |grep aac
  faac @1.28_2 (active)


I actually don't know how the test _can succeed_ with XCode 5?  There 
is no '-L' flag to indicate that the library is under /opt/local/lib.


I must be missing something obvious.  Pointers to introductory 
material gratefully accepted.


Craig
--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054  ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #40654: Upgrade of iterm2

[Craig Treleaven]

At 7:30 PM -0400 10/2/13, Mark Anderson wrote:
I submitted two tickets 40653 and 40654 with patches, that are 
nomaintainer. I would be willing to take them over, but I wasn't 
sure how I was supposed to do that. Just declare myself the 
maintainer? I also contributed a perl 5.18 Portfile, which seems to 
have a maintainer + openmaintainer. I'd wasn't sure how that worked 
either. Can someone tell me how this works or where I need to RTFM?


I don't have commit privs but I maintain a couple ports.  Info at:

http://guide.macports.org/#project.contributing

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

Re: [109460] trunk/dports/security/certsync/Portfile

[Craig Treleaven]

until the next generation MacBook Pros are announced, which I'm 
hoping is on September 10th.


I think the chances of that are slim to none.  Doesn't make sense for 
Apple to 'dilute' an iPhone event with Mac announcements.


Craig
(Not that I have any inside information.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev