Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Joshua Root]

Bachsau wrote:

Am 02.11.2016 um 23:48 schrieb Murray Eisenberg:

After upgrading from OS X El Capitan to macOS Sierra (10.12.1), I’m
following the migration steps at https://trac.macports.org/wiki/Migration.


Against the recommendations in that article, I discovered the easiest
way to migrate is to reinstall MacPorts base and just do a port
selfupdate && port upgrade outdated. Chances to run into problems are
minimal and much lower than going the recomended way.


The best thing that can be said for that approach is that it may well 
work. It doesn't always, and it wouldn't have solved the OP's problem.


Trust me, if we could safely tell people to just run 'port upgrade 
outdated', we would. But experience over many years of OS updates has 
resulted in the recommended Migration procedure. We couldn't make this 
stuff up if we tried; real users ran into real, often confusing, 
problems. So I have to disagree with your statement that the recommended 
way has a higher chance of running into problems.


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

Re: Trac & Subversion available again

[Joshua Root]

On 2016-10-23 14:48 , Jeremy Huddleston Sequoia wrote:



On Oct 21, 2016, at 18:16, Clemens Lang  wrote:

Hello MacPorts users and developers,

On Fri, Oct 21, 2016 at 08:12:59PM +0200, Clemens Lang wrote:

Due to the current SVN and Trac downtime, we are also discussing to
make the move of Trac sooner if that helps us restore service earlier.
We will keep you informed on this.


Due to the current unplanned downtime, we brought the migration of our
Trac installation forward and finished it today. Pending DNS
propagation, you should be able to reach Trac at trac.macports.org
again. Note that you will need a GitHub account to log into Trac now.

Please make sure that you have added the email address you used in Trac
to your GitHub account. A cronjob will automatically associate your
tickets and other contributions with the GitHub login a few minutes
after your login.


How often does this job run?  It's been about a day now, and I still cannot 
edit tickets (beyond making comments).  My @macports.org email address was on 
my github account months ago, so that's not the issue.


The problem would have been that you weren't a member of the MacPorts 
org on GitHub. Once you accept the invitation I just sent, you should be 
able to edit tickets.


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

Re: Moving to GitHub: Status Update, Action Required

[Joshua Root]

On 2016-10-22 23:31 , Marko Käning wrote:

Hi Clemens,

great to see the GitHub conversion progressing this rapidly! Thumbs up from 
me!!!


When reading the WorkingWithGit wiki page [1] I saw how port contributors can 
post
their suggestions to MacPorts via "Pull Requests”, yet it does not get clear 
from
that text how those PRs will then actually be included into the official repo…


The usual way; an organisation member will review the PR and merge it if 
appropriate. We're still open to suggestions on the details of the workflow.



Just this moment I got invited to MacPorts' "Developer team" on GitHub and saw 
that
I now have "pull access” to the MacPorts ports repository, which is probably 
enabling
me in the future to push changes into it?

But the term “pull access” confuses me here!

I mean, I can pull in changes into my clone or fork from the MacPorts repo any 
time…

Can you clarify this somewhat, as I have no experience yet in teams on GitHub!?

Thanks,
Marko


Please see the Migration Timeline section in the first message in this 
thread. Developers cannot yet push to the git repos.


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

Imagick version?

[Joshua Root]

Bjarne D Mathiesen wrote:

You'll just have to re-compile php55-imagick :

This will take care of all of your php\d{2}-imagick versions

port -q installed name:imagic \
| while read -a port
do port -n upgrade --force ${port[0]}
  done

but more explicitly for just php55-imagick :

port -n upgrade --force php55-imagick


That doesn't necessarily recompile the port, it reinstalls it (quite 
possibly from the same binary archive as before). If you really need to 
force a build from source, you have to use -s.


But if there really is a problem that requires a rebuild, the maintainer 
should bump the revision so everyone gets the rebuilt version.


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

Getting rid of port binaries in /software

[Joshua Root]

Eric A. Borisch wrote:

If you are just looking to save some space at the expense of time, you
could set:

portarchivetype  txz

in macports.conf; on some of the big clang/llvm archives this is ~2x
improvement...


Nobody has yet mentioned the very important fact that you can't just 
change the config file and have this work. Apple does not ship xz with 
OS X, so there is an obvious bootstrap problem (How do you build the 
archive of the xz port?) and a somewhat less obvious problem when 
upgrading xz (you need to extract the archive of the new version *after* 
the old version has been deactivated).


So in fact you have to install xz somewhere outside of MacPorts and 
configure base to use it, before you can make this config file change.


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

Re: How add variant when upgrading octave

[Joshua Root]

Murray Eisenberg wrote:

Currently installed and active is:

   octave @3.8.2_18+atlas+gcc48+glgui

This is flagged as having available upgrade to 4.0.2_0, so I executed...

  sudo port upgrade octave

…which generated the error:

 Error: org.macports.fetch for port octave returned: must set at least one 
Fortran variant

Presumably I want to add fortran

Is there some form of the upgrade command to do that?

Or do I simply have to do a new install:

   sudo port install octave @4.0.2_0+atlas+gcc48+glgui+gfortran


I think you want to do:

sudo port upgrade octave +gfortran

which will add gfortran to the currently installed set of variants while 
upgrading.


Having to manually intervene during an upgrade like this is of course 
poor UX. The problem here is that the gcc48 variant (actually all of 
gcc44, gcc45, gcc46, gcc47, gcc48, gcc49) was removed rather than 
sticking around as a "legacy compatibility variant" that just causes a 
mandatory replacement variant (presumably +gfortran here) to be selected.


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

Re: About mozjs24 being built

[Joshua Root]

On 2016-4-4 01:46 , Clemens Lang wrote:

Hi Josh,

On Mon, Apr 04, 2016 at 01:06:50AM +1000, Joshua Root wrote:

MPL 2.0 is GPL compatible only by way of an optional clause that
allows relicensing under the GPL. Some software is under MPL-2 but has
an "Incompatible With Secondary Licenses" notice. If a port uses the
version of MPL-2 that does allow the relicensing then its license
should be listed as {MPL-2 LGPL-2.1+}. (You could list GPL-2+ and
AGPL-3+ in there too but it makes no practical difference.)


I'm aware of that. Still, it's probably the most common case that this
optional clause applies, and I'd argue it should be the default for this
reason -- especially because there is no documentation (that I could
find) that explains that you have to explicitly list (L)GPL.


Well, documentation can be written. :)


I think we should add an additional MPL-2-NoRelicensing (or "MPL-2
GPLConflict") license to denote the few ports that explicitly do not
have the exception.


Making the dual licensing explicit seems less confusing to me than 
calling the same license two different names.


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

Re: About mozjs24 being built

[Joshua Root]

On 2016-4-4 00:45 , Clemens Lang wrote:

Hi,

On Sun, Apr 03, 2016 at 04:05:02PM +0200, Clemens Lang wrote:

Doesn't seem like it will:

$ port_binary_distributable.tcl -v mozjs24
"mozjs24" is not distributable because its license "mpl" conflicts with license "GPL-3+" 
of dependency "gdbm"


Actually, mozjs24's license is MPL-2.0, which is -- according to the
FSF's interpretation of things [1] -- compatible with GPL-3. Our license
check tooling, however, explicitly marks all MPL licenses as
incompatible with all GPL licenses [2]. I think that's a bug.

The GPL <-> MPL conflict was already there in the inital script
committed 5 years ago by Josh [3]. Josh, do you agree this is a bug?

[1] http://www.gnu.org/licenses/license-list.en.html#MPL-2.0
[2] 
https://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl?marks=91#L85
[3] https://trac.macports.org/changeset/75780


MPL 2.0 is GPL compatible only by way of an optional clause that allows 
relicensing under the GPL. Some software is under MPL-2 but has an 
"Incompatible With Secondary Licenses" notice. If a port uses the 
version of MPL-2 that does allow the relicensing then its license should 
be listed as {MPL-2 LGPL-2.1+}. (You could list GPL-2+ and AGPL-3+ in 
there too but it makes no practical difference.)


Older MPL versions were also GPL incompatible, although software using 
them was often explicitly dual-licensed.


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

Re: python_select

[Joshua Root]

If you want to run 'python', use python_select. This can be linked to 
any version of python. If you want to run 'python2' or 'python3', use 
the others. These can only be linked to python 2.x or 3.x respectively. 
A common use for this might be if you have scripts that only work with 
one or the other, in which case you can start them with something like 
'#!/usr/bin/env python2'.


- Josh

On 2016-3-29 00:02 , Mark Brethen wrote:

So if you have a single python version installed use python_select, whereas 
python2_select and python3_select allow you to set those default versions if 
you need both?


On Mar 28, 2016, at 5:46 AM, Joshua Root  wrote:

Mark Brethen wrote:

Why are there a python_select, python2_select and python3_select? When is one 
vs the others used?


They allow creating links 'python', 'python2' and 'python3' respectively.

- Josh


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

python_select

[Joshua Root]

Mark Brethen wrote:

Why are there a python_select, python2_select and python3_select? When is one 
vs the others used?


They allow creating links 'python', 'python2' and 'python3' respectively.

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

py-pip usage

[Joshua Root]

Mark Brethen wrote:

How is the py-pip port used to install python packages and where are they 
installed? Is this advisable?


You use it just as described in the pip documentation[1]. By default the 
packages go to the same place as a normal distutils install, which is 
not a good idea since that's also where modules installed as ports go. 
If you don't use a virtualenv, at least use the --user option or specify 
a custom directory.


- Josh

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

Sending logs to the list (was: Guile is broken, again...)

[Joshua Root]

Dave Horsfall  wrote:
> On Wed, 10 Feb 2016, Chris Jones wrote:
> 
>> Just compress the log file before posting it. It will be a fraction of 
>> its original size then...
> 
> Yet another hoop through which to jump, in other words...  Should it be 
> ZIP, Compress, or what?  Sigh, so many standards, and so little time...

A link to a pastebin is a better solution. There are plenty of them out
there, and it's good netiquette to avoid sending attachments to an
entire mailing list.

If you must attach the log, any of zip, gzip, bzip2 are fine, pretty
much everyone can extract those.

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

py33-scipy problem

[Joshua Root]

David Strubbe wrote:
> As the message says, you need to select a Fortran variant. You have not.
> You can see this from the fact that the file trying to be fetched is
> py33-scipy-0.16.1_0.darwin_13.x86_64.tbz2 not
> py33-scipy-0.16.1_0+gcc48.darwin_13.x86_64.tbz2. Yes, you had py33-scipy
> +gcc48 installed previously, and macports will try to use the same variants
> you had selected before when upgrading. However, there is no longer a
> variant +gcc48 (as below). Therefore, you must choose one of the four
> currently existing Fortran variants. e.g. sudo port install py33-scipy
> +gfortran.

Breaking the port for existing users and making them fix it is poor UX.
The way the removal of variants like this is usually handled is:

# Can be removed after 2017-01-22
variant gcc48 requires gfortran description {Legacy compatibility
variant} {}

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

Usefulness of boost-jam and boost-build

[Joshua Root]

Are people using boost-jam and/or boost-build? They have no dependents
in the ports tree, haven't been updated upstream in years, and
apparently boost-jam is somewhat broken:


Just wondering if it's worth patching or if we should just delete them.

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

Cannot connect to X server

[Joshua Root]

Brandon Allbery  wrote:
> On Thu, Dec 17, 2015 at 4:23 PM, Eneko Gotzon  
> wrote:
> 
>> As being just an humble user, do you think advisable to also install the
>> xinit port? (Responsible for configuring the initial environment when X11
>> starts up)
> 
> 
> xinit also has the launchd configuration to autostart the server. This is
> generally recommended on OS X.

The xorg-server port has a dependency on xinit, so installing the former
will also get you the latter.

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

Re: Volunteer for a workshop on "setting up your own buildbot/buildslave"?

[Joshua Root]

On 2015-11-11 01:26 , Daniel J. Luke wrote:
> On Nov 10, 2015, at 5:42 AM, Ryan Schmidt  wrote:
>> I think interest in PowerPC systems is truly very low at this time.
> 
> These machines no longer run a version of Mac OS X that receives security 
> updates from Apple - and don’t run one of the 2 major OS releases we support 
> per policy (current, previous).

It's actually 3 now (current, current-1, current-2) since Apple started
doing annual releases. Not that that affects your point.

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

Re_ graphite2 build error

[Joshua Root]

rmgls  wrote:
> On Mon, 26 Oct 2>15 16:13:24 -0500 Ryan Schmidt 
> wrote:
> 
>> Yes. Not having /usr/include would be a problem. /usr/include is =
>> provided by the Xcode command line tools, so install that.
> 
> Hello Ryan,
> 
> then i do not understand, please look:
> xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software 
> Update" to install updates

I don't know what happened on your system, but on mine:

% ls -l /usr/include/unistd.h
-r--r--r--  1 root  wheel  26993 23 Aug 07:40 /usr/include/unistd.h

% pkgutil --file-info /usr/include/unistd.h
volume: /
path: /usr/include/unistd.h

pkgid: com.apple.pkg.DevSDK
pkg-version: 10.11.0.0.1.1440659988
install-time: 1443462826
uid: 0
gid: 0
mode: 444

pkgid: com.apple.pkg.DevSDK_OSX1011
pkg-version: 7.1.0.0.1.1444952191
install-time: 1445466199
uid: 0
gid: 0
mode: 444

Maybe try downloading the command line tools manually from the developer
downloads site and reinstalling?

>  xcode-select -p
> /Applications/Xcode.app/Contents/Developer

That is the correct path for xcode-select to be using.

> is it a way to set this default path?
> /applications/xcode.app/contents/Developer/Platforms/MacOSX.platform/developer/sdks/MacOSX10.11.sdk/usr/include

You don't want to do that.

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

Re: libgmp

[Joshua Root]

+1

I would suggest looking at how the binary distros build their gmp. We
should do the same thing in our port for the default no-variants case,
and have a variant that forces a local build and gives better runtime
performance.

Personally I don't need gfactor from coreutils to run at peak efficiency
that badly. :)

