Re: Finding ports by install date?

[Harald Hanche-Olsen]

-Original Message-
From: Carlo Tambuatco 
Date: 30 May 2016 at 23:26:04

> Dude, thanks!

You’re welcome.

> Yeah the port -v installed does not list the dates for 2.3.4…wonder if 
> previous versions  
> ever did…

Probably not. Ryan mentioned trunk, which indicates a future, not yet released 
version.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Finding ports by install date?

[Harald Hanche-Olsen]

> Is there a way to search for ports installed on a given date? I want to find 
> ports I installed 
> on a specific date and uninstall them. 

Absent a built-in method, the following seems to work correctly: 

sqlite3 /opt/local/var/macports/registry/registry.db "select name from ports 
where date(date,'unixepoch')=='2016-05-27’" 

It’s a bit jarring that “date” names both a function and a database field, but 
sqlite is not confused by this, thank goodness. 

– Harald 

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

Re: Finding ports by install date?

[Harald Hanche-Olsen]

-Original Message-
From: Ryan Schmidt 
Date: 30 May 2016 at 20:41:22
To: Carlo Tambuatco 
Cc: MacPorts Users 
Subject:  Re: Finding ports by install date?

> Not built in, but you can print the install date with:
>  
> port -v installed
> […]
>  
> (I'm not certain whether this feature is in MacPorts 2.3.4 or if you need to 
> be running  
> MacPorts trunk to get it.)

Not in 2.3.4.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: installer doesn't modify root path

[Harald Hanche-Olsen]

-Original Message-
From: Phil Oertel 
Date: 2 February 2016 at 17:13:59

> Yes, it has both env_reset and a secure_path. And some comments at the top
> indicating that the file is periodically overwritten by Puppet.

Ah, then we have a definite diagnosis! Good. Then what remains is for you to 
negotiate with the puppet admins. Meanwhile, or if you can’t make them change 
their practice, you can always invoke macports via a shell script looking 
somewhat like this:

#!/bin/sh
PATH="/opt/local/bin:/opt/local/sbin:$PATH”
export PATH
exec port “$@“

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: installer doesn't modify root path

[Harald Hanche-Olsen]

-Original Message-
From: Phil Oertel 
Date: 2 February 2016 at 16:31:12

> Entirely possible. I didn't make any such modification personally, but it's
> a work laptop, so I don't know what they've done to the image prior to
> giving it to me. Maybe I'll get them to stop whatever it is they're doing
> to sudoers. Thanks, Brandon and Harald, this makes a lot more sense than
> there being an installer bug :)

You might look to see if they have set secure_path. If you can run sudo, surely 
you can look inside /etc/suoers and see what is there. 8-)

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: installer doesn't modify root path

[Harald Hanche-Olsen]

-Original Message-
From: Brandon Allbery 
Date: 2 February 2016 at 16:28:50

> The problem with paths.d is that it adds path entries *after* the standard
> ones, whereas users tend to expect that e.g. /opt/local/bin/python
> "overrides" Apple's /usr/bin/python. So MacPorts edits your .bash_profile
> or .profile to prepend /opt/local/bin to $PATH.

Ah. That explains it; thanks. And that doesn’t work for me because I don’t use 
bash for my login shell, which would be why I made my own hack.

An alternative would have been to modify /etc/paths instead? Or is that too 
global, or something?

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: installer doesn't modify root path

[Harald Hanche-Olsen]

-Original Message-
From: Brandon Allbery 
Date: 2 February 2016 at 16:06:18

> On Tue, Feb 2, 2016 at 9:57 AM, Harald Hanche-Olsen  
> wrote:
>  
> > Well, you did not say in the bug report that you were using sudo, so no
> > wonder it got closed.
>  
> ? sudo is the recommended way to do this.

Yes, but the way the bug report was phrased, it was very easy to suspect that 
either a root shell had been run using “sudo -i”, or perhaps even by enabling 
the root account and logging in as root – which is definitely not recommended, 
but I have seen this suggestion in the wild – though not recently.

> > My own systems are too heavily modified at the moment for me to be sure,
> > but I have a file /etc/paths.d/45-macports containing the two lines
> >
> > /opt/local/bin
> > /opt/local/sbin
> >
>  
> This is not standard.

Okay, now I am curious. How does the macports installation manipulate the path? 
As far as I know, the above method is standard, even though it may not be what 
macports does. (If I installed that file there, I must have done it because it 
didn’t work otherwise.)

> I would also suspect a sudoers modification here. The default should retain
> the user's PATH,

That’s what I am finding too, after some experimentation. Even the sudo man 
page agrees, though only if you read it really carefully.

– Harald

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

Re: installer doesn't modify root path

[Harald Hanche-Olsen]

-Original Message-
From: Harald Hanche-Olsen 
Date: 2 February 2016 at 15:57:39

> […] You can check by running “sudo printenv PATH”.  […]

Uh, sorry, I missed the fact that you did show the result of running that, and 
that /opt/local/bin is missing from the output. So the question remains, why? 
As I said, I have fiddled too much with my own system to be sure what things 
look like in a standard setup.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: installer doesn't modify root path

[Harald Hanche-Olsen]

Well, you did not say in the bug report that you were using sudo, so no wonder 
it got closed.

My own systems are too heavily modified at the moment for me to be sure, but I 
have a file /etc/paths.d/45-macports containing the two lines

/opt/local/bin
/opt/local/sbin

These should be enough to ensure that those directories appear in the path when 
you run sudo. You can check by running “sudo printenv PATH”. I believe that 
file is installed by the macports installer? If not, you can install it 
yourself. But from what you say, I gather you must have this file? What about 
/etc/sudoers? Have you made any modifications to that file?

– Harald

-Original Message-
From: Phil Oertel 
Date: 2 February 2016 at 06:34:21

> I'm unable to sudo run any port commands after installing macports (version
> 2.3.4, system is El Capitan 10.11.3). I installed via the package
> installer. After running the installer and opening a new shell, my login
> user has /opt/local/bin on his path, but root does not. So `sudo port`
> results in "not found".
>  
> I filed a bug, https://trac.macports.org/ticket/50503, and it was promptly
> closed […]

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

Re: Versions in ports

[Harald Hanche-Olsen]

Chris Jones wrote:

However, your concern above will be caught by the rev-upgrade mechanism.


Aha, thanks. Time to re-RTFM, I see. It's been too long.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Versions in ports

[Harald Hanche-Olsen]

Chris Jones wrote:


[…] A normal upgrade will first upgrade all the ports
dependencies, as required, such that you end up with a consistent
updated port. Only if you specifically disable this can you get into a
mess.


But if ports A and B both depend on port C, and you run “port upgrade 
A”, then it will upgrade C as well, if necessary, but then what about B?


Concerns like this is one reason why I never upgrade ports individually, 
but rather just run “port upgrade outdated” instead.


– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ledger fails to build on yosemite

[Harald Hanche-Olsen]

Kastus Shchuka wrote:

I attempted to install ledger on yosemite (10.10.5) but it failed. I found 
ticket https://trac.macports.org/ticket/47597 with a log which looks very 
similar to mine. The ticket contains a patch which does not seem to be 
committed to the port yet. Please excuse my ignorance, but how do I apply this 
patch?


That patch should already be applied, assuming you have run port 
selfupdate lately.


Unfortunately, ledger still doesn't build, not for me at any rate, as of 
my latest attempt about a week ago. But I suspect the reason is 
different. I should have submitted a bug report, but haven't gotten 
around to it yet.


– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: OpenSSL

[Harald Hanche-Olsen]

[Niels Dettenbach  (2014-04-08 12:46:27 UTC)]

> Anyhow: where server secret keys could be changed more easily (i.e. SSH host 
> keys) this should be done.

But ssh does not use the openssl libraries, so there is no point, as
this bug will not have exposed the ssh host keys.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Troubles installing rc

[Harald Hanche-Olsen]

[Joshua Root  (2014-01-19 06:47:31 UTC)]

> > destroot fails for rc:
> > 
> > /usr/bin/install -c history /opt/local/bin/- ;\
> > rm -f /opt/local/bin/--;  ln /opt/local/bin/- /opt/local/bin/-- ;\
> > rm -f /opt/local/bin/-p;  ln /opt/local/bin/- /opt/local/bin/-p ;\
> > rm -f /opt/local/bin/--p; ln /opt/local/bin/- /opt/local/bin/--p
> > install: /opt/local/bin/-: Operation not permitted
> 
> It's installing into ${prefix} directly instead of into
> ${destroot}${prefix} as it should.

