Re: Feature request

[Mojca Miklavec]

On 5 May 2017 at 22:04, rmgls wrote:
> hi all,
>
> installing a port compute all dependancies, and print:
> installing ... do you want to continue Y/N?
>
> its ok! but what would be useful is to print the required space for all 
> packages:

Yes, it would be nice, but we don't always know how big they are as
they are often compiled from source. In case of binary packages (or if
the same kind of package was already compiled on the buildbot, only
not distributed) we could do that, yes, but someone still needs to
write the code to:
- collect the data
- show the data.

You may open a feature request on Trac (just don't expect too much as
we are currently somewhat understaffed; if you really want that
feature, asking for advice to help you get it done would give you
higher chances :).

(I know we have a ticket for showing percentage of the build, but
don't know where. This is somewhat related.)

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

Re: 10.6.8 and ffmpeg

[Mojca Miklavec]

On 2 November 2016 at 10:03, Jeremy Huddleston Sequoia wrote:
> Do you know *why* it is requiring the 10.7 SDK to build?  Why can't libsdl2 
> use the 10.6 SDK effectively?

See my analysis at
https://trac.macports.org/ticket/52210#comment:9

I'm pretty sure one can make it build without 10.7 SDK, it will just
take quite a bit of work to do so. Perhaps you know if there is an
elegant way to actually patch the code in a way that would be
acceptable for upstream in case we manage to find a sufficient set of
patches (other than using a bunch of #if statements all over the
place)?

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

Re: 10.6.8 and ffmpeg

[Mojca Miklavec]

On 2 November 2016 at 09:46, Davide Liessi wrote:
> 2016-10-30 15:38 GMT+01:00 Ryan Schmidt:
>> copying the 10.7 SDK into /Developer/SDKs is the simplest solution.
>
> How can I get a copy of the 10.7 SDK?
> I have only the 10.5 and 10.6 SDKs on my machine.

I didn't test this, but I guess that you should be be able to download
Xcode for 10.7 from Apple developer site (say version 4.6.3), extract
it from the command-line (hdiutil attach "Xcode 4.6.3.dmg") and copy
the SDK.

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

Re: Error installing gnuplot/aquaterm

[Mojca Miklavec]

On 28 October 2016 at 06:23, Tom Gederberg  wrote:
> I am sorry if this is a silly question, but I am trying to install gnuplot
> (I am running Mac OS Sierra, recently updated and performed the MacPorts
> migration) and am getting the error shown below.  Aquaterm is needing to be
> installed and that seem to be where it is hanging up.
>
> Error: org.macports.activate for port aquaterm returned: Image error:
> /Applications/MacPorts/AquaTerm.app/Contents/Info.plist already exists and
> does not belong to a registered port.  Unable to activate port aquaterm. Use
> 'port -f activate aquaterm' to force the activation.

This looks like a local problem on your machines. Some files exist
that shouldn't be there. Try to run
sudo rm -rf /Applications/MacPorts/AquaTerm.app/
and then try to install/activate aquaterm again. Alternatively do
sudo port -f activate aquaterm
as suggested.

How did you uninstall MacPorts during migration? Just "sudo rm -rf
/opt/local"? Or did you actually do "sudo port deactivate active" or
"sudo port uninstall active"? If you just removed the contents of
"/opt/local" without uninstalling or deactivating old ports, you might
run into the same problem with other ports that install files outside
of $prefix.

In that case I would suggest you to run "sudo port deactivate active",
then "rm -rf /Applications/MacPorts" and potentially clean up a few
more places (I have no clue which ones). You might have to force
install other ports if you didn't properly uninstall the ports from
earlier.

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

Re: is Docker port still supported?

[Mojca Miklavec]

On 19 September 2016 at 05:08, Ryan Schmidt wrote:
>> On Sep 18, 2016, at 9:36 PM, Ron Sidell wrote:
>>
>> Please forgive my ignorance but I'm trying to understand whether the
>> Docker port is still being maintained.
/.../
>> Please help me understand if I should consider to be under active
>> maintenance even though nomaintainer is still listed as the maintainer?
>>
>> Thanks!
>> Ron (a dedicated MacPorts user) thank you to all maintainers!
>
> "nomaintainer" means nobody has agreed to be the port's maintainer, and that 
> anybody with commit access may feel free to make changes to it.

... and that you can volunteer to become a maintainer.

"nomaintainer" doesn't mean that the port won't receive any updates.
It's just that whenever someone files a bug or asks for an update, the
ticket won't be sent to any particular developer and might go
unnoticed for a longer period of time. It is then up to random
volunteers to browse through the database of open tickets.

New maintainers are always welcome.

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

Re: MacPorts missing links

[Mojca Miklavec]

On 10 September 2016 at 20:38, Lawrence Velázquez wrote:
>
>> I wonder what causes this kind of problem? I cannot remember any of my port 
>> processes terminating incorrectly. I have lately been uninstalling 
>> python-related ports, because I had too many different versions of python on 
>> my machine, and I was getting confused.
>
> The symlinks created by "port select" are not modified if the selected port 
> is subsequently deactivated or uninstalled. I think there is an open ticket 
> about this, but I can't find it at the moment.

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

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Mojca Miklavec]

On 28 August 2016 at 23:21, Ken Cunningham wrote:
> OK - I see what happened.
>
> All traces of llvm37 have been from the new ld64 portfile.
>
> and so when the porfile saw my requested +llvm37, it saw that as no llvm 
> variant, and defaulted to llvm34. And now my toolchain is looking pretty 
> inoperable.
>
> there isn't an llm37 option in the ld64 portfile any longer.
>
> I either have to add one -- or -- reinstall everything
>
> but the  instructions 
> currently have a mixture of clang-3.7 references and llvm38 references.

That's partially because it was written when 3.7 made sense (ok, it
was probably earlier, when 3.5 or 3.6 was there), then 3.8 was
released, but buggy, so some instructions reverted back to 3.7 ...

> I thought 3.8 was not yet workable, and so we were to stick with 3.7 -- maybe 
> this is in transition?

Probably. Your feedback might help though.

> Looks like I need to let this all settle down in the portfile evolution for a 
> bit, and come back in a few days :>

Jeremy was cleaning up some of these files recently and it's quite
likely that not all of the changes were heavily tested on 10.5 and
10.6.

As an example, a recently discovered problem on 10.5 has just been
fixed and more changes have been applied just now. It makes sense to
open a new ticket for a problem like the one you mentioned. (Actually,
it also makes sense to upload crash reports and other problems to a
ticket in Trac. Trac can easily handle a 2 MB file that pastebin is
refusing.)

The setup for libc++ has a very small audience / a very small pool of
testers. Until we set up new build slaves and attract more users,
problems are to be expected. (Even then it will still be a problem
because most developers use the latest OS, so there are very often
very few people able to help.) Most support for old OSes is there
because those OSes used to be "up-to-date" some time back and
developers made sure everything was working (at least until new
software came up that required C++11). The libc++ support came later
and is constantly evolving due to releases of newer compilers.

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

Re: Updating tk +quartz failed on Snow Leopard

[Mojca Miklavec]

On 25 August 2016 at 10:09, Chris Jones wrote:
>
> Why don't you only apply the patch when needed, i.e. when building on OSX
> 10.6, but skip it elsewhere ?

One argument against it is that apps compiled on 10.6 wouldn't work
ideally on 10.7 and later. But that's a weak argument.

Anyway, let's continue the discussion on the developer mailing list.
It's too off-topic for the user list.

https://lists.macosforge.org/pipermail/macports-dev/2016-August/033484.html

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

Re: Updating tk +quartz failed on Snow Leopard

[Mojca Miklavec]

On 24 August 2016 at 04:37, Ryan Schmidt wrote:
>> On Aug 23, 2016, at 9:10 PM, Kevin Walzer  wrote:
>> On 8/23/16 10:04 PM, Ryan Schmidt wrote:
>>>
>>> This is weird because the backingScaleFactor method is supposed to return a 
>>> double, not an id, and is part of the Retina display API introduced in Mac 
>>> OS X 10.7. It is not in 10.6. The window should not be responding to the 
>>> backingScaleFactor selector on 10.6, so that if statement should never have 
>>> returned true and that code should never have been run.

Ryan, thank you very much for the analysis of the code.

>> While I'm not the author of that code, I did commit it, and you're right, it 
>> should not have run. What compiler is this error being triggered on?
>
> Apple gcc-4.2.1, the default compiler on Snow Leopard with Xcode 3.2.6.

It's more likely to happen with any compiler. (It's certainly
reproducible with clang 3.4.)

I might be wrong, but I suspect that

if (win && [win respondsToSelector:@selector(backingScaleFactor)]) {
scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
}

fails for the same reason as

int a=0;
if(a) {
doSomethingCompilerDoesntWantYouToDo();
}

does.

Sure, when executing the code, that "if" would resolve to false and
the loop wouldn't be entered. But the compiler doesn't know that in
advance. The compiler probably has to compile whatever is inside the
loop and complains about the type mismatch.

According to
http://stackoverflow.com/questions/307128/how-do-i-cast-id-to-a-float
I guess that
scalefactor = ([[win backingScaleFactor] floatValue] == 2.0) ? 2 : 1;
instead of
scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
should wok.