- Josh

Daniel J. Luke wrote:
> It would probably be a useful variant on the port (and if I were the 
> maintainer, it would probably be the default - if only so that people could 
> get a binary archive).
> 
>> On Oct 13, 2015, at 5:21 PM, Ryan Schmidt  wrote:
>> On Oct 13, 2015, at 1:06 PM, Thomas Bodlien wrote:
>>> it is really great, that Macports-Software is compiled with 
>>> Haswell-Optimizations.
>>> But I want to bundle libgmp with an App.
>>> How can I compile a universal Version of the Library?
>> 
>> MacPorts doesn't specifically request haswell optimizations. Rather, gmp is 
>> special in that its build system tries to get the best performance for a 
>> particular system. You'll have to consult the gmp documentation to see if 
>> there's a way to tell it not to do that.

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

Re: Darwin Version

[Joshua Root]

Jeremy Huddleston Sequoia  wrote:
>> On Oct 2, 2015, at 08:01, Clemens Lang  wrote:
>> There are changes that can be done by Apple with OS upgrades that will render
>> your currently installed libraries useless. Examples for changes that are of
>> this nature are:
>>  - Apple changing CPU architecture
>>  - Apple changing the ABI of a library you link against (e.g. when moving
>>to C++11 using libc++)
> 
> We haven't changed the ABI.
> 
> We've added a new C++ runtime (libc++), but still continue to ship the older 
> libstdc++ runtime for binary compatibility.

You are technically correct of course, but making the distinction may be
muddying the waters. Binary compatibility only applies where an
executable and the libraries it uses are all built for the same target.

Yes, if you upgrade the OS, all your installed ports will generally work
fine--to start with. But if we didn't require a rebuild for ports that
were built for a different OS version, something like this would happen:

X 1.0 uses libstdc++ and links with libY 1.0 which also uses libstdc++
User updates OS to a version where the compiler defaults to libc++
libY is updated to 1.1 and is now using libc++
X is now broken.

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

MacPorts 2.3.4 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.3.4. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.11,
10.10, 10.9, 10.8, 10.7, 10.6, and 10.5 (10.6 is universal i386/x86_64;
10.5 is i386/ppc) at [2]. The source is also available as
tarballs compressed with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 

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

Re: Problem upgrading `tiff`

[Joshua Root]

> On 08.08.2015 11:43 AM, Kurt Pfeifle wrote:
>> But I have every package installed which has /jpeg/ in its name:
>> 
>> |$> port installed *jpeg* jpeg @9a_1+universal (active) jpeg2ps @1.9_0 
>> (active)
>> jpegoptim @1.2.4_1 (active) libjpeg-turbo @1.3.1_0 libjpeg-turbo @1.4.0_0
>> libjpeg-turbo @1.4.0_1 (active) mozjpeg @3.0_1 mozjpeg @3.1_0 (active) 
>> openjpeg
>> @2.1.0_0+universal (active) openjpeg15 @1.5.1_0+universal (active) |
> 
> Wow, this should be literally impossible.
> You probably messed up your system pro-actively and are better off wiping
> ${prefix} (in this case /opt/local) and reinstalling everything, pretty much 
> as
> explained in https://trac.macports.org/wiki/Migration - just without the Xcode
> steps and with moving the old /opt/local directory out of the way *after*
> getting the installed port list.
> 
> Even then, you cannot just install from this "installed" list, because it's
> broken and will need some manual care.
> 
> The ports jpeg, jpeg-turbo and mozjpeg conflict with each other. You should
> *never*, *ever*, have more than one of them active. It looks like you
> force-activated them, anyway, and that's the end result of these operations.

While this isn't a state you want to be in, I don't think it's as
hopelessly broken as all that. The files that have had .mp_timestamp
appended to their names by forced activation are still tracked and will
be removed when the associated port is deactivated. So all you need to
do to get back to a sane state is deactivate all the conflicting ports
and then activate only one of them. Like so:

sudo port -f deactivate jpeg libjpeg-turbo mozjpeg
sudo port activate jpeg

And then you probably want to rev-upgrade just in case anything ended up
linked with one of the now-inactive ports:

sudo port rev-upgrade

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

port-search: is --glob option really the default?

[Joshua Root]

> Hello list,
> 
> The man page of port-search says --glob is the default, but the result
> was different when I added this option manually, for example:
> $ port search --name guile
> found 6 ports
> 
> $ port search --name --glob guile
> found 1 ports
> 
> Did I misunderstand anything here?
> 
> Thanks.
> 
> --
> Chunyang

The man page is sort of right but also sort of wrong. If you run:

port search term

then it actually uses "*term*" as the glob. This is not the same as

port search --glob term

which uses "term" as the glob.

If you enter a search term that looks like a glob, though, it is used
as-is. These are equivalent:

port search *term
port search --glob *term

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

Re: selfupdate doesn't work

[Joshua Root]

(Re-adding the list.)

OK. You need to mention what exactly you have tried, or we'll probably
just re-suggest all of it. :)

The gist of the FAQ is very relevant though. The rsync server is working
(I just tried it), so there has to be something about your computer or
internet connection that is blocking access to it. If you can't fix
whatever that is, an alternative mirror or the alternative methods of
syncing can be used.

- Josh

On 2015-3-3 00:20 , Jim Goudie wrote:
> Hi Josh,
> Thanks...  
> 
> I've looked at that and everything else I could find by searching around... a 
> number of times... and so far, nothing I have tried has helped.   I was 
> hoping that somebody might have some new insight ;-) that I've missed so far. 
>  I gather there's something in there that I've overlooked, so I'll go back at 
> it some more.
> 
> Thanks again,
> Jim
> 
> 
>>
>> Please see:
>> 
>>
>> - Josh

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

Re: selfupdate doesn't work

[Joshua Root]

> Hello...  I'm running OS X 10.6.8 on a dual-core Macbook Pro...
> 
> I've got Xcode 3.2 loaded from the snow leopard CD.  Software Update did not 
> find an update for it.
> 
> Using the pkg file, I loaded Macports 2.3.3
> 
> Selfupdate doesn't work; any advice? ...
> 
> Last login: Sun Mar  1 23:42:37 on ttys000
> Office:~ Jim$ port
> MacPorts 2.3.3
> Entering interactive mode... ("help" for help, "quit" to quit)
> [Users/Jim] > quit
> Goodbye
> Office:~ Jim$ sudo port -d selfupdate
> Password:
> DEBUG: MacPorts sources location: 
> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
> --->  Updating MacPorts base sources using rsync
> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /SourceCache/rsync/rsync-40/rsync/clientserver.c(105) [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzv --delete-after 
> rsync://rsync.macports.org/release/tarballs/base.tar 
> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
> Exit code: 10
> DEBUG: Error synchronizing MacPorts sources: command execution failed
> while executing
> "macports::selfupdate [array get global_options] base_updated"
> Error: Error synchronizing MacPorts sources: command execution failed
> To report a bug, follow the instructions in the guide:
> http://guide.macports.org/#project.tickets
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> Office:~ Jim$ 

Please see:


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

Re: updating a very old Macports install

[Joshua Root]

On 2015-2-14 15:01 , Ryan Schmidt wrote:
> 
> On Feb 13, 2015, at 9:21 PM, Joshua Root wrote:
> 
>>> See below:
>>> expected integer but got "-exclusive" obtaining lock on
>>> /opt/local/var/macports/registry/.registry.lock
>>>while executing
>>> "registry::exclusive_lock"
>>>(procedure "mportexec" line 32)
>>
>> You appear to be running trunk. You could take this opportunity to go
>> back to a released version of base; or you could just accept this aspect
>> of living on trunk. :)
> 
> Could you elaborate? Are you saying he was running an old version of trunk 
> before the update, or that he is running the current version of trunk now? 
> Why does this error occur, and is it something that's going to happen for 
> some stable-to-stable updates in the future, or is it only a problem with 
> trunk that will be (or was) fixed before release?