Ah, of course. I should have realized. Not used to squinting so hard
at the destroot phase, as it usually succeeds.

> Fixed in r116136.

Thanks. And now there is a binary package too, excellent.

[Davor Cubranic  (2014-01-19 00:28:33 UTC)]

> You can use “Ticket Query” with “port is” set to “rc”.

Again, I should have realized. The difference between search and query
may not be blindingly obvious, but they are there, next to each other,
so it should have been obvious that if one fails the other might work.
Thanks for your patience.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Troubles installing rc

[Harald Hanche-Olsen]

Before I get to the main point: How do I search for tickets regarding
the rc port? The search string is too short, and obviously I don't
want all tickets with the letter pair "rc" appearing in the ticket
description anyway.

destroot fails for rc:

/usr/bin/install -c history /opt/local/bin/- ;\
rm -f /opt/local/bin/--;  ln /opt/local/bin/- /opt/local/bin/-- ;\
rm -f /opt/local/bin/-p;  ln /opt/local/bin/- /opt/local/bin/-p ;\
rm -f /opt/local/bin/--p; ln /opt/local/bin/- /opt/local/bin/--p
install: /opt/local/bin/-: Operation not permitted

Before you ask: Yes, I am running as root. But I'm intrigued by these
lines in the log file:

:notice:destroot --->  Staging rc into destroot
:debug:destroot Can't run destroot under sudo without elevated privileges (due 
to mtree).
:debug:destroot Run destroot without sudo to avoid root privileges.
:debug:destroot Going to escalate privileges back to root.
:debug:destroot euid changed to: 0. egid changed to: 0.

It seems like these operations may have failed to work as expected.
Or maybe it's some other newfangled security device misfiring.
I can certainly run the install command by hand without problem.

OS version: 10.9.1
Port version: 2.2.1
Xcode version: 5.0.2

I'd file a ticket, except for my inability to search for relevant
tickets already in the system.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port selfupdate error

[Harald Hanche-Olsen]

[Jeremy Lavergne  (2013-07-19 13:48:24 UTC)]

> You likely need to install (or reinstall) Xcode:
> http://trac.macports.org/wiki/FAQ#missingxcode

Or possibly, agree to the license by running xcodebuild -license
and typing "agree" when prompted. It may also be necessary to do this
as root, if I recall correctly.

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

Re: Macports stopped working after xcode 4.6 upgrade

[Harald Hanche-Olsen]

[Lawrence Velázquez  (2013-02-21 06:31:44 UTC)]

> Very annoying. I've actually filed a Radar about this.
> 
> http://openradar.appspot.com/radar?id=2620402

Good.

> > (Should this be in the FAQ?)
> 
> Considering that we don't recommend using /etc/paths or /etc/paths.d 
> anywhere, I'm not sure it needs to be.

The reason would be to inform people who know about these, or discover them, 
may want to use them in the way I suggested. But if it doesn't satisfy the F in 
FAQ, then perhaps it should not be included. Tha balancing act between 
supplying too little information and too much is always tricky.

– Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Macports stopped working after xcode 4.6 upgrade

[Harald Hanche-Olsen]

[Lawrence Velázquez  (2013-02-20 09:16:27 UTC)]

> On Feb 20, 2013, at 4:09 AM, Harald Hanche-Olsen  wrote:
> 
> > True. If that is what you want, you can tack the directories onto the front 
> > of /etc/paths instead. Not sure if either will survive a system upgrade, 
> > though. But on the other hand, it will work for all users on the machine.
> 
> For the curious. […]