That compiles on 10.6 at least (I didn't check the actual
functionality, I don't even have GUI access to that 10.6 VM).

While it still throws
tkMacOSXXStubs.c:901:23: warning: instance
  method '-backingScaleFactor' not found (return type defaults to
'id') [-Wobjc-method-access]
I guess that the warning is expected.

Mojca

(I guess that's beyond the scope of the users' mailing list, but well ...)
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Updating tk failed on Snow Leopard

[Mojca Miklavec]

Hi,

On 23 August 2016 at 02:00, Ken Cunningham wrote:
> On 2016-08-22, at 3:48 PM, Richard L. Hamilton wrote:
>> Updating tk failed on Snow Leopard, trying to update to the current tk@8.6.6 
>> (probably +quartz+universal, given that's what the current @8.6.5_0 is)
>>
> Hi Richard,
>
> I have tk 8.6.6 running on snow leopard, but with +x11 (and not universal, 
> but x86_64)
>
> $ port -v installed tk
> The following ports are currently installed:
>   tk @8.6.6_0+x11 (active) platform='darwin 10' archs='x86_64'
>
> for what that's worth. I installed it with clang-3.7, and my first thought is 
> that your compiler might be too old. You might try installing clang-3.7 (and 
> ld64/cctools/llvm-3.7 that go along with it) and see where that takes you

The "official" binaries are indeed available for 10.6 and they were
compiled with the default compiler:
http://packages.macports.org/tk/

I can confirm that tk +quartz compiles fine for me on 10.7, but not on
10.6 (not even with clang 3.4, I didn't test with 3.7).

I don't find a ticket in the tracker, so feel free to open one. The
closest one I found was
https://trac.macports.org/ticket/22994
but that one is ancient and most likely unrelated.

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

Re: What's the "right" way to update a port to

[Mojca Miklavec]

Dear Gabriel,

On 21 August 2016 at 13:32, Yongwei Wu wrote:
> On Saturday, 20 August 2016, Gabriel Rosenkoetter wrote:
>>
>> I'm very new to this mailing list (as of yesterday), but only relatively
>> new to using MacPorts (for little things over the past few years).
>>
>> Recently, I finally got around to reripping my CD collection, and I
>> figured I'd use the same tool to do that that I did 15 years ago on a
>> now-deceased FreeBSD system: abcde.
>>
>> The port installs just fine, and with the right abcde.conf configuration
>> can work, but as noted in https://trac.macports.org/ticket/49799, the
>> preferred way to retrieve tracks from a CD under Mac OS X (cddafs, or "just
>> copy the AIFFs from the mounted volume") is flat broken under the current
>> port version (2.7).
>>
>> The note in that bug report about the upstream bug is exactly correct, and
>> the fix is available in the relatively recently (April 2016, I think) 2.7.2
>> upstream release.
>>
>> I think this should be relatively simple to fix, and I'd like to learn how
>> to do that and contribute the update. Any pointers where I should start
>> reading?
>
> Maybe the following two links?
>
> https://trac.macports.org/wiki/howto/InstallingOlderPort
> https://guide.macports.org/#development.local-repositories

Like Yongwei Wu suggested, you need to create a local portfile
repository. I would start with a SVN checkout (might be a sparse
checkout with just the relevant port) of
https://svn.macports.org/repository/macports/trunk/dports/
(please note that we'll soon switch to git), even though just copying
the file from $(port dir abcde) or from somewhere else should also
work fine.

You then need to add path to that new dports to
${prefix}/etc/macports/sources.conf as instructed by the links, run
poinindex inside dports and make sure that "port dir abcde" points to
your local checkout. Then:

- replace the version 2.7 with 2.7.2 in the Portfile

- (optional) run "portindex" in your local "dports" again

- run "sudo port -v extract abcde"

- you should get an error along with the suggested new checksums that
should be replaced in the Portfile (make sure that the checksums are
correct before copy-pasting them and that you fetch the right files)

- "sudo port -v install abcde" should then install the latest version;
you might need minor modifications in the Portfile in case that the
port changed in any significant way

Once you get that working, you can open a new ticket to request an
upgrade. You could run "svn diff" inside abcde and attach the diff to
the ticket. (Please note that we will soon try to switch to pull
requests on GitHub.)

Ideally you would also volunteer to be the maintainer of that port
that currently has nobody to look after. In that case you would add
eclipsed.net:gr openmaintainer
to the maintainers field (openmaintainer is optional and allows others
to make minor modifications to the port).

Then just reply to this thread again or ask on IRC. IRC might also be
useful to resolve your problems quickly in case you are stuck.

(I need to add that you could also just request an update of the port
and someone else could do the required steps. But if you are willing
to look after it yourself, being able to add or update other software
in the future without having to wait for others to do it for you is
often a valuable asset. And in particular ports without the maintainer
would more than welcome any new caring hands to look after them.)

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

Re: Idea: Port Checks for Disk Space Before Compiling?

[Mojca Miklavec]

On 11 August 2016 at 15:05, Jean-François Caron wrote:
> I’m glad my idea wasn’t as silly as I had thought.  Maybe this will go 
> somewhere.
>
> I needed to build clang locally because I use the +analyzer variant.  Maybe 
> this variant could be made default, since it has no performance impacts and 
> shouldn’t cause any problems for users who ignore the analyzer.  There are 
> probably more people who currently do +analyzer than people who would insist 
> on -analyzer if it were default.

This is the user mailing list. It might make sense to ask that
particular question on the devel mailing list or even better, to open
a ticket requesting adding that variant as the default (and CC the
maintainer).

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

Re: lilypond configure failure

[Mojca Miklavec]

On 11 August 2016 at 03:42, Lenore Horner wrote:
>
> :info:configure ERROR: Please install required programs:
> /opt/local/bin/fontforge >= 20110222 (installed: 2016-08-10 21:14:00.539
> osascript[47227:131873)

This looks like a bug in lilypond that is checking for
STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED, 20110222)

The version is MacPorts is 20120731, so the test should pass.

There's already a ticket for that:
https://trac.macports.org/ticket/49338

Weird enough the -devel version uses the same strategy, but it
installed just fine for me.

You could also ask for help on the lilypond list or perhaps switch to
macports-devel. And of course you can install the binary from upstream
as a temporary workaround. I guess that you could also remove that
check altogether (delete the relevant lines from configure) and try
again.

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

Re: Idea: Port Checks for Disk Space Before Compiling?

[Mojca Miklavec]

On 11 August 2016 at 03:32, Ryan Schmidt <ryandes...@macports.org> wrote:
>> On Aug 10, 2016, at 8:28 PM, Lawrence Velázquez <lar...@macports.org> wrote:
>>> On Aug 10, 2016, at 9:04 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>>>> On Aug 10, 2016, at 5:15 PM, Mojca Miklavec <mo...@macports.org> wrote:
>>>>
>>>> The major problem is that there is basically no way to predict how
>>>> much space an installation of a port from source might need (one might
>>>> be able to do some heuristics based on old build logs from the
>>>> buildbot or so, but that might be quite some work for very little gain
>>>> and it won't work well for non-default variants etc).
>>>
>>> It would be easy for the buildbot to record the size of the installed 
>>> package, even if the package isn't distributable, and could submit that 
>>> information to our hypothetical new web site, from which MacPorts could 
>>> query it.
>>
>> This could be helpful, but it wouldn't provide information about the 
>> *maximum* disk space required by a build, which could easily surpass the 
>> size of the final build products.
>
> That's true. The buildbot could also record the size of the work directory 
> before it's cleaned up. That wouldn't be 100% accurate either, since it's 
> possible for a build to create temporary files that are cleaned up during the 
> build, such as the gcc ports, but it would be a place to start.

I added some very crude statistics in
https://trac.macports.org/changeset/151264/

But:
- Ryan has to deploy those changes first
- these numbers should be collected somewhere to be of any use
- the collected statistics should eventually be integrated
into/accessible (via some api) to MacPorts

Please not that what I implemented on the link above won't help you in
any way if the builder starts building port A that depends on
clang-3.7 because clang-3.7 will then be built inside another build
and won't contain the statistics you are asking for.

For that to happen we would need to go further and add this meta info
to each dependency build step (doable though).

It also won't help you if you decide to use different variants and
will only be of partial help if your OS is not supported on the build
infrastructure. At the moment you should be able to get any clang in
binary format unless you use 10.5.

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

Re: Idea: Port Checks for Disk Space Before Compiling?

[Mojca Miklavec]

On 10 August 2016 at 23:58, Jean-François Caron wrote:
> This keeps happening.  My laptop’s hard drive has only a few (~5) gigs of 
> space left, and I foolishly decide this is a good time to upgrade clang.  
> Turns out clang needs infinite space (kidding) to compile, so about 30 
> minutes into the compilation my computer tries to warn me that the disk is 
> nearly full but it’s already too late and I can’t scramble to make space 
> before everything starts crawling.
>
> This might be specific to clang only, but is there a way for ports that need 
> a LOT of free space to check before trying to compile?
>
> I know the obvious solution is to keep more free space on the disk, which is 
> a good idea generally, but these SSDs get pretty expensive!  It feels extra 
> stupid that all this time I have like 5 Gb of RAM left unused, but that’s a 
> different issue.

The major problem is that there is basically no way to predict how
much space an installation of a port from source might need (one might
be able to do some heuristics based on old build logs from the
buildbot or so, but that might be quite some work for very little gain
and it won't work well for non-default variants etc).

When fetching the binary archives, we could get the information about
the size of the tarball and I'm pretty sure one could do something to
compute and calculate the size of the extracted package. But
estimating the size of the build from source is going to be difficult.

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

Re: New build system

[Mojca Miklavec]

On 10 August 2016 at 08:02, Ryan Schmidt wrote:
>
> On Aug 10, 2016, at 1:00 AM, Marko Käning wrote:
>
>> The waterfall view is - horizontally - pretty full these days... It would be 
>> neat if at least a logged on user could customise the view a little, like 
>> e.g. being able to only display the ports columns while hiding all columns 
>> for base!
>> Or perhaps just introduce a ports waterfall page which allows those who 
>> don’t need to see base to have an easier way of just tracking the ports?!
>
> There are many options for excluding columns; see:
>
> https://build.macports.org/waterfall/help

Plus, you have tags on top of the waterfall page that you can click
on. To get just the overview of ports being built, you can select
portbuild:
https://build.macports.org/waterfall?tag=portbuilder
(which might be a bit faster than picking manually).

And if there's a need, we could probably also group the libc++ builds
together etc. But we probably don't want to end up with too many tags.

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

Re: Macports fails to build in macOS 10.12 Sierra

[Mojca Miklavec]

On 19 June 2016 at 06:13, Al Varnell wrote:
>
> That being said, I was under the impression that before we can attempt to
> migrate from an older OS, we must wait for MacPorts to release a Sierra
> version of the MacPorts installation package.

No, that's not a requirement. You can of course try to install
MacPorts from sources, you just need to know that you are to a big
extent on your own, both because:
- many developers don't have access to the new OS and are unable to help you
- from what I understood it's not allowed to discuss the problems publicly

> That's what I have always done
> in the past, but I don't recall how long it took to get such a package put
> together after a new OS X was announced.

Usually that's as soon as the new OS gets released officially (plus
the time needed until one of the developers with access to all OS
versions and with a valid certificate makes the binaries).

But even after that you are still likely to run into many problems
with various software that would refuse to build or run properly on
the new OS.

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

Re: Error installing gmp

[Mojca Miklavec]

On 19 May 2016 at 17:48, John T. Chung wrote:
> Ryan, I reinstalled xcode from the app store and have included a screenshot
> of the preferences.
> As far as I can tell, it's installed.

It's been long since I last installed Xcode, but I would say that
there is the arrow next to 124 MB that you have to click to download
the command line tools.

Components that are installed have a checkmark already and no size next to it.

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

Re: How to discover what TeXLive ports I need

[Mojca Miklavec]

On 19 May 2016 at 14:02, Rainer Müller wrote:
> On 2016-05-19 12:06, list_em...@icloud.com wrote:
>> That's it. Is there some way to figure out what ports I need to add
>> to get specific functionality? Or will I have to bite the bullet and
>> do sudo port install texlive +full which warns "Full installation
>> scheme (very large!)".
>
> There is an index listing which LaTeX packages are in which MacPorts ports:
>
> https://trac.macports.org/wiki/TeXLivePackages
>
> Where should we add this to make it easier to find? Port descriptions?

*Personally* I would find it most useful if I could search for, say,
"prettyref.sty" with a command like
port searchfile "prettyref.sty"

But on the other hand it probably wouldn't be a bad idea if all the
texlive packages would actually list the list of packages they
contain. For example:

> port info texlive-basic
texlive-basic @37485 (tex)
Variants: [+]doc, src

Description:  These files are regarded as basic for any TeX
system, covering plain TeX macros, Computer Modern fonts, and
configuration for common drivers; no LaTeX. Contains packages:
amsfonts, bibtex, cm, dvipdfmx, dvipdfmx-def, dvips, ..., xdvi


This would still be only semi-useful because many times it's not
exactly clear to which package a missing file belongs until one checks
texlive.tlpdb.

Maybe texlive could also ship texlive.tlpdb (or perhaps some subset of
it to make searching for files easier). In the extreme case it should
actually be possible to trigger installation of the required package
when a known file is missing (this is what MikTeX does for example),
but it would require some extra coding.

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

Re: How to discover what TeXLive ports I need

[Mojca Miklavec]

On 19 May 2016 at 12:06,   wrote:
> I'm trying to make a functional replacement for TeXLive 2013 provided by 
> MacTeX http://tug.org/mactex/, using MacPorts, and reaching some level of 
> frustration with figuring out what MacPorts stuff I need. I did
>
> sudo port install texlive +medium
>
> But now, for example, a long-worked-on LyX project now fails to compile, 
> complaining of
>
> LaTeX Error: File `prettyref.sty' not found.

This one is in texlive-latex-extra.

> Ditto for flushend and who knows what else will pop up. I went through the 
> various port descriptions at macports.org that contain texlive in their names 
> and get a very limited amount of information such as
>
> nametexlive-latex-extra
> ...
> description TeX Live: LaTeX additional packages
> long_descriptionA very large collection of add-on packages for LaTeX
>
> That's it. Is there some way to figure out what ports I need to add to get 
> specific functionality? Or will I have to bite the bullet and do sudo port 
> install texlive +full which warns "Full installation scheme (very large!)".

If you want a full replacement of MacTeX, you need to do the full
installation of TeX Live. I no longer have version 2013 installed, but
MacTeX 2016 is 5 GB (minus epsilon). You cannot get any thinner
installation by getting the full installation scheme from MacPorts
except that you wouldn't be installing PPC and 32-bit Intel binaries.

If you merely want to compile your documents and want to discover
which packages are needed, we really should set up some service to
list the files in the packages, but at the moment most likely the
easiest way is to do a checkout of
svn://tug.org/texlive/trunk/Master/tlpkg/texlive.tlpdb

And search for that file. You can find it in package "prettyref":

name prettyref
category Package
revision 15878
...
runfiles size=1
 texmf-dist/tex/latex/prettyref/prettyref.sty


and the package prettyref is in colection "latexextra":

name collection-latexextra
category Collection
revision 40214
...
depend pressrelease
depend prettyref
depend preview

And then you know which package to install. I agree that this is
pretty annoying though, but I don't see any better solution at the
moment (other than perhaps installing MikTeX; last time I tried it
failed to compile on OS X though).

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

Re: Getting rid of port binaries in /software

[Mojca Miklavec]

On 19 May 2016 at 00:25, 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...

But in current implementation that probably means that all the
packages have to be compiled locally?

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

Re: Issues installing rvm?

[Mojca Miklavec]

On 14 May 2016 at 05:29, Nathan Brazil wrote:
> I would recommend that you visit https://rvm.io and install RVM using the
> instructions therein.

Please note that this is not the same software:

> port info rvm
rvm @1.07 (sysutils, net)
Variants: universal

Description:  The Rsync Vault Manager is an archive manager
that uses rsync to manage backups of multiple clients across multiple
logical partitions (vaults).
Homepage: http://rvm.sourceforge.net/

It's not clear to me which one the user had in mind though.

I tried to fix the master_sites field for the port, but since my
macports is always fetching the file from the mirror, I don't know how
to verify the change.

Mojca

> On May 13, 2016, at 7:11 AM, André-John Mas wrote:
>
> Hi,
>
> I am running into issues installing rvm onto a MacOS 10.11.x system.
>
> First thing I did was a `port selfupdate`, followed by `port install rvm`,
> which gives me:
>
> sudo port install rvm
> --->  Computing dependencies for rvm
> --->  Dependencies to be installed: rsync
> --->  Fetching archive for rsync
> --->  Attempting to fetch rsync-3.1.2_0.darwin_15.x86_64.tbz2 from
> https://packages.macports.org/rsync
> --->  Attempting to fetch rsync-3.1.2_0.darwin_15.x86_64.tbz2.rmd160 from
> https://packages.macports.org/rsync
> --->  Installing rsync @3.1.2_0
> --->  Activating rsync @3.1.2_0
>
> To use the rsyncd server you must copy /opt/local/etc/rsyncd.conf.example to
> rsyncd.conf and add your modules there. See 'man rsyncd.conf' for more
> information.
>
> --->  Cleaning rsync
> --->  Fetching archive for rvm
> --->  Attempting to fetch rvm-1.07_0.darwin_15.x86_64.tbz2 from
> https://packages.macports.org/rvm
> --->  Attempting to fetch rvm-1.07_0.darwin_15.x86_64.tbz2 from
> http://mse.uk.packages.macports.org/sites/packages.macports.org/rvm
> --->  Attempting to fetch rvm-1.07_0.darwin_15.x86_64.tbz2 from
> http://lil.fr.packages.macports.org/rvm
> --->  Fetching distfiles for rvm
> --->  Attempting to fetch rvm_1.07.tar.gz from
> http://iweb.dl.sourceforge.net/rvm
> --->  Verifying checksums for rvm
> Error: Checksum (md5) mismatch for rvm_1.07.tar.gz
> Error: Checksum (sha1) mismatch for rvm_1.07.tar.gz
> Error: Checksum (rmd160) mismatch for rvm_1.07.tar.gz
> ***
> The non-matching file appears to be HTML. See this page for possible reasons
> for the checksum mismatch:
> 
> ***
> The file has been moved to:
> /opt/local/var/macports/distfiles/rvm/rvm_1.07.tar.gz.html
> Error: org.macports.checksum for port rvm returned: Unable to verify file
> checksums
> Please see the log file for port rvm for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_rvm/rvm/main.log
> To report a bug, follow the instructions in the guide:
> http://guide.macports.org/#project.tickets
> Error: Processing of port rvm failed
>
>
> Before opening  a ticket I want to be sure there isn't something else I
> should be looking at? At the same time, the fact the
> intended download results in an HTML page suggest a URL might need updating
> somewhere?
>
> Thanks
>
> Andre
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: WebKit2-GTK: quartz VS XQuartz

[Mojca Miklavec]

On 8 May 2016 at 11:19, Andrea Giammarchi wrote:
> Like I've said, telling users they need to wait at least one hour to
> install and build gtk3 +quartz and webkit2-gtk +quartz due lack of pre built
> version

There are two options:
(i) Switch the default from x11 to quartz
(ii) Provide binaries for both x11 and quartz

The first option is problematic because a lot of software doesn't work
without X11 (assuming that GTK implies X11). If MacPorts switches to
Quartz, all that software will be broken and it would be even more
pain to explain to users that they need to switch to X11 just to get
the software from a broken state to a working state (and they would
also have to compile equally long). Now only those who want a better
user experience have to switch.

In theory there is also:
(iii) allow co-existing support for quartz and x11 (at least for gtk3;
I'm sure this is not possible for wxWidgets for example)

So at the moment we could consider different options for (ii). These
are for example:

(a) Provide support for resolving dependencies automatically (some
work has been done during GSOC 2015, but it has not been finished
yet). Then the required binary packages would be built automatically
on the buildbot (as soon as one package would request "gtk3 +quartz").

(b) Provide more hardware to set up a separate buildbot with "+quartz"
being set by default. This means 6 additional virtual machines running
on Apple hardware. That's not trivial, at least not at the moment.
(Does anyone have extra hardware lying around? It has to be reasonably
fast to catch up with all commits though. If so, we could in principle
play with an unofficial buildslave building packages for +quartz.)

(c) Modify the existing buildbot setup to perform (very) dirty tricks
to build support for +quartz (for example: build packages, deactivate
them, modify the default variants to add +quartz, build packages
again, deactivate them, set the default flags back).

It's also true that if binary packages for Quartz were supported,
there would probably be more incentive to fix the broken software.


But unless you have concrete solutions for any of the points mentioned above ...

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

Re: py27-wxpython-* not working

[Mojca Miklavec]

On 1 May 2016 at 01:10, Brandon Allbery wrote:
>
> (b) what does "type python" return? ("which" can lie. Specifically, it's
> prone to tell you what a *new* shell will see --- not what your *current*
> shell is doing, because shells cache what they've already seen. If you ran
> "port select --set" in that shell and it had already seen /usr/bin/python,
> it will be running that still when you run "python"; "which" may not show
> this, "type" will.)

You can indeed try
/opt/local/bin/python2.7 -c 'import wx'
and then perhaps also
port contents py27-wxpython-3.0
just in case to double check that the wx module is indeed there.

You should have lots of files under

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx

"port select --set wxWidgets ..." shouldn't have any influence, but
"port select --set python ..." does influence the python that gets
executed, so that might be relevant.

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

Re: WebKit2-GTK: quartz VS XQuartz

[Mojca Miklavec]

Hi,

I'm sorry for posting the reply to the developer mailing list rather
than the user mailing list where this was originally posted, but I had
a feeling that the dirty details don't interest regular users so much.

On 5 April 2016 at 01:10, David Evans wrote:
> On 4/4/16 1:21 AM, Andrea Giammarchi wrote:
>>
>>  2. wouldn't be better macports experience if quartz backend was also 
>> pre-built like it is for the xquartz one?
>> Installation time is 10x slower than the Homebrew one
>
> This could probably be done, but would require more buildbot resources than 
> we currently have allocated.  Ryan, our
> sysadmin for these issues, could address what it would take to do this.

With slightly modified behaviour of MacPorts we wouldn't even need
additional resources. The buildbot could check if variant +quartz
exists and if +x11 is the default one. And in that case run another
build of the same port with +quartz -x11. That would be easy to do.
The biggest problem at the moment would be the dependencies where
variants cannot easily be imposed (at least not until the dependency
resolving gets fully implemented).

(Another dirty hack would be to do the same check of existence of
x11/quartz variants and if it turns out that this is the case, change
variants.conf on the buildslave to +quartz -x11 before the rebuild of
that port and then change it back after the build is finished.)

The above mentioned trick(s) would only consume slightly more
computational power on ports that offer the choice, but wouldn't
require setting up a zillion new build slaves. But Rainer was working
hard on reimplementation of the buildbot and it would make sense to
wait until his implementation goes live before spending any effort on
the old setup.

(In any case I believe that we would end up with better support for
Quartz if we had those packages prebuilt and if errors were reported.)

> However, there is another way.  gtk3 has for some time supported the concept 
> of building with multiple backends
> simultaneously (as cairo and pango do).  So we could look at having a single 
> gtk3 +quartz+x11 default build.  I'm
> looking at what the consequences of this would be on gtk3's dependent ports 
> as a background task at this point, but it
> should be doable.

Wow! This would be awesome indeed and would solve just about 99 % of
the problems I had with some ports (because I cannot rely on existence
of quartz support nor easily test things / make quartz default for
ports where this would be supported). Whenever I want to test
something, I run into a huge number of conflicts because of many ports
that have been built against gtk3 +x11 and I lose the motivation to
push my MacPorts installation to an inconsistent state.

If you can figure that out, I would be enormously grateful for that.

> Unfortunately gtk2 does not support this ability and probably never will.

That doesn't really matter. It's not like gkt2's support for quartz is shining.

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

Re: Is any clang version known to work in PPC/Tiger?

[Mojca Miklavec]

On 4 April 2016 at 00:44, César wrote:
> On 3 de April 2016, Mojca Miklavec wrote:
>> On 3 April 2016 at 22:13, César wrote:
>> > I've read that clang/llvm have been improving their PPC support over the
>> > years. But, is any version known to build?
>>
>> I have clang-3.4 installed on 10.5 PPC. Installing the latest versions
>> requires quite a bit of bootstrapping headaches:
>> https://trac.macports.org/wiki/LibcxxOnOlderSystems
>
> I tried several clang versions and port rejected to do so, telling that
> Intel was required. I don't remember if it was 3.4 or 3.3 the most recent
> version that didn't stop with that error (I think it was 3.3 but I'm not
> sure now).

I don't see anything obvious that would prevent one from compiling 3.3
on PPC, but I made just a short glimpse. In any case I would go for
3.4 rather than 3.3.

> BTW, reading that wiki link, makes me feel it's quite scary to use clang for
> distributable apps in anything older than Mountain Lion.

That should be "anything older that Lion". Lion comes with libc++
preinstalled. Only 10.6 and earlier lack that library. And even then
it's not about clang per se, but about using the latest versions of
clang which support C++11 and also require libc++. Version 3.4 works
with the default stdlibc++ installed on the system.

> Does that article
> mean that the users machines must install a working libc++ if the app has
> C++ code?

If the app has C++11 code, you won't even be able to compile it
without libc++ (or without libstdc++ version 3 & a recent GCC, but in
that case you would be facing exactly the same problem: you would have
to install a separate libstdc++).

But yes, if the app has C++ code and if you use clang > 3.4 (or maybe
> 3.5, I'm not sure), the binaries will link against libc++ that you
would have to ship with the binary.

> Can't executables be built statically without such requirement?

I never tested that, but it might work.

I know that TeX Live (http://tug.org/svn/texlive/trunk/Build/source/)
uses some hack to build against libstdc++ statically, so that the
binaries can be "universally" distributed.

And google finds a number of recipes. I have zero experience with
doing that on 10.5/PPC with the latest clang though.

> I'd prefer to move to clang in all my Macs because I like it more than gcc,
> but I'm beginning to feel it's wiser to keep using gcc in <10.8 Macs.

When you say "clang" you need to specify which version and whether or
not C++11 support is needed. 10.7 comes with libc++ and fully
functional clang/clang++ 3.2svn (with certain bugs every now and then
and cases when one needs to switch to a newer compiler). Even 10.6
comes with clang (but without clang++ and without libc++). And only
10.9 implemented support for C++11 by default.

You should be able to use version 3.4 on all systems, but using newer
versions might require a bit of extra effort.

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

Re: Is any clang version known to work in PPC/Tiger?

[Mojca Miklavec]

On 3 April 2016 at 22:13, César wrote:
> I've read that clang/llvm have been improving their PPC support over the
> years. But, is any version known to build?

I have clang-3.4 installed on 10.5 PPC. Installing the latest versions
requires quite a bit of bootstrapping headaches:
https://trac.macports.org/wiki/LibcxxOnOlderSystems
but it should build. (I tried to bootstrap with the help of 10.6, but
I ran into too many problems.)

See also:
http://www.csl.cornell.edu/~fang/sw/llvm/
and the link to GitHub.

> And, can it be used in
> production, or there's the risk of getting corrupted/nonworking binaries?

Please don't take my word for granted ...

It depends on what you mean with "production". Generally you should
get working binaries, but you should also be ready to deal with
problems way more often than on other platforms. (There are many
compiler-related problems even on x86_64.)

I would imagine that you would more often run into compile-time
problems than runtime problems. All that is pure speculation though.

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

Re: libgcc fails to build

[Mojca Miklavec]

On 21 March 2016 at 21:29, [ftp83plus] wrote:
> After cleaning libgcc and reinstalling, no error. Now attempting to install
> xsane…
> Now webkit-gtk fails. I cleaned and reattempted installation, as told, but
> it failed again:
> log is http://pastebin.com/wxyHSjBV

Update and try again.

This commit hopefully fixed the problem:
https://trac.macports.org/changeset/146945/

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

Thank you all for the wonderful MacPorts Meeting in Slovenia (and see you again soon ...)

[Mojca Miklavec]

Hi,

All good things come to an end and so did the wonderful week that we
spent together in Gozd Martuljek.

While I was initially hoping to see a larger group of people come
together, the relatively small group of hackers eventually turned out
to be the perfect recipe for boosting up the motivation, allowing us
for very productive one-to-one learning experience and hacking
sessions, resulting in quite satisfactory amount of work being done,
new people getting confidence in hacking the core of MacPorts, new
people joining the project, ...

The spirit was so motivating that our "chef" nearly had to tear us
apart from the notebooks to make us come to the lunch and dinner.
Nevertheless we still managed to find some time to enjoy the wonderful
weather playing snowleyball on fresh air.

Special thanks to Ryan for joining us in a remote session, to Rainer
for representing the PortMgr, to Clemens for convincing us that
hacking the base might not be as scary as it sounds, for attracting
and mentoring new developers, to Dagobert for bringing in a fresh
perspective from a different package manager and helping us with the
buildbot setup, to Jackson for flying in from the other side of the
globe, to Peter for keeping us awake with Italian coffee and not
minding to completely change his meeting agenda, to our cook Darko.
And finally to Aljaž who set up all the infrastructure for the
conference and helped a lot with preparation work.

Some moments have been captured in https://twitter.com/macports, but
during the week we are all too busy to document everything we have
done and everything that we discussed. You may expect the minutes from
the meeting arriving in not too distant future though.

We all agreed that we have to meet again. So stay tuned.

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

Re: Audacity build question. for Ticket #47189

[Mojca Miklavec]

On 27 February 2016 at 13:53, Robert Chalmers wrote:
> I don’t mean to mis-lead anyone. The issues I”m talking about are part of
> Audacity 2.1.2. Things like not being able to drag-highlight-scroll right in
> editing a track, and drag+highlight-dcroll left+edit only works sometimes.
> There also appears to be something about it that interferes with other
> running apps, in this case, iBooks running at the same time over the course
> of about half an hour gets slower and slower to scroll, untill it gives up
> all together and becomes unusable. If I close down Audacity 2.1.2, and close
> iBooks, then open iBooks again. It starts working as it should.  Start up
> 2.1.2, and after half an hour there abouts - it caries - back comes the
> problem with iBooks.

These are most likely problems that have been introduced with
transition to wxWidgets 3.0. You should certainly report them to
upstream developers.

It might help to check whether this is also a problem on Linux or on
wxGTK flavour (on Mac). It might be slightly easier to debug then. (I
have an impression that most developers work on Linux or occasionally
on Windows and Mac is just something that has to be done by someone.)

> So, I’m not talking about the macports build of Audacity - the current port
> installed fine, and lives in the macports folder in Applications, although
> it does read the cfg file in the “default” location of course. Which doesn’t
> seem to trouble it.
> . It does however exhibit the same problems with
> scrolling/editing/highlighting as the Audacity build by the Audacity
> Developers. And probably other issues that I gave up tracking. AS I said.
> I’m back on 2.1.1, because it’s at least fully functional for what I want.

These problems have to be resolved sooner or later, or you'll end up
with some version of OS X that will refuse to run i386 binaries :), or
you will at some point want to use the latest features, and then
you'll have no choice.

> While I’m thinking of it - does the port install session create a log file
> anywhere of what it does when “port installing” - I’d like to see what’s
> happening.

sudo port -v install audacity

But most likely you got a binary from MacPorts. If you want to see the
complete process, you need "sudo port -vs install audacity" or perhaps
"sudo port -v destroot audacity". You can also use "-d" for debug
rather than "-v" for verbose to get even more [nasty] output.

>> I didn't even look at it, but from what I understand the Xcode project
>> has the 10.6 SDK hardcoded and it might become tricky to get it to
>> build under later OSes. (Official build instructions start with tricks
>> about how to install an ancient Xcode on your machine.)
>>
>> What is your main reason/motivation to get the Xcode build working?
>
> I’ll probably keep tinkering with this unless someone beats me to it. I
> would like to get the build going with the XCode project, using the latest
> versions of the SDK, and XCode etc, because trying to use the now almost
> ancient 10.6 SDK seems counter productive, and is begging for built in
> instabilities.

10.6 was in fact needed until Audacity depended on wxWidgets 2.8. This
is no longer the case, so there is no reason why it wouldn't build
with the latest Xcode on the latest OS now that they made the switch
(just keep in mind that you'll probably get the same "buggy" version).

However I have almost no experience with xcode projects and what
little experience I have, the project would generally hardcode both
the SDK and architectures when one creates a new project by clicking
different buttons. I remember that I was manually replacing parts of
text in .xcodeproject to avoid hardcoded SDK.

> So the reason/motivation is to “make it work” and remove that pesky hard
> coding so that updates to XCode and SDKs can be more easily followed and
> checked in the actual project.
> I know it’s difficult, but it shouldn’t be im possible, if I can create a
> “map” or a tree diagram of where and what everything is in Audacity’s base
> source code. I don’t see a source code map anywhere, and the code it’self is
> minimally commented. Whick is one thing XCode is good for, Sou can see where
> everything is at a glance pretty much.

It might be easier to create a new project from scratch, but I'm just
speculating.

> Does anyone know exactly what the calls are that require the 10.6 SDK?

wxWidgets 2.8 which is no longer needed (but you have problems with
version 3.0).

> Shouldn’t it then just be a mission to update that code to the new SDK?

It already was by the time of the 2.1.2 release. But now someone has
to step in to fix the xcodeproject.

On top of that you might experience some problems with the 64-bit
build. René included some patches in MacPorts and we need to submit
those patches upstream, but we need some proper testing first.

Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org

Re: Managing multiple TeXLive installations

[Mojca Miklavec]

On 27 February 2016 at 00:21, Jerry wrote:
> I am struggling with two different installations of TeXLive.
>
> One is a 2013 version from TUG which was a binary installed mostly into 
> /usr/local/texlive but with GUI apps in /Applications/TeX/.

2013 is relatively old.

> The other is MacPorts 2015 version...
>
> $ port installed *texlive*
> The following ports are currently installed:
>   texlive-basic @30847_0+doc
>   texlive-basic @34245_0+doc
>   texlive-basic @37485_0+doc (active)
>   texlive-bin @2013_5+x11
>   texlive-bin @2014_1+x11
>   texlive-bin @2014_9+x11
>   texlive-bin @2015_8+x11 (active)
>   texlive-common @2013_0
>   texlive-common @2014_0
>   texlive-common @2015_0 (active)
>   texlive-fonts-recommended @36916_0+doc (active)
>   texlive-latex @30738_0+doc
>   texlive-latex @34192_0+doc
>   texlive-latex @37361_0+doc (active)
>
> I want to simplify and save space and reduce the possibility of conflicts.

You can also run "sudo port uninstall inactive" or "sudo port unintall
inactive and 'texlive*'" to save extra space. I just wanted to add
that I have multiple installations of TeX (MacTeX 2014, 2015), TeXLive
from MacPorts, a standalone ConTeXt installation, ...

In System Preferences you most likely have an icon for "TeX
Distribution". It is possible that you can select MacPorts from there
(I'm not sure about the exact history of when MacPorts was
added/removed) and then all the nice GUI apps would automatically
switch to using TeX Live from MacPorts as well (it's mostly just a
symlink /usr/texbin and some other link on 10.11, but if you have
version 2013, it's probably /usr/texbin).

Other than that it all depends on PATH settings. Whatever
"latex/pdftex/kpsewhich/..." comes first in PATH will also be used.
I'm not sure how exactly LyX deals with paths though because it's not
a command-line program.

> However, the 2013 TUG version installed the very nice collection of GUI apps 
> in /Applications/TeX which I would like to use especially BibDesk. When I 
> look in /Applications/MacPorts there are no corresponding programs.

Many programs are standalone apps that are not really part of TeX
Live, but are packaged for convenience by the person who creates
MacTeX.

You can download BibDesk from http://bibdesk.sourceforge.net/. And
given that the sources are available, it should be feasible to create
a package in MacPorts as well. The same is true for most other apps
that come bundled with MacTeX.

> Can I delete /usr/local/texlive/2013 and keep the GUI apps in 
> /Applications/TeX and if so, how would I keep the GUIs updated?

Sure. Just do "sudo rm -rf /usr/local/texlive/2013" (or perhaps "sudo
mv /usr/local/texlive /usr/local/texlive-backup"). You will probably
also want to remove /usr/texbin from PATH or perhaps point /usr/texbin
to /opt/local/bin.

After that you might need to adjust paths in individual programs. I
don't use BibDesk, so I'm not sure what has to be done there, but in
case that it actually needs TeX and doesn't just output .bib files I'm
sure there exists some setting to point it to the desired version of
TeX.

> Or is there a way to get the GUI apps to be installed by MacPorts, presumably 
> into /Applications/MacPorts? I don't see a GUI variant.

There is no +gui variant or will ever be one. Someone would have to
prepare build rules for these individual programs. There are some
attempts like this one:
https://trac.macports.org/ticket/16055
but someone motivated would have to step in to package all of them.

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

Re: Audacity build question. for Ticket #47189

[Mojca Miklavec]

On 26 February 2016 at 18:08, Robert Chalmers wrote:
> Thanks Mojca,
>
> It does compile and install with no problems as you say. However it’s still
> the same 2.1.2 that has it’s own issues (bugs?) that I’m waiting patiently
> to see fixed. But not to worry.

It could be helpful to point those problems out. Are these upstream
issues or something that's only present in MacPorts? I only use the
most basic features, so I'm unlikely to run into problems.

I can imagine that the switch from wxWidgets 2.8 to 3.0 introduced a
number of problems. If you can describe the steps to reproduce them
(either in our tracker or even better upstream), we could at least
test and try to figure out if we know how to fix them.

> I’m pretty impressed by your work getting this to build.

This was done by René, not by me.

> I’d love to have
> the time to get it working under XCode with the XCode build. I started with
> it, but collided with a whole lot of issues…

I didn't even look at it, but from what I understand the Xcode project
has the 10.6 SDK hardcoded and it might become tricky to get it to
build under later OSes. (Official build instructions start with tricks
about how to install an ancient Xcode on your machine.)

What is your main reason/motivation to get the Xcode build working?

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

Re: Audacity build question. for Ticket #47189

[Mojca Miklavec]

On 25 February 2016 at 17:47, Robert Chalmers wrote:
> Sounds good.
>
> Given that the usual method is
>
> port install
>
> Where will the binary/app/package be installed to…. I’d hate to overwrite my
> functional Audacity 2.1.1, but other than that I’m happy to be a tester.

You should already be able to do the usual
sudo port selfupdate
sudo port install audacity

The app gets installed to /Applications/MacPorts/Audacity.app (unless
you installed MacPorts from source and configured it differently) plus
a few extra files under /opt/local. I guess your other app is in
/Applications/Audacity.app, so it shouldn't conflict. And even if it
would conflict (if you would install manually inside
/Applications/MacPorts/), MacPorts should throw an error and tell you
that activation of the port failed.

Feedback welcome.

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

Re: Audacity build question. for Ticket #47189

[Mojca Miklavec]

On 25 February 2016 at 14:57, Russell Jones wrote:
> On 23/02/16 11:02, Robert Chalmers wrote:
>>
>> Interesting port.
>>
>> Do you plan to update this to use wxWidgets-3.0.2.0 - or has it in fact been
>> done…. a newer ticket somewhere?
>
> I see the version of the Portfile at
> https://github.com/RJVB/macstrop/tree/master/audio/audacity linked in
> https://trac.macports.org/ticket/47189 uses wxWidgets 3.0.x: "wxWidgets.use
> wxWidgets-3.0"

Indeed. The port linked from that ticket already uses wxWidgets 3.0.2.
I just tested it and there are only some minor glitches (easy to fix).
Other than that the official port could be added (soon).

(Testers on 10.11 welcome.)

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

Re: Where are texlive-fonts-recommended stored?

[Mojca Miklavec]

On 25 February 2016 at 08:43, Jerry wrote:
> On Feb 24, 2016, at 11:10 PM, Mojca Miklavec wrote:
>
>> On 25 February 2016 at 01:37, Brandon Allbery wrote:
>>> On Wed, Feb 24, 2016 at 7:36 PM, Jerry wrote:
>>>>
>>>> When installing texlive-fonts-recommended, are the indicated fonts stored
>>>> in /opt/local/ or in the usual system font place(s).
>>>
>>> port contents texlive-fonts-recommended
>>> ?
>>
>> /opt/local/share/texmf-texlive/fonts
>>
>> So they won't be seen by the system by default.
>>
>> Mojca
>
> Thanks, Brandon and Mojca. Just what I needed to know. I'm trying to work out 
> a problem with (non-MacPorts) LyX.

The only important thing is that LyX uses the right compiler
(/opt/local/bin/pdf[la]tex or whatever compiler you are using). It
should then pick up the fonts automatically via kpsewhich. Perhaps try
to make sure that LyX sees /opt/local/bin in PATH.

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

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

[Mojca Miklavec]

On 12 February 2016 at 09:28, Christopher Jones wrote:
>> On 12 Feb 2016, at 2:54 am, Joshua Root wrote:
>> 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.
>
> fair enough. I personally prefer compressed attachments, but concur the point 
> as I might be a minority on that point.

In most cases (when problems occur) the log can be attached to a
ticket in trac. I would say that attaching the log to the trac (or
perhaps posting it somewhere else if it's only a short-term issue) is
better than getting large attachments in lots of emails, in particular
when most recipients are not even remotely interested in looking at
the attachments at all.

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

Re: Trying to execute LibcxxOnOlderSytems (2nd ed.)

[Mojca Miklavec]

On 9 February 2016 at 20:30, [ftp83plus]  wrote:
> Ok, after a night of fetching-compiling, it now fails at step 6
>
> --->  Unable to uninstall llvm-3.4 @3.4.2_8, the following ports depend on it:
> --->cctools @877.5_2+llvm34
> --->ld64-136 @136_2+llvm34
> Error: org.macports.uninstall for port llvm-3.4 returned: Please uninstall 
> the ports that depend on llvm-3.4 first.
> Warning: targets not executed for llvm-3.4: org.macports.uninstall
> Please see the log file for port llvm-3.4 for details:
> 
> /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_llvm-3.4-3.4.2_8_15b8a350e8ebfedc44efd55b4e7ca47de93e6f1c2d2686c8a60bf0ae8d52a73a-20651/llvm-3.4/main.log
> Warning: Failed to execute portfile from registry for llvm-3.4 @3.4.2_8
> --->  Unable to uninstall llvm-3.4 @3.4.2_8, the following ports depend on it:
> --->cctools @877.5_2+llvm34
> --->ld64-136 @136_2+llvm34
> Error: port uninstall failed: Please uninstall the ports that depend on 
> llvm-3.4 first.
>
> The previous step 5 succeeded, but did it kept the clang-3.4 as well as the 
> clang-3.7 variant?

If "port installed cctools" shows two ports being installed and only
the one with "+llvm37" active (and the same for ld64), you can do:
sudo port -v uninstall cctools @877.5_2+llvm34
sudo port -v uninstall ld64-136 @136_2+llvm34
sudo port -v uninstall llvm-3.4 clang-3.4

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

Re: Perl5 (meta package) switched from 5.16 to 5.22 - p5-* and git not switched

[Mojca Miklavec]

On 12 January 2016 at 19:40, Justin Vallon wrote:
> I just did a selfupdate && upgrade, and perl5 was upgraded from perl5.16
> to perl5.22.
>
> However, my p5-string-shellquote was not automatically upgraded from
> p5.16- to p5.22-, and I had to reinstall it.
>
> Similar for git and ossp-uuid.  Each had a perl5_16 variant installed
> and ugprade did nothing, but reinstalling ended up with perl5_22.
>
> My guess is that the perl5 Portfile was changed, so upgrade rebuilt it
> and thus installed perl5.22, but p5-string-shellquote was not changed,
> so did not get an automatic upgrade.
>
> Is this expected?

These problems should be fixed now (and you may [almost] ignore the
rest of the thread which is mostly no longer true).

Mojca

(PS: we still might have to revbump some ports though.)
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Perl 6

[Mojca Miklavec]

On 5 January 2016 at 12:52, Carlo Tambuatco wrote:
> Will this work with perl_select…?

No. Or at least not yet.

Perl 6 is not even remotely compatible with Perl 5, so there is no way
to switch between the two versions of Perl to run the same script.

In the future it might be possible to provide multiple versions of
Perl 6 and switch between those (I'm not sure if we want that, but who
knows). We could talk about improvements of port select for perl 5,
but perl 6 is still relatively far from that.

> My installation of perl_select has been a bit flaky. I have perl5.22, 5.16 
> and 5.18 installed but I had to install a specific variant of perl5 to get it 
> to work with all those different perls.

You could file individual bug reports on Trac in cases when calling
perl5.18 doesn't do the job for you for example, even though "port
select" is not quite ready yet and we might use a different approach
completely. I'm not sure if implementing port select for perl is even
feasible.

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

Perl 6

[Mojca Miklavec]

This is just to let you know that we now have Perl 6 in MacPorts.

We don't ship any modules (modules are installed to ~/.perl6 with
'panda' – the equivalent of cpan).

You can install it with
sudo port install rakudo panda

and install modules with
panda install Task::Star

Feedback and (upstream) bug reports welcome. This is the initial
packaging and a relatively fresh public release of rakudo perl, so
problems are not unexpected.

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

Re: Can't build gnupg

[Mojca Miklavec]

On 25 December 2015 at 06:48, Stephen Rasku wrote:
> I've pasted the log here: http://pastebin.com/y3wyHiHb
>
> I believe this is the error causing the build to fail:
>
> :info:build error: invalid value 'c++11' in '-std=c++11'
>
> I am using Xcode 4.6.3 (4H1503) on Lion.  How can I resolve this?

The subject says that you were trying to build "gnupg", but you gave
us a link to a build failure of ld64-latest.

Both gnupg and ld64-latest build fine for me though. What does
/usr/bin/clang++ --version
return?

Please also try to run
   sudo port clean ld64-latest
   sudo port -v build ld64-latest
and provide the complete log again.

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

Re: Migration conflicting ports

[Mojca Miklavec]

On 23 December 2015 at 16:12, Adam Dershowitz wrote:
> Before I upgraded to OS 10.11 I had the gmsh and octave ports installed.  
> Both depended on fltk.  I am now reinstalling my ports per the migration 
> instructions.  The problem is that octave now depends on fltk-devel while 
> gmsh depends on fltk and these conflict with each other.
> The strange part is that the octave port is the same rev that I had installed 
> before the migration (@3.8.2_14).  I don’t know when there might have been a 
> change, or what it was.
> Is there any way to have both gmsh and octave installed?  I am not sure if I 
> should even file a ticket as it seems that there is not a bug in either port, 
> just a conflict between them.

I'm not maintainer of the Octave port, but the Portfile contains the
following comment & code:

http://trac.macports.org/changeset/140782/

# for now on OSX 10.11, just use fltk-devel since fltk does not
# build; remove this condition with the next fltk release (noted
# in that Portfile too).

if {${os.major} == 15} {
depends_lib-append port:fltk-devel
} else {
depends_lib-append path:lib/libfltk.dylib:fltk

(You can try to run "sudo port install fltk" just to confirm that it's
indeed broken.)

You should be able to work around the problem by installing fltk-devel
first, then gmsh and octave (gmsh is happy with either fltk or
fltk-devel, but it would install fltk by default if no binary is
already there).

But you could just as well file a ticket (put michaelld in CC) to
apply the same kind of fix to gmsh as the one in octave.

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

Re: Migration issue

[Mojca Miklavec]

Dear Adam,

On 16 December 2015 at 17:34, Adam Dershowitz wrote:
> I did a selfupdate.  I uninstalled per5, perl5.16 and perl5.22
> Next, I installed perl5 +perl5_16
> Next I installed perl5.16 +universal
>
> Then I did 5.22 and had the problem again:
>
>  sudo port install perl5.22 +universal
> --->  Computing dependencies for perl5.22
> --->  Fetching archive for perl5.22
> --->  Attempting to fetch
> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
> http://packages.macports.org/perl5.22
> --->  Attempting to fetch
> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
> http://lil.fr.packages.macports.org/perl5.22
> --->  Attempting to fetch
> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
> http://nue.de.packages.macports.org/macports/packages/perl5.22
> --->  Fetching distfiles for perl5.22
> --->  Verifying checksums for perl5.22
> --->  Extracting perl5.22
> --->  Applying patches to perl5.22
> --->  Configuring perl5.22
> --->  Building perl5.22
> --->  Staging perl5.22 into destroot
> --->  Installing perl5.22 @5.22.1_0+universal
> --->  Activating perl5.22 @5.22.1_0+universal
> Error: org.macports.activate for port perl5.22 returned: Image error:
> /opt/local/bin/c2ph-5.22 is being used by the active perl5.16 port.  Please
> deactivate this port first, or use 'port -f activate perl5.22' to force the
> activation.
> Please see the log file for port perl5.22 for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.22/main.log
> To report a bug, follow the instructions in the guide:
> http://guide.macports.org/#project.tickets
> Error: Processing of port perl5.22 failed
>
> I did the check that you asked and I see a whole bunch of stuff:
>
> port contents perl5.16 | grep 5.22
>   /opt/local/bin/a2p-5.22
>   /opt/local/bin/c2ph-5.22
...

I need to investigate that. That shouldn't have happened.

> I can send the full list if that would help.  It includes a pile of stuff in
> share/man as well.

You can send me the list of all files (port contents perl5.16) off
list. But I have to try it out myself and see where I screwed up.

> Is the problem with perl5 +perl5_16 ?  Since that is version 5.22.1?
> Should I not have installed that?

If perl5 +perl5_16 installs version 5.22.1 for you, that certainly
shouldn't have happened.

I would warmly suggest you to install perl5 +perl5_22 anyway, but the
behaviour you describe is clearly a bug that we need to investigate
and fix with a very high priority.

Mojca

> On Dec 16, 2015, at 10:30 AM, Mojca Miklavec wrote:
>
> Dear Adam,
>
> Your setup contains some mixture of universal and non-universal ports
> that seems to be interfering.
>
> Add to that the fact that if you would install some ports from scratch
> now, you would get the +perl5_22 variant, while you probably installed
> +perl5_16 in the past. And an upgrade would not automatically switch
> to the other variant. Plus some ports have not been migrated to 5.22
> yet:
>http://trac.macports.org/ticket/48365
>
> I suspect that you get the error because two ports are trying to
> install the same dependency, but one of them is requesting the
> universal variant.
>
> However there is one horribly strange error:
>/opt/local/bin/c2ph-5.22 is being used by the active perl5.16 port
> Something seems wrong here. In my opinion you should force uninstall
> both perl5.16 and perl5.22 and try to install them again. I have no
> clue how you could end up in that situation though (and would
> potentially like to know).
>
> Once you reinstall both perl ports, please check
>port contents perl5.22 | grep 5.16
>port contents perl5.16 | grep 5.22
> and make sure that you don't get any hits. Also, make sure that you
> are using the very latest "selfupdate" (14 hours ago Perl was a tiny
> bit broken).
>
> Having both Perl 5.16 and 5.22 active should not be a problem.
>
> Personally I would remove Perl ports and all ports with +perl5_xx
> variants from the list of activated ports and install them manually
> after migration is done.
>
> Mojca
>
>
> On 16 December 2015 at 15:52, Adam Dershowitz wrote:
>
> I have been attempting to follow the full set of migration instructions,
> after upgrading to 10.11, but I have run into issue with perl stuff.
> i have a bunch of perl libraries that were all installed as dependents of
> other ports.  Before I uninstalled my ports I had
>
>  perl5 @5.22.1_0+perl5_16 (active) platform='darwin 14' archs='noarch'
>  perl5.12 @5.12.5_0+universal platform='darwin 14' archs='i386 x86_64'
>  perl5.16 @5.16.3_1+universal (active) 

Re: Migration issue

[Mojca Miklavec]

On 16 December 2015 at 21:50, Ryan Schmidt wrote:
>> On Dec 16, 2015, at 10:58 AM, Mojca Miklavec wrote:
>>
>> Dear Adam,
>>
>> On 16 December 2015 at 17:34, Adam Dershowitz wrote:
>>> I did a selfupdate.  I uninstalled per5, perl5.16 and perl5.22
>>> Next, I installed perl5 +perl5_16
>>> Next I installed perl5.16 +universal
>>>
>>> Then I did 5.22 and had the problem again:
>>>
>>> sudo port install perl5.22 +universal
>>> --->  Computing dependencies for perl5.22
>>> --->  Fetching archive for perl5.22
>>> --->  Attempting to fetch
>>> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
>>> http://packages.macports.org/perl5.22
>>> --->  Attempting to fetch
>>> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
>>> http://lil.fr.packages.macports.org/perl5.22
>>> --->  Attempting to fetch
>>> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
>>> http://nue.de.packages.macports.org/macports/packages/perl5.22
>>> --->  Fetching distfiles for perl5.22
>>> --->  Verifying checksums for perl5.22
>>> --->  Extracting perl5.22
>>> --->  Applying patches to perl5.22
>>> --->  Configuring perl5.22
>>> --->  Building perl5.22
>>> --->  Staging perl5.22 into destroot
>>> --->  Installing perl5.22 @5.22.1_0+universal
>>> --->  Activating perl5.22 @5.22.1_0+universal
>>> Error: org.macports.activate for port perl5.22 returned: Image error:
>>> /opt/local/bin/c2ph-5.22 is being used by the active perl5.16 port.  Please
>>> deactivate this port first, or use 'port -f activate perl5.22' to force the
>>> activation.
>>> Please see the log file for port perl5.22 for details:
>>>
>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.22/main.log
>>> To report a bug, follow the instructions in the guide:
>>>http://guide.macports.org/#project.tickets
>>> Error: Processing of port perl5.22 failed
>>>
>>> I did the check that you asked and I see a whole bunch of stuff:
>>>
>>> port contents perl5.16 | grep 5.22
>>>  /opt/local/bin/a2p-5.22
>>>  /opt/local/bin/c2ph-5.22
>> ...
>>
>> I need to investigate that. That shouldn't have happened.
>
> I don't see the above, but I do see this:
>
>
> $ port installed perl5
> The following ports are currently installed:
>   perl5 @5.22.1_0+perl5_22 (active)
> $ port destroot perl5.16 +universal
> --->  Computing dependencies for perl5.16
> --->  Fetching distfiles for perl5.16
> --->  Verifying checksums for perl5.16
> --->  Extracting perl5.16
> --->  Applying patches to perl5.16
> --->  Configuring perl5.16
> --->  Building perl5.16
> --->  Staging perl5.16 into destroot
> $ port log perl5.16 | grep '5\.22'
> DEBUG: system: cd 
> /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_perl5/perl5.16/work/perl-5.16.3
>  && ed - 
> /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_perl5/perl5.16/work/perl-5.16.3/config.h
>  < /Users/rschmidt/macports/dports/lang/perl5/files/5.22/config.h.ed
>
>
> That shouldn't have happened either. The 5.16 and 5.22 versions of 
> config.h.ed happen to be the same, but the intention was obviously to use the 
> correct version, and that's not happening.
>
> Combining multiple ports into a single port is fraught with peril; the php 
> port is a rather extreme example, possibly even an antipattern.
>
> My initial attempt at understanding the problem goes something like this:
>
> In this case, you've got a foreach loop in which you're defining subports. 
> However when you define a block inside a subport, such as the post-configure 
> block that runs the ed script when the universal variant is chosen, the block 
> gets stored verbatim for later use, without any variables (such as 
> (${perl5.major}) being expanded. The variables get expanded later, when the 
> block is actually used, in this case after the configure phase. By that time, 
> the foreach loop is long over, and all of the variables over which the 
> foreach loop was looping are now set to their ending values, rather than the 
> intended value.
>
> However, that doesn't explain why, for me, the same is not happening in the 
> post-destroot phase.

Oh, this reminded me on the following thread from the past:
https://lists.macosforge.org/pipermail/macports-dev/2013-July/023498.html

Ryan, does the following patch help?

--- Portfi

Re: Migration issue

[Mojca Miklavec]

Hi,

On 16 December 2015 at 23:33, Mojca Miklavec wrote:
> On 16 December 2015 at 21:50, Ryan Schmidt wrote:
>>> On Dec 16, 2015, at 10:58 AM, Mojca Miklavec wrote:
>>>
>>> Dear Adam,
>>>
>>> On 16 December 2015 at 17:34, Adam Dershowitz wrote:
>>>> I did a selfupdate.  I uninstalled per5, perl5.16 and perl5.22
>>>> Next, I installed perl5 +perl5_16
>>>> Next I installed perl5.16 +universal
>>>>
>>>> Then I did 5.22 and had the problem again:
>>>>
>>>> sudo port install perl5.22 +universal
>>>> --->  Computing dependencies for perl5.22
>>>> --->  Fetching archive for perl5.22
>>>> --->  Attempting to fetch
>>>> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
>>>> http://packages.macports.org/perl5.22
>>>> --->  Attempting to fetch
>>>> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
>>>> http://lil.fr.packages.macports.org/perl5.22
>>>> --->  Attempting to fetch
>>>> perl5.22-5.22.1_0+universal.darwin_15.i386-x86_64.tbz2 from
>>>> http://nue.de.packages.macports.org/macports/packages/perl5.22
>>>> --->  Fetching distfiles for perl5.22
>>>> --->  Verifying checksums for perl5.22
>>>> --->  Extracting perl5.22
>>>> --->  Applying patches to perl5.22
>>>> --->  Configuring perl5.22
>>>> --->  Building perl5.22
>>>> --->  Staging perl5.22 into destroot
>>>> --->  Installing perl5.22 @5.22.1_0+universal
>>>> --->  Activating perl5.22 @5.22.1_0+universal
>>>> Error: org.macports.activate for port perl5.22 returned: Image error:
>>>> /opt/local/bin/c2ph-5.22 is being used by the active perl5.16 port.  Please
>>>> deactivate this port first, or use 'port -f activate perl5.22' to force the
>>>> activation.
>>>> Please see the log file for port perl5.22 for details:
>>>>
>>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.22/main.log
>>>> To report a bug, follow the instructions in the guide:
>>>>http://guide.macports.org/#project.tickets
>>>> Error: Processing of port perl5.22 failed
>>>>
>>>> I did the check that you asked and I see a whole bunch of stuff:
>>>>
>>>> port contents perl5.16 | grep 5.22
>>>>  /opt/local/bin/a2p-5.22
>>>>  /opt/local/bin/c2ph-5.22
>>> ...
>>>
>>> I need to investigate that. That shouldn't have happened.
>>
>> I don't see the above, but I do see this:
>>
>>
>> $ port installed perl5
>> The following ports are currently installed:
>>   perl5 @5.22.1_0+perl5_22 (active)
>> $ port destroot perl5.16 +universal
>> --->  Computing dependencies for perl5.16
>> --->  Fetching distfiles for perl5.16
>> --->  Verifying checksums for perl5.16
>> --->  Extracting perl5.16
>> --->  Applying patches to perl5.16
>> --->  Configuring perl5.16
>> --->  Building perl5.16
>> --->  Staging perl5.16 into destroot
>> $ port log perl5.16 | grep '5\.22'
>> DEBUG: system: cd 
>> /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_perl5/perl5.16/work/perl-5.16.3
>>  && ed - 
>> /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_perl5/perl5.16/work/perl-5.16.3/config.h
>>  < /Users/rschmidt/macports/dports/lang/perl5/files/5.22/config.h.ed
>>
>>
>> That shouldn't have happened either. The 5.16 and 5.22 versions of 
>> config.h.ed happen to be the same, but the intention was obviously to use 
>> the correct version, and that's not happening.
>>
>> Combining multiple ports into a single port is fraught with peril; the php 
>> port is a rather extreme example, possibly even an antipattern.
>>
>> My initial attempt at understanding the problem goes something like this:
>>
>> In this case, you've got a foreach loop in which you're defining subports. 
>> However when you define a block inside a subport, such as the post-configure 
>> block that runs the ed script when the universal variant is chosen, the 
>> block gets stored verbatim for later use, without any variables (such as 
>> (${perl5.major}) being expanded. The variables get expanded later, when the 
>> block is actually used, in this case after the configure phase. By that 
>> time, the foreach loop is long over, and all of the vari

Re: Migration issue

[Mojca Miklavec]

Dear Adam,

Your setup contains some mixture of universal and non-universal ports
that seems to be interfering.

Add to that the fact that if you would install some ports from scratch
now, you would get the +perl5_22 variant, while you probably installed
+perl5_16 in the past. And an upgrade would not automatically switch
to the other variant. Plus some ports have not been migrated to 5.22
yet:
http://trac.macports.org/ticket/48365

I suspect that you get the error because two ports are trying to
install the same dependency, but one of them is requesting the
universal variant.

However there is one horribly strange error:
/opt/local/bin/c2ph-5.22 is being used by the active perl5.16 port
Something seems wrong here. In my opinion you should force uninstall
both perl5.16 and perl5.22 and try to install them again. I have no
clue how you could end up in that situation though (and would
potentially like to know).

Once you reinstall both perl ports, please check
port contents perl5.22 | grep 5.16
port contents perl5.16 | grep 5.22
and make sure that you don't get any hits. Also, make sure that you
are using the very latest "selfupdate" (14 hours ago Perl was a tiny
bit broken).

Having both Perl 5.16 and 5.22 active should not be a problem.

Personally I would remove Perl ports and all ports with +perl5_xx
variants from the list of activated ports and install them manually
after migration is done.

Mojca


On 16 December 2015 at 15:52, Adam Dershowitz wrote:
> I have been attempting to follow the full set of migration instructions,
> after upgrading to 10.11, but I have run into issue with perl stuff.
> i have a bunch of perl libraries that were all installed as dependents of
> other ports.  Before I uninstalled my ports I had
>
>   perl5 @5.22.1_0+perl5_16 (active) platform='darwin 14' archs='noarch'
>   perl5.12 @5.12.5_0+universal platform='darwin 14' archs='i386 x86_64'
>   perl5.16 @5.16.3_1+universal (active) platform='darwin 14' archs='i386
> x86_64'
>   perl5.22 @5.22.1_0+universal (active) platform='darwin 14' archs='i386
> x86_64’
>
>
> But, when I try to run restore_ports.tcl I get a bunch of errors related to
> perl libraries.  The end of the attempt looked like this:
>
> --->  Computing dependencies for p5.16-tree-dag_node
> --->  Dependencies to be installed: p5.16-file-slurp-tiny p5.16-pathtools
> p5.16-test-pod p5.16-pod-simple p5.16-pod-escapes p5.16-test-simple
> --->  Configuring p5.16-file-slurp-tiny
> Error: org.macports.configure for port p5.16-file-slurp-tiny returned:
> configure failure: command execution failed
> Error: Failed to install p5.16-file-slurp-tiny
> Please see the log file for port p5.16-file-slurp-tiny for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-file-slurp-tiny/p5.16-file-slurp-tiny/main.log
> Error: The following dependencies were not installed: p5.16-file-slurp-tiny
> p5.16-pathtools p5.16-test-pod p5.16-pod-simple p5.16-pod-escapes
> p5.16-test-simple
> --->  Computing dependencies for p5.16-uri
> --->  Dependencies to be installed: p5.16-mime-base64
> Error: Requested variants "" do not match those the build was started with:
> "+universal".
> Error: Please use the same variants again, or run 'port clean
> p5.16-mime-base64' first to remove the existing partially completed build.
> Error: Failed to install p5.16-mime-base64
> Please see the log file for port p5.16-mime-base64 for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-mime-base64/p5.16-mime-base64/main.log
> Error: The following dependencies were not installed: p5.16-mime-base64
> can't create directory
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-version":
> permission denied
> while executing
> "file mkdir $workpath/.home"
> (procedure "open_statefile" line 29)
> invoked from within
> "open_statefile"
> (procedure "check_variants" line 29)
> invoked from within
> "check_variants activate"
> invoked from within
> "$workername eval check_variants $target"
> (procedure "mportexec" line 7)
> invoked from within
> "mportexec $workername $install_target"
> Unable to execute target 'install' for port 'p5.16-version': can't create
> directory
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-version":
> permission denied
> while executing
> "install_ports $operationList"
> (file "./restore_ports.tcl" line 287)
>
>
> It seems that there is an issue about having both perl 5.16 and 5.22 active?
> I have tried to manually install each, but can’t seem to get both to be
> active, even though I had them both active before.
>
> I also tried this without making any progress:
>
> sudo port deactivate perl5.16 +universal
> --->  Deactivating perl5.16 @5.16.3_1+universal
> --->  

Re: Problem installing Perl5.22

[Mojca Miklavec]

On 16 December 2015 at 02:09, Horst Simon wrote:
>
> Error: Can't find perl 5.22 (as /opt/local/bin/perl5.22) so can't link perl5
> to it.

Please wait a few minutes. I'll commit a fix.

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

Re: on upgrade cannot link perl5 to perl5.22

[Mojca Miklavec]

On 16 December 2015 at 02:51, Brandon Allbery wrote:
> On Tue, Dec 15, 2015 at 8:46 PM, Murray Eisenberg wrote:
>>
>> Just tried an upgrade of some outdated perl ports. Successfully upgraded
>> perl5.22, but upgrade of perl5 failed:
>
> This was just reported, a fix should be up and selfupdate-able within half
> an hour.

Except that a revbump is probably needed for all the unlucky users who
upgraded during the last hour. (Buildbots should be fine as they kept
the old version.)

Before a revbump: did I manage to break anything else? :)

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

Re: port install of amavis-new failed because I have later version of mail-spf? and p5

[Mojca Miklavec]

On 9 December 2015 at 02:35, Sara Buson wrote:
> Thanks a lot for looking over this!
> Starla
>
> ps: I checked the permissions but even enabling those it would not allow me 
> to change the box.

One can easily move or remove that file during post-destroot phase (or
in the patch). The problem is that we need someone who can test how to
fix all other programs that potentially depend on the presence of that
file.

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

Invitation to the MacPorts Meeting in Slovenia from the 13-17th of March 2016

[Mojca Miklavec]

Dear MacPorts users and developers,

We are happy to announce a MacPorts Meeting taking place in Gozd
Martuljek in Slovenia (next to Italy & Austria) between the 13th and
17th of March 2016.

(In [an unlikely?] case that a significant number of people fill in
the registration form by the end of this week claiming that one week
earlier would work better for everyone, we can still shift the
meeting. We could also prolong the meeting for one day if there is
demand for that.)

Information:
http://trac.macports.org/wiki/Meetings/MacPortsMeeting2016

Registration form:
https://docs.google.com/forms/d/1bZSY0bHtJPvYNq1gjm8QhkA7EhoBjVqKr_l7RQfGjlQ/viewform

(We would like to ask you to register by the end of the year to help
us better plan for the meeting. Your registration is confirmed once
you send 100 EUR which we will use for place reservation.)


A MacPorts meeting would be an excellent opportunity to meet fellow
port developers face-to-face, to brainstorm ideas together, agree
about priorities of future development, decrease the number of open
tickets, put your heads together and finally code (or force someone to
code) those hacks that you never had time to or knew how to implement.

This should also be an excellent opportunity for anyone who would like
to learn more about development of packages/port for the Mac. Or maybe
you are a devoted user or a developer of some software package that
doesn't have a package on Mac yet and you would like some help?

We need your input (and your presence at the meeting) to put together
a wonderful program, packed with a mixture of interesting talks,
round-table discussions, brainstorming sessions, hacking sessions late
in the night next to a fireplace of a tile stove ... possibly while
your kids have a snowball fight just outside of the house. The
location is suitable for family holidays.

Feel free to contact me and Aljaž with any further questions (or keep
the questions that are of general interest on the macports-dev mailing
list).

-

If there are any volunteers to help us put a link to the meeting to
the most suitable place on our website, we will be grateful for your
help.

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

Re: port install of amavis-new failed because I have later version of mail-spf? and p5

[Mojca Miklavec]

On 8 December 2015 at 16:09, Brandon Allbery wrote:
> On Tue, Dec 8, 2015 at 9:48 AM, Robert Chalmers wrote:
>>
>> Decided to install amaves-new and watched as it happily installed
>> everything to do with p5.16xxx and considering I am running p5.22 already I
>> watched as it happily installed just about everything in the port tree as a
>> dependency of amaves-new but in p5.16 … not p5.22,
>
>
> amavisd-new appears to be specifically configured for perl 5.16; you might
> contact the maintainer (pixilla) or just try editing the Portfile to change
> the "set perl_version" line and see if it works.

That is ticket http://trac.macports.org/ticket/48365

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

Re: port install of amavis-new failed because I have later version of mail-spf? and p5

[Mojca Miklavec]

On 8 December 2015 at 23:46, Ryan Schmidt wrote:
>
> Looks like the subports of the p5-mail-spf port conflict with one another on 
> this one file. This is a bug. You should file a bug report in our issue 
> tracker.

I did now: https://trac.macports.org/ticket/49941

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

Re: latex/texlive port: broken latex?

[Mojca Miklavec]

On 30 November 2015 at 16:42, Thomas Ruedas wrote:
> Am 30.11.15 um 16:29 schrieb Mojca Miklavec:
>>
>> But this cannot be solved easily on a MacPorts level except in the
>> same way as MikTeX does it on Windows (ie. it install files on the fly
>> based on whatever files the user is trying to access) with quite some
>> coding. The only safe way is to install the complete texlive suite.
>
> I see; I had expected such fonts to come with latex-extra and its
> dependencies already, but now I remember that this is only a subset of
> texlive. It's been some time since the last update...

The problem is that there are literally thousands of packages in TeX
Live and unless MacPorts would make thousand MacPorts packages out of
TL packages, it's nearly impossible to get all the common dependencies
resolved in any clever way.

In this particular case it might be possible to ask the TeX Live core
team to think whether the package in question (I'm talking about
ecrm1200, not about fonts-recommended) could be included in one of the
"core" collections and this would later be reflected in MacPorts and
possibly installed automatically, but again: which collection would
that be? This collection is already "recommended". Feel free to raise
the question on the TeX Live mailing list if you want. (If you do so,
remove all unnecessary definitions like \usepackage{mydefs} and all
other packages that are not relevant to trigger the problem.)

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

Re: latex/texlive port: broken latex?

[Mojca Miklavec]

On 30 November 2015 at 14:18, Thomas Ruedas  wrote:
> Hi again,
> I am just trying a newly installed texlive installation (latex-extra,
> Macports 2.3.4), but it seems that something is broken.
...
> mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode;
> input ecrm1200
> This is METAFONT, Version 2.7182818 (TeX Live 2015/MacPorts 2015_7)
> (preloaded base=mf)

Does it help if you install
sudo port install texlive-fonts-recommended
?

Mojca

PS: in case it helps, here's how I usually diagnose these issues (on a
complete installation):

> locate ecrm1200
...
/opt/local/share/texmf-texlive/fonts/source/jknappen/ec/ecrm1200.mf
/opt/local/share/texmf-texlive/fonts/tfm/jknappen/ec/ecrm1200.tfm
...
/usr/local/texlive/2015/texmf-dist/fonts/source/jknappen/ec/ecrm1200.mf
/usr/local/texlive/2015/texmf-dist/fonts/tfm/jknappen/ec/ecrm1200.tfm
...
> port provides 
> /opt/local/share/texmf-texlive/fonts/tfm/jknappen/ec/ecrm1200.tfm
/opt/local/share/texmf-texlive/fonts/tfm/jknappen/ec/ecrm1200.tfm is
provided by: texlive-fonts-recommended

If you (or a package) are trying to use some font without a .tfm file,
tex calls metafont, hoping to get the metric files from metafont
sources which usually don't exist.

But this cannot be solved easily on a MacPorts level except in the
same way as MikTeX does it on Windows (ie. it install files on the fly
based on whatever files the user is trying to access) with quite some
coding. The only safe way is to install the complete texlive suite.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Variant conflicts

[Mojca Miklavec]

2015-11-19 0:09 GMT+01:00 Eric A. Borisch wrote:
> On Wed, Nov 18, 2015 at 3:29 PM, Bachsau wrote:
>
>> Is there a way to find all ports still installed with +x11 and
>> reinstall with quartz instead?
>
> Try this first:
>
> port echo active and variant:quartz and variant:x11 \
>   | sed -n -e '/\+quartz/d;s/@[^+-]*//;s/\+x11/-x11+quartz/p' \
>   | xargs -n 2

I would never be able to remember that. I would use a simple
   port installed | grep x11
to get the initial list.

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

Re: ROOT-CERN Installation

[Mojca Miklavec]

On Fri, Nov 13, 2015 at 2:23 AM, Brandon Allbery wrote:
> On Thu, Nov 12, 2015 at 8:14 PM, Daniel Han wrote:
>>
>> Sorry about that. The file was too large and so my email was rejected if I
>> included the attachment. Here is the log file that I meant to attach.
>
> This would appear to be https://trac.macports.org/ticket/49594 and there is
> a patch attached to that ticket that you can try to apply.

I'm sorry. I was traveling when Chris uploaded the patch and then
forgot about it. I'll test it an commit it now.

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

Re: ROOT-CERN Installation

[Mojca Miklavec]

On Fri, Nov 13, 2015 at 7:23 AM, Mojca Miklavec wrote:
> On Fri, Nov 13, 2015 at 2:23 AM, Brandon Allbery wrote:
>> On Thu, Nov 12, 2015 at 8:14 PM, Daniel Han wrote:
>>>
>>> Sorry about that. The file was too large and so my email was rejected if I
>>> included the attachment. Here is the log file that I meant to attach.
>>
>> This would appear to be https://trac.macports.org/ticket/49594 and there is
>> a patch attached to that ticket that you can try to apply.
>
> I'm sorry. I was traveling when Chris uploaded the patch and then
> forgot about it. I'll test it an commit it now.

I committed the fix. It should be enough to do a selfupdate and "port
install root5" now.

Mojca
___
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"?

[Mojca Miklavec]

On Tue, Nov 10, 2015 at 3:26 PM, Daniel J. Luke wrote:
> On Nov 10, 2015, at 5:42 AM, Ryan Schmidt wrote:
>> You could presumably edit archive_sites.tcl to add another packages server 
>> IP address.
>
> or just modify $prefix/etc/archive_sites.conf
>
> see also https://trac.macports.org/wiki/howto/ShareArchives2

I've seen this page recently and was thinking about someone willing to
check this page + check the installation and configuration of the
buildbot software, so that we could play with it during the meeting
(hopefully we will manage to find some older/spare MacPro somewhere to
test it on).

>> 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 -

True. But for the few that do have them, even if just for fun, having
a working MacPorts available is almost the only way to get decent and
recent software running on them.

And you should not entirely ignore the "coolness" factor of them and
the joy that some developers have while fixing problems for those
legacy machines.

> and don’t run one of the 2 major OS releases we support per policy (current, 
> previous).

Despite this being the official policy some time ago, I don't think
that anyone takes this 100% seriously and/or closes the tickets for
build problems on < 10.10 as invalid, particularly now that Apple
switched to one-year release cycles.

On the contrary the latest OS is usually the "most broken one" (and
without binary packages), sometimes for months after the release.

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

Volunteer for a workshop on "setting up your own buildbot/buildslave"? (Was: Experiences with El Capitan)

[Mojca Miklavec]

Hi,

On Mon, Nov 9, 2015 at 10:29 PM, Ryan Schmidt wrote:
> On Nov 9, 2015, at 2:34 AM, Artur Szostak wrote:
>
>> Let me ask another question: Is there a seamless way to add building and 
>> mirroring services from 3rd parties for the pre-built binaries?
>
> No. We want verified binaries built in a clean-room by known servers, not 
> binaries built in unknown conditions by arbitrary contributors.

But from what I understand one should be able to *manually* add a
buildbot's IP or URL to fetch the binaries? I totally agree that
MacPorts should not support adding arbitrary buildbots automatically,
but it should be possible to add your own, right?

Me and Aljaž were discussing the idea of:
- bringing a recent decent mac to the MacPorts meeting (in March 2016)
- bringing a PowerMac G5
- trying to set up a local mirror (for distfiles etc.) and a local
buildbot/buildslave on both
- preparing a short workshop/tutorial about setting up your own
buildbot/buildslave (with someone preparing slides with clear
instructions and giving enough time for a hands-on exercise)

The output/benefit of this workshop would be the following:
- having a 10.5 buildslave (ideally also including libc++ support) at
hand to get feedback about potential problems with software (and
hopefully having an unofficial 10.11 buildslave to play with)
- get more developers familiar with the process
- so that potentially some university/company could easily set up
their own buildbots according to their local needs, or maybe just to
build some additional software that is not part of the official
distribution
- so that a group of "hackers" with mutual trust could use their own buildbots
- so that a group of developers could decide to easily test some
nontrivial changes in private trees with portfiles (like a switch from
multiple versions of Perl to a single version; or a move of Qt from
one location to another)
- so that some eager user could monitor building problems of the
latest commits in case the official buildbots experience problems

My question is: is there any volunteer on this list (independent on
whether he or she will be able to physically attend the meeting) to
prepare the workshop [materials] and test the procedures?

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

Re: p5.16-libapreq2 won't reinstall after migration to El Capitan

[Mojca Miklavec]

On Tue, Nov 3, 2015 at 12:14 AM, Murray Eisenberg wrote:
> After uninstalling p5.16-libapeq2 and mod_perl2 + perl5_16, I was able to 
> install in order:
>
> perl5 + perl5_22
> mod_perl2 +perl5_22
>
> However, "port install  p5.22-libapreq2" still used mod_perl2 + perl5.20

Can you please try again the following:
port info mod_perl2
sudo port selfupdate
port info mod_perl2
sudo port install mod_perl2
port installed mod_perl2
(and tell me the variants reported by mod_perl2)?

For some weird reason "sudo port install mod_perl2 +perl5_22" would
also install "mod_perl2 + perl5_20" for me in the beginning, but that
was before I fixed the port and added perl5_22 to the list of
variants. (I'm curious why it picked 5.20; I would expect 5.16 at
best.)

So maybe you did a selfupdate too fast. Unless you have a second copy
of the Portfile somewhere, that's my only explanation, otherwise you
shouldn't have ended up with +perl5_20. So hopefully another
selfupdate and installation of mod_perl2 will fix the issue.

> and the process ends with error that mod_perl2 must be installed with 
> +perl5_22 !

At least the error message is more clear now. Earlier you would have
ended up with a cryptic build error saying that one perl module was
missing.

> So no go.

You seem to be almost there.

Mojca


>> On 2 Nov2015, at 11:14 AM, Mojca Miklavec <mo...@macports.org> wrote:
>>
>> Dear Murray,
>>
>> On Mon, Nov 2, 2015 at 4:20 PM, Murray Eisenberg wrote:
>>>
>>> The issue re p5.16-libapreq2 is solved!  After the migration, I had never 
>>> activated a version of perl5 by doing "sudo install perl5 +perl5_16. Not 
>>> doing that seems to be what caused failure to build mod_perl2 and hence 
>>> prevented subsequent installation of p5.16-libapreq2.
>>>
>>> (I do still wish a port p5.20-libapreq2 were available, so that I would not 
>>> need to deal with the older versions of perl5.)
>>
>> I just added it now (you could try to switch to 5.22, else you'll be
>> "outdated" soon again).
>>
>> You will have to uninstall or deactivate p5.16-libapreq2, install
>> "perl5 +perl5_22" and "mod_perl2 +perl5_22" and finally install
>> p5.22-libapreq2.
>>
>> Then again it might be nice to get some feedback. Running the
>> testsuite on p5.22-libapre2 fails for some tests. I got rid of some
>> failures by upgrading mod_perl2 to 2.0.9, but some failures remain.
>>
>> Mojca
>>
>> (PS: you might have to wait for half an hour for the port definitions
>> to catch up if you are using rsync for selfupdate)
>
> ---
> Murray Eisenbergmurrayeisenb...@gmail.com
> 503 King Farm Blvd #101 Home (240)-246-7240
> Rockville, MD 20850-6667Mobile (413)-427-5334
>
>
>
>
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: p5.16-libapreq2 won't reinstall after migration to El Capitan - SOLVED!

[Mojca Miklavec]

Dear Murray,

On Mon, Nov 2, 2015 at 4:20 PM, Murray Eisenberg wrote:
>
> The issue re p5.16-libapreq2 is solved!  After the migration, I had never 
> activated a version of perl5 by doing "sudo install perl5 +perl5_16. Not 
> doing that seems to be what caused failure to build mod_perl2 and hence 
> prevented subsequent installation of p5.16-libapreq2.
>
> (I do still wish a port p5.20-libapreq2 were available, so that I would not 
> need to deal with the older versions of perl5.)

I just added it now (you could try to switch to 5.22, else you'll be
"outdated" soon again).

You will have to uninstall or deactivate p5.16-libapreq2, install
"perl5 +perl5_22" and "mod_perl2 +perl5_22" and finally install
p5.22-libapreq2.

Then again it might be nice to get some feedback. Running the
testsuite on p5.22-libapre2 fails for some tests. I got rid of some
failures by upgrading mod_perl2 to 2.0.9, but some failures remain.

Mojca

(PS: you might have to wait for half an hour for the port definitions
to catch up if you are using rsync for selfupdate)
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: error upgrading gcc48 port

[Mojca Miklavec]

On Fri, Oct 30, 2015 at 1:49 PM, Chris Jones wrote:
> On 30/10/15 12:26, Fabrizio Salvatore wrote:
>>
>> I see that there are two ports related to gcc48, one of which is active:
>>
>> --->  The following versions of gcc48 are currently installed:
>> --->  gcc48 @4.8.2_2
>> --->  gcc48 @4.8.3_3 (active)
>>
>> How do I remove both and make gcc49 the default one?
>
> specify the version when uninstalling
>
>> sudo port uninstall gcc48@4.8.2_2

Is there also something like
sudo port uninstall gcc48@all
?

Also, what happened to the GSOC project where user would simply select
which port to uninstall in an interactive way?

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

Re: p5.16-libapreq2 won't reinstall after migration to El Capitan

[Mojca Miklavec]

On Tue, Oct 27, 2015 at 11:03 PM, Murray Eisenberg wrote:
> After migrating macports from Yosemite to El Capitan, installing 
> p5.16-libapreq2 failed during build its all-too-tamiliar error:
>
>   Can't locate ModPerl/MM.pm in @INC
>
> Following a recommendation when the same thing happened under Yosemite, with 
> the reinstalled macports under El Capitan I did follow the same procedure:
>
>   * install perl5 with a variant that corresponds to the perl version you 
> want to use
>
> I think I got this right; I have:
>
> perl5 @5.16.3_0+perl5_16
> perl5 @5.16.3_0+perl5_20 (active)
>
>   * forcibly rebuild mod_perl2 from source (i.e. "sudo port -ns upgrade 
> --force mod_perl2") or if you have not yet installed mod_perl2, install it 
> from source (i.e. "sudo port -s install mod_perl2")
>
> I did the force rebuild of mod_perl2.
>
>   * install the p5-libapreq2 support for the perl version you want to use
>
> I tried "sudo port install p5.16-libapreq2", which failed.
>
>
> Also, I note that there no longer seems to be any p5.20-libapreq2 port 
> available.
>
> How fix??

If you want to keep using perl5perl +perl5_20, then you need to
install mod_perl2 +perl5_20 and p5.20-libapreq2. I have no clue why
p5.20-libapreq is missing and thin could be fixed.

If you want to switch to 5.16, you need to install perl5 +perl5_16,
then mod_perl2 +perl5_16 and finally p5.16-libapreq2.

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

Re: Modification of .profile

[Mojca Miklavec]

On Mon, Oct 19, 2015 at 11:10 AM, Ryan Schmidt wrote:
>
> But I would think most if not all users would want the MacPorts prefix to be 
> in their path. And if there's a problem where MacPorts modifies the profile 
> even if the MacPorts prefix is already in the path, then that could be a bug 
> that we should fix.

I'm almost sure that this is the case. I often find spurious additions
of /opt/local in "~/.bash_profile" when the PATH was already set there
previously. The last time this happened to me was when I first
installed MP on 10.11 from source and the new version with installer
became available a few hours later. I don't remember whether I used
the installer or "--selfupdate" (most likely it was the installer),
but I already had MP in PATH and the installer/updater just made a
backup copy of the old .bash_profile file and added an additional
/opt/local at the end of the file.

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

Re: MacPorts Meeting (preliminary questionnaire)

[Mojca Miklavec]

Hi,

(and sorry for top-posting; if you missed the inital mail, start reading below)

Here's a short follow-up about the potential brainstorming meeting.
Based on the questionnaire it seems that early March with a 4 nights
stay would be the most suitable for the majority.

I was thinking about placing the meeting to Gozd Martuljek, close to a
ski resort. For that area the suitable time windows outside of public
holidays and ski or ski jumping world cups (and thus with lower
prices) are as follows:
- 28.2.2016 - 3.3.2016
- 6.3.2016 - 16.3.2016

The cheaper option would be this hotel Rute:
https://www.booking.com/hotel/si/garni-rute.en-gb.html
https://www.booking.com/hotel/si/guest-house-depandansa-rute.en-gb.html

A nearby hotel Špik is slightly more expensive, with a swimming pool
and offering different types/prices of rooms:
https://www.booking.com/hotel/si/spik-alpine-wellness-resort.en-gb.html
https://www.booking.com/hotel/si/spik.en-gb.html
but we would have to pay extra to use a "proffessional" conference
room. I still need to figure out how much that would be.

The third option would be Planica:
http://www.osc-planica.si/index.php?str=nam_hotel
(you can switch the language and then reload the same URL in case you
don't get the English page)

Anyone *really* interested in watching proffessional sports could
extend the stay and visit the world cup in Planica
(http://www.planica.si/Programme) or Vitranc
(http://www.pokal-vitranc.com/en/programme/). The others could simply
go walking, swimming or skiing, either for a shorter period during the
meeting or before/after that.

If we go for the cheaper option(s), the meeting should cost *well*
below 200 EUR in total.

The destination is reachable with a train (Villach (AT) or Jesenice
(SI)) + a 30 minutes drive by car that we could probably arrange for
everyone. The closest airports are Klagenfurt (AT) and Brnik (SI).

***

One PortMgr member confirmed the attendance and I'm expecting a few
more senior developers to join, but based on the initial feedback from
13 people (a couple more answered months back when I asked) we might
end up with a relatively small number of participants. I would hope
for something like 16, but let's try even if only a handful of us show
up at the end and then grow with years. I will be away for 2-3 weeks.
After that I will take Aljaz with me to Gozd Martuljek and Planica,
check these locations (or maybe others just in case) and decide for
one.

In the meantime we could set up a wiki page collecting both ideas for
the programme as well as other details.

Mojca

***

On Mon, Aug 17, 2015 at 12:02 PM, Mojca Miklavec <mo...@macports.org> wrote:
> Dear MacPorts developers and users,
>
> For those who find the email too long: just fill in this form:
> http://goo.gl/forms/uBYzM4Yrst
>
> --
>
> For everyone else:
>
> Me and Aljaž (g5pw) would be willing to organize a MacPorts
> (developer) meeting in Europe with the intention of:
> - brainstorming and exchanging ideas about the project
> - defining the agenda and priorities for future development of MacPorts
> - having day-long ticket-closing sessions
> - enjoying some longer group hacking sessions that would let us
> realize some long-standing items on the wishlist (finish parts of the
> website, statistics, ...)
> - meeting fellow users and developers and having fun together
>
> We would welcome anyone who:
> - maintains or would like to maintain a port
> - wants to get some core functionality implemented or knows how to implement 
> it
> - would like to help us shape the future of MacPorts
> - wants to help us implement tiny "sugars" (better website, wiki
> pages, documentation, more functionality, ...)
> - has some artistic tallent
> - just wants to enjoy in the company of great people ;)
>
> Here is a preliminary questionnaire. Anyone that is remotely
> interested in joining the meeting is kindly invited to answer a few
> questions:
> http://goo.gl/forms/uBYzM4Yrst
>
> Additional questions can go to the developer mailing list or to me personally.
>
> Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Macports for El Capitan...

[Mojca Miklavec]

On Fri, Oct 2, 2015 at 9:33 PM, Carlo Tambuatco wrote:
> I'm holding off on upgrading to El Capitan until macports for El Capitan
> (version 2.4..?) is available. Any idea when that will be?

It has already been announced. You can fetch the binary from
   https://www.macports.org/install.php

Of course there are no binary archives for ports yet. And some ports
like Qt don't work at the moment.

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

Re: ghostscript problem

[Mojca Miklavec]

On Fri, Sep 25, 2015 at 5:52 PM, j. van den hoff wrote:
> not sure whether this qualifies for a ticket: after recent (~ 2 days ago)
> `port upgrade outdated' postscript generation via `ghostscript' fails for me
> with an error
>
> Error: /invalidfont in /findfont
> Operand stack:
>Times-Roman@0   --nostringval--   Times-Roman
> Execution stack:
>%interp_exit   .runexec2   --nostringval--   --nostringval--
> --nostringval
> p   1966   1   3   %oparray_pop   1950   1   3   %oparray_pop   1836   1   3
> --nostringval--   --nostringval--   1919   3   4   %oparray_pop
> Dictionary stack:
>--dict:1200/1684(ro)(G)--   --dict:0/20(G)--   --dict:79/200(L)--
> --dict:5
> Current allocation mode is local
> Last OS error: Invalid argument
> Current file position is 5762
> GPL Ghostscript 9.16: Unrecoverable error, exit code 1
>
>
> apparently when looking for basic fonts such as times roman. so it seems to
> longer be able to locate any fonts. unfortunately I don't know anything
> specific of ghostscript (just using it via `groff' to generate some
> postscript/pdf output).
>
> this happens with  ghostscript @9.16_1+x11. if I deactivate this one and
> activate `ghostscript @9.10_2+x11' (which I luckily still had available)
> everything goes back to normal.
>
> no idea what is going on here. any help appreciated. if I can provide
> further information I'll be glad to do this.
>
> seen with macos 10.10.5 and MacPorts 2.3.3

It looks suspiciously similar to
https://trac.macports.org/ticket/42395, even though it could be
different enough to happen for to a different reason. That ticket was
opened while 9.10 was still the latest version.

You could either open a new ticket or add more information to the
existing one, possibly together with some "minimal" (or at least
relatively small) GS file (or description of how you got that file)
that triggers the error, to make it easier for others to reproduce the
problem.

(In any case I have no clue where the fonts are.)

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

Re: Writing portfiles: How to depend on a certain variant of a port?

[Mojca Miklavec]

On Sun, Sep 6, 2015 at 8:09 PM, Lars Sonchocky-Helldorf wrote:
>
> brew install gnuplot --with-wxmac --with-cairo --with-pdflib-lite 
> --with-x11 --without-lua
> -
>
> now for gnuplot the default variants are +aquaterm +luaterm +pangocairo 
> +wxwidgets +x11 but according to the above brew stuff I guess I would need 
> the variants +wxwidgets +pangocairo +pdflib +x11
>
> So how would I specify the variants I want in depends_lib?

Having +auaterm +luaterm enabled certainly won't be a problem, but in
general I really doubt that the software requires *exactly* those
terminals enabled. In particular I don't understand why one would need
both X11 and wxWidgets at the same time. And if you have pangocairo
(note that this also requires pango, not just cairo; having just cairo
installed might not be sufficient to get the desired functionality),
there is no need for yet another PDF library because pangocairo knows
how to generate a PDF (and even if you set "set term pdf", it will
automatically work and use pdfcairo instead of pdf even if pdflib is
not installed).

Just start with defaults for now and check how it works. You could in
principle use something like this:

PortGroup active_variants 1.1
require_active_variants gnuplot wxwidgets

to make sure that wxWidgets has been compiled into gnuplot, but leave
that for the end.

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

MacPorts Meeting (preliminary questionnaire)

[Mojca Miklavec]

Dear MacPorts developers and users,

For those who find the email too long: just fill in this form:
http://goo.gl/forms/uBYzM4Yrst

--

For everyone else:

Me and Aljaž (g5pw) would be willing to organize a MacPorts
(developer) meeting in Europe with the intention of:
- brainstorming and exchanging ideas about the project
- defining the agenda and priorities for future development of MacPorts
- having day-long ticket-closing sessions
- enjoying some longer group hacking sessions that would let us
realize some long-standing items on the wishlist (finish parts of the
website, statistics, ...)
- meeting fellow users and developers and having fun together

We would welcome anyone who:
- maintains or would like to maintain a port
- wants to get some core functionality implemented or knows how to implement it
- would like to help us shape the future of MacPorts
- wants to help us implement tiny sugars (better website, wiki
pages, documentation, more functionality, ...)
- has some artistic tallent
- just wants to enjoy in the company of great people ;)

Here is a preliminary questionnaire. Anyone that is remotely
interested in joining the meeting is kindly invited to answer a few
questions:
http://goo.gl/forms/uBYzM4Yrst

Additional questions can go to the developer mailing list or to me personally.

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

Re: MacPorts on PPC

[Mojca Miklavec]

Dear Eneko,

On Fri, Jun 26, 2015 at 2:27 PM, Eneko Gotzon wrote:
 Hello FOSS Wonderful Delivers!

 About a perfectly working PowerPC G5 running Mac OS X.5 (Leopard), do you
 think it is:

 Sensible to use MacPorts on it?

Yes. (I would rather say that it's almost impossible to use 10.5
without a package manager ;)

 Fair to ask for help in case of issues?

Yes. It might not be fair to expect/demand answers though (in case
that nobody with the knowledge to solve that problem still has a
machine to test on).

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

Re: Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Mojca Miklavec]

Dear everyone (but mostly other developers),

I think this was all just an unfortunate misunderstanding.

What I *believe* happened (but I have no way to know) is that the OP
probably tried to build a project cloned with git. That project
required autotools and failed to build because of the weird bug in
MacPorts (non-existent symlink), There must have been a confusion
solely due to the fact that building a git project triggered the
bug.

Please let's not go off-topic in useless discussions about whether or
not macports should magically know which ports theoretically conflict
in case users mess up with their system in unpredictable ways.

On Tue, Jun 23, 2015 at 10:30 PM, Christopher David Ramos wrote:

 I do understand, however, that git is about version control of, usually,
 source code. That said, if building the source code of any given git
 project leads to conflicts with Macports, doesn't that constitute an
 undesirable conflict?

It would. But building the source code of *any given* git project
should not generally lead to conflicts.

The problem from the subject had to do with autotools failing to work
when a symlink points to non-existent location. Git has nothing to do
with autotools (other than the fact that many projects in subversion
or git ask users to run autotools first; while distributed tarballs
contain the configure script and autotools are not needed).

It was all just a misunderstanding. Maybe you were bitten by the
original problem (which is indeed some kind of a weird bug in
MacPorts) while compiling a project that you cloned with git, but the
failure itself is not related to git in any way (unless you
experienced other problems that you didn't describe yet).

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

Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Mojca Miklavec]

On Tue, Jun 23, 2015 at 11:20 PM, Christopher David Ramos wrote:

 Please forgive me if what I'm suggesting is not feasible. That said, it
 was my understanding that makefiles include instructions on what and
 where libraries should be built.

Yes.

 If there were a special Macports
 version of git that included a daemon, could it not be used to overrule
 the default install directories for any libraries a git project's
 makefile may call for?

Generally it shouldn't be.

While it is *not exactly impossible* to adjust installation locations
of directories and libraries based on whatever crazy idea the main
developer comes up with***, no sane setup should change installation
directories based on whether the git binary comes from /usr/bin/git or
/opt/local/bin/git.

Mojca

*** the author of makefile is of course free to use rules like if
folder '/opt/local' exists, then run 'rm -rf /'.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: configure: error: cannot find QtCore header

[Mojca Miklavec]

On Thu, Jun 11, 2015 at 4:44 PM, Hinckley Dan wrote:
 On 11 Jun, 2015, at 8:08, Rainer Müller wrote:

 On 2015-06-11 13:09, Hinckley Dan wrote:
 I have qt5-mac installed and am compiling a program which looks for 
 qtccore. The error I get is:

 checking QtCore usability... no
 checking QtCore presence... no
 checking for QtCore... no
 configure: error: cannot find QtCore header; try setting CPPFLAGS.

 You should look into config.log to get the details of this failing test.

 Perhaps it is also trying to link a simple program which requires setting 
 LDFLAGS as well.

 Have you made sure it is actually looking for the right version of Qt? 
 Often, Qt 5.x is referenced by Qt5Core and Qt 4.x is QtCore.

 configure.ac:

 # libqt 4.7 or compatible newer version is required.
 AC_CHECK_HEADER([QtCore], [],
 [AC_MSG_ERROR([cannot find QtCore header; try setting 
 CPPFLAGS.])])
 AC_CHECK_HEADER([QtGui], [],
 [AC_MSG_ERROR([cannot find QtGui header; try setting 
 CPPFLAGS.])])
 AC_CHECK_HEADER([Qt3Support], [],
 [AC_MSG_ERROR([cannot find Qt3Support header; try setting 
 CPPFLAGS.])])

 I have qt-mac4 installed (and 5, but deactivated) but don’t know which path 
 to put into the CPPFLAGS.

This is contradicting your previous claim that you have qt5-mac installed.

If you have qt5-mac deactivated, then building against Qt5 won't work,
no matter what combination of
/opt/local/libexec/qt5-mac/...
flags you try to set.

But the code above seems to be looking after Qt 4, not Qt 5.

You could either use frameworks:
/opt/local/Library/Frameworks/QtCore.framework
(with -F/opt/local/Library/Frameworks -framework QtCore)

or check the flags with

 pkg-config --libs QtCore
-L/opt/local/lib -lQtCore
 pkg-config --cflags QtCore
-DQT_SHARED -I/opt/local/include -I/opt/local/include/QtCore

These are the flags you need to get QtCore working, but you will
likely have to add others.

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

Re: Cleaning MacPorts from old (unused) ports versions

[Mojca Miklavec]

On Thu, May 28, 2015 at 4:20 AM, Brandon Allbery wrote:
 On Wed, May 27, 2015 at 10:10 PM, Gustavo Seabra wrote:

 So, there were 4 (!) versions of grace installed! That should be remnants
 of old MacPorts installations. I suppose similar multiple versions must be
 present for a number of different ports.

 My question is: is there a way to hunt and remove those older versions of
 ports? (preferably, some automatic way to remove them all, from all
 programs?)


 Those are preserved old versions, from `port upgrade` --- so, if something
 is broken for you in the new version, you can easily roll back.

 `sudo port uninstall inactive` will clear them. If you decide you don't want
 to keep them at all, use `sudo port -u upgrade outdated`.

This is true, but I agree that it would be great to have something like
 sudo port uninstall --all grace

Otherwise one has to manually copy and paste every single version (if
one wants to keep older versions for other ports except with the
interactive version of the port command).

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

Re: libjpeg vs. libjpeg-turbo

[Mojca Miklavec]

On Mon, May 25, 2015 at 11:48 AM, René J.V. wrote:

 Concretely, what happens with applications built against libjpeg.8.dylib when 
 that library becomes a symlink to  libjpeg.9.dylib?

I would guess that the application would crash.

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

Re: selfupdate doesn't work

[Mojca Miklavec]

On Mon, Mar 2, 2015 at 5:53 AM, Jim Goudie wrote:

 Selfupdate doesn't work; any advice? ...

 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

Does the following work if you run rsync from the command line?

 rsync rsync://rsync.macports.org/release/
drwxr-xr-x  4,096 2015/03/03 06:45:07 .
-rw-r--r-- 29,763,932 2015/03/03 06:45:07 ports.tar.gz
lrwxrwxrwx 16 2015/03/03 06:32:32 tarballs
drwxr-xr-x  4,096 2015/03/03 06:01:44 base
drwxr-xr-x  4,096 2014/10/28 01:01:34 ports
drwxr-xr-x  4,096 2014/10/28 01:13:01 tarballs_current

Our sysadmin is happily blocking the port for rsync in the firewall
(being convinced that opening it would decrease the integrity of the
network). Maybe you have rsync blocked as well.

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

Re: Perl -- Why is 5.16 (not 5.20) the default?

[Mojca Miklavec]

On Mon, Feb 23, 2015 at 8:48 AM, Michael wrote:
 I'd like to know if there is a good reason (such as incompatible language 
 change) for perl to be at 5.16 by default?

 I noticed this when I was about to update git -- checking the variants of 
 git, I saw that perl5.16 was the default used by git, and what looks like 2 
 years out of date.

See:
https://lists.macosforge.org/pipermail/macports-dev/2015-February/029762.html

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

Re: How long to expect a new port submission to be processed?

[Mojca Miklavec]

On Mon, Feb 16, 2015 at 8:41 AM, René J.V. wrote:
 On Sunday February 15 2015 23:55:15 Tom Limoncelli wrote:

Hi folks!  I submitted a new port 12 days ago and it hasn't gotten any
attention.  Did I do something wrong?

The problem is that there is a small number of people actively
following new submissions. So if you don't see any response, the best
thing to do is to drop an email on the mailing list (which is exactly
what you did now).

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

 There is no guaranteed processing delay or something of the sort that I know 
 of.  I do think it depends on how useful/interesting your port is judged to 
 be, so even if it may not be wrong, it doesn't seems productive to omit any 
 form of description and/or argumentation from your submission.

There is long_description in the Portfile and there is an extensive
description on homepage (https://github.com/StackExchange/blackbox).
But true, the description of the field could at least repeat what's in
long_description. (However I don't believe that this would make the
process much faster if there is no person with commit rights and
sufficient time and interest to review the submission checking the
ticket submissions.)

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

Re: /opt/local/macports/software

[Mojca Miklavec]

On Tue, Jan 20, 2015 at 9:12 AM, Akim Demaille a...@lrde.epita.fr wrote:

 Also, do people really use deactivate/activate offline?

Yes. I do.

(While I'm usually on a fast internet connection, sometimes the
connection is just as limited and expensive (3G) as hard disk
replacements for the first laptops with tiny SSDs. Or non-existent.)

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

Using xz by default for compression

[Mojca Miklavec]

(was: /opt/local/macports/software)

I'm switching to the developers mailing list – I believe the
discussion belongs there more than to the users' list.

On Tue, Jan 20, 2015 at 10:46 AM, Chris Jones wrote:
 On 20/01/15 02:37, Joshua Root wrote:
 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.

 Or... MP starts shipping xz as a requirement, such as is done with TCL. If
 using xv saves more than it takes up (almost certainly the case) it is
 something to consider.

I would support the switch to xz. Yes, MacPorts could ship xz along
with Tcl and ports could check for both tar.xz and tar.bz2 if tar.xz
wasn't found.

If we wanted to change the contents on the servers, the buildbots
wouldn't have to rebuild everything. It's just a matter of writing a
script that recurses through contents and first extract tar.bz2, then
compresses into tar.xz, done.

TeX Live started shipping xz archives and xz + xzdec binary. It can be
build with no external dependencies and takes up a minimal amount of
space:

350K xz.universal-darwin
361K xz.x86_64-darwin
153K xzdec.universal-darwin
162K xzdec.x86_64-darwin

(universal-darwin: ppc + i386 built on 10.5, x86_64 built on 10.6; the
binaries shipped by TL work on all machines from 10.5 on without any
problems, but they could easily be built on Tiger)

A slight disadvantage of xz is that many users still don't know how to
decompress such files, but this argument doesn't apply here since
port would do everything automatically for the user.

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

Re: cmake 3.1

[Mojca Miklavec]

On Wed, Jan 14, 2015 at 3:34 PM, René J.V. wrote:
 On Wednesday January 14 2015 12:43:27 Mojca Miklavec wrote:

 You could already use a maintainer timeout by now.
 ?

 But I had some (very weird) issues with the update (see the ticket)
 and I would suggest performing at least some very basic tests after
 that fundamental change in Modules/Platform/Darwin.cmake.

 One would hope that the cmake devs tested that new version, no?

Yes, I would expect them to test the new version, but I wouldn't
expect them to test it on utterly weird setups such as the ones where
we have been bitten by the problem:
- Mac OS X 10.6
- with libc++ (or another library) installed under /usr, but not under
/path/to/MacOSX10.6.sdk/usr
- trying to compile software with clang-3.4 against libc++
(This is not the only setup where CMake misbehaved, but it was
difficult to see problems under normal circumstances.)

 Re: extraction: I've been having more and more crashes using port:gnutar to 
 access or create compressed tarchives, while the system tar command (that 
 doesn't even need to be told to decompress before accessing an archive) does 
 not have such issues. Any chance that's related?

Probably.

But unrelated: am I the only one who gets different checksums than the
ones cited in the ticket?

The ticket was created a few days ago and the file on their server is
one month old, so it's not like they made a silent change in the last
few days.

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

Re: cmake 3.1

[Mojca Miklavec]

On Thu, Jan 8, 2015 at 10:27 PM, Marius Schamschula wrote:
 On Jan 8, 2015, at 3:22 PM, René J.V. Bertin wrote:

 On Thursday January 08 2015 14:46:57 Marius Schamschula wrote:
 Rene,

 I posted a ticket with an updated Portfile: see 
 https://trac.macports.org/ticket/46493

 Great, any issues using that new version?

 I haven’t tested it, but in the past cmake has caused more errors when 
 building then when using the resulting executable.

 The only change with the new version is that 
 patch-Modules-Platform-Darwin.cmake.diff no longer works, as Darwin.cmake 
 appears to have been fundamentally rewritten.

 As cmake is not openmaintainer, we will have to wait for the maintainer to 
 take action.

You could already use a maintainer timeout by now.

But I had some (very weird) issues with the update (see the ticket)
and I would suggest performing at least some very basic tests after
that fundamental change in Modules/Platform/Darwin.cmake.

I wrote the details in the ticket.

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

Selecting python3.4

[Mojca Miklavec]

Hi,

I'm a bit confused by the behaviour of starting the python. I tried to
select python with
 sudo port select python python34
Selecting 'python34' for 'python' succeeded. 'python34' is now active.

But it behaves a bit weird, it doesn't give me the version 3.4:

 python --version
Python 2.7.1

Other commands:

 /usr/bin/python --version
Python 2.7.1
 which python
/opt/local/bin/python
 /opt/local/bin/python --version
Python 3.4.2
 ll /opt/local/bin/python
... /opt/local/bin/python - /opt/local/bin/python3.4

How is it possible that python --version runs the version 2.7 instead of 3.4?

---

It might be relevant that I initially had unexplainable problems with:

 sudo port select python python34
Selecting 'python34' for 'python' failed: symlink:
/opt/local/etc/select/python/current - python34: file already exists
 ll /opt/local/etc/select/python/current
lrwxr-xr-x  1 root  admin  8  4 jul 14:07
/opt/local/etc/select/python/current - python33
 sudo port select python none
Selecting 'none' for 'python' failed: symlink:
/opt/local/etc/select/python/current - none: file already exists

So I did
 sudo rm /opt/local/etc/select/python/current
which was necessary to make the port select work in the first place.
I don't know why that happened, but it is true that I deactivated (or
uninstalled) python3.3 recently, so maybe that uninstallation
interfered with port select in some way.

Still I don't understand why that would have any effect in the first place.

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

Re: Selecting python3.4

[Mojca Miklavec]

On Tue, Nov 25, 2014 at 10:30 AM, Andreas Kusalananda Kähäri wrote:

 I don't know if I'm totally off track here, but the shell caches the
 location of binaries.  You may have to do hash -r (or restart the
 shell).

Hi,

Indeed. Starting a new shell or running hash -r fixed the problem.
Weird, I didn't know that binary locations are cached.

Thanks a lot for the pointer, problem solved.

Mojca

 On Tue, Nov 25, 2014 at 10:23:15AM +0100, Mojca Miklavec wrote:
 Hi,

 I'm a bit confused by the behaviour of starting the python. I tried to
 select python with
  sudo port select python python34
 Selecting 'python34' for 'python' succeeded. 'python34' is now active.

 But it behaves a bit weird, it doesn't give me the version 3.4:

  python --version
 Python 2.7.1

 Other commands:

  /usr/bin/python --version
 Python 2.7.1
  which python
 /opt/local/bin/python
  /opt/local/bin/python --version
 Python 3.4.2
  ll /opt/local/bin/python
 ... /opt/local/bin/python - /opt/local/bin/python3.4

 How is it possible that python --version runs the version 2.7 instead of 
 3.4?

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

Re: digikam 4.3.0 (was: depends_build on minimal version?)

[Mojca Miklavec]

On Sat, Sep 20, 2014 at 9:52 AM, René J.V. wrote:
 On Friday September 19 2014 19:42:06 Lawrence Velázquez wrote:

 No ... it was easier to just remove the offending include directory ...

That's an unacceptable solution. If a user interrupts the build, that 
directory might never be put back where it belongs, and they'll have no idea 
how it happened.

Just figure out how to add the correct directories to the header search path.


 I wasn't proposing this as a solution for the portfile. I have reported the 
 issue upstream, but so far the only reply I have got (from the official port 
 maintainer) boils down to works for me. At the same time this person didn't 
 know MacPort provides binary packages, so I'm not 100% sure that testing was 
 done properly. You wouldn't run into this issue installing digikam anew, for 
 instance, instead of upgrading an existing install.

 I'd love to figure out exactly what happens, but I'd need a hand from a 
 seasoned cmake user for that. I find the syntax very unhelpful and it's not 
 like this is a small and easy project to jump in and learn while doing.

I'm somewhat following this thread, but I miss more detailed
information about the problem (without having to spend a few hours
figuring out which version to install, what files to check, how to fix
things, ...). To start with it complains about something I'm not
familiar with: Can't install libiodbc because conflicting ports are
active: unixODBC

I'm almost sure that this is a common  well-known underlying problem
though. I first came across it in
https://its.cern.ch/jira/browse/CLHEP-101

(Ending with Please consider dropping MacPorts in favor of homebrew,
which is at least easier to deal with. Many people have dropped
MacPorts because of problems such as the ones you are having.)

The autotools/configure-based installations of almost anything would
require setting something like
CPPFLAGS=-I/opt/local/include
to find the header files and then the code would be compiled with something like
$(CC) -I./ -I/opt/local/include [...]
which would make sure that the local/newer copy of the header would be
found before the already installed header.

On the contrary this is all very very confusing in CMake. And if you
happen to add -I/opt/local/include to CFLAGS, you will almost always
end up with
$(CC) -I/opt/local/include -I./ [...]
and having an older version of the (incompatible) headers installed
will almost always break compilation.

Se also https://trac.macports.org/ticket/42872

A few things that seem a bit strange in the digikam's Portfile are the
following:

-DCMAKE_SYSTEM_PREFIX_PATH=\${prefix}\;/usr\ \
-DCMAKE_MODULE_PATH=\${prefix}/share/cmake-2.8/Modules\;${prefix}/share/cmake/modules\
\
-DCMAKE_PREFIX_PATH=\${prefix}/lib/cmake\ \

The second line is wrong anyway. In particular we no longer ship CMake
2.8, but 3.0. The rest is (in my opinion) something that either the
PortGroup should set or shouldn't (need to) be set at all.

One thing that I hate about CMake in particular is the need to specify
each and every dependency in the following way:
   configure.args-append
-DMYSQL_CONFIG_EXECUTABLE=${prefix}/lib/mysql55/bin/mysql_config
   configure.args-append
-DPOSTGRESQL_INCLUDE_DIR=${prefix}/include/postgresql92 \
   -DPOSTGRESQL_LIBRARIES=${prefix}/lib/postgresql92/libpq.dylib
other workarounds and shortcuts failed to work for me so far.

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

Re: How install p5-libapreq2 for perl 5.20?

[Mojca Miklavec]

On Mon, Sep 15, 2014 at 4:19 AM, Ryan Schmidt wrote:
 On Sep 14, 2014, at 9:43 AM, Murray Eisenberg wrote:

 Can somebody tell me in simple terms how to go about installing 
 p5.20-libapreq2?

 I tried sudo port install p5.20-libapreq2 but, as I already reported in a 
 ticket, this gives during build the usual error:

   info:build Can't locate ModPerl/MM.pm in @INC (you may need to install the 
 ModPerl::MM module)

 [Currently I have  p5.18-libapreq2 @2.130.0_3 installed, but also errors 
 (report in a ticket) if I try to upgrade it to latest version.]

 When I filed the ticket, it was closed as being a duplicate of #42582: 
 p5-libapreq2: fails to build for any perl version except the default one 
 (Can't locate ModPerl/MM.pm).

 Is there some resolution?

 Not being a macports developer or, for that matter, a perl developer -- just 
 somebody who needs to use perl and perl modules within something else 
 (WeBWorK) -- at this point I don't understand what to do.

 We need to change the mod_perl2 port into a p5-mod_perl2 port that has 
 subports for each perl version.

What is not clear to me is *how* to do that. It's clear about the
majority of files (perl modules), header files could be shared in a
separate package, but what would you do with
  /opt/local/apache2/libexec/mod_perl.so
  /opt/local/apache2/modules/mod_perl.so
?

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

Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)

[Mojca Miklavec]

On Sun, Sep 7, 2014 at 8:36 PM, Lawrence Velázquez wrote:

 All this talk about keeping track of C++ runtimes and switching to libc++ is 
 dangerous because it proposes a huge amount of work that deftly dances around 
 the actual problem.

It's not a huge amount of work. It already works. The question is
about providing a buildbot with binaries. (Personally I'm not willing
to keep recompiling Qt, clang and all other software just to get
libc++ working.)

What do you mean with dancing around the actual problem? The problem
is that the default libstdc++ on  10.9 doesn't have support for
C++11.

(But yes, the use of GPLv3 has something to do with the issue. The
version of libstdc++ that supports C++11 no longer provides a suitable
licence for Apple.)

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

Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)

[Mojca Miklavec]

On Sun, Sep 7, 2014 at 12:52 AM, Ryan Schmidt wrote:
 On Sep 6, 2014, at 5:51 AM, Mojca Miklavec wrote:

 I already argued that we really need a libc++-based buildbot for 10.6-10.8.

 From what I understood all we need is a fix in binary package
 signature + time and resources to set up the buildbots. Once the
 buildbots run, people can start testing and switching to libc++. Once
 we get to a satisfactory support, we can recommend everyone to switch
 and retire the libstdc++-based buildbots if needed.

 Switching from libstdc++ to libc++ would be equal to switching from
 10.x to 10.(x+1). (Nice to automate one day, but people should switch
 manually for now and reinstall everything from scratch.)

 Anything where we're asking people to manually reinstall things is, IMHO, a 
 niche situation. My guess is that a few very interested and involved people 
 subscribe to the macports-users list, but that the vast majority of MacPorts 
 users just use it and never communicate with the community. Those users 
 should be given a smooth upgrade experience as well; they shouldn't have to 
 seek out help to get the best MacPorts experience; it should just work.

I never suggested doing dramatic changes that would *require* users to
do a manual upgrade. But at least to those users that start
complaining about mkvtoolnix crashing, we would have a satisfactory
answer: go to this wiki page and follow instructions to switch to
libc++.


Switching to libc++ only means changing a single setting in
macports.conf. (For better support this also means changing the binary
signature depending on which libc++/libstdc++ library is being used
and setting up a buildbot.)

Support for libstdc++ can stay (to the extent that port maintainers
will support it – same as with support for Tiger).

It would be weird if we forced users to switch to a different runtime.
If nothing else I bet there are users who would really want to keep
using libstdc++ for various reasons (easier to compile [own] software
manually etc.) and don't bother about C++11.

But it would be really really nice to create a mechanism that:
- remembers which ports are installed and which ones are requested
- deactivates (and possibly uninstalls) all ports
- installs all the ports again
which could be applied in both situations:
- switching to a different library or changing some other options in
macports.conf (maybe change applications_dir or frameworks_dir or so)
- upgrading the OS

But that's not *required* to improve support for libc++ on older OSes.

 Do we already record the C++ runtime in the registry with each installed 
 port? If not, we should do that, in addition to getting it into the binary 
 filenames. And just as we do for architectures, maybe we should have an 
 indication for software that doesn't use any C++ runtime (nocxx?).

This is something that I'm not familiar with at all. I would be very
grateful if some other developer would add the necessary code. I'm
willing to keep testing and fixing ports ...

 Presumably we would (or possibly already do) record in the registry the value 
 of configure.cxx_stdlib. But it would be nice if we would also automatically 
 check (somehow: either as part of the install, or maybe as part of 
 rev-upgrade) that the specified C++ library is the one that actually got 
 used. Similarly, it would be nice if we checked that the architectures we 
 recorded are the architectures that actually got built.

 The libc++-based MacPorts works well on  10.9 already for most
 packages.

 Good to know many ports have worked, but I still suspect there are many ports 
 you either haven't tried or haven't noticed the situations where libstdc++ is 
 still being used even though libc++ was requested. An automated check would 
 help with this.

Most definitely there are other/more problems to be expected. If we
add a buildbot, it will be a lot easier to get more people to test.

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

Re: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)

[Mojca Miklavec]

On Fri, Sep 5, 2014 at 9:05 PM, Ryan Schmidt wrote:
 On Sep 5, 2014, at 1:45 PM, René J.V. Bertin wrote:

 Starting with kdevelop 4.7, C++11 is going to be required

 Currently, that means the port will have require OS X 10.9 and later. Support 
 for 10.7 and 10.8 would involve moving all of MacPorts from libstdc++ to 
 libc++ on those systems, which we have pondered before but not yet agreed to 
 do, nor worked out how such an upgrade could be facilitated.

I already argued that we really need a libc++-based buildbot for 10.6-10.8.

From what I understood all we need is a fix in binary package
signature + time and resources to set up the buildbots. Once the
buildbots run, people can start testing and switching to libc++. Once
we get to a satisfactory support, we can recommend everyone to switch
and retire the libstdc++-based buildbots if needed.

Switching from libstdc++ to libc++ would be equal to switching from
10.x to 10.(x+1). (Nice to automate one day, but people should switch
manually for now and reinstall everything from scratch.)

The libc++-based MacPorts works well on  10.9 already for most
packages. Supporting libstdc++ is getting increasingly painful with
more and more software depending on C++11.

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

Re: pdfTeX in texlive missing pdftex.fmt

[Mojca Miklavec]

On Fri, Aug 29, 2014 at 3:40 AM, Jim Graham wrote:
 On Thu, Aug 28, 2014 at 06:35:33PM -0700, Dan Ports wrote:

 This is strange. That file -- which, for the record, is found in
 /opt/local/var/db/texmf/web2c/pdftex/pdftex.fmt -- is compiled during
 the activation of texlive-basic. I haven't heard any other reports of
 problems building that file. If you happen to have a logfile for the
 installation of texlive-basic, I'd be interested to see it.

 I've already uninstalled the MacPorts version of TeXlive and installed
 the one from CTAN.  Sorry, no logs, no anything left of it.

 Now I just need to reset Tex's environment variables, and I'm back
 up and running.

What do you mean with reset TeX's environmental variables? You don't
need *anything at all* other than having binaries in PATH unless you
are doing something really unusual (and you know what you are doing /
what you want to achieve). If you were messing with environmental
variables, this might be one of the most likely reasons why TeX
wasn't able to find the fmt file. You should add configuration to your
own copy of texmf.cnf instead. Can you please list those environmental
variables (before you remove them)?

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

Re: geant4 and/or geant4.10.0

[Mojca Miklavec]

On Sat, Aug 23, 2014 at 4:16 AM, John Hanly wrote:
 Has anyone installed either the geant4 or geant4.10.0 ports?  If so, how do
 you run it after installing?

Geant4: do something like
source /opt/local/libexec/Geant4/Geant4.10.0/geant4.sh

(You can also run sudo port select geant4 geant4.10.0 and then just
source geant4.sh.)

You need to source that file in every newly opened terminal before
running any Geant4 simulation (and often before compiling one, even
though CMake usually finds the module).

But of course there is no such thing as running Geant4. You can
compile source code and run programs compiled against Geant4 ... You
can run something like ccmake
/opt/local/share/Geant4/Geant4-10.0.2/examples/basic/B3/ to configure
the examples.


Gate: the easiest way is to simply launch Gate.app (start it from
launchpad, click on /Applications/MacPorts/Gate.app or run open -a
Gate.app). You can also run Gate from the terminal (you can check
the contents of /opt/local/bin/Gate), but that one is not as
comfortable to use as the Qt app. Or run Gate --qt.

You could install sudo port install gate +geant4100 if you want Gate
compiled against Geant4 10.0, but I'm not yet sure if that works
reliably.

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

Re: geant4 and/or geant4.10.0

[Mojca Miklavec]

On Sat, Aug 23, 2014 at 5:57 PM, John Hanly wrote:
 one other note:  i have never heard of Gate?  what is it?

I'm sorry. I wrote back to you before drinking the morning cup of coffee ;)

I have misread your question and thought that you were asking about
*Gate* and/or Geant4. Gate is a Geant4 application suitable for
medical physics (PET, SPECT, CT, RT, ...) and similar applications. It
allows one to write certain kinds of simulations relatively easy / in
a user-friendly way and users don't have to be programmers to be able
to make simulations with it (while one has to be fluent in C++ for
working with Geant4).

 port info gate
gate @7.0_1 (science)
Variants: debug, examples, geant4100, geant4101, geant495,
  [+]geant496, [+]qt4, qt5, universal

Description:  GATE is dedicated to numerical simulations in medical
  imaging and radiotherapy. It currently supports
  simulations of Emission Tomography (PET and SPECT),
  Computed Tomography (CT) and Radiotherapy experiments.
Homepage: http://www.opengatecollaboration.org

Or http://wiki.opengatecollaboration.org/index.php/Users_Guide_V7.0

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

Re: [KDE/Mac] compiling/installing

[Mojca Miklavec]

On Tue, Jul 29, 2014 at 10:24 AM, René J.V. Bertin wrote:
 Hi,

 I think I stumbled upon a more likely reason for the build issues evoked 
 below. There's been a change in the cmake portgroup,
 registry/portgroups/636464737c420ea283d4ad483ea35193d9da591588cba9f1d1d4e56d8ff6912e-6789/cmake-1.0.tcl
  vs. 
 registry/portgroups/75f5e1bbba3b966f499792f00c2d7f4a1d35c65f00a5600ebfa600fa36b276cf-6911/cmake-1.0.tcl
  :

 @@ -1,5 +1,5 @@
  # -*- coding: utf-8; mode: tcl; c-basic-offset: 4; indent-tabs-mode: nil; 
 tab-width: 4; truncate-lines: t -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
 -# $Id: cmake-1.0.tcl 121112 2014-06-17 20:16:44Z mo...@macports.org $
 +# $Id: cmake-1.0.tcl 119436 2014-04-25 13:10:38Z ni...@macports.org $
  #
  # Copyright (c) 2009 Orville Bennett illogical1 at gmail.com
  # Copyright (c) 2010-2013 The MacPorts Project
 @@ -81,9 +81,12 @@
  # The environment variable CPPFLAGS is not considered by CMake.
  # (CMake upstream ticket #12928 CMake silently ignores CPPFLAGS
  # http://www.cmake.org/Bug/view.php?id=12928).
 -#
 -# But adding -I${prefix}/include to CFLAGS/CXXFLAGS is a bad idea.
 -# If any other flags are needed, we need to add them.
 +# Thus, we have to add them manually to the CFLAGS and CXXFLAGS in the
 +# pre-configure phase.
 +if {${configure.cppflags} ne } {
 +configure.cflags-append ${configure.cppflags}
 +configure.cxxflags-append ${configure.cppflags}
 +}

  # In addition, CMake provides build-type-specific flags for
  # Release (-O3 -DNDEBUG), Debug (-g), MinSizeRel (-Os -DNDEBUG), and

 This ought at least explain the failures to find headerfiles in 
 /opt/local/include mentioned by b...@ithryn.net .

You reversed the direction of the commit
(http://trac.macports.org/changeset/121112), but adding
configure.cppflags is certainly not acceptable as it causes way too
many headaches.

Does it help if you add -DCMAKE_INCLUDE_PATH=${prefix}/include? (I'm
not 100% sure if that's the right variable.)

We were discussion replacing cppflags=-I${prefix}/include with a
variable with a list of include paths. Then CMake or any other build
system could convert that list into its own format.

For example
configure.includedirs-append ${prefix}/include/somelib
could end up as
-DCMAKE_INCLUDE_PATH=${prefix}/include/somelib...
in CMake and as something else in another system.

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

Re: [KDE/Mac] compiling/installing

[Mojca Miklavec]

On Tue, Jul 29, 2014 at 11:36 AM, René J.V. Bertin wrote:
 On Jul 29, 2014, at 10:51, Mojca Miklavec wrote:

 You reversed the direction of the commit
 Indeed ...

 (http://trac.macports.org/changeset/121112), but adding
 configure.cppflags is certainly not acceptable as it causes way too
 many headaches.

 Really? How long had it been there (i.e. the previous cmake-1.0.tcl version), 
 because I don't recall any issues that might have been caused by it.

The comment on the changeset includes a link to the ticket:
   - http://trac.macports.org/ticket/42872
But there are others:
   - http://trac.macports.org/ticket/41241
And the ticket alone lists 24 ports that added local patches to work
around the problem.

The problem probably affected *every single port* during an *upgrade*
from an icompatible API change.

 In fact, how can one get by NOT adding -I${prefix}/include and 
 -L${prefix}/lib, if prefix is not /usr or /usr/local ??

Mostly FindFoo.cmake. But ask the CMake developers. Usually the better
question would be how to *remove* /opt/local, /sw and other prefixes
when you have your ports installed under some nonstandard prefix or
when you have both MP and HB installed for example.

In any case adding -I${prefix}/include to CFLAGS will probably sooner
or later bite you back, so think about using one of the other CMake
variables.

 Maybe I just don't have any of the ports that add options other than -I to 
 configure.cppflags, if those exist?

CMake doesn't support cppflags. So if a port uses CMake and needs some
extra flags, it would be useless for that Portfiles to add cppflags
anyway.

 Does it help if you add -DCMAKE_INCLUDE_PATH=${prefix}/include? (I'm
 not 100% sure if that's the right variable.)

 I'd have to keep that in mind for when I run into a header search issue when 
 building. I personally only had the issue with (-lakonadi-calendar) not 
 finding libakonadi-calendar.dylib. And somehow I doubt cmake is clever enough 
 to add -L/opt/local/lib if it encountered -I/opt/local/include?

You usually have to explicitly add something like
-DAKONADI_CALENDAR_LIBRARY=${prefix}/lib/libakonadi-calendar.dylib
to the Portfile. See root6 for example.

 We were discussion replacing cppflags=-I${prefix}/include with a
 variable with a list of include paths. Then CMake or any other build
 system could convert that list into its own format.

 For example
configure.includedirs-append ${prefix}/include/somelib
 could end up as
-DCMAKE_INCLUDE_PATH=${prefix}/include/somelib...
 in CMake and as something else in another system.

 Yes, sounds like a plan, with something similar for LIBDIR I guess.

Yes.

 I'm not sure if CMAKE_INCLUDE_PATH is the one to go for though, and not 
 INCLUDEDIRS or something like that ...

Maybe. I'm not sure which variable is the proper one.

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

Re: Recent p5.16-module-runtime update broke p5.16-moose

[Mojca Miklavec]

On Wed, Jul 23, 2014 at 3:17 PM, Andreas Kusalananda Kähäri wrote:
 Will do! Thanks!

I upgraded the port already, r122526. (But I need to update a bunch of
other dependencies to be able to enable perl 5.18 and/or 5.20.)

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

Re: Recent p5.16-module-runtime update broke p5.16-moose

[Mojca Miklavec]

On Wed, Jul 23, 2014 at 6:35 PM, Frank Schima wrote:
 On Jul 23, 2014, at 10:33 AM, Mojca Miklavec wrote:

 On Wed, Jul 23, 2014 at 3:17 PM, Andreas Kusalananda Kähäri wrote:
 Will do! Thanks!

 I upgraded the port already, r122526. (But I need to update a bunch of
 other dependencies to be able to enable perl 5.18 and/or 5.20.)

 I’m actually working on that if you want to wait for me to commit my updates 
 for many p5-* ports.

Yes, feel free to finish the job. I'm going out for a while and I
don't plan to do anything else today.

Until now I went through a bunch of ports and made different edits
(checksums, whitespace, upgrades, added p5.18, ...)

One question though in case that you are going through mass-editing the ports.

In case that p5.20 turns out to be working OK and in case that we
don't plan to get rid of p5.18 soon ... can you please help me figure
out whether it makes sense to make the same change as I did for 5.20
also for 5.18? (We would need to revbump ports, but the number is
still relatively small at this moment compared to the total number of
perl modules.) That's totally optional though.

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

Re: where does macports installs programs?

[Mojca Miklavec]

On Thu, Jul 10, 2014 at 2:48 AM, Fabrizio Salvatore wrote:
 thanks!

 I am having a bit of trouble now... I have two macs on which I think I have 
 installed everything in the same way (python27, root5, root5 +python27); on 
 one mac I can use pyROOT with no problem:

 python
 Python 2.7.8 (default, Jul  3 2014, 06:00:18)
 [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
 Type help, copyright, credits or license for more information.
 import ROOT


 it works perfectly.

 On the second laptop I have the following:

 python
 Python 2.7.8 (default, Jul 2 2014, 10:14:58)
 [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
 Type help, copyright, credits or license for more information.
 import ROOT
 Traceback (most recent call last):
  File stdin, line 1, in module ImportError:
 No module named ROOT 

 Despite I have used exactly the same commands to install python
 (sudo port install python27)

 I see that there are some subtle differences in the output of the 'python' 
 command, but I don't know if they matter

 In any case, I have done (as suggested in this thread)
 sudo port select python python27
 sudo port select root root5

 on both macs and I have checked that I have

 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/libPyROOT.so
  - /opt/local/libexec/root5/lib/root/libPyROOT.so
 /opt/local/libexec/root5/lib/root/libPyROOT.so - libPyROOT.5.34.so

 so I really don't understand why pyROOT works on one and not on the other

Please run which python, ls -l /opt/local/bin/python and port
select --show python to verify that you have properly enabled the
default python.

Then also check port installed root5 to verify that the active
variant of root has python support enabled.

 I have tried to uninstall root5 on the second mac, to see if by re-installing 
 from scratch solves the problem, but I have the following error:

 sudo port uninstall root5
 --- The following versions of root5 are currently installed:
 --- root5 
 @5.34.18_0+cocoa+gcc48+graphviz+gsl+minuit2+opengl+python27+roofit+soversion+ssl+tmva+xml
  (active)
 --- root5 
 @5.34.18_0+cocoa+gcc48+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml
 Error: port uninstall failed: Registry error: Please specify the full version 
 as recorded in the port registry.

 If anyone has any idea of what I'm doing wrong (or what could be wrong), I 
 would be really grateful!

When you have multiple variants or versions installed, you need to use
sudo port uninstall
root5@5.34.18_0+cocoa+gcc48+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml
to specify which version you want to uninstall. But you can just as well use
sudo port deactivate root5
to just remove all files from path etc. Then you can activate the same
version/variants later.

Mojca

PS: It is or at least was true that ROOT installation notes instructed
users to set LD_LIBRARY_PATH. Or to source a file that would set it
for you. I remember seeing binaries or libraries that pointed to
libraries without full path as is usual on Mac. I think that the
issues improved considerably with time (but I didn't check
documentation) and MacPorts certainly doesn't (or at least shouldn't)
need any of that.

(Sadly Geant4 still needs a bunch of environmental variables for
example, else it crashes.)

PPS: You can also use sudo port select --set root root5. (I also
find it weird that root-config5 has that name; root5-config would be
more natural.)
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: texlive-bin-extra and texlive-latex-extra conflict?

[Mojca Miklavec]

On Sun, Jul 6, 2014 at 11:10 AM, Lenore Horner wrote:
 Upgraded outdated after not having done so for a few months (on Mavericks).
 The following.

 ---  Activating texlive-latex-extra @34239_0+doc
 Error: org.macports.activate for port texlive-latex-extra returned: Image
 error: /opt/local/bin/ps4pdf is being used by the active texlive-bin-extra
 port.  Please deactivate this port first, or use 'port -f activate
 texlive-latex-extra' to force the activation.

 I used -f but it seems odd that I should have had to do this.  I tried to
 find a bug report and failed.  I don’t know if I have something weird going
 on or my search skills stink.

I didn't look closely yet, but my blind guess is that ps4pdf used to
be part of texlive-bin-extra and is now part of texlive-latex-extra.
That's a common problem with TeX Live packaging on MacPorts (upstream
sometimes moves files from one collection to another and it's a
problem during upgrade on MP when one package gets upgraded while
other packages from 2013 are still active).

For example if you take a look at texlive-latex/Portfile you'll find
the following code:

# TL 2014: miscdoc moved from texlive-latex-recommended to texlive-latex
pre-activate {
if { ![catch {set vers [lindex [registry_active
texlive-latex-recommended] 0]}]
  ([vercmp [lindex $vers 1] 32420]  0
 || [vercmp [lindex $vers 1] 32420] == 0
  [lindex $vers 2]  1)} {
registry_deactivate_composite texlive-latex-recommended 
[list ports_nodepcheck 1]
}
}

There is a high chance that the same trick needs to be used in
texlive-latex-extra.

A workaround should be to upgrade texlive-bin-extra before activating
texlive-latex-extra.


There is another pretty annoying limitation of MacPorts when
installing TeX Live. After a TeX Live installation is complete, one
needs to run mktexlsr and remake the formats and that takes a while.
TeX Live provides roughly 90 packages. In MacPorts those commands are
being run after every single package. There are 35 texlive-lang-*
packages plus a bunch of others that require remaking formats, but
that remake should only be done once. MacPorts probably regenerates
the format about 40 times when installing TeX Live. That process alone
could easily lead to extra 20 minutes of installation time for no good
reason.

It would be nice if MacPorts offered a hook similar to
post-(de)activate, but something that would be executed only once the
whole batch of packages gets removed, installed or upgraded, not after
every single package.

The second useful feature would be to first deactivate all active TeX
Live package from 2013 and only then install packages from 2014. Then
the above mentioned hack would only have to be implemented once.

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

Re: cmake universal?

[Mojca Miklavec]

Can someone please help me come up with a setting in the cmake
PortGroup that wouldn't lead to CMake being built as universal (when a
port using the PortGroup would be installed as +universal)?

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

Re: cmake universal?

[Mojca Miklavec]

On Sun, Jul 6, 2014 at 4:27 PM, René J.V. wrote:

 If one agrees that there is 0 (zero, nil) interest in a universal cmake
 variant, you could disallow building one with

 universal_variant no

I don't agree with this change. The universal_variant no is there
for ports that are not capable of being built as universal.

It would be nice to figure out why you ended up with +universal (I
didn't know that using sudo port install something +universal would
install all dependencies as universal for example), but I don't
support disabling a variant just to prevent unintentional installation
(which might have happened by mistake; or if you installed it long
time ago when the necessary mechanisms weren't there already and you
were stuck with +universal forever).

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