Current problem for trunk only. Has to do with having two flock
implementations.

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

updating a very old Macports install

[Joshua Root]

> See below:
> expected integer but got "-exclusive" obtaining lock on
> /opt/local/var/macports/registry/.registry.lock
> while executing
> "registry::exclusive_lock"
> (procedure "mportexec" line 32)

You appear to be running trunk. You could take this opportunity to go
back to a released version of base; or you could just accept this aspect
of living on trunk. :)

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

Re: Not really MacPorts problem, I don't think.

[Joshua Root]

On 2015-1-24 14:40 , William H. Magill wrote:
> 
>> On Jan 23, 2015, at 2:36 AM, Joshua Root  wrote:
>>
>>> At 8:42 PM -0600 1/22/15, Ryan Schmidt wrote:
>>>> So launchd is launching apache too early. I believe there are some 
>>>> keys one can use in a launchd plist that would affect when launchd 
>>>> tries to launch a service. If you can find a launchd plist key/value 
>>>> that fixes this issue, MacPorts could be enhanced to offer portfile 
>>>> authors a way to use that key, or to use that key/value by default 
>>>> even.
>>>
>>> I'm not expert, but would the NetworkState key help?  See:
>>>
>>> http://launchd.info/
>>>
>>> Goto "Configuration", scroll down to "...Depending on Network Availability:"
>>
>> We do have startupitem.netchange.
> 
> I'm confused.
> 
> The implication of "startupitem.netchange" :
> "Cause the daemon to be restarted when a change in network state is detected."
>
> https://guide.macports.org/chunked/reference.startupitems.html
> 
> is different from "NetworkState"
> "Setting this subkey to true will start the job when/while any network 
> is/becomes available. Setting this subkey to false will start the job 
> when/while all network connections are down."
>http://launchd.info

Yes, it's not the same thing, but it would probably fix the problem that
started this thread.

> And there is no indication on the guide.macports.org page as to what the 
> output of "startupitem.netchange" might generate.
> 
> i.e. no translation between the syntax of launchd and startupitems.

It doesn't change how launchd handles the job, it simply adds
--restart-netchange to the arguments passed to daemondo.

As I've said many times in the past, the StartupItem code could really
use some love. Especially allowing jobs to not use daemondo if they
support running directly from launchd, and exposing more of launchd's
functionality.

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

Not really MacPorts problem, I don't think.

[Joshua Root]

> At 8:42 PM -0600 1/22/15, Ryan Schmidt wrote:
>>So launchd is launching apache too early. I believe there are some 
>>keys one can use in a launchd plist that would affect when launchd 
>>tries to launch a service. If you can find a launchd plist key/value 
>>that fixes this issue, MacPorts could be enhanced to offer portfile 
>>authors a way to use that key, or to use that key/value by default 
>>even.
> 
> I'm not expert, but would the NetworkState key help?  See:
> 
> http://launchd.info/
> 
> Goto "Configuration", scroll down to "...Depending on Network Availability:"

We do have startupitem.netchange.

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

/opt/local/macports/software

[Joshua Root]

Daniel J. Luke wrote:
>> On Jan 19, 2015, at 6:34 AM, René J.V. Bertin  wrote:
>> What could be an option:
>> - use xz instead of bzip2 to compact things a bit more
> 
> this would probably be a small change (I think there's support for gzip and 
> zip already) - but changing your local archive type means you won't get 
> binary archives.

This was true in the past, but no longer. Setting portarchivetype only
affects the type of archives that are generated when building locally.
Each archive site now has an associated archive type, which happens to
be tbz2 for packages.macports.org and its mirrors.

We do support building txz archives already, and they can happily
coexist with downloaded tbz2 ones. The catch is that you have to have
the xz port installed to install or activate any txz archives. So the
default is not going to change unless/until Apple starts shipping xz
with OS X.

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

Re: Multiple MacPort prefixes

[Joshua Root]

On 2014-12-18 01:53 , Tres Finocchiaro wrote:
> I'll fire up a Lion VM for this, thank you.

NP. That's probably the best approach.

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

Multiple MacPort prefixes

[Joshua Root]

> Hi,
> 
> I'm recently trying to bundling some backwards compat software packages
> using a Lion version of XCode  (3.x) on Mavericks and MacPorts.

Xcode 3.x is not the right version to use with Lion, 4.x is. 3.1 is for
Leopard and 3.2 is for Snow Leopard. IIRC, 3.2.6 didn't even work right
on Lion, so I wouldn't expect it to work on Mavericks.

> However, Mavericks had previously been setup with MacPorts and the
> Mavericks version of XCode (5.x).
> 
> The compilation is succeeding when I force the Lion build environment.
> 
> Unfortunately, the Lion builds won't run on Lion.

The Apple-endorsed way to build for an older OS version has always been
to use the latest Xcode and set MACOSX_DEPLOYMENT_TARGET to the oldest
version you want to target.

MacPorts doesn't officially support doing this, mainly because autoconf
and similar systems consider it to be cross-compiling and need you to
tell them about the target manually, instead of being able to detect the
characteristics of the build machine automatically.

> Ideally, I'd like to have two MacPorts installs that I can build software
> against... One for Mavericks and a second instance for Lion.

You can certainly configure MacPorts to use a different prefix when
building it from source.

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

Identifying newly available ports

[Joshua Root]

> Howdy all.
> 
> I’ve been using macports for a number of years, but have never figured out 
> how to readily identify NEW ports (newly available ports, not updates of 
> existing packages).  I am forced to root around in the ports list or the 
> categories among thousands of files, like a pig after a shiny, smelly new 
> truffle. Am I overlooking something obvious?
> 
> Thanks.
> DMW

There isn't really a good way, but this works as a first approximation
of what you want:

svn log --search new
https://svn.macports.org/repository/macports/trunk/dports

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

Friendly reminder: we have another list :)

[Joshua Root]

Not to be the OT police, but all the recent portfile development
discussion on this list would be much more at home on macports-dev.

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

Re: [KDE/Mac] MacPorts usage statistics

[Joshua Root]

On 2014-12-8 07:45 , Marko Käning wrote:
> Hi René,
> 
> On 07 Dec 2014, at 21:32 , René J.V. Bertin  wrote:
>> That calls for a bit of lobbying -- or maybe a survey how many MacPorts 
>> users were aware of the port's existence.
>>
>> Not me in any case…
> 
> well, the original thread started off wrt Homebrew [1] and was then followed 
> by [2].
> 
> And yes, graphs like these [3] are very helpful when trying to understand 
> what to focus on.
> 
> I didn’t imagine, that already 40% of the (contributing) users are on OSX 
> 10.10 and only 30% on 10.9...
> 
> Interesting also, that 10.6 is still THIRD!!! :-)

Note that the sample size is only 50, and that's almost certainly
heavily skewed towards committers.

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

MacPorts 2.3.3 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.3.3. This is a bugfix release which addresses performance issues when
using the SQLite version included with Yosemite.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.10,
10.9, 10.8, 10.7, 10.6, 10.5 and 10.4 (10.6 is universal i386/x86_64;
10.4 and 10.5 are i386/ppc) at [2]. The source is also available as
tarballs compressed with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 


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

Logging bug (was: Port update outdated problem.)

[Joshua Root]

> I don't truly understand how base works and fits together, and my feeling is 
> few people do, or someone would have figured out the solution to weird bugs 
> like https://trac.macports.org/ticket/37093 by now.

I assure you the logging code is not that hard to understand compared
with some other parts of base. That bug not being fixed is down to it
not happening very often in the wild (I've personally never seen it) and
nobody having provided a reduced test case.

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

controlling Macports version of Apache2 -- part 2

[Joshua Root]

>> On Oct 23, 2014, at 9:42 PM, Brandon Allbery  wrote:
>> 
>> On Thu, Oct 23, 2014 at 9:37 PM, William H. Magill  wrote:
>> What is the equivalent today? MacPorts does not contain a Lynx port which 
>> the search command can find.
>> 
>> links or elinks, probably. Ports exist for both. There's also w3m and netrik.
>> 
>> ("port search browser" also tells me there is indeed a lynx port. What 
>> exactly did you use with "port search"?)
> 
> Using the search function on the web page: 
> 
> https://www.macports.org/ports.php?by=category&substr=Lynx
> 
> And
> 
> https://www.macports.org/ports.php?by=category&substr=lynx
> 
> 
> T.T.F.N.
> William H. Magill

You were searching by category (and there is no "lynx" category).
Searching by name works:

https://www.macports.org/ports.php?by=name&substr=lynx

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

Cyrus-IMapd fails to build on 10.10

[Joshua Root]

> On Oct 21, 2014, at 8:45 PM, Horst Simon wrote:
> 
>> OS/X 10.10, Xcode 6.1 and Command Line tools 6.1.
>> 
>> cyrus_imapd fails again to build, but this time it appears to be a different 
>> error:
> 
> Ok, the log says:
> 
>> :info:build Can't locate Digest/SHA1.pm in @INC (@INC contains: 
>> /opt/local/lib/perl5/site_perl/5.16.3/darwin-thread-multi-2level 
>> /opt/local/lib/perl5/site_perl/5.16.3 
>> /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level 
>> /opt/local/lib/perl5/vendor_perl/5.16.3 
>> /opt/local/lib/perl5/5.16.3/darwin-thread-multi-2level 
>> /opt/local/lib/perl5/5.16.3 /opt/local/lib/perl5/site_perl 
>> /opt/local/lib/perl5/vendor_perl .) at ./mkchartable.pl line 51.
> 
> So, is the p5.16-digest-sha1 port installed? If not, try installing it.

The port depends on perl5.12. Earlier in the log:

> :info:configure checking for /opt/local/bin/perl5.12... no

Start with that. (Try checking the config.log.)

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

MacPorts 2.3.2 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.3.2. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.10,
10.9, 10.8, 10.7, 10.6, 10.5 and 10.4 (10.6 is universal i386/x86_64;
10.4 and 10.5 are i386/ppc) at [2]. The source is also available as
tarballs compressed with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 


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

libgcc update ... to 4.9?

[Joshua Root]

> On Aug 21, 2014, at 12:17, Clemens Lang wrote:
> 
>> I couldn't see anything that would prevent the use of binary archives. Can 
>> you
>> attach the main.log of an attempt to install a package that should use binary
>> archives, but didn't?
> 
> I still had the log from the attempt to install libgcc 4.9; it's attached.

The log shows that the configure phase was already complete. So it
picked up from where it left off and continued on with the build phase.

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

Re: Undo universal?