Argh. So that doesn't work either, then. path_helper starts with the current 
PATH, then append pathnames from /etc/paths and /etc/paths.d/* excepting, 
presumably, patnames that have already been included – so you can't prepend a 
pathname to PATH this way. Good to know. (Should this be in the FAQ?)

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

Re: Macports stopped working after xcode 4.6 upgrade

[Harald Hanche-Olsen]

[Lawrence Velázquez  (2013-02-20 08:47:13 UTC)]

> On Feb 20, 2013, at 3:22 AM, Harald Hanche-Olsen  wrote:
> 
> > ["Richard R. Cahilig"  (2013-02-19 22:39:32 UTC)]
> > 
> >> export PATH="/opt/local/bin:/opt/local/sbin:$PATH"
> > 
> > Another way to do that is to put this in a file in /etc/paths.d/:
> > 
> > /opt/local/bin
> > /opt/local/sbin
> 
> These are not equivalent. Directory entries added via /etc/paths.d are tacked 
> onto the *end* of the default PATH, while the quoted "export" statement adds 
> them to the *beginning*. The latter is necessary if you want your shell to 
> find MacPorts executables before system ones.

True. If that is what you want, you can tack the directories onto the front of 
/etc/paths instead. Not sure if either will survive a system upgrade, though. 
But on the other hand, it will work for all users on the machine.

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

Re: Macports stopped working after xcode 4.6 upgrade

[Harald Hanche-Olsen]

["Richard R. Cahilig"  (2013-02-19 22:39:32 UTC)]

> Sorry about the typo.
> 
> export PATH="/opt/local/bin:/opt/local/sbin:$PATH"

Another way to do that is to put this in a file in /etc/paths.d/:

/opt/local/bin
/opt/local/sbin

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

Re: Gimp's dockable dialogs always on top

[Harald Hanche-Olsen]

[Chris Jones  (2013-01-05 18:35:21 UTC)]

> On 5 Jan 2013, at 6:32pm, Chris Jones  wrote:
> 
> > Macports gimp does have a quartz variant, which presumably does the same. 
> > You could try that …

Maybe I will someday, thanks. But for now I'm sticking with the binary I 
downloaded from gimp.org.

> It also has the port
> 
> > gimp-app @2.8.2 (aqua, graphics)
> > GIMP.app application bundle
> 
> which presumably installs gimp as an /Application as well.

That's just a wrapper for the x11 gimp.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Gimp's dockable dialogs always on top

[Harald Hanche-Olsen]

[Harald Hanche-Olsen  (2013-01-05 15:44:13 UTC)]

> Oh, crap. But thanks for the info. It's time to abondon gimp and go
> shopping for some commercial software, I'm afraid.

I was just informed (off-list) that there is a native (i.e., non-x11)
OS X binary. It seems to work fine, and saves me from selling my soul
to Adobe for a while yet. But the macports one goes out.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: Gimp's dockable dialogs always on top

[Harald Hanche-Olsen]

[Brandon Allbery  (2013-01-05 15:23:10 UTC)]

> You're not the only one; recent Gimp is not playing well with window
> managers other than the ones that are part of Gnome and maybe KDE.  It's a
> common issue among xmonad users, for example.

Oh, crap. But thanks for the info. It's time to abondon gimp and go
shopping for some commercial software, I'm afraid.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Gimp's dockable dialogs always on top

[Harald Hanche-Olsen]

I have this odd problem with gimp. I tried googling and looking for
bug reports describing it, and finding nothing. So I wonder if I am
the only one seeing it?

The problem is with the so-called dochable dialogs, such as the
toolbox and layers and paths dialogs.

The smaller problem is that these always stay on top of other windows,
even if I switch from X11 to some other application. That's annoying,
but can be worked around by running gimp in its own desktop.

Much worse is a related problem with popup menues in these dialogs:
When I activate such a popup, it pops up *under* the corresponding
dialog. Needless to say, this renders gimp just about unusable.

Is anybody else seeing this? I suspect the answer is no, or there
would be howls of frustration. Can you think of ways to investigate
the cause of the problem? Some possibly corrupt config files that I
can remove?

(Should I take this to some gimp mailing list/forum instead?)

This is with gimp @2.8.2_0 on OS X 10.8.2.
I am running XQuartz 2.7.5_rc1, but downgrading to 2.7.4 didn't help.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: FreeBSD partition

[Harald Hanche-Olsen]

[Raoul  (2012-11-14 07:58:32 UTC)]

> I was not aware of zevo, and i will investigate this point.

There is also a free zfs implementation for OS X:

http://code.google.com/p/maczfs/

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts 2.0.4 and recommendation for Lion Xcode version

[Harald Hanche-Olsen]

[Tabitha McNerney  (2012-03-17 09:56:56 UTC)]

> I've downloaded MacPorts 2.0.4 but I'm
> wondering if I should install it using a slightly older version of Xcode
> for Lion (like 4.2.1) or if its generally ok and recommended to use
> MacPorts 2.0.4 with Xcode 4.3.1 (which is the current version offered in
> the App Store)?

FWIW, I am running MacPorts 2.0.4 with Xcode 4.3 with no ill effects.
(I haven't got around to upgrading to Xcode 4.3.1 yet.)

> I ask because I seem to recall not too long ago there were
> some problems with getting MacPorts to work well with Xcode 4.3.x.

There were, but I believe fixing that was the point of the 2.0.4
version.

- Harald (not an expert; just a satisfied user)
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Xcode 4.3: Apparently Persistent License Agreement

[Harald Hanche-Olsen]

[Harald Hanche-Olsen  (2012-03-04 21:38:46 UTC)]

> [Harald Hanche-Olsen  (2012-03-04 21:30:49 UTC)]
> 
> > How exactly does it determine where to copy the accepted license from?
> 
> I got it; by examining $HOME, which is not changed by sudo.

So here is a suggestion for making it more robust:

If no license agreement is found in $HOME/Library/Preferences, look
instead in ~$SUDO_USER/Library/Preferences (probably not valid syntax,
but I trust the intent is clear).

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Xcode 4.3: Apparently Persistent License Agreement

[Harald Hanche-Olsen]

[Harald Hanche-Olsen  (2012-03-04 21:30:49 UTC)]

> How exactly does it determine where to copy the accepted license from?

I got it; by examining $HOME, which is not changed by sudo. My problem
is in the way I run my macports upgrades: I run "sudo es" (es is my
login shell of choice), and I run the port command in the shell. Now
es (even if not a login shell) sets HOME to the home directory of the
owner of the process, in this case /var/root. By manually changing
HOME to be my own home directory, I managed to get it to work.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Xcode 4.3: Apparently Persistent License Agreement

[Harald Hanche-Olsen]

[Rainer Müller  (2012-03-04 21:19:54 UTC)]

> On 2012-03-04 21:43 , Harald Hanche-Olsen wrote:
> > So what is the trick required to have the macports user "accept" the 
> > XCode license agreement?
> 
> MacPorts 2.0.4 just copies the agreement to the license from the home
> directory of the user executing the command.

Oh. But that would be the root user, then? I don't think the root user
has accepted the license, either.

> There should not be anything special required once you accepted the
> license (either by running Xcode.app or xcodebuild), which is stored
> in ~/Library/Preferences/com.apple.dt.Xcode.plist.

But most people run macports as root (using sudo), don't they?
How exactly does it determine where to copy the accepted license from?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: upgrade Xcode to 4.3 with MacPorts 2.0.4

[Harald Hanche-Olsen]

[Murray Eisenberg  (2012-03-04 21:00:20 UTC)]

> xcode-select -version gives "xcode-select version 2003."
> 
> Is that the trouble: I still have the Xcode command-line utilities
> left from Xcode 4.2?

Could be. Make sure you're running /usr/bin/xcode-select. Maybe you
are running one inside /Developer instead. (I have deleted my own
/Developer, so I can't know if this is likely. Just guessing.)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Xcode 4.3: Apparently Persistent License Agreement

[Harald Hanche-Olsen]

[Anthony Michael Agelastos  (2012-02-18 16:22:05 
UTC)]




On Feb 18, 2012, at 5:45 AM, Aljaž Srebrnič wrote:

> unfortunately this doesn't work, probably because the license 
agreement is stored in the home directory of the user (which is 
/var/empty for macports user)


For situations such as this, could/should a $HOME be created for 
macports user within /opt/local, e.g. /opt/local/home? I am not 
familiar with how MacPorts handles its builds behind the scenes, 
but all of the files within /opt/local are owned by root user and 
admin or wheel groups. So, does macports user do a chown on the 
data, or is root (through sudo typically) the one doing the 
building? If root is doing the building, should root be the one 
with the license agreement?


Also, from what I can tell, and I could easily be wrong, this 
license agreement verification is stored within 
$HOME/Library/Preferences/com.apple.dt.Xcode.plist.


I notice that with the upgrade to macports 2.0.4, there is now a 
proper home for the macports user. But still, I am getting the 
dreaded error message. Worse, I seem to be unable to to get rid of 
it. I have tried "sudo -u macports xcodebuild" (as root), it does ask 
me to accept the license agreement, and I do, but nothing changes in 
~macports/Library/Preferences/ (which remains empty). I tried adding 
the -H flag to no avail.


So what is the trick required to have the macports user "accept" the 
XCode license agreement?


- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Cleaning up stale dependencies

[Harald Hanche-Olsen]

[Ryan Schmidt  (2012-02-26 19:38:49 UTC)]

> If you want to switch to a new version of python, that's up to you, and you 
> can reinstall the port with the python27 variant to indicate that desire.

Yup. Already did, before seeing your response. It seemed the sensible thing to 
do, after I finally figured out what was going on. After dealing with a couple 
other ports, I managed to get rid of python26 as well as a pile of py26-* ports.

But thank you for the patient lectures.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Cleaning up stale dependencies

[Harald Hanche-Olsen]

[Joshua Root  (2012-02-26 14:48:38 UTC)]

> Harald Hanche-Olsen hanche at math.ntnu.no wrote:
> > [Ryan Schmidt  (2012-02-25 20:05:51 UTC)]
> > 
> >> deps and dependencies are conceptual inverses of one another.
> >> However the information is recorded in the registry at install
> >> time. At the time you installed py26-lxml, it was needed for
> >> inkscape.
> > 
> > Right; this much makes sense. But when inkscape is upgraded, why not remove 
> > the dependency information for the old version from the registry?
> 
> This is exactly what happens, not when inkscape is upgraded necessarily,
> but when the old version is uninstalled.
> 
> Possibilities: inkscape hasn't been updated since you were migrated from
> the flat registry (in which case the extra dep will go away in the next
> version or if you reinstall), or you still have the old version
> installed but inactive.

Hmm. I notice that I've used the sqlite registry as far back as my
time machine backup goes (2010-12-19), and inkscape was last upgraded
almost a year later.

But - wait a moment:

; port echo inkscape and installed
inkscape   @0.48.2_2+python26

Well, wow. That explains a lot. I guess I'll reinstall with +python27,
and this particular problem will go away. Splendid.

I guess the source of my confusion is the output of this:

; port deps inkscape
Full Name: inkscape @0.48.2_2+python27
Build Dependencies:   pkgconfig, intltool, perl5
Library Dependencies: boehmgc, gsl, gtkmm, gnome-vfs, lcms, poppler, boost,
  ImageMagick, libwpg, gtkspell2, py27-lxml, py27-numpy,
  py27-xml

I hadn't even looked at the first output line, giving the full name,
which of course doesn't match what is installed. I was not aware of
this discrepancy. So I take it that the output of “port deps” has
little relationship to the actual installed ports, but merely shows
information from the portfile?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Cleaning up stale dependencies

[Harald Hanche-Olsen]

[Brandon Allbery  (2012-02-26 11:08:46 UTC)]

> On Sun, Feb 26, 2012 at 04:12, Harald Hanche-Olsen wrote:
> 
> > But surely, the intent is to do away with [the flat file registry]
> option in the future?
> >
> 
> Isn't it already gone as of 2.0?

Oh. I didn't know that; but I don't see it mentioned in the current
macports.conf.default, so I guess you're right. Good riddance.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Cleaning up stale dependencies

[Harald Hanche-Olsen]

[Ryan Schmidt  (2012-02-25 21:31:30 UTC)]



On Feb 25, 2012, at 15:19, Harald Hanche-Olsen wrote:

> [Ryan Schmidt  (2012-02-25 20:05:51 UTC)]
>
>> Later (r83781) inkscape changed to use py27-lxml (or rather, 
changed to give you the option of using python26 or python27) but 
that did not change py26-lxml's registry entry which still records 
the fact that inkscape is its dependent, though that's no longer 
necessarily the case.

>
> I suppose there are good reason for doing it that way, but I 
would (perhaps naively) have thought it made more sense to tie 
dependency information to the dependent port, not to the dependency?


I don't know.


I think I can guess, actually. I suspect it is a holdover from the 
days when the registry was a bunch of files. Efficiency concerns 
might well have dictated the current solution. Perhaps for so long as 
the flat file registry remains an option, it has to remain this way. 
But surely, the intent is to do away with that option in the future? 
At that point, a saner policy should be easy to implement.


- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Cleaning up stale dependencies

[Harald Hanche-Olsen]

[Ryan Schmidt  (2012-02-25 20:05:51 UTC)]

> deps and dependencies are conceptual inverses of one another. However the 
> information is recorded in the registry at install time. At the time you 
> installed py26-lxml, it was needed for inkscape.

Right; this much makes sense. But when inkscape is upgraded, why not remove the 
dependency information for the old version from the registry?

Later (r83781) inkscape changed to use py27-lxml (or rather, changed to give 
you the option of using python26 or python27) but that did not change 
py26-lxml's registry entry which still records the fact that inkscape is its 
dependent, though that's no longer necessarily the case.

I suppose there are good reason for doing it that way, but I would (perhaps 
naively) have thought it made more sense to tie dependency information to the 
dependent port, not to the dependency?

> If you know that no other port needed py26-lxml, feel free to, uninstall it, 
> forcibly (-f) if needed.

Okay, but it's not worth the effort to get rid of a single port that way. I had 
hoped there was a way to clean up things more thoroughly. Right now I have 56 
requested ports and 365 ports in total. That is way too many ports to go 
through manually in order to find out if they are truly needed. I had hoped for 
a way to automate it. Right now I can think of one: Record my list of requested 
ports, uninstall everything, then reinstall all the requested ones. Maybe I'll 
just wait for Mountain Lion, and do that then.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Cleaning up stale dependencies

[Harald Hanche-Olsen]

Here is an oddity on my machine:

Inkscape depends on py27-lxml, but py26-lxml counts inkscape among its
dependents.

; port deps inkscape
Full Name: inkscape @0.48.2_2+python27
Build Dependencies:   pkgconfig, intltool, perl5
Library Dependencies: boehmgc, gsl, gtkmm, gnome-vfs, lcms, poppler, boost,
  ImageMagick, libwpg, gtkspell2, py27-lxml, py27-numpy,
  py27-xml
; port dependents py26-lxml
inkscape depends on py26-lxml

>From a small amount of poking around, I think there are more instances
of this phenomenon. If possible, I would like to get rid of python26
altogether, along with all the py26-* ports. But I don't know if this
is indeed safe. How can I find out? And why aren't deps and dependents
simply inverses of each other?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: barcode fails to build

[Harald Hanche-Olsen]

[Ryan Schmidt  (2012-02-02 18:33:01 UTC)]

> On Feb 2, 2012, at 12:04, Harald Hanche-Olsen wrote:
> 
> > Funny, it built for me, but the resulting binary segfaulted.
> > See https://trac.macports.org/ticket/33000 – I haven't looked at it since 
> > filing the bug report.
> 
> You did not mention in your ticket what OS version, Xcode version, or 
> compiler you're using (could you add that to the ticket please?) but from 
> Richard's log we see he's using clang, which does not use CPATH, which, if 
> you're using an Xcode earlier than 4.2, and therefore not using clang, would 
> account for why it built for you and not for him.

Um, okay, I've done my best. Damn, this business with remembering to run the 
Xcode Installer is confusing. Turned out I hadn't, so I did indeed have 4.1. 
(At least Xcode.app was 4.1. I am not sure if this always correspond with the 
Xcode distribution version.)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: barcode fails to build

[Harald Hanche-Olsen]

["Richard L. Hamilton"  (2012-02-02 12:59:29 UTC)]


OS X 10.7.2, latest gen Mac Mini

Among other things, log says paper.h not found, silly 'cause it's 
in /opt/local/include, although there's no -I for that shown on the 
command line.


Anyone play with this enough to have a workaround?  Environment 
variable maybe, or using the command-line option to use a compiler 
other than clang, or whatever?


Funny, it built for me, but the resulting binary segfaulted.

See https://trac.macports.org/ticket/33000 – I haven't looked at it 
since filing the bug report.


- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Request: make the ML's default return candidate be the ML

[Harald Hanche-Olsen]

[Phillip Koebbe  (2011-11-26 16:37:22 UTC)]

> Or to use the mailing list's address as the from? I believe that's what 
> Google Groups does: You get the message from the same address you send one 
> to. In my experience, that seems to work out well. And there is the added 
> benefit that we are not broadcasting our email addresses around. Some might 
> find that appealing.

I would find it extremely annoying myself. After being on a mailing list for a 
while, you begin to learn the names of those most likely to write useful posts. 
Being able to pick them out at a glance without going into each message is 
quite useful.

Google Groups doesn't do this universally, anyhow. There is a setting for 
reply-to munging, and one for allowing members to post on behalf of the group.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Request: make the ML's default return candidate be the ML

[Harald Hanche-Olsen]

[Roger Pack  (2011-11-26 15:48:43 UTC)]

> > This can usually be set as default by any decent MUA.
> 
> I'm sure it can.  Wouldn't you agree that it would be more convenient,
> perhaps, for it not to have to be set by each new participant?

You seem to be asking for the mailing list to set the Reply-To field.
That is controversial to say the least; see the link below.

  http://www.unicom.com/pw/reply-to-harmful.html

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Solved! Re: Lots and lots of system time

[Harald Hanche-Olsen]

[Brandon Allbery  (2011-11-26 15:46:34 UTC)]

> On Sat, Nov 26, 2011 at 08:42, Harald Hanche-Olsen wrote:
> 
> > syscall::connect*:entry
> > syscall::connect*:return
> >
> 
> I wonder if there's a better way to do that, in particular avoiding the
> wildcards; I would suspect it ends up waking up on *every* syscall to do
> the glob, which on a system-wide basis will be extremely expensive no
> matter how much it's optimized.

My understanding is that wildcard matching is done only when dtrace
starts. It should create just four probes:

; sudo dtrace -l -n 'syscall::connect*:'
   ID   PROVIDERMODULE  FUNCTION NAME
  840syscall connect entry
  841syscall connect return
 1462syscallconnect_nocancel entry
 1463syscallconnect_nocancel return

> Also, I would try to limit what processes
> are getting traced.

That would defeat my purpose, which was to track this globally to find
out if processes are making unexpected TCP connections. I know, there
is an application to do that: Little Snitch. I just thought dtrace
could do the same job.

> DTrace isn't magic; if you hook a critical path system-wide (and
> they don't come much more critical than the syscall provider),
> you''re going to feel it.

Right, but I think it's claimed to be magic, at least in the sense
that it will not impact anything other than the targets you are
probing. You're supposed to be able to use dtrace on a production
server under heavy load to pinpoint any performance problems. That is
a major reason for having created dtrace in the first place, as far as
I am aware. So I am still surprised.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Solved! Re: Lots and lots of system time

[Harald Hanche-Olsen]

I found out what has been biting me. I had been running a dtrace 
script in the background to record all tcp connections in a file. 
After I removed that, updating ports is so much snappier I can't 
believe it.


According to the hype, dtrace is not supposed to affect system 
performance, or at least not by much. While that may be so on 
Solaris, it appears to be very far from the truth on MacOS. Bummer.


- Harald

PS. For the curious: I used these two providers in my dtrace script:

syscall::connect*:entry
syscall::connect*:return

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Lots and lots of system time

[Harald Hanche-Olsen]

[Jeremy Lavergne  (2011-11-25 20:25:46 UTC)]

> > MacBook Pro, 2.66 GHz Intel Core 2 Duo, 8 GB RAM
> 
> Looks like build.macports.org is a quad core Xeon Xserve running 2.0, 2.66 or 
> 3.0 GHz. If you have some ports that cannot be built in parallel, it should 
> give you a reasonable comparison.
> 
> The latest build took just under 10 minutes, where that entailed installing 
> all pre-built dependencies where no ports were installed then building gegl. 
> As noted below, gegl itself only took 3 minutes to compile and install.

Thanks! For comparison, here is my timing result, where all the dependencies of 
gegl were already built and installed:

  4545r   102.7u  2968.9s   port -d upgrade gegl

That's disturbing, to say the least. It tells me I don't have a small problem, 
I have a GIANT one. I clearly need to work much harder at trying to figure this 
out.

DEBUG: extract phase started at Sat Nov 26 11:51:32 CET 2011
DEBUG: patch phase started at Sat Nov 26 11:51:33 CET 2011
DEBUG: configure phase started at Sat Nov 26 11:51:34 CET 2011
DEBUG: build phase started at Sat Nov 26 11:59:21 CET 2011
DEBUG: destroot phase started at Sat Nov 26 13:05:29 CET 2011
DEBUG: install phase started at Sat Nov 26 13:07:03 CET 2011
DEBUG: clean phase started at Sat Nov 26 13:07:05 CET 2011
DEBUG: activate phase started at Sat Nov 26 13:07:05 CET 2011
DEBUG: deactivate phase started at Sat Nov 26 13:07:05 CET 2011
DEBUG: clean phase started at Sat Nov 26 13:07:06 CET 2011

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Lots and lots of system time

[Harald Hanche-Olsen]

[Brandon Allbery  (2011-11-25 20:50:21 UTC)]

> On Fri, Nov 25, 2011 at 15:08, Harald Hanche-Olsen wrote:
> 
> > I have no idea what mach_kernel`chud is or does, but it disappears from
> > the list when the compilation is stopped. (So do the dtrace functions,
> > BTW.) The script runs for ten seconds, so
> 
> 
> CHUD is part of the instrumentation, I think (Computer Hardware
> Understanding for Developers; if it hasn't been folded into DTrace then it
> is at least *used* by DTrace).

Aha. Thanks; I'll ignore chud then.

> You may want to look for "Instruments", which is part of XCode and
> makes using DTrace to figure out what a process is doing much
> easier.

Again thanks. But something is wrong, either with my setup or my
understanding, for I am unable to make Instruments display any
information. Also, "Instruments help" doesn't bring up any window.

Uh, sorry about going off topic ... I'll ask elsewhere if I can't
figure it out on my own.

> In any case, I would be interested to see what happens if you turn off
> multiple jobs.  I wouldn't necessarily assume that psynch_cvwait doesn't
> use CPU, by the way; busywaiting is often used for what are expected to be
> short delays waiting on a mutex.  ("port install ... build.njobs=1", IIRC)

Trying that now, it didn't make any difference. Where could I found
out about options such as build.njobs, BTW? I looked around to verify
that you did RC, but to no avail.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Lots and lots of system time

[Harald Hanche-Olsen]

This thead has laid dormant for several weeks, so just a reminder:
I asked why system time was well above 50 % while I compile macports software.

["Daniel J. Luke"  (2011-10-30 15:03:08 UTC)]

> If you really want to know what is going on, you could probably use some of 
> the provided dtrace scripts (or write one up) to track down what is actually 
> happening on the machine.

I have been trying, but I am not learning a lot from my efforts. Here is my 
feeble attempt at tracing what is happening in the kernel when I compile some 
macports packages:

; sudo dtrace -qn 'profile-997 /arg0/ { @[func(arg0)] = count(); }
  profile:::tick-1sec /++x==10/ {exit(0);}
  END { trunc(@,10); }'

  NVDAResman`si570ProgramClk   43
  mach_kernel`ml_set_interrupts_enabled   119
  mach_kernel`vm_map_enter157
  mach_kernel`strncmp 157
  mach_kernel`strlen  344
  NVDAResman`osPciReadDword   527
  mach_kernel`dtrace_probe_arg   1295
  mach_kernel`dtrace_unregister  3217
  mach_kernel`chud   4705
  mach_kernel`machine_idle   7213

I have no idea what mach_kernel`chud is or does, but it disappears from the 
list when the compilation is stopped. (So do the dtrace functions, BTW.) The 
script runs for ten seconds, so the the first trigger should run 9970 times, or 
perhaps twice that number (because of the two CPU cores of the machine).

Trying to track system calls from userland is even less instructive. I learn 
that a lot of processes, or rather a lot of threads, are spending a lot of time 
in psynch_cvwait. But judging from the name, I don't expect that to burn CPU 
cycles.

It was suggested that disk encryption/decryption burns a lot of CPU time, but 
other tasks which do lots of disk I/O don't typicall use much CPU time, so I 
don't think that is the issue.

It was also suggested that it's just the accounting being way off, and there 
may be something to that. That sounds reasonable enough. But it does feel like 
package compilation is quite a lot slower than it used to be, so I do indeed 
suspect that CPU cycles are being burned to no avail. I guess I should do some 
timing experiments. Does anyone have timing data for building some typical 
macports packages, on a machine similar to mine (MacBook Pro, 2.66 GHz Intel 
Core 2 Duo, 8 GB RAM)?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Binary builds???

[Harald Hanche-Olsen]

[Dominik Reichardt  (2011-11-19 12:17:00 UTC)]

[...]
> >> Actually I uncommented:
> >> ---
> >> #portarchivetypetgz
> >> ---
> >> and things started working. :-)
> > 
> > I was discussing how it should work, not how it does. I think you've got
> > your story backwards though; uncommenting that line would have made it
> > *stop* working since the server only has tbz2 archives.
> 
> He he, indeed this should work when he uncomments the tgz, the default (tbz2) 
> kicks in ;)

I wonder if you and others are using the word "uncomment" in the opposite sense 
of the rest of us?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Lots and lots of system time

[Harald Hanche-Olsen]

Please pardon me if this is off topic, but it is about a phenomenon I
only see when macports is compiling software: So I'd like to hear if
other macports users are seeing the same:

Namely, that the majority of CPU time while compiling is system time,
not user time. Right now, for example, I am compiling gimp2, and top
says

CPU usage: 10.34% user, 86.20% sys, 3.44% idle

It did not use to be this way. Unfortunately, several things got
upgraded about the same time, so I am not certain which one to blame:
The OS to Lion, and XCode and macports itself.

Does anyone else see this? Can you come up with a possible explanation
off the top of your head?

I thought it might be possible to play around with dtrace to find out
what system calls are sucking up all the time, but my dtrace-foo is
rather limited.

The system is a 13 inch MacBook Pro with SSD, not a HD. I have
full-disk encryption enabled, but I am pretty sure this started before
I turned it on.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: xCode 4.1 ?

[Harald Hanche-Olsen]

[Jeremy Huddleston  (2011-07-22 07:08:49 UTC)]

> On Jul 21, 2011, at 11:53 PM, Harald Hanche-Olsen wrote:
> > 
> > The dangerous libnotify workaround? What's that all about?
> 
> Look at my post on macports-dev, and respond to it there ...

Okay, thanks. For those who, like me, don't subscribe to macports-dev, go to 
http://lists.macosforge.org/pipermail/macports-dev/2011-July/thread.html and 
look for the thread named "MacPorts on Lion (common issues, fixes, and 
workarounds)".

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: xCode 4.1 ?

[Harald Hanche-Olsen]

[Jeremy Huddleston  (2011-07-22 03:06:06 UTC)]

> FWIW, these ports work on Lion (they're the ones I install ... I haven't 
> tried testing random ports) ... gnome and firefox require the dangerous 
> libnotify workaround for now (you can always undo the workaround and your 
> system will be fine ... it's only necessary during build)...

The dangerous libnotify workaround? What's that all about?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Uninstalling a port

[Harald Hanche-Olsen]

[Ryan Schmidt  (2011-03-04 15:06:21 UTC)]

> sudo port uninstall dokuwiki
> port installed leaves
> sudo port uninstall leaves

See also the newish requested flag:

port echo leaves and unrequested

Look at the output, run “sudo port setrequested” for those ports
you want to keep, then

sudo port uninstall leaves and unrequested

Note that uninstalling leaves can create new leaves, so iterate this
procedure until nothing more happens.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: What does (epoch 0 < 2 ) mean?

[Harald Hanche-Olsen]

[Marko Käning  (2011-02-21 16:19:43 UTC)]

> This is why by using "epoch" older versions of some ports were deliberately 
> enforced.

Also, run “man portfile” and search for “epoch”.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts throws errors on everything (include uninstall) since selfupdate

[Harald Hanche-Olsen]

[Aba-Sah Dadzie  (2011-02-21 10:32:32 UTC)]

> Both when I tried on Saturday and again just now it starts to install,
> gets through the required libs successfully, but fails on the checksum
> for the actual application, and then invites me to submit a bug
> report.

These things happen unfortunately, because sometimes the file gets
altered upstream. What is the application in question, what
distribution file, and what are the expected and actual checksums?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts throws errors on everything (include uninstall) since selfupdate

[Harald Hanche-Olsen]

[Aba-Sah Dadzie  (2011-02-18 12:14:01 UTC)]

> I ran selfupdate almost a week ago, and my computer is pretty much
> broken now - for any program remotely related to MacPorts.

Is it *only* macports?

Your litany of woes would make me suspect either a hardware problem or
a corrupted system file outside of macports. But if you never have any
problems with non-macports software then that sounds a mite unlikely.

Still, if this happened to me, I would run a hardware test. Including
a thorough disk test. A bad sector in the midst of a much used library
would surely be an endless source of grief!

When you said you reinstalled macports from scratch, did you really
mean that? I.e., did you run  sudo rm -fr /opt/local  and then install
macports and then all your ports?

If so, and if the hardware test shows no problems, I'd suspect a
corrupt system file somewhere. In which case, maybe downloading the
latest combo updater from apple.com and installing it just might fix
the problem. Or failing that, a complete reinstall of your entire OS.

It's time consuming and painful, but sometimes such drastic measures
can't be avoided. I do hope you have good backups! Good luck.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: preventing sleep during compilation

[Harald Hanche-Olsen]

[Scott Webster  (2011-02-04 03:30:33 UTC)]

> Or a way to prevent this problem other than just turning sleep on
> and off manually all the time?

Someone mentioned caffeine, but sometimes the command line is more
useful, especially if you run your port commands from a script.
While “pmset noidle” is running the machine is not supposed to go to
sleep. So you could structure your port script along the lines of

#!/bin/bash
pmset noidle &
... do the work here ...
kill %pmset

You can also use pmset to manipulate the power management settings,
bypassing the System Preferences. See the man page for details.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Changing X11 interface to something better

[Harald Hanche-Olsen]

[Jasper Frumau  (2011-01-19 06:03:12 UTC)]

> What different WMs are there?

Now this is the macports list, so may I suggest trying

  port search 'window manager'

? You'll get quite a number of hits. If you look outside the macports
world, the number of window managers out there is truly astounding.
I have long since given up keeping track of even the major players.
But you might look at the questions and answers here:

  http://stackoverflow.com/questions/tagged/window-managers

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: errors installing a port

[Harald Hanche-Olsen]

[Ryan Schmidt  (2011-01-03 21:03:37 UTC)]

> If that fails the same way, verify perl5 and perl5.8 are installed and active:
> 
> port installed perl5.8 perl5
> 
> If they are, you could try reinstalling them:
> 
> sudo port -n upgrade --force perl5.8 perl5

Indeed, that is almost certainly necessary. For this line appeared in
Thomas's original report:

:info:configure sh: /opt/local/bin/perl: No such file or directory

which indicates that something has gone awry with his perl installation.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Checksum error

[Harald Hanche-Olsen]

+ Ryan Schmidt :


Please see:

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


Ugh. The whole unversioned distfile situation seems awkward, to say 
the least. Would it be better if macports were to automatically fall 
back to the distfiles mirror whenever there is a checksum mismatch?


- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Checksum error

[Harald Hanche-Olsen]

+ "Frank J. R. Hanstick" :

> Hello,
>   The following port gets a checksum error:
> 
> --->  Computing dependencies for curl-ca-bundle
> --->  Verifying checksum(s) for curl-ca-bundle
> Error: Checksum (sha1) mismatch for certdata-1.67.txt
> Error: Checksum (rmd160) mismatch for certdata-1.67.txt
> Error: Target org.macports.checksum returned: Unable to verify file
> checksums

I have a copy of the file that matches the portfile checksum as given
in your log file. I'll send it to you under separate cover. You should
be able to just drop it into
/opt/local/var/macports/distfiles/curl/certdata-1.67.txt and build
your port, but before you do, it would be interesting if you were to
run a diff between the two files and report back. This is after all a
security related file, so it is good to be a bit paranoid. Most
likely, though it has just gotten truncated in the download.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: inkscape crashes

[Harald Hanche-Olsen]

+ ~suv :

> That's the issue Jonathan initially asked about, see

Oh, right. Sorry, there are too many issues for my tiny brain to keep
track of.

> The issue seems related to building inkscape or one of the dependencies
> on 64bit operating systems, also described in Bug #672111 in Inkscape:
> “Operations in Fill/Stroke dialog results in SEGV (on a 64bit Mac)”:
> :
> "(…) problem is in handling of 64bit address in Inkscape or Glib."

Aha. That rings a bell. I do run a 32 bit kernel, but a while back, I
experimented for a short while with a 64 bit kernel. I had to give it
up because there were some applications I need that won't run on a 64
bit kernel. I wonder if I did any port upgrades during the 64 bit
period? That would explain my troubles, then. I have kept a careful
log of all my port upgrade activities, but of course I haven't made a
note of when my 64 bit kernel experiment started and stopped.

Is there an easy way to find out what, if any, ports were built under
a 64 bit kernel? If not, maybe I really need to blow away my entire
ports tree and rebuild. (Ouch.)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: inkscape crashes

[Harald Hanche-Olsen]

+ ~suv :

> The following bugs also affect Inkscape (0.48.0 and trunk) if installed
> with MacPorts using GTK+ 2.22:
> [...]
> 
> Bug #651678 “crashes with assertion failure on startup”:
> 
> 
> The second one happens as soon as there are entries in
> '~/.recently-used.xbel'. Workaround (so far): install 'gnome-icon-theme'
> and add this line to ~/.gtkrc-2.0:
> 
> gtk-icon-theme-name = "gnome"

Yes, that does work. Not that it helps me, for now I get instead a
crash as soon as I try to change a line thickness:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x056bd978
0x0001003d2dc9 in sp_stroke_style_line_update ()
(gdb) back
#0  0x0001003d2dc9 in sp_stroke_style_line_update ()
#1  0x00010246cd92 in g_closure_invoke ()
#2  0x00010248225b in signal_emit_unlocked_R ()
#3  0x000102483c84 in g_signal_emit_valist ()
#4  0x000102484054 in g_signal_emit ()
#5  0x00010246cd92 in g_closure_invoke ()
#6  0x00010248225b in signal_emit_unlocked_R ()
#7  0x000102483c84 in g_signal_emit_valist ()
#8  0x000102484054 in g_signal_emit ()
#9  0x000100106abc in Inkscape::Selection::_emitModified ()
#10 0x000100106c7a in Inkscape::Selection::_emit_modified ()
#11 0x0001024ee919 in g_main_context_dispatch ()
#12 0x0001024f1fb1 in g_main_context_iterate ()
#13 0x0001024f22c5 in g_main_loop_run ()
#14 0x0001019e0d90 in gtk_main ()
#15 0x0001000303a0 in sp_main_gui ()
#16 0x00010002fa1e in main ()

> Another issue that also affects Inkscape installed with MacPorts after
> upgrading to GTK+ 2.22:
> 
> Bug #627134 “Cursor position markers are not cleared from rulers”:
> 
> (not solved yet)

Yep, I am seeing that too.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts vs Mac PATH Conflicts - Best Workaround???

[Harald Hanche-Olsen]

+ LeAnne Lis :

> I understand that MacPorts exports /opt/local/bin and
> /opt/local/sbin in the .profile to ensure its paths go to the front
> of the env PATH.  Apparently this is done because typically Apple
> has older versions of "stuff" than MacPorts, and, of course, most
> MacPorts users want to use the new stuff.
> 
> What if, however, there is an instance (or two) where a user wants
> the Apple version to be accessed rather than the MacPorts version?

Create a new bin directory and put it in front of everything else in
PATH, then if you want to use (say) /usr/bin/ssh rather than
/opt/local/bin/ssh, put a symlink to the former in the new bin
directory.

I like to have a directory /local/bin that will apply for all users on
the machine: So you do

  ln -s /usr/bin/ssh /local/bin/

To put /local/bin at the front for everybody, do

  echo /local/bin > /etc/paths.d/10-local

For stuff you want to be at the front for only yourself, create a
directory bin in your home directory, add the line

  PATH=$HOME/bin:$PATH

in your .profile, and put symlinks and other useful stuff there.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: emacs-app does not find latex

[Harald Hanche-Olsen]

+ Andre Massing :

> (setenv "PATH" (concat "/opt/local/bin:" (getenv "PATH"))) because of
> gs
> (setenv "PATH" (concat "/usr/texbin:" (getenv "PATH"))) because of
> latex and pdflatex

You could combine the two into
  (setenv "PATH" (concat "/usr/texbin:/opt/local/bin:" (getenv "PATH")))
or even
  (setenv "PATH" (concat "/usr/texbin:" "/opt/local/bin:" (getenv "PATH")))

> But somehow it seems strange me that I have to explicitly add them,
> isn't?

Depends how you start emacs. If you start it from the command line
that should not be necessary, but if you start it from the dock or
finder, things are trickier. Check out

  http://developer.apple.com/library/mac/#qa/qa2001/qa1067.html

or do a google search for ".MacOSX/enviroment.plist" for how to set
the environment in those cases.

I am sorry I can't help you with your latest problem, as I don't (yet)
use auc-tex, and neither do I use the macports version of emacs.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: emacs-app does not find latex

[Harald Hanche-Olsen]

+ Andre Massing :

> For some reasons, emacs-app does not find my latex installation
> (Mactex, bin files are located in /usr/texbin).
> I installed emacs-app together with the auctex package (using
> +emacs_app +mactex variants)
> When I run pdflatex via the command menu, I only got the message
> 
> [...]
> "\input" paper.tex''
> /bin/sh: pdflatex: command not found
> [...]
> indicating that pdflatex was not found. But the /usr/texbin is added
> to my PATH variable and I added it as well to the exec-path of emacs.

Exec-path is irrelevant here, as it is sh that can't find pdflatex,
not emacs. PATH is relevant, however. Please run

M-x getenv  PATH 

in emacs and check again that /usr/texbin is in there. If not, maybe
try (setenv "PATH" (concat "/usr/texbin:" (getenv "PATH"))) ?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: OT: "find" command with branch/pipe

[Harald Hanche-Olsen]

+ Andre Massing :

> I am struggling with the find command, trying to find all files ending
> with .h or .cpp in a certain directory.
> On my former linux machine the following worked as intended:
> find   ./ -regextype grep -regex '.*\.\(\(h\)\|\(cpp\)'
> but Apple's find command does neither know the regextype option nor
> does it work as expected if I omit it. I tried already different kind
> of
> grouping and escaping but without success. Has anybody an idea how I
> can get find to work as intended?

Have you checked the man page for Apple's find, notably the -E flag
(and the resulting reference to re_format(7))?

Anyhow, for your particular need, using regexps is overkill.

find . \( -name '*.h' -o -name '*.cpp' \)

will work, and is easier both to type and to read.
You may skip \( and \) in the above usage, but they are needed if you
follow the search term with -print0 or stuff like that.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: inkscape crashes

[Harald Hanche-Olsen]

Inkscape has been unusable for me on the mac since mid-September due
to it crashing, usually within the first one or two actions after
startup. I haven't complained yet because I don't use inkscape all
that often; and when have needed it, I have been able to use it on a
linux machine at work; and finally, I haven't had the time to
investigate enough to produce a bug report of sufficient quality to be
of any use.

Maybe I should blow away all of inkscape's direct and indirect
dependencies and rebuild, but that is a huge number of ports. I might
as well blow away my entire ports tree and rebuild it.

All I can offer is an excerpt from a recent crashlog:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib   0x7fff84f403d6 __kill + 10
1   libSystem.B.dylib   0x7fff84fe0913 __abort + 103
2   libSystem.B.dylib   0x7fff84fe0981 abort_report_np + 0
3   libglib-2.0.0.dylib 0x000102505bf8 g_assertion_message 
+ 328
4   libglib-2.0.0.dylib 0x000102506142 
g_assertion_message_expr + 82
5   libgtk-x11-2.0.0.dylib  0x000101a3a947 get_icon_fallback + 
103
6   libgtk-x11-2.0.0.dylib  0x000101a352d7 idle_populate_func + 
839
7   libgdk-x11-2.0.0.dylib  0x000101db8c19 gdk_threads_dispatch 
+ 89
8   libglib-2.0.0.dylib 0x0001024e0919 
g_main_context_dispatch + 553
9   libglib-2.0.0.dylib 0x0001024e3fb1 
g_main_context_iterate + 961
10  libglib-2.0.0.dylib 0x0001024e42c5 g_main_loop_run + 485
11  libgtk-x11-2.0.0.dylib  0x0001019dfd90 gtk_main + 176
12  inkscape0x0001000303a0 sp_main_gui(int, 
char const**) + 1280
13  inkscape0x00010002fa1e main + 1230
14  inkscape0x00010002eec8 start + 52

It might be interesting to know if others see the same in their
crashlogs. Look for them in ~/Library/Logs/CrashReporter/, with names
like inkscape__.crash

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: has anyone else noticed?

[Harald Hanche-Olsen]

+ Bayard Bell :

> bay...@precious:~ 17:14:48 [504]$ dig www.apensource.apple.com
> [...]
> According to 
> http://webcache.googleusercontent.com/search?q=cache:http://www.opensource.apple.com/,
>  the last time the page was updated for caching was Oct. 29. Seems a bit odd 
> that the DNS entries have simply disappeared for what looks like days at a 
> time. Anyone know what's up with this?

You could try again, but spell it correctly this time around.  8-)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Up to date MacPorts

[Harald Hanche-Olsen]

+ Scott Haneda :

I just want to make sure I have the most current and best tools.  
sqlite seems a great tool to have as a backend for MacPorts.


Absolutely. Note, however, that you need to have

portdbformat sqlite

in /opt/local/etc/macports/macports.conf (assuming your macport 
installation is in the default location). The database will be 
automatically converted next time you run a port command, I think.


- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: All files port doesn't provide

[Harald Hanche-Olsen]

+ Rainer Müller :

> This will also match all files which are part of MacPorts base. And even
> worse, a lot of files in /opt/local/var/macports/ are for internal use
> only, e.g. images and build directories.
> 
> But I also can't come up with anything better than adding a few more
> grep -v calls to the pipeline to filter out unwanted files.

You could also use the -prune argument to find.

find $PREFIX \( -path $PREFIX/here -o -path $PREFIX/there \) -prune -o \
 -type f -print0 | ...

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: rubber dependencies

[Harald Hanche-Olsen]

+ Arno Hautala :

> On Fri, Aug 20, 2010 at 06:47, Michael Williams  wrote:
> >
> > Why then does the MacPorts rubber package depend on 142 packages,
> > including the MacPorts perl, python, texlive and X11 systems ($
> > port rdeps rubber | wc -l)? Is this intended?

> 
> Yes, it is intended.  Directly, Rubber only depends on Python and
> TexLive.  Those 142 other packages are brought in when you fully
> follow the dependencies of Python and TexLive.

If you're feeling adventurous, it should be possible to write your own
dummy texlive port to override the macports one, following
instructions here:

http://guide.macports.org/#development.local-repositories

This probably only makes sense for really big ports like texlive,
though. If you try to do this too much, you only let yourself get
sucked into some nightmare maintenence scenario.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Error setting locale in python

[Harald Hanche-Olsen]

+ Brandon S Allbery KF8NH :

>  On 07/23/2010 05:14 AM, Harald Hanche-Olsen wrote:
> > (Uh, setting LC_ALL to C would override my LC_CTYPE
> > setting, would it not? But nevermind.)
> 
> No, the individual entries override LANG / LC_ALL, so you can do
> things like set the locale to en_US.UTF-8 and then override LC_COLLATE
> to C so "ls" does what we old timers expect.  :)

The locale(1) man page seems to disagree:

 LC_ALL   Will override the setting of all other LC_* variables.

A quick experiment with locale (the program) confirms this.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Error setting locale in python

[Harald Hanche-Olsen]

+ Brandon S Allbery KF8NH :

> As such, you might try setting LANG and LC_ALL to C instead, in
> case the iconv library you're using doesn't parse set-but-empty environment
> variables correctly.

Good catch! (Uh, setting LC_ALL to C would override my LC_CTYPE
setting, would it not? But nevermind.) So this works:

; env - LC_CTYPE\=en_US.UTF-8 LANG\=C PATH\=$PATH python2.6
Python 2.6.5 (r265:79063, Jul 16 2010, 21:35:10) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'')
'C/en_US.UTF-8/C/C/C/C'
>>>

Now at least I have a workaround, but it's still a bug.
Shall I assume the bug is in libiconv then?
(But iconv the program does not complain.)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Error setting locale in python

[Harald Hanche-Olsen]

+ Bryan Blackburn :

> Do you have anything else in your env that could be affecting the locale
> stuff?  If I use those LANG/LC settings you've listed, the MacPorts python
> seems okay with it:
> 
> % env LANG= LC_COLLATE="C" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="C" 
> LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL= /mp/bin/python2.6

I get the same result if I clear the environment using env - ...
All the variables whose values are listed as "C" were actually not
set; but setlocale reports them as "C". Not that it matters: Setting
them to "C" does not change anything either.

> Though this is on 10.6, whereas I'm guessing you're on an earlier
> version since the gcc listed for your build is 4.0.1.

You're right, this is on 10.5.8. The macports tree is quite recent
however, about a week since I upgraded.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Error setting locale in python

[Harald Hanche-Olsen]

python2.5 and python2.6 both don't like my locale setting:

  ; python2.6
  Python 2.6.5 (r265:79063, Jul 16 2010, 21:35:10) 
  [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import locale
  >>> locale.setlocale(locale.LC_ALL,'')
  Traceback (most recent call last):
File "", line 1, in 
File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py",
 line 513, in setlocale
  return _setlocale(category, locale)
  locale.Error: unsupported locale setting

/usr/bin/python, on the other hand, has no such problems.
My locale setting may be a bit unusual, but not illegal AFAIK:

  ; locale
  LANG=
  LC_COLLATE="C"
  LC_CTYPE="en_US.UTF-8"
  LC_MESSAGES="C"
  LC_MONETARY="C"
  LC_NUMERIC="C"
  LC_TIME="C"
  LC_ALL=

Any suggestions? Is this a bug, or am I actually not allowed to
specify my locale that way?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sqlite error: disk I/O error

[Harald Hanche-Olsen]

+ Ryan Schmidt :

> I pressed Control-C while MacPorts was activating a port. Now anything I do 
> with port gives me:
> [...]
> Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: disk 
> I/O error (10) while executing query: ATTACH DATABASE 
> '/opt/local/var/macports/registry/registry.db' AS registry
> 
> 
> How do I recover?

Assuming the error message is accurate, it probably has nothing to do
with your pressing Control-C and everything to do with a bad disk. In
which case I would replace it ASAP. I think real disk I/O errors are
logged to /var/log/system.log. Check there. You can also check if
  cat /opt/local/var/macports/registry/registry.db > /dev/null
produces any errors.

If the error message is bogus and your disk is okay, I think the best
you can do is to restore registry.db from backup. Or better all of
/opt/local, since an old registry.db will not accurately reflect the
state of your ports tree.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Atlas problems

[Harald Hanche-Olsen]

+ Lenore Horner :

> I''m having the problem reported in ticket 23349.

It looks like it may be resolved now. There's a patch there if you
don't want to wait for it to be comitted to the ports tree.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Setting up mysql5

[Harald Hanche-Olsen]

+ Scott Haneda :

> Here is how I have been getting it to work:
> [...]

Thanks. I have another machine to set up once it is done doing a
massive "port upgrade outdated". (It hasn't been done since June, and
it appears to require a couple days' worth of compiling stuff.)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

What is a dependent?

[Harald Hanche-Olsen]

In order to do a bit of housecleaning, getting rid of old ports that I
am not really using, I thought I could run "port dependents active"
and deactivate the ports that come up with "has no dependents!" and
that I am otherwise not interested in.

But then I come up with oddities like the following:

; port dependents p5-pathtools
p5-pathtools has no dependents!

; port deps intltool
Full Name: intltool @0.40.6
Build Dependencies:   gnome-common
Library Dependencies: expat, perl5, p5-xml-parser, p5-getopt-long, p5-pathtools,
  p5-scalar-list-utils

So intltool depends on p5-pathtools, but it is not among the
dependents of p5-pathtools.

Is my understanding of "dependent" wrong, or is there a bug lurking
here?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Setting up mysql5

[Harald Hanche-Olsen]

I just installed mysql5. Compiling it went fine, and running it seems
to be no problem using the supplied launchd item.

However, I am unable to connect to the database:

; mysql5 -h localhost -u root
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: 
NO)

After messing around a bit (actually, several hours went down the
drain doing this), finally running the server using the extra flag
--skip-grant-tables, I found out that the table mysql.user had no rows
at all. Adding data to this table by hand I now finally have a root
user, hopefully with all the necessary privileges (time will show).

Surely, this is not how the mysql setup is supposed to go. I must
have done something wrong somewhere, but can't figure out where.

This is basically what I did:

#; port -v install mysql5-server
[...]
#; launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
#; /opt/local/lib/mysql5/bin/mysqladmin -u root password 'new-password'
[... produced an access denied error like the one below
 ... but I seem to have closed that terminal window, so no copy ...]
; mysql5 -h localhost -u root
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: 
NO)

It did not seem to make any difference whether or not I ran
; sudo -u _mysql mysql_install_db5
(as recommended at the end of installation) before launchctl load.

FWIW: This is macports version 1.8.2 on OS X 10.5.8 (intel).

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Everything was properly upgraded.

[Harald Hanche-Olsen]

+ "Frank J. R. Hanstick" :

>   Just an unusual note that everything installed successfully upgraded
>   using:
> 
>   sudo port upgrade installed.
> 
>   Good news should be broadcasted as well.

Reminds me of the captain who quite truthfully entered into the log
that the first mate was drunk one day. The next day the first mate
wrote this entry: "The captain was sober today."

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Why should I use macports?

[Harald Hanche-Olsen]

+ Randolph Fritz :

> On 2009-10-15, Wendy Bossons  wrote:
> >
> > Can someone explain the purpose of Macports and why I might need it?
> >
> 
> Broadly, because it's an easy-to-use library of useful free
> software. It provides, especially, dependency tracking, which means
> that when you install a package you want, you get the packages that
> that that package depends on automatically, without fuss.

I beg to differ. Over the years I have used macports I have certainly
seen my share of fuss. Enough so that I have started being careful
taking a backup of /opt before doing an update, so I can roll back to
an earlier version if needed. (I haven't needed to yet, but I have
come close to doing it a couple times.)

If you had said a minimum of fuss, I would agree. It's almost
impossible to avoid problems in a system that is dragging in source
code from all over the intertubes the way macports does, and I must
say I am impressed and pleased that I don't see more problems than I
do. But let's not oversell it. "No fuss"? No way.

> The value of the tool depends, of course, on what you are doing, but
> Macports has helped me greatly in my software development work.

Amen to that. I don't do software development myself, but I know
enough about programming that I can generally work my way around most
problems that arise. The typical Mac user, whose idea of software
installation involves dragging a .app to /Applications or double
clicking a .mpkg, will however soon be out of their depths when a port
command fails. And that will happen, if they use many ports and
upgrade regularly.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: .bashrc .profile .bash_profile

[Harald Hanche-Olsen]

+ Brandon Allbery :

> If you run vi and type ":!ls", vi will spawn a noninteractive shell to
> run "ls".  Noninteractive shells are also used by "make", "port", and
> numerous other commands.

Note, however, that these invoke /bin/sh and not bash. Even if /bin/sh
is bash, it will behave more like the classical Bourne shell for
compatility reasons. See the bash man page for the rather hairy
details.

And thus endeth the minilecture.  8-)

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Path

[Harald Hanche-Olsen]

+ Ryan Schmidt :

> Bash might look in one of several files for its initialization
> instructions. These files are called .profile, .bash_profile, .bashrc,
> .login, and .bash_login, and would be directly in your home
> directory. Which of those files do you have, and what is their
> contents?

There is also the system-wide /etc/profile, which reads path elements
from /etc/paths and individual files in /etc/paths.d/. I have a file
/etc/paths.d/macports which contains /opt/local/bin. I don't think I
am the one who put it there?

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts 1.8.1 has been released

[Harald Hanche-Olsen]

+ Damien Clauzel :

> Same here :
> 
> $ uname -a
> Darwin arda.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31
> 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386

What is wrong with that? On Leopard, I see

; uname -a
Darwin mach 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; 
root:xnu-1228.15.4~1/RELEASE_I386 i386
; sw_vers
ProductName:Mac OS X
ProductVersion: 10.5.8
BuildVersion:   9L30

The numbers given by uname is the kernel version, NOT the OS version.

- Harald
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users