[Joshua Root]

On 2014-8-21 03:54 , Brandon Allbery wrote:
> On Wed, Aug 20, 2014 at 1:31 PM, Joshua Root  <mailto:j...@macports.org>> wrote:
> 
> >> What about:
> >>
> >> sudo port upgrade --enforce-variants OpenSceneGraph -universal
> >>
> >> - Josh
> >>
> >
> > I believe that would just change OpenSceneGraph, not the 35 or so
> dependents.  Can anyone verify?
> 
> Upgrade is a recursive procedure unless you use the -n option. But if it
> wasn't, you could add rdepof:OpenSceneGraph to the expression.
> 
> 
> While it's recursive, a dependency being +universal is unlikely to break
> the dependent when it's -universal so I would not expect it to do
> anything by itself.

I'm not quite clear on what you mean here (are you thinking of
rev-upgrade rather than upgrade?), but the --enforce-variants flag means
"make all the ports touched by the upgrade have the variants I'm
specifying". So it will definitely do something unless the variants
already match.

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

Re: Undo universal?

[Joshua Root]

On 2014-8-21 03:28 , Adam Dershowitz Ph.D., P.E. wrote:
> 
> 
> On Aug 20, 2014, at 1:22 PM, Joshua Root  wrote:
> 
>>> I had OpenSceneGraph installed, but, for another application I was testing, 
>>> I needed a universal version.  So, I did 
>>> sudo port install OpenSceneGraph +universal  
>>> It then proceeded to upgrade MANY things to universal.  I hadn’t realized 
>>> how many dependencies there were.
>>> My question is, is there a way to undo that?  If I am done with that 
>>> testing, so I no longer need the universal version of OpenScenegraph (and 
>>> then the many dependencies).  If I just do:
>>> sudo port deactivate OpenSceneGraph +universal
>>> sudo port activate OpenSceneGraph 
>>> sudo port uninstall OpenSceneGraph +universal
>>> I believe that it would remove that one thing.  But, it won’t then follow 
>>> all the dependencies.  Is there any way to make all the dependencies that 
>>> would no longer have to be universal be removed and just have the original 
>>> versions made active?
>>>
>>> Essentially I am looking for a command:  
>>> Make OpenSceneGraph and all dependents no longer universal
>>
>> What about:
>>
>> sudo port upgrade --enforce-variants OpenSceneGraph -universal
>>
>> - Josh
>>
> 
> I believe that would just change OpenSceneGraph, not the 35 or so dependents. 
>  Can anyone verify?

Upgrade is a recursive procedure unless you use the -n option. But if it
wasn't, you could add rdepof:OpenSceneGraph to the expression.

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

Use proxy only on one network

[Joshua Root]

> I'm experimenting with running a proxy server on my network, which I would 
> like MacPorts to use while on that network, while not interfering with my 
> ability to use MacPorts while connected to other networks. What's the best 
> way to do this in an automated way? Editing macports.conf proxy settings 
> every time I switch networks is cumbersome. Similarly manually setting and 
> unsetting environment variables. I'm currently thinking of wrapping the 
> "port" command in a shell function (which I already do) and using the IP 
> address or AirPort network name to determine whether I'm on the home network 
> and setting the environment variables accordingly. I'm also dimly aware of OS 
> X's network locations feature, but way back when those were introduced I 
> remember you had to manually select which location you wanted to use.

This is what I have on my laptop:

LOCATION=$(scselect 2>&1 | grep "^ \*" | cut -f 2)
case "$LOCATION" in
"(Home)")
unset http_proxy
unset FTP_PROXY
;;
"(Work)")
export http_proxy="http://workproxy:3128";
export FTP_PROXY="http://workproxy:3128";
;;
*)
echo unknown location $LOCATION
;;
esac

There are apps that will switch locations for you automatically based on
AirPort SSID or other network characteristics. Alternatively you could
look at the output of something like 'networksetup -getairportnetwork
en1' instead of the scselect command used above .

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

Undo universal?

[Joshua Root]

> I had OpenSceneGraph installed, but, for another application I was testing, I 
> needed a universal version.  So, I did 
> sudo port install OpenSceneGraph +universal  
> It then proceeded to upgrade MANY things to universal.  I hadn’t realized how 
> many dependencies there were.
> My question is, is there a way to undo that?  If I am done with that testing, 
> so I no longer need the universal version of OpenScenegraph (and then the 
> many dependencies).  If I just do:
> sudo port deactivate OpenSceneGraph +universal
> sudo port activate OpenSceneGraph 
> sudo port uninstall OpenSceneGraph +universal
> I believe that it would remove that one thing.  But, it won’t then follow all 
> the dependencies.  Is there any way to make all the dependencies that would 
> no longer have to be universal be removed and just have the original versions 
> made active?
> 
> Essentially I am looking for a command:  
>   Make OpenSceneGraph and all dependents no longer universal

What about:

sudo port upgrade --enforce-variants OpenSceneGraph -universal

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

Re: gnupg12, gnupg users, please reply.

[Joshua Root]

On 2014-7-7 10:00 , Mihai Moldovan wrote:
> Hi gpg users,
> 
> We currently have three unmaintained ports for gnupg: gnupg (ver 1.4), gnupg12
> (ver 1.2) and gnupg2 (ver 2.x).
> 
> In order to implement proper launchd integration in gpg-agent, I will likely
> have to slightly patch gnupg as well.
> 
> If anyone here is (actively) using gpg 1.4 or 1.2, please reply. Why do you 
> need
> those ports? Is switching to gpg 2 an option for you?
> If you only "use" gpg as a dependency of some other port, you don't have to do
> anything. All ports currently depending on gnupg12 or gnupg seem to be
> compatible with gnupg2 (at least after a version bump.)
> 
> I'd like to get rid of gnupg and gnupg12 after a grace period.

I doubt we need gnupg12 any more. However I'm using gnupg because it
does everything I need, and it's still maintained upstream, so why
install the extra deps for gnupg2?

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

Re: Troubles installing ports with Macports 2.3.1

[Joshua Root]

On 2014-7-3 04:38 , Ryan Schmidt wrote:
> 
> On Jul 2, 2014, at 2:25 AM, Joshua Root wrote:
> 
>>> On Jul 1, 2014, at 4:58 AM, Joël Brogniart wrote:
>>>
>>>> I suppose that, during the "Computing dependencies for 
>>>> auto-multiple-choice" phase, a lot of http requests are made to obtain 
>>>> port information and that these requests are not fully closed either by 
>>>> Macports or by the proxy. As this problem is recent (at least for me), it 
>>>> is perhaps related to a recent Java update (the proxy is a java 
>>>> application).
>>>
>>> During "computing dependencies", no http requests would be made by 
>>> MacPorts, as far as I know.
>>
>> To determine whether build dependencies are required, it must know
>> whether an archive is available, and to find that out, it (usually) must
>> query the packages server.
> 
> Ok, but that would only be enough http requests to determine if an archive 
> for the main port is available, right? So ideally 1 http request (in the case 
> where the archive exists on the server it tried), or maybe a few requests (to 
> check a few additional servers). It wouldn't be proportional to the number of 
> dependencies.

Dependency calculation is a recursive process. Dependencies can have
dependencies of their own.

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

Troubles installing ports with Macports 2.3.1

[Joshua Root]

> On Jul 1, 2014, at 4:58 AM, Joël Brogniart wrote:
> 
>> I suppose that, during the "Computing dependencies for auto-multiple-choice" 
>> phase, a lot of http requests are made to obtain port information and that 
>> these requests are not fully closed either by Macports or by the proxy. As 
>> this problem is recent (at least for me), it is perhaps related to a recent 
>> Java update (the proxy is a java application).
> 
> During "computing dependencies", no http requests would be made by MacPorts, 
> as far as I know.

To determine whether build dependencies are required, it must know
whether an archive is available, and to find that out, it (usually) must
query the packages server.

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

MacPorts 2.3.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.3.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.9,
10.8, 10.7, 10.6, 10.5 and 10.4 (10.6 is universal i386/x86_64; 10.4 and
10.5 are i386/ppc) at [2]. The source is also available as
tarballs compressed with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 

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

Problem compiling gnome-libs

[Joshua Root]

> 1) I assume that this or another error must be occurring on the bulk build
> server as there is no pre-built package.

It's because of the same error. Open a ticket and attach your config.log.

> 2) On my old PB G4 running Leopard, I can get past Configure, but the build
> dies later on with some complaint about libpng include files.

I would guess the configure checks are doing something invalid that
clang treats as an error but old gcc doesn't.

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

Idle (Python) on OS X Mavericks

[Joshua Root]

> Ok, I’ve got python2.7 and 3.4 from Macports installed. I’m trying to use 
> idle but the error printed is:
> 
> ** IDLE can’t import Tkinter. Your Python may not be configured for tk **
> 
> I also installed the py34-tkinter port as I believe this port contains the 
> required libraries for Idle. The same error is printed. 
> 
> Could it be a $PATH issue or missing libraries issue or both?
> 
> PATH is currently set to: 
> 
> /Users/jamie/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/Users/jamie/bin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/texbin
> 
> Some repetition of directories but that shouldn’t cause a problem (I don’t 
> think)
> 
> Would anyone be able to offer some advice/info?

How are you starting IDLE? I just installed python34 and py34-tkinter
and double-clicking on /Applications/MacPorts/Python 3.4/IDLE.app works
fine. (If you want to run /Applications/MacPorts/Python 2.7/IDLE.app
then of course you would need py27-tkinter.)

PATH should have no effect here. PYTHONPATH could, though it would have
to be set globally by launchd to affect an app launched from Finder.
There are various other ways that sys.path can be modified in python,
and these could certainly stop the tkinter module from being found.

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

Re: 'port build' is getting EPERM from access(2) on "/var/tmp"

[Joshua Root]

On 2014-5-25 09:21 , Quentin Barnes wrote:
> On Sat, May 24, 2014 at 10:18:12AM +1000, Joshua Root wrote:
>> I'm not sure what exact syscalls test -w uses,
> 
> That was covered in my base note, access("/var/tmp", W_OK).
> 
>> but possibly allowing
>> file-write-data on /var/tmp would be correct and allow it to succeed.

Well, try this:

Index: src/port1.0/portsandbox.tcl
===
--- src/port1.0/portsandbox.tcl (revision 120356)
+++ src/port1.0/portsandbox.tcl (working copy)
@@ -89,6 +89,7 @@
 (allow file-write-data (literal \"/dev/null\") (literal \"/dev/zero\") \
 (literal \"/dev/dtracehelper\") (literal \"/dev/tty\") \
 (literal \"/dev/stdin\") (literal \"/dev/stdout\") (literal
\"/dev/stderr\") \
+(regex #\"^(/private)?(/var)?/tmp\$\") \
 (regex #\"^/dev/fd/\")) (allow file-write* \
 (regex #\"^(/private)?(/var)?/tmp/\" #\"^(/private)?/var/folders/\"))"


>> But it wouldn't hurt for the script to try $TMPDIR as well.
> 
> I suspect that's not going to work well since the configure script
> is looking for a writable tmp directory to compile into the program
> for when it is run by the user after installation.

Ah, OK. The right thing would be for the program to look at TMPDIR at
runtime then. I guess it would still want a fallback in case TMPDIR
isn't set, so the configure script should provide a way to specify one
directly in case it can't find one automatically. You can probably
override some autoconf var on the command line without even modifying
the script.

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

MacPorts 2.3.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.3.0 version has now
been released. It is available via the usual methods:

 - selfupdate if you already have MacPorts installed
 - package installers for 10.4 [1], 10.5 [2], 10.6 [3], 10.7 [4], 10.8
[5] and 10.9 [6] (all universal builds, i386/ppc for 10.4/10.5 and the
others i386/x86_64)
 - source tarballs, both .tar.bz2 [7] and .tar.gz [8]
 - subversion tag [9]

The list of what's new in 2.3.0 can be found in the ChangeLog [10].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.3.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [11].

- Josh

[1] 
[2]

[3]

[4] 
[5]

[6]

[7] 
[8] 
[9] 
[10]

[11] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: 'port build' is getting EPERM from access(2) on "/var/tmp"

[Joshua Root]

On 2014-5-24 03:19 , Quentin Barnes wrote:
> On Tue, May 13, 2014 at 05:34:31AM +1000, Joshua Root wrote:
>> We do exclude /var/tmp itself with the regex we use. We certainly don't
>> want to allow file-write* on it, but possibly one of the subsets could
>> be added safely.
> 
> Obviously, in the sandbox /var/tmp can be written to since I can
> touch a file underneath it, so I'm not sure I follow your last point.

I believe the checks operate purely on the (normalised) path. So when we
say:

(allow file-write* \
(regex #\"^(/private)?(/var)?/tmp/\" #\"^(/private)?/var/folders/\"))

operations that specify /var/tmp/foo as their target will be allowed,
but not ones that specify /var/tmp.

> Could you explain what you meant by the "*"?

The complete list of operations covered by file-write* is, to the best
of my knowledge:

file-write-data
file-write-flags
file-write-mode
file-write-mount
file-write-owner
file-write-setugid
file-write-times
file-write-unmount
file-write-xattr

> The configure script is searching a potential list for a valid
> directory on the system that it has write access to for its scratch
> files.  It iterates using a "if test -d $i -a -w $i; then ..." test.
> 
> What should be the most appropriate, long-term fix?  Change the
> sandbox config in some way?  Patch the configure script?

I'm not sure what exact syscalls test -w uses, but possibly allowing
file-write-data on /var/tmp would be correct and allow it to succeed.

But it wouldn't hurt for the script to try $TMPDIR as well.

> Can the sandbox config be changed so it creates a writable scratch
> tmp directory and then transforms /var/tmp paths to point to it?

No, all sandboxing can do is deny access to stuff. We do already set
TMPDIR to "${workpath}/.tmp".

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

MacPorts 2.3.0-rc2 now available for testing

[Joshua Root]

Source code and pkg/dmgs for MacPorts 2.3.0-rc2 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no showstopping bugs are found in the next few days, this will become
the 2.3.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since rc1 are:
 * Fixed files being installed with too restrictive permissions when the
user has a restrictive umask.
 * Portability fixes (for the rsync server, which generates the PortIndex)

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: 'port build' is getting EPERM from access(2) on "/var/tmp"

[Joshua Root]

On 2014-5-13 05:01 , Clemens Lang wrote:
> Hi,
> 
> Please keep the conversation on the list so others with the same problem
> can follow.
> 
>> Yes!  The `sandbox_enable no' hack worked around the problem.
>>
>> Can you reproduce the problem by creating a fake package and trying the
>> "test -w /var/tmp"?
> 
> Yes, I can reproduce this with a minimal example:
> 
>   PortSystem  1.0
>   nametest
>   version 1.0
>   maintainers cal
>   categories  test
>   description Description
>   long_descriptionLongDescription
>   platforms   darwin
>   homepageHomepage
>   distfiles
>   configure {
>   system "test -w /var/tmp"
>   system "test -w /var/tmp/"
>   system "test -w /var/tmp/foo"
>   }
> 
> I'm not sure why it fails for /var/tmp/foo, though – my understanding is it
> should work.

You would have to create foo first.

>> What else would you like me to try?
> 
> I've CC'd somebody more knowledgeable on sandboxing than I am. Joshua, any
> idea what's wrong here or is this expected behavior?

We do exclude /var/tmp itself with the regex we use. We certainly don't
want to allow file-write* on it, but possibly one of the subsets could
be added safely.

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

Re: Migration question and binary question

[Joshua Root]

On 2014-5-10 00:03 , Brandon Allbery wrote:
> On Fri, May 9, 2014 at 1:39 AM, Joshua Root  <mailto:j...@macports.org>> wrote:
> 
> Handling variants of dependencies correctly is precisely why
> restore_ports.tcl exists. The lack of automatic preservation of the
> requested flag is an annoyance, certainly, but you can get around it by
> running this at the same time you generate myports.txt:
> 
> port echo requested | cut -d ' ' -f 1 > requested.txt
> 
> and this after you've run restore_ports.tcl and 'port unsetrequested
> installed':
> 
> < requested.txt xargs port setrequested
> 
> 
> Isn't this backwards? That is, all ports would show as requested and you
> need to set unrequested the ports not in the original requested list?

That's what the 'port unsetrequested installed' is for. But sure, you
could save and restore a list of unrequested ports instead.

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

MacPorts 2.3.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.3.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.3.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since beta2 are:
 * version number only

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Migration question and binary question

[Joshua Root]

Jerry wrote:
> I am considering using the "Automatically reinstall ports" suggestion whereby 
> a script is downloaded which script then works with a previously saved 
> myports.txt. If I do this, will the script install old versions of ports 
> which had not been active? I'm thinking that this might be a good time to do 
> some decrufting and I would like to consider these old inactive versions as 
> mostly cruft and not reinstall them.

As Ryan said, it can only install the current version of each port. But
if you have a port installed with different variants, it will reproduce
that. E.g. if you start with this:

foo @1.0_0
foo @1.0_0+bar (active)
foo @1.1_0

then if 1.1 is the current version of foo, after running restore_ports
you will have:

foo @1.1_0+bar (active)
foo @1.1_0

After you generate myports.txt, it's worthwhile to glance through it and
delete any lines you don't want any more, as well as to adjust some of
the variants if desired, as Brandon suggested.

Brandon Allbery wrote:
> On Thu, May 8, 2014 at 6:26 PM, Jerry  wrote:
> 
>> I redirected this output to .txt files. Do you have a quick way (script)
>> to use these echoed files during reinstallation?
> 
> 
> I don't need to do it often enough to script it, I generally build it on
> the fly :)
> 
> port echo active and requested | perl -lpe 's/[ \t]+\@[^-+]+/ /;
> s/^/port install /'
> 
> Output is something you can feed to /bin/sh, via sudo; you may want to
> check it for sanity and possibly add/remove some things manually. One thing
> it doesn't deal with is possible changes in default variants, because it's
> difficult to script. For example, the default perl5 variant has changed
> from +perl5_12 to +perl5_16 within the past several months --- you may want
> to take the chance to upgrade stuff to the new default rather than
> propagating the old. It also doesn't try to deal with dependencies, so
> there is some chance that a dependency of something earlier in the list
> will install with default variants something later in the list with an
> explicit variant; there's no good way to deal with this in MacPorts
> currently, especially when variants can alter dependencies (and I'm not
> sure that a "good way to deal with this" even exists).

Handling variants of dependencies correctly is precisely why
restore_ports.tcl exists. The lack of automatic preservation of the
requested flag is an annoyance, certainly, but you can get around it by
running this at the same time you generate myports.txt:

port echo requested | cut -d ' ' -f 1 > requested.txt

and this after you've run restore_ports.tcl and 'port unsetrequested
installed':

< requested.txt xargs port setrequested

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

MacPorts 2.3.0-beta2 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.3.0-beta2 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Notable changes since beta1 are:
 * Added a port-tclsh link for the use of contrib scripts, and removed
   the requirement for them to source macports_fastload.tcl.
 * Fixed pkg_mkIndex failure at build time on Leopard and Tiger
 * Fixes for trace mode when not running as root
 * Fixed an error when executing portfiles from the registry

Known issue: make install will fail on Tiger due to chmod not accepting
the -h option. A fix is already on the branch:


Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

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

Problem pyton PIL

[Joshua Root]

> On Tue, Apr 15, 2014 at 9:00 AM, Spinxer  wrote:
> 
>> $ python
>> Python 2.7 (r27:82508, Jul  3 2010, 21:12:11)
>> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
>>
> 
> You're getting /usr/bin/python (Apple's build). No idea what's up with its
> PIL.
> 
> You probably want `sudo port select --set python python27; hash -r` to (a)
> set MacPorts python as default and (b) tell your shell to check $PATH again
> instead of using the Apple one it found before.

That's not /usr/bin/python, as that would be 2.5 on Leopard. But it's
clearly also not (an up-to-date) MacPorts python2.7 since that would be
2.7.6.

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

OpenSSL

[Joshua Root]

Niels Dettenbach wrote:
> On 8. April 2014 05:34:28 MESZ, Ludwig  wrote:
>>What else do I need to do about the addressed vulnerability besides
>>updating
>>the port — generate new keys or what?
> 
> ...as far as i informed about the current security notice / patch in OpenSSH 
> (!) it makes no sense to generate new host or client keys. It could make 
> sense to delete the known_hosts as the sec flaw could make it possible in 
> curcumstances that a new client connects to a DNS faked host when not 
> verifying the host key fingerprint during the host verifying process.

According to heartbleed.com, any data that was in the memory of the
process using openssl could have been revealed to an attacker. That
would include private keys.

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

MacPorts 2.3.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.3.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

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

py27-gst-python, targeting gstreamer1 vs gstreamer010

[Joshua Root]

> Is there a port which is like py27-gst-python, but for gstreamer1 instead?

Apparently there's no need for a specific installation of gstreamer
python bindings any more with the new version; everything can be done
via gobject-introspection and pygobject.

I don't know much more about it than that, but hopefully that's enough
to get you started.

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

Re: Swarm on OS X 10.9

[Joshua Root]

> On Feb 6, 2014, at 00:48, Degang Wu wrote:
> 
>> Is there any progress in "porting" swarm to OS X 10.9? What prevents it to 
>> build on 10.9? I tried to build it from the source, but have encountered 
>> errors after errors.
> 
> I don’t know why the port is disabled on Mavericks.

I would guess because it doesn't build with clang and contains C++.
Because llvm-g++-4.2 always uses libstdc++, it's only safe to build C++
with it on Mavericks when none of the dependencies and dependents
contain any C++ code, or all of them also link with libstdc++.

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

Re: cutting the tree: is there a way to remove leaves recursivelly?

[Joshua Root]

sudo port uninstall --follow-dependencies leaves

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

Re: Scheduled downtime on Jan 28, 15-19 UTC

[Joshua Root]

On 2014-1-24 05:44 , Rainer Müller wrote:
> Hello,
> 
> there will be a scheduled downtime for all MacPorts services due to
> maintenance at our hosting provider MacOSforge. The servers will be
> available with new IP addresses after the downtime, which will take up
> to an hour until the change propagates in DNS due to caching.
> 
> The services will be affected on Tuesday, January 28th, from 15:00 to at
> least 19:00 UTC.

This downtime has been postponed. We'll let you know when a new time is set.

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

Re: Troubles installing rc

[Joshua Root]

> 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. Fixed in r116136.

> Or maybe it's some other newfangled security device misfiring.
> I can certainly run the install command by hand without problem.

Yes, sandboxing is doing its job here.

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

Re: Trouble updating gnucash to current version with quartz

[Joshua Root]

> On Dec 29, 2013, at 05:19, Olaf Föllinger wrote:
> 
>> Error: org.macports.build for port gnome-desktop returned: command
>> execution failed
>> Please see the log file for port gnome-desktop for details:
>> 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-desktop/gnome-desktop/main.log
>> To report a bug, follow the instructions in the guide:
>>http://guide.macports.org/#project.tickets
>> Error: Processing of port gnome-desktop failed
> 
> This output just tells us that an error occurred; it doesn’t tell us what 
> error occurred. For that, we’d need to examine the main.log file.
> 
> 
>> The problem is https://trac.macports.org/ticket/19939 "gnome-desktop
>> fails to build with +quartz”. Since the ticket is open since 5 years
>> there must be a workaround to build gnucash +quartz but I cannot find it.
> 
> For a ticket that has been open for a long time with no resolution, I’d 
> assume that either the problem has been fixed by someone who was not aware of 
> the ticket, or nobody who’s encountered the ticket knows how to fix it. If 
> you’ve examined the main.log file and matched its contents to what’s in the 
> ticket, then it appears to be the latter.

It's worth noting that gnome-desktop doesn't actually have a quartz
variant any more.

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

Re: gcc48/gcc49: isalnum/isgraph: Undefined symbols for architecture x86_64

[Joshua Root]

On 2013-11-7 10:44 , Brian D. McGrew wrote:
>>>
>> Shouldn't that be '#include ' since you're compiling as C++?
> 
> Yeah, probably so.  It¹s compiled like this for over a year in MacOS 7 and
> 8Š  It¹s just now that I¹ve gone to 9 it¹s a problem.  And, changing it to
> #include  didn¹t change anything.

OK. I don't have Mavericks so I couldn't test. I was thinking maybe they
completely inlined the C functions, so maybe there was a different
version for C++.

You might try using std::isalnum, or including  which has its
own versions.

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

gcc48/gcc49: isalnum/isgraph: Undefined symbols for architecture x86_64

[Joshua Root]

> Hello all,
> 
> I’m getting an undefined symbol for isalnum and isgraph using g++-mp-4.8.
> 
> I found this article here: 
> http://stackoverflow.com/questions/19649421/something-odd-happened-to-c-11-in-mavericks
>  which mentions the issue in Mavericks and the Xcode command line tools.  
> However, I’m using MP and the g++ from mp when trying to build.  And yes, I 
> rebuilt ports, from scratch, when I upgraded (clean install) to Mavericks.
> 
> It could just be me missing something, but I’ve tried everything I can think 
> of and every combination of google searches to figure this one out.  The code 
> is very simple (I think).  Oh, and yes, I did a +universal when I installed 
> gcc49 and gcc48.  And if it matters, I installed gcc49 (with libgcc) before 
> gcc48.  When I tried gcc48 then gcc49 I got an error about libgcc, but doing 
> it the other way works.
> 
> What am I missing???
> 
> Thanks,
> 
> -b
> 
> #include 

Shouldn't that be '#include ' since you're compiling as C++?

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

MacPorts 2.2.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.2.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.9,
10.7, 10.6, 10.5 and 10.4 (universal builds, the last two i386/ppc
and the others i386/x86_64) at [2]. The source is also available as
tarballs compressed with gzip or bzip2, or from the subversion tag [3].

A 10.8 pkg will be available soon; in the meantime you can use 2.2.0 for
new installs and run selfupdate as above.

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

The Mavericks pkg was built by Adam Mercer, and is signed with his
Developer ID.

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 

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

Downgrading squid3

[Joshua Root]

It's pretty garbled because of overlapping output from multiple make
jobs (append 'build.jobs=1' to the command to avoid this BTW), but it
looks like the failure is due to a compiler warning about a tautological
comparison, which is escalated to an error because -Werror is used.

The current squid3 portfile has --disable-strict-error-checking in
configure.args to prevent the use of -Werror.

(BTW, please don't send full logs to the list; most subscribers likely
don't want to see or download them. Host them somewhere, e.g. a pastebin
service, and send the URL to the list.)

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

MacPorts 2.2.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.2.0 version has now
been released. It is available via the usual methods:

 - selfupdate if you already have MacPorts installed
 - package installers for 10.5 [1], 10.6 [2], 10.7 [3], and 10.8 [4]
   (all universal builds, i386/ppc for 10.5 and the others i386/x86_64)
 - source tarballs, both .tar.bz2 [5] and .tar.gz [6]
 - subversion tag [7]

The list of what's new in 2.2.0 can be found in the ChangeLog [8].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.2.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [9].

- Josh

[1]

[2]

[3] 
[4]

[5] 
[6] 
[7] 
[8]

[9] 

PS, my PGP key ID is 63BAD8CF2A10D5EE,
fingerprint 5F83 E16B D885 0601 5084  63C2 63BA D8CF 2A10 D5EE
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

MacPorts 2.2.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.2.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

While there are no known regressions from 2.1.3 at this point, be
prepared to encounter bugs. As always, having a recent backup would be
wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.2.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Notable changes since beta1 are:
 * fixed disabling the default archive source in archive_sites.conf
 * workaround: disabled sandboxing for the 'pkg' target on 10.8 until a
   real fix can be found.

NOTE FOR DEVELOPERS RUNNING THE 10.9 MAVERICKS PREVIEW:
Deletion of libtool archives (".la" files) now happens by default. You
will want to reinstall all your ports to avoid build failures. As a
temporary workaround you can add 'delete_la_files no' to macports.conf,
but this should not be relied upon long-term.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

MacPorts 2.2.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.2.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

There is one known issue:
* 'port pkg' may fail on 10.8 when sandboxing is enabled.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

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

qt4-mac using wrong g++

[Joshua Root]

> On Feb 11, 2013, at 15:21, Frank J. R. Hanstick wrote:
> 
>> I thought that MacPorts defaulted to the system gcc default setting(s) 
>> (limited to Apple certified versions of course) rather than a hard coded 
>> default setting.
> 
> The hardcoded default compiler in MacPorts, which varies by Xcode version, 
> was meant to mirror the default compiler used by that version of Xcode, but 
> in the case of Leopard there seems to have been some discrepancy. Perhaps 
> Leopard's Xcode used to default to gcc 4.0 and then changed to 4.2 later and 
> we didn't notice. I thought it was that "gcc" on the command line was gcc-4.0 
> while in Xcode projects gcc-4.2 was used by default, but I could be mistaken.

Frank expected whereis(1) to behave differently than it in fact does.
His 'port select' output shows that his 'gcc' is /opt/local/bin/gcc. On
Leopard, /usr/bin/{gcc,g++} are links to {gcc-4.0,g++-4.0}.

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

How to get a full list of dependents?

[Joshua Root]

> Apparently commands such as "port dependents xxx" or "port echo 
> dependentof:xxx"
> will only list *installed* dependents --- and "xxx" must itself be installed.
> 
> How can I get a full list of ports that are dependents of "xxx", whether or 
> not
> they or "xxx" are installed?
> 
> ATM I would like to see which ports depend on Growl and which depend on
> MacPorts_Framework.  Pallet depends on both, but are there others?

port echo depends:Growl

This uses the index, so it won't find dependencies that are added in
non-default variants.

> If I wish to make a change in MacPorts_Framework, what might be the impact
> on ports other than Pallet, or is Pallet the only user?
>
> Ditto, if I wish to remove the dependency of Pallet on Growl?  Do
other ports
> use it successfully?  It is apparently not doing anything in Pallet.

This (and other questions regarding development of Pallet and
MacPorts.framework) is probably more suited to the macports-dev list,
where you'll get the attention of more developer types.

MacPorts_Framework is still in a pretty "pre-alpha" state, so I wouldn't
worry too much about maintaining compatibility if not doing so will make
it better. Just make sure you mention the interface breakage in the
commit logs, and fix Pallet to match.

Growl support is good to have, but Pallet should still be usable without
Growl.

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

MacPorts 2.1.3 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.1.3. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.4,
10.5, 10.6, 10.7 and 10.8 (universal builds, the first two i386/ppc and
the others i386/x86_64) at [2]. The source is also available as tarballs
compressed with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x63BAD8CF2A10D5EE: 5F83 E16B D885 0601 5084  63C2 63BA D8CF 2A10 D5EE

The Mountain Lion pkg was built by Adam Mercer, and is signed with his
Developer ID.

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 

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

mongodb-2.2.2_0 binaries for ML 10.8 missing from MacPorts

[Joshua Root]

Lawrence Velázquez wrote:
> On Dec 9, 2012, at 11:08 PM, Behrang Saeedzadeh  
> wrote:
> 
>> Is this intentional or are the binaries eventually going to be added to 
>> MacPorts?
> 
> We cannot distribute a binary for mongodb because it has a dependency on 
> openssl, and their licenses conflict.
> 
> % cd ~/Projects/MacPorts/trunk/base/portmgr/jobs
> % ./port_binary_distributable.tcl -v mongodb
> dependency 'openssl' has license 'OpenSSL' which conflicts with license 
> 'agpl' from 'mongodb'
> 
> Admittedly, it's only a build dependency (mongodb -> scons -> python27 -> 
> openssl). Don't know if that makes a difference.

Needs "license_noconflict scons".

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

Re: dyld: Library not loaded: libmaloc.dylib

[Joshua Root]

On 2012-12-9 14:42 , Ryan Schmidt wrote:
> On Dec 8, 2012, at 17:26, Jeremy Huddleston Sequoia wrote:
> 
>> On Dec 7, 2012, at 1:50 PM, "Yao, Xiaolan" wrote:
>>
>>> I installed Pymol and the APBS plugin using MacPorts.  I  tried to
>>> run APBS calculations within Pymol, but it didn't give the proper
>>> output and I think the following message might be the reason:
>>>
>>> dyld: Library not loaded: libmaloc.dylib
>>>
>>> What should I do to solve this problem?
>>>
>>> Also, I have noticed when I try to use the APBS plugin to display
>>> surface electrostatic potential calculated from PDB2PQR server, it is not 
>>> displayed properly. I don't
>>> know if there two problems are related.
>>
>> malloc is provided by libSystem.  What is actually linking against 
>> libmalloc.dylib?  Can you provide the entire crash report?
> 
> I thought it was a typo at first too, but there actually is something called 
> libmaloc with one l:
> 
> http://fetk.org/codes/maloc/
> 
> I don't think we have it in MacPorts though, or if we do, it's being bundled 
> with another port.

APBS uses FEtk, according to its homepage.

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

Re: Fetching anything segfaults when Pextlib calls system Tcl

[Joshua Root]

> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   libSystem.B.dylib 0x7fff85270c00 strlen + 16
> 1   Tcl   0x00010008a350 Tcl_SetResult + 83
> 2   Pextlib.dylib 0x00010070e617 
> SetResultFromCurlErrorCode + 103
> 3   Pextlib.dylib 0x00010070f47c CurlFetchCmd + 1420
> 4   Pextlib.dylib 0x00010070f788 CurlCmd + 184

The relevant code is:


Crashing where and how it does would suggest that curl_easy_strerror is
somehow returning either a bad pointer or an unterminated string. If you
build base from source you can add some debug printfs to see what the
error code is at least, and which operation it comes from.

Given that you're the first to report this problem AFAIK (#31472 is
different), I wouldn't rule out something like bad RAM or disk corruption.

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

Re: any way to use OS 10.3.9?

[Joshua Root]

Ryan Schmidt  wrote:
> You can get an archive of ports from December 14, 2008, from the day MacPorts 
> 1.7.0 was released, here:
> 
> https://svn.macports.org/repository/macports/downloads/MacPorts-1.7.0/
> 
> Using that, you could install the subversion port, then you could get 
> somewhat newer ports from the Subversion repository. For example to check out 
> ports from the day before 1.8.0 was released:
> 
> svn co https://svn.macports.org/repository/macports/trunk/dports -r 
> '{2009-08-28}'

Getting

would be easier and virtually the same (compatible with 1.7.1), since
the archive tarballs are generated just before the corresponding base
version is released.

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

Re: any way to use OS 10.3.9?

[Joshua Root]

David Prager Branner  wrote:
> I have OS 10.3.9 on an old iBook, with Xcode v. 1.5 installed. No higher
> versions of the OS can be installed on this hardware.
> 
> I was able to install and build Macports 1.710, apparently without
> problems, but on the initial
> 
> sudo port -v selfupdate
> 
> I get what appears to be a fatal error:
> 
> Command output: checking build system type... powerpc-apple-darwin7.9.0
> checking host system type... powerpc-apple-darwin7.9.0
> checking target system type... powerpc-apple-darwin7.9.0
> checking MacPorts version... 2.1.2
> checking for sw_vers... /usr/bin/sw_vers
> checking for defaults... /usr/bin/defaults
> checking for xcode-select... no
> checking Mac OS X version... 10.3.9
> configure: error: This version of Mac OS X is not supported
>   Please upgrade at http://store.apple.com/
> 
> Are there any options I can use to enable even partial compatibility with
> my ancient system? Or am I sunk?

It may be feasible, but no guarantees. You would have to meet the
prerequisites for the current version of MacPorts.

1. SQLite. Panther doesn't ship with it. You'd have to install a version
at least as new as the one that ships with Tiger, though a newer version
would be better if possible.

2. Tcl 8.4+. I forget which version of Tcl Panther has, but if it's <
8.4, you'll need to install 8.4.x or 8.5.x. You need tcl threads enabled.

3. You would then need to install MacPorts from source. You'd first need
to edit configure.ac to remove 10.3 from the list of unsupported
versions, and then run ./regen.sh (hopefully you have autoconf? If not
you'd have to just edit the configure script directly.) Then you need to
use configure args to indicate where your SQLite and possibly Tcl
installations are located.

There may be other problems with base. There are definitely problems
with many ports.

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

Re: I need consultation on running WINE on the Mac

[Joshua Root]

On 2012-10-17 05:40 , William H. Magill wrote:
> 
> On Oct 16, 2012, at 7:00 AM, Joshua Root  wrote:
> 
>> After installing wine-crossover, all you should need to run is (all one
>> line, ignore any line breaks inserted by email software):
>>
>> WINEPREFIX="/Users//Library/Application
>> Support/CrossOver/Bottles/Lord of the Rings Online" wine
>> ~/Library/Application\ Support/CrossOver/Bottles/Lord\ of\ the\ Rings\
>> Online/drive_c/Program\ Files/PyLotRO/pylotro.exe
> 
> Hmmm... seems to partially work...  Keep in mind that I have only ever used 
> Crossover, and never "raw WINE." 
> I did install wine-devel, apparently successfully, which I then uninstalled.
> 
>> uninstalled wine-devel
>> sudo port install wine-crossover
>>  "No broken files found."
> 
>> I have multiple bottles, so I simply modified the paths as necessary.
> 
> WINEPREFIX="/Users/magill/Library/Application 
> Support/CrossOver/Bottles/LOTRO-4" wine ~/Library/Application\ 
> Support/CrossOver/Bottles/LOTRO-4/drive_c/Program\ Files/PyLotRO/pylotro.exe
> 
> fixme:heap:HeapSetInformation 0x0 1 0x0 0
> fixme:process:SetProcessDEPPolicy (1): stub
> fixme:heap:HeapSetInformation 0x0 1 0x0 0
> err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make 
> sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in 
> the winbind package of your distribution.
> Application tried to create a window, but no driver could be loaded.
> Make sure that your X server is running and that $DISPLAY is set correctly.
> err:systray:initialize_systray Could not create tray window
> Application tried to create a window, but no driver could be loaded.
> Make sure that your X server is running and that $DISPLAY is set correctly.
> QEventDispatcher: Failed to create QEventDispatcherWin32 internal window: 1
> 
> fixme:system:SetProcessDPIAware stub!
> err:module:import_dll Library QtSvg4.dll (which is needed by L"C:\\Program 
> Files\\PyLotRO\\qt4_plugins\\iconengines\\qsvgicon4.dll") not found
> err:module:import_dll Library QtSvg4.dll (which is needed by L"C:\\Program 
> Files\\PyLotRO\\qt4_plugins\\imageformats\\qsvg4.dll") not found
> QWidget::create: Failed to create window (Invalid window handle.)
> err:module:import_dll Library QtSvg4.dll (which is needed by L"C:\\Program 
> Files\\PyLotRO\\qt4_plugins\\iconengines\\qsvgicon4.dll") not found
> err:module:import_dll Library QtSvg4.dll (which is needed by L"C:\\Program 
> Files\\PyLotRO\\qt4_plugins\\iconengines\\qsvgicon4.dll") not found
> QWidget::create: Failed to create window ()
> wine: Unhandled page fault on read access to 0x0010 at address 0x6514382d 
> (thread 0009), starting debugger...
> Application tried to create a window, but no driver could be loaded.
> Make sure that your X server is running and that $DISPLAY is set correctly.
> Unhandled exception: page fault on read access to 0x0010 in 32-bit code 
> (0x6514382d).
> Register dump:
>  CS:001b SS:0023 DS:0023 ES:0023 FS:1007 GS:000f
>  EIP:6514382d ESP:0032f0c8 EBP:0032f0d8 EFLAGS:00210246(  R- --  I  Z- -P- )
>  EAX:00154ae0 EBX: ECX:00154ae0 EDX:
>  ESI:001548b8 EDI:
> Stack dump:
> ...
> Threads:
> process  tid  prio (all id:s are in hex)
> 0008 (D) C:\Program Files\PyLotRO\pylotro.exe
>   00280
>   00090 <==
> 
> 
>  Correct, I have not installed X11, and therefore no X server. However, I 
> thought PyLotRO bypassed that issue by using Python.

PyLotRO uses the PyQt bindings, but since it's built as a Windows app,
Qt uses Windows API calls, which are implemented by wine using X11.
CrossOver runs its own internal X server. With MacPorts, you'll need
either XQuartz or the xorg-server port.

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

Re: I need consultation on running WINE on the Mac

[Joshua Root]

On 2012-10-16 22:33 , Ryan Schmidt wrote:
> 
> On Oct 16, 2012, at 06:00, Joshua Root wrote:
> 
>> I've just applied it to the wine-crossover port. Seems to work fine.
> 
> But wine-crossover 11.2.2 is based on wine 1.4.1, with which William says his 
> game no longer runs. I think he said the patch requires wine 1.5.15, so he 
> may want to try the wine-devel port instead, as he said he was doing.

Yes, the game no longer runs in any released wine version. As I said,
the patch works fine with wine-crossover.

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

Re: I need consultation on running WINE on the Mac

[Joshua Root]

> I know this is not a MacPorts issue, so please direct this to somewhere that 
> makes sense.
> 
> Basically, I'm a total newbee when it comes to RAW WINE. I've historically 
> used Codeweavers Crossover which is Wine 1.4.1
> Which is packaged to run quite nicely under Mountain Lion (10.8.2)
> 
> I play LOTRO, which just did a major upgrade, and therefore no longer runs 
> under 1.4.1
> 
> WINEhq has a fix which requires WINE 1.1.15. 
> However, the folks there are al LINUX types.
> 
> SO. I just installed MacPorts wine-dev 1.5.15 and now I need to do two 
> things. (That I know of.)
> 1- Find out how to apply the patch (which I believe is a classic diff file)-- 
> I have no idea how badly that will break the MacPorts installation.

I've just applied it to the wine-crossover port. Seems to work fine.

> 2- Find out how to configure "raw WINE"  on the mac. In particular how to 
> point it to the existing Crossover WINE Bottles.
> 
> Pointers to appropriate OSX oriented instructions are desired.
> Any help is greatly appreciated.

After installing wine-crossover, all you should need to run is (all one
line, ignore any line breaks inserted by email software):

WINEPREFIX="/Users//Library/Application
Support/CrossOver/Bottles/Lord of the Rings Online" wine
~/Library/Application\ Support/CrossOver/Bottles/Lord\ of\ the\ Rings\
Online/drive_c/Program\ Files/PyLotRO/pylotro.exe

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

Re: Prebuilt alternatives

[Joshua Root]

On 2012-9-26 04:05 , Kenneth Miller wrote:
> Why does macports insist on using only local builds?

It doesn't. If a prebuilt package is available, it will be used. There
are a number of reasons why one might not be.

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

gdk-pixbuf fails to build

[Joshua Root]

> Hi,
> gdk-pixbuf fails to build
> logfile attached
> ideas welcome
> Thanks
> 
> --R

Out of curiosity, what do you need gdk-pixbuf for?

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

MacPorts 2.1.2 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.1.2. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.5,
10.6, 10.7 and 10.8 (universal builds, the first i386/ppc and the others
i386/x86_64) at [2]. The source is also available as tarballs compressed
with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk image, packages and source tarballs
have been made with my key, which is available on the keyservers and my
MacPorts wiki page [4], the fingerprint being:

0x63BAD8CF2A10D5EE: 5F83 E16B D885 0601 5084  63C2 63BA D8CF 2A10 D5EE

The Mountain Lion pkg was built by Adam Mercer, and is signed with his
Developer ID.

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 

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

Re: xmms from ports uses Disk Writer Plugin for audio output?

[Joshua Root]

On 2012-6-19 20:52 , Jim Graham wrote:
> On Mon, Jun 18, 2012 at 11:28:51PM -0700, Jeremy Huddleston wrote:
>> xmms was old and barely maintained a decade ago.
> 
> Oh.  Well, any suggestions for a similar port, then?

xmms2?

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

Re: post-pkg failing

[Joshua Root]

(moving to -dev since this involves writing a portfile)

On 2012-5-28 10:43 , Paulo Moura wrote:
> Hi,
> 
> I'm using the latest versions of MacPorts, Xcode, and PackageMaker. I have a 
> portfile where I define:
> 
> post-pkg {
>   set resources ${workpath}/${name}-${version}.pkg/Contents/Resources/
>   file copy -force -- 
> ${workpath}/${worksrcdir}/scripts/macosx/License.html ${resources}
>   file copy -force -- 
> ${workpath}/${worksrcdir}/scripts/macosx/ReadMe.html ${resources}
>   file copy -force -- 
> ${workpath}/${worksrcdir}/scripts/macosx/Welcome.html ${resources}
>   file copy -force -- ${workpath}/${worksrcdir}/scripts/macosx/postflight 
> ${resources}
> }
> 
> Trying to create a package fails with the error:
> 
> Error: org.macports.pkg for port logtalk returned: error copying 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_logtalk/logtalk/work/lgt2441/scripts/macosx/License.html"
>  to 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_logtalk/logtalk/work/logtalk-2.44.1.pkg/Contents/Resources/":
>  not a directory
> 
> This worked before so I guess something change in the latest MacPorts and/or 
> PackageMaker versions. Any hints?

MacPorts 2.1 will build flat packages by default on 10.6+. This means
you can't just copy files into the resources dir, since it's now inside
a xar archive.

You can get the old behaviour back by setting 'package.flat no'. To make
this work with flat packages, you should instead copy the html files to
${package.resources} in pre-pkg, and the postflight script to
${package.scripts}/postinstall. (Flat packages apparently don't support
postflight scripts as such. Apple tends to simulate them by adding a
dummy package that only contains a postinstall script to the enclosing
Distribution package.)

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

MacPorts 2.1.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.1.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for 10.5,
10.6 and 10.7 (universal builds, the former i386/ppc and the latter two
i386/x86_64) at [2]. The source is also available as tarballs compressed
with gzip or bzip2, or from the subversion tag [3].

Detached PGP signatures for the disk images and source tarballs have
been made with my key, which is available on the keyservers and my
MacPorts wiki page [4], the fingerprint being:

0x63BAD8CF2A10D5EE: 5F83 E16B D885 0601 5084  63C2 63BA D8CF 2A10 D5EE

Josh
(on behalf of the MacPorts Port Managers)

[1]

[2] 
[3] 
[4] 

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

Re: archive_site_local [was: MacPorts 2.1.0 has been released]

[Joshua Root]

On 2012-5-16 06:09 , Joshua Root wrote:
> On 2012-5-16 06:01 , Arno Hautala wrote:
>> On 5/15/12, C D  wrote:
>>>
>>>  Then there might be a bug: following the procedure in
>>> https://trac.macports.org/wiki/howto/ShareArchives2, I have set up a local
>>> archive repository, which I access through the URL http://localhost:6227/ .
>>> When this URL is put into ${prefix}/etc/archive_sites.conf, the port number
>>> 6227 gets replaced with the port name in the fetch command. E.g.: "port -v
>>> upgrade openssl" leads to
>>>
>>> "--->  Attempting to fetch
>>> openssl-1.0.1c_0+universal.darwin_10.i386-x86_64.tbz2 from
>>> http://localhostopenssl/openssl";
>>>
>>> instead of "[...] from http://localhost:6227/openssl";.
>>
>> This does, at least initially, sound like a bug, unless there's a new
>> way to specify the port number.
>>
>> I haven't upgraded yet, but I should have time later today; when I'll
>> investigate further. In the mean time, you should be able to serve the
>> portfiles on port 80 and drop the port number in
>> archive_site_local.conf
>>
>> If there isn't a proper way to specify the port number, this should be
>> reported as a bug ( trac.macports.org ).
> 
> It's this one:
> <https://trac.macports.org/ticket/32018>

archive_site_local still works for me BTW.

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

Re: archive_site_local [was: MacPorts 2.1.0 has been released]

[Joshua Root]

On 2012-5-16 06:01 , Arno Hautala wrote:
> On 5/15/12, C D  wrote:
>>
>>  Then there might be a bug: following the procedure in
>> https://trac.macports.org/wiki/howto/ShareArchives2, I have set up a local
>> archive repository, which I access through the URL http://localhost:6227/ .
>> When this URL is put into ${prefix}/etc/archive_sites.conf, the port number
>> 6227 gets replaced with the port name in the fetch command. E.g.: "port -v
>> upgrade openssl" leads to
>>
>> "--->  Attempting to fetch
>> openssl-1.0.1c_0+universal.darwin_10.i386-x86_64.tbz2 from
>> http://localhostopenssl/openssl";
>>
>> instead of "[...] from http://localhost:6227/openssl";.
> 
> This does, at least initially, sound like a bug, unless there's a new
> way to specify the port number.
> 
> I haven't upgraded yet, but I should have time later today; when I'll
> investigate further. In the mean time, you should be able to serve the
> portfiles on port 80 and drop the port number in
> archive_site_local.conf
> 
> If there isn't a proper way to specify the port number, this should be
> reported as a bug ( trac.macports.org ).

It's this one:


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

Re: MacPorts 2.1.0 has been released

[Joshua Root]

On 2012-5-16 03:55 , Craig Treleaven wrote:
> Thanks to the devs for all their work.
> 
> In the NEWS, I noticed a couple of points:
> 
>> == Overview of changes from MacPorts 2.0.4 to 2.1.0 ==
>> 
>> *) The pkg and mpkg targets will create flat packages on 10.6+.
>>
>> 
>> *) Multiple ports can now be defined in one Portfile using the 'subport'
>>procedure.
>>
>> *) New option 'add_users' can be set to ensure that the listed users are
>>created at the right times during the install process.
>>
> 
> Being a neophyte Portfile author, is there more documentation of the
> above features?  ( mpkg, subports, add_users.)  I looked up the
> revisions to pkg/mpkg, for example, but I don't read TCL well enough to
> really understand.  Even a pointer to a message thread would help.

There are entries in the port(1) man page and the Guide about mpkg.
General info about Installer packages is available on the web, e.g.:




The add_users option is documented in the portfile(7) man page.

Have a look here:



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

MacPorts 2.1.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.1.0 version has now
been released. It is available via the usual methods:

 - selfupdate if you already have MacPorts installed
 - package installers for 10.5 [1], 10.6 [2], and 10.7 [3] (all
   universal builds, the first i386/ppc and the latter two i386/x86_64)
 - source tarballs, both .tar.bz2 [4] and .tar.gz [5]
 - subversion tag [6]

The list of what's new in 2.1.0 is quite extensive (so I won't list it
here), the details can be found in the NEWS [7] file or the somewhat
more exhaustive ChangeLog [8].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.1.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [9].

- Josh

[1]

[2]

[3]

[4] 
[5] 
[6] 
[7]

[8]

[9] 

PS, my PGP key ID is 63BAD8CF2A10D5EE,
fingerprint 5F83 E16B D885 0601 5084  63C2 63BA D8CF 2A10 D5EE
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts 2.1.0-rc2 now available for testing

[Joshua Root]

On 2012-5-13 05:48 , Jack Howarth wrote:
> Is anyone else finding that a clean install of MacPorts 2.1.0-rc2 from
> the source tarball on 10.7.4 with Xcode 4.3.2 results in the installed
> MacPorts building packages with llvm-gcc rather than clang? Is there a quick
> fix to hack port to properly default back to clang on such a configuration?

In fact there is such a thing:


However, I see the default being clang as expected. The default compiler
is based on $xcodeversion, which is derived from the output of
`xcodebuild -version`, and controls the value of CC, CXX etc. during the
configure step.

Of course, whether any given port will obey those environment variables
is a different question. Also, some ports of course change
configure.compiler for various reasons.

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

MacPorts 2.1.0-rc2 now available for testing

[Joshua Root]

Source code and pkg/dmgs for MacPorts 2.1.0-rc2 are now
available [1]. Testing of either of these install methods is helpful.

While there are no known regressions from 2.0.4 at this point, be
prepared to encounter bugs. As always, having a recent backup would be
wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no showstopping bugs are found in the next few days, this will become
the 2.1.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since rc1 are:
 * Fixed 'port livecheck' on pre-10.6 systems.
 * Fixed postflight scripts in flat packages. (#34386)

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

MacPorts 2.1.0-rc1 now available for testing

[Joshua Root]

Source code and pkg/dmgs for MacPorts 2.1.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

While there are no known regressions from 2.0.4 at this point, be
prepared to encounter bugs. As always, having a recent backup would be
wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no showstopping bugs are found in the next few days, this will become
the 2.1.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Notable changes since beta1 are:
 * Fixed installing from archives on systems where tar is gnutar (i.e.
   Leopard and Tiger). (#34080)
 * Fixed incorrect behaviour of 'port deps' and 'port log' in the case
   where a subport is specified via a glob or pseudo-portname selector.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts 2.1.0-beta1 now available for testing

[Joshua Root]

A different rsync url that you could put in macports.conf would be
possible. I believe there's already one for trunk.

On 2012-4-24 03:03 , Daniel wrote:
> I would have tested it were it a little bit easier. 
> 
> What would people think of a port selfupdate --pre (prerelease or
> --beta) flag for updating easily to the testing versions?
> 
> -d
> 
> 
> On Mon, Apr 23, 2012 at 8:42 AM, Joshua Root  <mailto:j...@macports.org>> wrote:
> 
> Have many people tested this? We've only had one real bug reported so
> far, and that one was present in 2.0.4. If this is just a really solid
> release, great; but if nobody is testing it, well, please do or the bugs
> will just end up in the final release. :-)
> 
> Cheers,
> Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users