Re: PR usage by people with commit access

[Joshua Root]

On 2016-11-5 06:14 , Daniel J. Luke wrote:

On Nov 4, 2016, at 2:09 PM, Sterling Smith  wrote:

In the past, I have seen responses to svn changelogs directed to the committer 
and copied to the dev list,


I expect that to continue to be the case.


so apparently port maintainers who are committers are not always the best 
reviewers.  How many times has there been a post-svn-commit debate about 
whether something warranted a revision bump?  I would recommend that any change 
that changes the build more than a version and checksum change warrants a pull 
request.  If no one acts to review it within the timeliness dictated of the 
committer, then they still have the prerogative and authority to commit the 
changes when they want.


-1 from me.

I'm not sure what problem this actually would solve, and it would be more work 
for committers.

[if we had lots of people capable and willing to do review every change, then I 
could see it being helpful - but we don't have that]


I can see PRs being helpful in the case where a committer has a change 
to someone else's port ready to go and they just want to run it by the 
maintainer. In that situation it's quicker and easier than the alternatives.


But in general, yeah, not enough hours in the day.

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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-5 03:14 , Ryan Schmidt wrote:




On Nov 4, 2016, at 08:03, Adam Mercer  wrote:

Or is there a way to tell
the buildbot not to produce packages?


Whether the buildbot distributes the binary is based on whether its stated 
license is distributable or not. But I'm reluctant to suggest you change the 
license to something not distributable if it is.


Instead of replacing the license string, you could append some 
human-readable string that indicates that we don't want to upload 
binaries. As long as it's not in the list of recognised licenses it will 
have that effect.


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

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[Joshua Root]

On 2016-11-4 19:36 , René J. V. Bertin wrote:

Lawrence Velázquez wrote:


Overall, can we just stop this discussion, please? We settled to stay

migrating is not worth it right now. At this point, we are kicking
a horse that is dead and buried and worm food, and it is wasting
everyone's time and energy. Enough.


So is this the kind of attitude with which you think to motivate others to
contribute to help make MP better?

Great job, really.


We could really do without this kind of sarcastic, insinuated personal 
attack. Cool it.


And yes, by explaining just how unlikely we are to make this change, 
Larry is attempting to direct contributions towards more productive 
areas. We're not doing another ticket migration any time soon, and we're 
even less likely to add a second bug tracker.


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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-4 15:02 , Joshua Root wrote:

On 2016-11-4 14:53 , Blair Zajac wrote:


$ port info mercurial | head -2
mercurial @3.9.2 (devel, python)
Sub-ports:mercurial-devel


$ port info --index mercurial | head -2
mercurial @4.0 (devel, python)
Sub-ports:mercurial-devel


OK, so the Portfiles are up to date but not the PortIndex. Not sure why
that would be happening; I guess Ryan needs to take a look.


No, wait, other way round. That's even stranger. :-|

Could be the non-tarball ports tree is not updating properly. Try 
changing to the tarball? That's a good idea anyway as it's signed.


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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-4 14:53 , Blair Zajac wrote:



On Nov 3, 2016, at 8:51 PM, Joshua Root <j...@macports.org> wrote:

On 2016-11-4 14:41 , Blair Zajac wrote:

Seeing some odd things with rsync with this config:

root@poppy-mbp:~#  grep -v ^# /opt/local/etc/macports/sources.conf | uniq

rsync://rsync.macports.org/release/ports/ [default]



root@poppy-mbp:~# port -v outdated
The following installed ports are outdated:
curl-ca-bundle 7.50.3_0 < 7.50.3_1
mercurial  3.9.2_0 < 4.0_0
root@poppy-mbp:~# port -v upgrade --enforce-variants outdated
--->  Scanning binaries for linking errors
--->  No broken files found.
root@poppy-mbp:~#


It doesn’t look like the files on rsync.macports.org are being kept up to date. 
Did I miss a command to run on my MacPort installs?


Ryan mentioned earlier that his internet connection was being saturated by 
package uploads, which delays the update of the ports tree and index.

But in this case you do see the new version, so that can't be what happened. 
Did you activate the older version of these ports after upgrading previously? 
If not, does 'port info mercurial' agree with 'port info --index mercurial’?


No, I didn’t activate the old versions of the ports. The two commands don’t 
match:

$ port info mercurial | head -2
mercurial @3.9.2 (devel, python)
Sub-ports:mercurial-devel


$ port info --index mercurial | head -2
mercurial @4.0 (devel, python)
Sub-ports:mercurial-devel


OK, so the Portfiles are up to date but not the PortIndex. Not sure why 
that would be happening; I guess Ryan needs to take a look.


To work around you can probably run portindex.

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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-4 14:41 , Blair Zajac wrote:

Seeing some odd things with rsync with this config:

root@poppy-mbp:~#  grep -v ^# /opt/local/etc/macports/sources.conf | uniq

rsync://rsync.macports.org/release/ports/ [default]



root@poppy-mbp:~# port -v outdated
The following installed ports are outdated:
curl-ca-bundle 7.50.3_0 < 7.50.3_1
mercurial  3.9.2_0 < 4.0_0
root@poppy-mbp:~# port -v upgrade --enforce-variants outdated
--->  Scanning binaries for linking errors
--->  No broken files found.
root@poppy-mbp:~#


It doesn’t look like the files on rsync.macports.org are being kept up to date. 
Did I miss a command to run on my MacPort installs?


Ryan mentioned earlier that his internet connection was being saturated 
by package uploads, which delays the update of the ports tree and index.


But in this case you do see the new version, so that can't be what 
happened. Did you activate the older version of these ports after 
upgrading previously? If not, does 'port info mercurial' agree with 
'port info --index mercurial'?


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

Re: How to keep uncommitted work in a git clone

[Joshua Root]

On 2016-11-4 12:56 , Ryan Schmidt wrote:

With Subversion, I was accustomed to keeping changes in my working copy that I 
was not ready to commit yet.

Git doesn't let me do that. It complains and tells me to git stash and later 
git stash pop.

Well, I tried that. I git stashed, then made changes to curl and committed 
them, and later when I tried to git stash pop, my other changes that I had in 
my git clone were not restored. I have no idea where they are now.

I can get these particular changes back from my old Subversion working copy, 
but I don't understand how I'm meant to work with git when I have changes that 
I'm not ready to commit yet, yet there are other changes I need to make and 
commit elsewhere within that same clone.


Using autostash as discussed earlier works well for me:



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

Re: GitHub desired workflow...

[Joshua Root]

While using the git port is a good idea for many reasons, the 
Xcode-provided git should have autostash since Xcode 5.1 or so.


- Josh

On 2016-11-2 03:40 , Eric A. Borisch wrote:

As should the fact that, for this to work, you need to be using a
new-enough git (like from ports) and not the system-provided one.

On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning > wrote:

On 01 Nov 2016, at 01:10 , Brandon Allbery > wrote:

> You can even configure so that becomes the default for "git pull" for 
that repo.
>
> git config --local --bool pull.rebase true
> git config --local --bool rebase.autoStash true

This should go into the wiki page!


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

Re: GitHub desired workflow...

[Joshua Root]

On 2016-11-1 09:21 , Lawrence Velázquez wrote:

The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.


Or cd there first. If you're working on a ports tree you'll often be in 
the right place already.


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

Re: GitHub desired workflow...

[Joshua Root]

On 2016-11-1 08:46 , Lawrence Velázquez wrote:

On Oct 31, 2016, at 5:01 PM, Eric A. Borisch  wrote:

5) 'push' changes (to macports-ports)

Oh, and and to capture upstream changes, somewhere after 1 and before
5 (4? 3?),

a) git fetch
b) git rebase origin/master
It looks like git pull --rebase does both of those, so that's not too
bad.


That's the idea, although you'll have to do this with a clean working
tree. That means committing or stashing your WIPs.


I'm using 'git pull --rebase --autostash' which does the stash-before 
and pop-after automatically.


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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

On 2016-11-1 06:34 , Marko Käning wrote:

On 31 Oct 2016, at 20:25 , Joshua Root <j...@macports.org> wrote:

Depends on the nature of the breakage, which is not shown above. The only 
dependency is jpeg, which has not changed in some time. My jasper installation 
is certainly not broken.


Hmmm…

OK, next time I need to get more detailed logs. Just don’t know how to get that 
done in the demoed workflow. :(


It would probably help to set:
revupgrade_mode report

Then if it finds anything, you can rerun with -v for details.


Maybe something else is being linked to, in which case simply rev bumping does 
not fix the problem. Or maybe something happened to your copy of jpeg that 
changed the soname, in which case that is the problem.


I don’t think I can do anything now there anymore.

Perhaps I better ask the list if I run into stg similar again and then we can 
decide together whether to revbump or not?


Tell me. That's what maintainers are for. :)

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

On 2016-11-1 06:08 , Marko Käning wrote:

Hi Joshua,

On 31 Oct 2016, at 18:04 , Joshua Root <j...@macports.org> wrote:

Why?


because I ran into this:
---
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16



Doesn’t the second build of jasper justify the revbump, or should we simply 
ignore this and let rev-upgrade take care of it??


Depends on the nature of the breakage, which is not shown above. The 
only dependency is jpeg, which has not changed in some time. My jasper 
installation is certainly not broken.


Maybe something else is being linked to, in which case simply rev 
bumping does not fix the problem. Or maybe something happened to your 
copy of jpeg that changed the soname, in which case that is the problem.


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

[macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

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

Re: Compiling dnsmasq with dnssec support?

[Joshua Root]

On 2016-10-30 19:15 , Johannes Kastl wrote:

Question 1: Is it possible to use different patchfiles-statements,
depending on the variant?


Yes.


Question 2: Is it possible to add another patch in one variant?


Yes.


Question 3: Is there any reason why no +dnssec variant exists? Or
why dnssec is not enabled by default (as long as the dnssec stuff is
commented in the dnsmasq.conf it should not interfere, I guess)?


Probably just nobody asked for it before now.

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

Re: Git tools for managing patchsets

[Joshua Root]

On 2016-10-25 10:03 , Michael wrote:


On 2016-10-24, at 2:57 PM, Marko Käning  wrote:


Hi folks,

when I read only the first two paragraphs of this thread...

On 24 Oct 2016, at 18:37 , Michael  wrote:

So since MacPorts is moving to git, and from what I saw in the "how to use git" 
docs you mentioned, you apparently want people to work with patchsets rebased onto the 
current head from upstream.

As I was thinking about that, I realized that you lose your history of the 
patchset in the process.


... I already got the shivers! My goodness, how much did I enjoy the ease of 
Mercurial! Loosing history because of a patch set?!
:-/

Well, but I think what you, Michael, are describing, is only needed if you work 
with many patches which aren’t really committed to any repository.


Actually, it's something else. It's the tracking of the history of changes when 
those changes get rebased.

This is not about the port files; those work just fine. This is about the 
patchsets needed to port a program to OS X.

If I have a set of patches to port version 1 of a program to OS X, what happens 
when version 2 of the program comes out?

If you just rebase the patches onto version 2's code, then there is no 
connection between the patches for v1 and v2; there's no good way to compare 
how your patches for version 1 compared to the patches for version 2, or 
version 3. Etc.

The answer is, that there are now two good methods for doing this. Git for 
Windows has one method (in fairness, I did not understand it, it seems mostly 
manual, but has been developed/improved over years), and the just-released 
git-series has a second one (based around extensions to normal git commands).


The real work of updating patchsets (which are effectively the same 
thing as a branch) can't really be automated. You have to resolve the 
conflicts manually because you have to understand what the patches are 
actually doing.


The parts that can be automated are handled by a tool like quilt. It 
looks like git-series does something similar but handled more like a 
real git branch.


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

Re: Trac & Subversion available again

[Joshua Root]

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



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

Hello MacPorts users and developers,

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

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


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

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


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


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


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

Re: Moving to GitHub: Status Update, Action Required

[Joshua Root]

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

Hi Clemens,

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


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


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



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

But the term “pull access” confuses me here!

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

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

Thanks,
Marko


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


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

Re: foo-snapshot / foo-diff convenience functions

[Joshua Root]

On 2016-10-21 01:42 , Lawrence Velázquez wrote:

On Oct 20, 2016, at 3:40 AM, René J.V. Bertin  wrote:


On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote:

No, that situation should not be common, nor indeed present at all.


I'm not sure I agree. PortGroups are intended to take care of setting
up things for the ports that use them (like declaring a dependency in
such a way ports work with the main as well as the -devel port), and
even an official one like the github PG adds dependency info. Ditto
for the Python PG: you cannot (to my knowledge) include it just to
obtain the variables that provide the python paths without also
redefining the configure mechanism.

You could claim that it should be uncommon that ports want only part
of the info a PG provides, but even that might not be relevant as
I think there are quite a few ports providing Python extensions but
that don't use Python's own configure/build/install mechanism (PyQt
and PyKDE come to mind).


This is arguably a defect of python-1.0 that should be fixed in the
portgroup.


No, it's just out of scope. The python portgroup is for installing with 
setup.py.


There is of course no reason why a different portgroup with a different 
purpose couldn't be created, and share code with this one behind the scenes.


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

Re: [154081] trunk/dports/textproc/extractopinion/Portfile

[Joshua Root]

On 2016-10-20 13:23 , Ryan Schmidt wrote:



On Oct 19, 2016, at 9:04 PM, mo...@macports.org wrote:

Revision
154081
Author
mo...@macports.org
Date
2016-10-19 19:04:20 -0700 (Wed, 19 Oct 2016)
Log Message

extractopinion: switch to perl5.24 (#52081)
Modified Paths

• trunk/dports/textproc/extractopinion/Portfile



@@ -29,7 +29,7 @@
 depends_lib port:crfpp \
 port:libiconv \
 port:gawk \
-port:p5.22-text-csv_xs \
+port:p5.24-text-csv_xs \
 port:juman6 \
 port:knp3


This only changes the dependency but doesn't tell the build system to use it. 
That needs to be done in patch-perl.diff. (We've actually forgotten to change 
this every time since perl5.12.)


Probably a good reason to use a placeholder string in the patch file and 
then reinplace it with the actual version-specific string in the portfile.


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

Re: advanced bash-ing for long compiles

[Joshua Root]

On 2016-10-15 01:50 , Ken Cunningham wrote:


I notice mdworker seems to go nuts during these long builds, often appearing to 
soak up lots of cycles. I assume it’s trying to index all the build files, etc

is it easy to sleep that function and then re-enable it after the compile is 
done?


Not sure why this would be, since we set the hidden flag on 
${prefix}/var/macports (technically $portdbpath) which should exclude it 
from Spotlight indexing. Maybe that doesn't work on 10.6? You could try 
adding it to the Privacy list in the Spotlight settings manually.


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

Re: trac down?

[Joshua Root]

On 2016-10-15 01:12 , Lawrence Velázquez wrote:

On Oct 14, 2016, at 8:55 AM, René J.V. Bertin  wrote:

I cannot connect to trac but the main site works fine. Is there a problem with 
the server?


I have not been able to reach it since last night (~12 hours ago).


It loaded fine for me just now, FWIW.

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

Re: reasons for `port provides` not working?

[Joshua Root]

On 2016-10-11 03:05 , René J.V. Bertin wrote:

Is there a good reason why action_provides (in port) does a `file normalize`?




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

Re: Issues with oudated ports / GitHub

[Joshua Root]

On 2016-10-9 06:10 , Marcel Bischoff wrote:

On 16/10/08, Ryan Schmidt wrote:



On Oct 8, 2016, at 8:30 AM, Marcel Bischoff 
wrote:

I see where you're coming from. However, your approach is contrary to
how the majority of issues are handled on services like GitHub. If the
ticket is too old, stale, not applicable any more or simply does not
receive any answer for weeks/months, it will usually be closed with a
note stating that. This helps keep the number of issues/tickets down to
a manageable level and avoids tickets being active for 11 years.


Well, we're not hosting issues on GitHub; we're hosting them on Trac.
And I don't want to close tickets that have not been dealt with.


It should be easy to just tag those issues as "abandoned" and close
them, so you can comfortably find them again at any point.


For something like a port submission that has never reached a working 
state, it might be reasonable to close the ticket with a resolution that 
indicates that work stalled and appears unlikely to resume. Or if 
there's a report of a bug that we can't reproduce, and we've asked the 
reporter for more info, and that info has not been provided, then that 
would be reasonable to close as well ("worksforme"). And certainly if a 
bug is no longer applicable, that's synonymous with "fixed".


But the idea that a valid, unfixed ticket can be "too old" makes no 
sense to me. Closing such a ticket without doing anything to resolve it 
doesn't mean you're actually more productive or responsive or whatever. 
(No doubt it makes certain stats look good.)


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

Re: order of operations in port upgrade

[Joshua Root]

On 2016-10-6 09:14 , Brandon Allbery wrote:

On Wed, Oct 5, 2016 at 5:41 PM, Rainer Müller > wrote:

On 2016-10-05 11:09, René J.V. Bertin wrote:
> Quick question: a normal (non-forced) upgrade currently does
>
> 1) install (create new tarball image)
> 2) deactivate old
> 3) activate new
> 4) clean ${workpath} (unless -k)

Cannot reproduce. The clean target will already be run after step 1) and
remove the work directory.


1 is the destroot phase of a "port upgrade", not a separate command


Doesn't matter. Running the install target with mportexec, as upgrade 
does in the non-forced case, will clean the work dir afterwards if 
autoclean is on.


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

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Joshua Root]

On 2016-9-30 12:18 , Ryan Schmidt wrote:



On Sep 29, 2016, at 8:30 PM, Mojca Miklavec  wrote:

Hi,

Under
https://svn.macports.org/repository/macports/users/mojca/ports/tex/miktex

I have a preliminary port for MikTeX with the following problem:
   https://sourceforge.net/p/miktex/bugs/2485/

The developer was fast in fixing many issues, but this one is
something that probably doesn't affect linux users, so he cannot
easily test.

The problem is that a binary that is needed as part of the build
procedure gets built and links against /opt/local/lib/something.dylib.
Usually that would be desired, but in this case the library
something.dylib cannot be found before the package is installed. The
build system should thus first give the libraries the id of the build
path and only fix that at the very end of the build procedure, but
it's not entirely clear to me how to properly achieve that.

Does anyone with a deeper understanding of CMake build system have any
idea what to fix?


The solution is to set DYLD_FALLBACK_LIBRARY_PATH to the path where the library 
can be found at build time. Set that environment variable at the time that you 
want to run the program that needs the library.

I don't know how to accomplish that in cmake specifically.


Actually, this is a valid situation for using DYLD_LIBRARY_PATH. If you 
use DYLD_FALLBACK_LIBRARY_PATH, and there is an older version of the 
library installed in ${prefix}/lib, the linker will find that first and 
run the executable with it instead of the new version in the build dir.


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

Re: [MacPorts] WorkingWithGit modified

[Joshua Root]

On 2016-9-24 06:02 , Ryan Schmidt wrote:


I think we should be able to add build status to commits. Building untrusted 
pull requests is however an entirely different matter. We would have to set up 
a new VM for each build. It's conceivable, but nothing of the kind is currently 
set up or in progress.


Autobuilding pull requests should be a lot safer for base than for 
ports, and that's all we have automated testing set up for at the moment 
anyway. I guess it would still be possible to add malicious code to the 
build system or test suite that performs a DoS or something.


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

Re: [152743] trunk/dports/_resources/port1.0/group

[Joshua Root]

On 2016-9-17 01:33 , Ryan Schmidt wrote:



On Sep 16, 2016, at 9:06 AM, Rainer Müller  wrote:

On 2016-09-16 01:09, ryandes...@macports.org wrote:

Revision: 152743
 https://trac.macports.org/changeset/152743
Author:   ryandes...@macports.org
Date: 2016-09-15 16:09:26 -0700 (Thu, 15 Sep 2016)
Log Message:
---
Portgroups: replace "Mac OS X" and "OS X" with "macOS"



Modified: trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
===
--- trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl  2016-09-15 
23:06:35 UTC (rev 152742)
+++ trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl  2016-09-15 
23:09:26 UTC (rev 152743)
@@ -38,7 +38,7 @@
#   minimum_xcodeversions   {darwin_major minimum_xcodeversion}
#
# where darwin_major is the major version of the underlying Darwin OS (e.g. 9
-# for Mac OS X 10.5 Leopard) and minimum_xcodeversion is the minimum version
+# for macOS Leopard) and minimum_xcodeversion is the minimum version
# of Xcode the port requires (e.g. 3.1).


I would keep this as Mac OS X 10.5 Leopard, the name does not change
retroactively.


I suppose that's an open question. Previously, I've tried to use the OS 
marketing name as it was when that OS version was released. Now, I'm thinking 
we should always use the current marketing name.


I agree with Rainer, "macOS Leopard" is just confusing. The current 
marketing name does not apply to previous releases.



Do we have any guidance from Apple on what they want people to do?


They still list previous OS releases back to Lion in the App Store as 
"OS X", if that helps you.


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

Re: Could not open Portfile

[Joshua Root]

On 2016-9-17 00:04 , Rainer Müller wrote:

On 2016-09-16 14:20, Craig Treleaven wrote:

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


What is your umask set to? From the permissions it looks like this is
with umask 0077.

I encountered the same problem before. svn patch does not preserve the
permissions of the existing files. Actually this behavior is not even
specific to svn patch, other commands such as svn revert behave the same
way. svn creates a new temporary file with umask applied, deletes the
existing file and moves the new file in place.

Personally, I use ACLs on my ports directory to automatically grant read
permissions to everyone on new files. This also resolves this problem
with svn patch for me.

chmod -R +a "group:everyone allow
read,execute,list,search,file_inherit,directory_inherit" ~/ports

It would be nice to have a better solution for this problem, but the
actual bug is in Subversion.


I reported this upstream a while ago with respect to svn commit and it 
was fixed. If you report these other affected commands and reference the 
fix for commit they should be able to fix them pretty easily too.




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

Re: RFC: mp-buildbot failcache

[Joshua Root]

On 2016-9-14 18:07 , Mojca Miklavec wrote:

On 14 September 2016 at 06:25, Ryan Schmidt wrote:

Now that we have the failcache (thanks!) what would be involved in getting a 
successcache?


- Before listing or installing any dependencies, ask MacPorts for the
name (full path) of the resulting binary tarball like

/opt/local/var/macports/software/name/name-vers_rev.darwin_xx.x86_64.tbz2

- If that tarball exists, skip the rest of the build procedure.


And as luck would have it, that exact code exists in MPAB ("package 
found, not building again").


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

Re: weird (buggy?) build dependency on a clang port

[Joshua Root]

First let me point you to this recent thread: 



On 2016-9-9 00:09 , René J.V. Bertin wrote:

I can still understand (=/= agree) that the compiler selection procedure is 
designed to take the lowest version of a compiler that is supposed to be able 
to build given code.


It isn't. It is designed to use the first compiler in the fallback list 
that is available and not blacklisted. It is implicit in this that 
compilers earlier in the list are more preferable than later ones.



But why does it not take the lowest *available* version, and why does it tell 
me to install (= activate) clang-3.7 rather than install clang-3.6 (from 
scratch)?


Because macports-clang-3.7 occurs first in the fallback list. Print out 
${compiler.fallback} if you don't believe me. :)


Installed compiler ports are not considered "more available" than 
uninstalled ones.


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

Re: Using other packages or distfiles servers

[Joshua Root]

On 2016-9-8 00:53 , Ryan Schmidt wrote:

Is there some entry I can make in a MacPorts config file that will tell it to 
only use a particular packages server and ignore the rest?


Yes, there's an example of overriding the standard archive sites given 
in the comments in archive_sites.conf.



Similarly, I want to configure MacPorts so that it only checks a single 
particular distfiles mirror, and if the file is not found there, then do not 
check any of the other distfiles mirror servers, but instead go straight to the 
port's configured master_sites.


I don't think there's any way to do that without patching base.


I realize I can explicitly list all of the packages and distfiles servers that 
I don't want to use in the host_blacklist line in macports.conf, and that's 
what we do in the buildbot 
(https://trac.macports.org/browser/contrib/mp-buildbot/mpbb-checkout), but it's 
an inconveniently long list and needs to be updated anytime we add new official 
mirrors.

I also want to be able to configure MacPorts to use a different distfiles and 
packages server than the ones that are listed in mirror_sites.tcl and 
archive_sites.tcl. I'd rather not have to maintain local edits to those files. 
I'm currently handling this with a local DNS server that advertises a different 
IP address for distfiles.macports.org and packages.macports.org but this isn't 
great.


It wouldn't be hard to add some code to the end of those .tcl files that 
overwrites the value of a variable that was defined earlier. That's not 
likely to have conflicts when updating.


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

Re: Binary archives are never fetched for files in my local port repository

[Joshua Root]

On 2016-9-6 23:58 , Brandon Allbery wrote:


On Tue, Sep 6, 2016 at 5:56 AM, Mojca Miklavec > wrote:

I recently figured out that ports that I have in my local repository
are *never* updated from the binary archives, but always compiled from
sources. MacPorts doesn't even try to fetch the binary archives, it
goes straight to fetching the sources.


Every repository has its own binary archives. After all, if you have it
in your local repository, this is a pretty obvious indication that you
are doing something different from the port in the main repo that has
the binary archive, and that the binary archive for the main port
therefore can't be considered compatible with your local port.


That's right. If you look at 
portarchivefetch::get_full_archive_sites_path in 
src/package1.0/portarchivefetch.tcl, it deliberately doesn't fall back 
to the default resources path.


If there is a _resources/port1.0/fetch/archive_sites.tcl in the repo, it 
will be used.


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

Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?

[Joshua Root]

On 2016-9-6 10:10 , Fred Wright wrote:


On Sat, 3 Sep 2016, Ryan Schmidt wrote:


But only do this if this software requires it. Otherwise, let MacPorts use its 
default value of -Os.


Seriously?  In this day and age?

AIUI, Apple used to use -Os for their own builds in the PPC era, since it
was needed to keep the bloat down to a dull roar in relation to disk
drives at the time.  But when they switched to Intel, they also switched
to -O2.  This allowed them to inflate the performance benefit of the
architecture switch. :-)


The gap between CPU speeds and memory speeds has grown much larger since 
the PPC era. The biggest factor in performance is usually whether your 
working set fits in the CPU caches, and if so, which level.


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

Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?

[Joshua Root]

On 2016-9-3 06:11 , Ken Cunningham wrote:



This is ludicrous. GCC 4.0 is a decade old.




Oh, way better news.

BasiliskII builds and runs, including the JIT, with clang-3.7 at least,
when it's held to i386 arch.

Apparently nobody has been able to do that before, assuming Dr. Google
is correct.

Built with arch x86_64 it runs (fairly quickly) without the JIT, but
enabling the JIT crashes it (no surprise).

That will make the portfile much much easier to finish.


Sounds like a jit variant which sets supported_archs may be in order 
then. That way users on x86_64 systems can decide whether they want to 
lose the JIT or rebuild all the dependencies with +universal.


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

Re: "Default" portgroup?

[Joshua Root]

On 2016-8-28 13:39 , Ken Cunningham wrote:

Does there exist a portgroup that might be considered "default", ie port code 
that would be included on all ports installed on a given machine?

If not, it could be useful to have machine or system-specific portfile 
additions that would apply to all ports on a given machine -- like adding the 
libsnowleopardfixes code to 10.6 systems, or adding -stdlib=libc++ to the CXX 
directives on all ports with libc++ added, or other things that I haven't 
considered yet..


Isn't that called "base"?

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

Re: Updating tk +quartz failed on Snow Leopard

[Joshua Root]

On 2016-8-26 11:21 , Ryan Schmidt wrote:


On Aug 25, 2016, at 11:38 AM, Ryan Schmidt wrote:


tk isn't the first program to need to deal with Retina displays. Can we find 
any other program that uses NSWindow's backingScaleFactor selector and see how 
it handles it?


I missed these warning from the original post:

warning: ‘NSWindow’ may not respond to ‘-backingScaleFactor’
warning: (Messages without a matching method signature
warning: will be assumed to return ‘id’ and accept
warning: ‘...’ as arguments.)

I *think* if we could use the 10.7 SDK, then it would know that 
-backingScaleFactor actually returns a float and wouldn't complain. But we 
can't use the 10.7 SDK because it's not in Xcode 3.2.6. Wikipedia says it's in 
Xcode 4.1 and later, but I don't see it in Xcode 4.1 or 4.2 for Snow Leopard. 
Maybe it's only in Xcode 4.1 and 4.2 for Lion. (They were different.)

I think that code just has to be excluded for 10.6 and earlier with 
preprocessor directives.


Or you could use a category to add a declaration of backingScaleFactor 
(appropriately #ifdef'd for < 10.7 only of course.)




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

Re: Goodbye Mac OS Forge, hello GitHub

[Joshua Root]

On 2016-8-20 11:04 , Kevin Walzer wrote:

On 8/19/16 8:18 PM, Ryan Schmidt wrote:

Since 2006, Apple has hosted MacPorts on its Mac OS Forge service. In the
decade since Mac OS Forge was created, collaborative software development
platforms like GitHub and BitBucket have become very popular and
successful,
and when I was hired as Mac OS Forge sysadmin last year, part of my
job was
to evaluate whether such services could be a suitable replacement for
those
offered by Mac OS Forge. We determined that the answer was yes, and that
GitHub was the best choice, due to its overwhelming popularity. Other
Mac OS
Forge projects including XQuartz, CUPS and CalendarServer are already
in the
process of moving to GitHub, and the time has now come for MacPorts to
likewise bid a fond farewell to Mac OS Forge and move on.


This is certainly an interesting development. I hope this works out well
for the MacPorts project. What will become of MacOS Forge if all its
projects migrate off it? Is Apple ceasing support for MacOS Forge?


I can't speak for Apple, but I imagine if all the projects move 
somewhere else, Mac OS Forge will simply cease to exist. Is it still a 
hosting service if it isn't hosting anything? :)


Pretty much every project on Mac OS Forge apart from us was run by Apple 
employees, and I'm sure Apple projects will continue to get the server 
resources they need. I can't imagine WebKit would just disappear, for 
example. Whether it will still be under the Mac OS Forge banner I don't 
know.



I understand that a lot of thought has gone into this decision, but it's
also not hard to view one of its primary motivators--"all the cool
projects are on Github, and it's crucial for developer mindshare"--as
something to view with concern. Competition in this space is healthy. A
decade ago SourceForge occupied the place in the community that Github
does now, and there was hardly any place else to go if their site was
down. One reason Tcl/Tk moved off SF to their own Fossil repo was
because of a serious outage at the site that prevented commits for weeks.

This is more of a hope that Github does not become the kind of
monoculture that SF was than any criticism of Github--as long as
Bitbucket and other platforms are around and still have some volume,
that will help.


I share these concerns and brought them up during the discussions. And 
TBH I think Mercurial is a better tool. But we did come to a consensus 
that GitHub is overall the best choice at this time.


And as Mark mentioned, one of the advantages of a DVCS is that the full 
repository history isn't locked away on a single server, so if GitHub 
goes down or turns evil, we can easily pack up and go elsewhere. (This 
of applies to source code but not to things like issues, which is 
another good reason to keep them on our own server.)


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

Re: small change in portconfigure.tcl appears to fix missing cxx_stdlib link

[Joshua Root]

On 2016-8-19 01:13 , Ken Cunningham wrote:

For your consideration

this small change in /base/src/port1.0/portconfigure.tcl

   # Add flags to specify C++ STL implementation
   if {${configure.cxx_stdlib} ne "" && [string match "*clang*" [option 
configure.cxx]]} {
   append_to_environment_value configure CXXFLAGS 
-stdlib=${configure.cxx_stdlib}
   append_to_environment_value configure OBJCXXFLAGS 
-stdlib=${configure.cxx_stdlib}
   #kenhack
   append_to_environment_value configure "LDFLAGS"  
-stdlib=${configure.cxx_stdlib}
   }

appears to fix the missing link reference to the standard c++ lib, and as far 
as I can see would apply to all ports.

It works well here, so far, to fix the missing libc++ link without modifying 
the portfile.

Will test further to see if it causes any unforeseen troubles on my other 
macports systems running different OS versions, but this would not appear 
likely to cause trouble to me...


The trouble is that LDFLAGS is not specific to C++, it's used when 
linking everything. At best, the link command will ignore -stdlib, at 
worst, it may fail when given an option it doesn't recognise. (This is 
much the same reason why it checks that configure.cxx is clang++ as well.)


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

Re: How to discontinue ports completely (py26 deprecation) ...

[Joshua Root]

On 2016-8-11 08:01 , Lawrence Velázquez wrote:

On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:


I don't consider Python 2.6 to be "cruft".  Developers need many
versions of Python installed for testing, and that includes any
packages that are also needed.  It's annoying to have to create local
versions of portfiles solely to add versions that are missing for no
substantive reason.


The substantive reason is that every additional version of CPython we
support is a maintenance burden, especially one that saw its last
feature release 6 years ago and its last bugfix release nearly 3 years
ago.


For the pythonXY ports themselves (and surely we should be starting with 
python24 if we're removing things?), I don't think it's much of a burden 
to slap a big warning on them about vulnerabilities and then never touch 
them again. For py26 module subports, it is of course up to the 
maintainer. I'm pretty sure most of the nomaintainer module ports have 
had 26 removed already.


That said, you're probably better off using pip in virtualenv for your 
multi python version testing.


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

Re: How to discontinue ports completely (py26 deprecation) ...

[Joshua Root]

On 2016-8-11 10:50 , Clemens Lang wrote:

On Wed, Aug 10, 2016 at 04:47:25PM -0500, Ryan Schmidt wrote:

On Aug 10, 2016, at 13:18, Peter Danecek  wrote:


However, how would we procede in this case, when we have no explicit
replacement to indicate?


I believe the obsolete 1.0 portgroup can accommodate this: include the
portgroup but don't set replaced_by.

However, do first consider whether this needs to be done, or whether
the port can instead be left as is.


What's the benefit of replacing a port we might no longer want to keep
with an explicit error message on upgrade? Instead, we could just
outright delete the port, which will leave it installed on the systems
of those users that had it installed (i.e. not break their system), but
also no longer allow fresh installations of it.


That is how it's been done historically. Failing with an error when the 
user is just trying to 'port upgrade outdated' is pretty poor UX.


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

Re: A separate PortIndex for libc++ on older systems

[Joshua Root]

On 2016-8-11 04:09 , Lawrence Velázquez wrote:

On Aug 10, 2016, at 4:37 AM, Ryan Schmidt  wrote:


We also still need to decide how to differentiate the URLs for libc++ packages 
from the URLs of the existing libstdc++ packages. One suggestion was to add 
cxx_stdlib as a variable in archive_sites.conf, and upload the libc++ archives 
with the same names as the libstdc++ archives but in a new subdirectory, e.g. 
https://packages.macports.org/libc++/.


One downside of using identical archive names is that we'd be unable to 
differentiate local libstdc++ archives from libc++ ones based on file name. 
This distinction could be used to rebuild packages after changing cxx_stdlib, 
for instance.


There are probably better places to keep metadata than a 255 character 
filename though.


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

Re: Get supported_archs from command line

[Joshua Root]

On 2016-8-3 17:48 , Ryan Schmidt wrote:

I'd like to know a port's supported_archs from a command line script.

"port info" doesn't appear to have a flag to display it.

This Tcl script shows how to get the list of subports from a portfile:

https://trac.macports.org/browser/contrib/mp-buildbot/tools/subports.tcl

However it does this by using mportinfo, and it doesn't look like mportinfo 
contains information on the supported archs.

Any ideas?


You can use _mportkey to get the value of any variable from the Portfile 
interpreter.


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

Re: pypi2port broken

[Joshua Root]

On 2016-7-22 19:08 , Mojca Miklavec wrote:

Hello,

It seems that pypi2port has some problems (most likely after the
changes done at pypi infrastructure):

xmlrpclib.ProtocolError: 

Is anyone willing to look at it?


Looks like it might be pretty easy to fix; try changing pypi2port.py 
line 42 to use https instead of http?


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

Re: Choice of compiler from compiler.whitelist

[Joshua Root]

On 2016-7-22 04:39 , Ryan Schmidt wrote:


On Jul 21, 2016, at 12:15 PM, Mojca Miklavec wrote:


The "problem" is that MacPorts seems to always take gcc 6 then, even
if I have gcc 5 already installed, but not the gcc 6.

What am I missing here? Couldn't MP take any compiler from the list?


As I understand it, if compiler.whitelist is set, MacPorts uses the first entry 
in compiler.whitelist that's not blacklisted.


Not quite -- it uses the first such compiler that is available on the 
system. Compilers provided by a port are always considered to be 
available, so this only makes a difference when Xcode-provided compilers 
are involved.



And if compiler.whitelist is not set, MacPorts uses the first entry in 
compiler.fallback that's not blacklisted. (As such, I'm not sure why 
compiler.whitelist exists; couldn't a port just as easily set compiler.fallback 
instead?)


Technically it's probably redundant, yes. But it seemed more clear to 
have a different option name to indicate that these compilers and only 
these compilers will work.



In any case, no attempt is currently made by MacPorts to check which of those 
compilers you might already have installed.


It would be possible to change that, but it would mean going from a 
simple algorithm of grabbing the first usable one from a list, to a much 
more complicated method of sorting the different possibilities according 
to multiple criteria and using the "best" one.


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

Re: Rev bumping mpi dependents

[Joshua Root]

On 2016-7-21 09:24 , Brandon Allbery wrote:

On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley > wrote:

OpenMPI just released 2.0 which will change the name of the libraries.
I'm guessing I should revbump all the dependents to force a rebuild but
is this something that `port rev-upgrade` should handle?


I think you can get into trouble with the automatic rev-upgrade catching
it, if it causes an upgrade for other reasons to fail? At the very least
it could be inefficient by causing multiple rounds of rebuilding
triggered during the rev-upgrade at the end of a normal upgrade.


The biggest reason to rev bump is that if you don't, the archives are 
useless. They get downloaded and installed, then rev-upgrade immediately 
detects that the linking is broken and rebuilds from source.


If the original question was about whether the rev bumping should be 
automated, well, maybe. We could certainly run rev-upgrade in report 
mode on all a port's dependents after it is updated. Do we then want the 
system automatically committing a rev bump? I'm not so sure. It might be 
better to just email a warning to the maintainers.


A concept of an archive revision as distinct from a port revision might 
be useful here.


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

Re: Reason why default rsync URL was changed to a tarball

[Joshua Root]

On 2016-7-20 01:09 , Ryan Schmidt wrote:

sources.conf used to default to:

rsync://rsync.macports.org/release/ports/ [default]

Since r79599 it defaults to:

rsync://rsync.macports.org/release/tarballs/ports.tar [default]

though not all of our documentation was updated to match.

The commit message says "make sync and selfupdate via signed tarballs the 
default"

Was signing support the only reason for this change? On one of my systems with an evidently slow 
disk, "sudo port sync" takes several minutes to complete, spent mostly on decompressing 
the tarball, even, I think, if the tarball is unchanged, whereas using the old rsync URL, 
"sudo port sync" is very quick since it only has to write the changes to disk and not the 
entire ports collection each time.


Yes, the easiest way to get signing working was to make a single file 
and sign it. It would be possible to do something like generate a 
manifest filled with checksums for each file in the tree instead, and 
sign that. There are tradeoffs to be considered with that approach, like 
do you verify all the checksums at sync time or defer until each file is 
used?


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

Re: Software that doesn't use DESTROOT and funny tarball directories

[Joshua Root]

On 2016-7-18 02:15 , Brandon Allbery wrote:


On Sun, Jul 17, 2016 at 2:16 AM, Joshua Root <j...@macports.org
<mailto:j...@macports.org>> wrote:

The second question is about names: I named the port chez-scheme.
Unfortunately the tarball they have expands into one with a
directory
named ChezScheme-9.4 and not chez-scheme-9.4  The obvious thing
to do
is to change the name of the port to ChezScheme, but I do not recall
many ports with uppercase names. Is this the right thing to do?


Port names are case-insensitive, so capitalise however is
preferable. Furthermore, the name of the port doesn't have to bear
any relation to the distfile name; you can set distname to whatever
is needed. See <https://guide.macports.org/#reference.phases.fetch

>.


In this case I think it's more the worksrcdir that you'd be changing?


Yes, if the name of the extracted directory doesn't match the name of 
the tarball.


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

Re: Software that doesn't use DESTROOT and funny tarball directories

[Joshua Root]

On 2016-7-17 16:16 , Joshua Root wrote:

On 2016-7-17 15:31 , Watson Ladd wrote:

Dear all,
I'm trying to write a portfile for ChezScheme. The problem is that
they want you to run configure with an argument indicating the install
prefix, then don't seem to support DESTROOT. I've gone to upstream to
report this, but I understand there is black magic we could use
instead.


Sometimes telling such a build system that the install prefix is
${destroot}${prefix} will work OK. (But not always.)


I looked at their configure script on github and it looks like they 
support a destroot but call it temproot. So it seems you should pass 
--temproot=${destroot} to configure.


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

Re: Removing --prefix from args to configure

[Joshua Root]

On 2016-7-17 16:02 , Watson Ladd wrote:

Dear all,
ChezScheme takes installprefix, not prefix as an arg, and having
prefix confuses it. I don't understand how to remove this unwanted
argument as I never put it in in the first place. I think once I have
this the portfile will be done.
Sincerely,
Watson


Change configure.pre_args to what you need. Like many options, it has a 
default value that works in a lot of cases. 
.


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

Re: Can't find local, correctly indexed Portfile

[Joshua Root]

On 2016-7-6 01:22 , Bill Barnhart wrote:

 I am trying to build a program from a local Portfile. After setting up the
 proper directory structure, placing the Portfile in it, and running
portindex,
 the port is correctly and successfully parsed. When I run port install on
 the program, though, I get an error stating that the previously indexed
port cannot be
 found. I am running El Capitan v10.11.5, and macports works fine on non-
 local port repositories. This particular local portfile also works fine on
 previous OS versions (i.e. Yosemite 10.10.5), so this should not be an
issue with the Portfile itself.
 I'm not sure where this error is originating from or why the portfile
can't be found after being correctly indexed and parsed. Any suggestions
would be helpful.


Sorry if this is asking the obvious, but have you checked that your 
sources.conf has the correct path to your local repo?


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

Re: [MacPorts] #51598: bsdmake: setrlimit: Invalid argument

[Joshua Root]

On 2016-6-21 07:58 , Bryan Nunweek wrote:

Thanks, but `sudo port -v install xinit` still fails with same error when using 
`/opt/local/bin/bsdmake`

The bsdmake port was already installed but was not being used. Path seems OK:


BingleyG5:~ bryan$ echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin



Had to rename `/usr/bin/bsdmake` to get `/opt/local/bin/bsdmake` to be used, 
then:


BingleyG5:~ bryan$ sudo port -v install xinit
--->  Computing dependencies for xinit..
--->  Dependencies to be installed: tradcpp xrdb xset xorg-libXfontcache 
xorg-fontcacheproto xorg-libXp xorg-printproto xorg-libXxf86misc xorg-xf86miscproto
--->  Building tradcpp
bsdmake: setrlimit: Invalid argument


 may be relevant here?

Maybe we should avoid using the system bsdmake if it's known to be 
broken in this way? Though it seems to be only triggered by a custom 
configuration.


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

Re: PortGroup python 1.0 guidance

[Joshua Root]

On 2016-6-18 05:44 , Edward Maros wrote:

I am working on a project that provides an interfaces to several
scripting languages. One of these is Python. I have been working on
using PortGroup python 1.0 to provide all the correct values for the
python variant requested. The most notable is python.pkgd.

The unfortunate side effect of using the python PortGroup for my
project, is that I need to redefine all of my build, make, and install
rules since my project isn't a pure python extension.

Is there a way or could the python PortGroup be modified such that via a
flag it could only generate the extended variables?


I think we should avoid scope creep in PortGroups if possible. It would 
be better to make a different PortGroup for ports that don't build with 
setup.py but want some of the paths and such. It could even share code 
with the python PortGroup by sourcing a common file.


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

Re: PortGroup directory hierarchy/priority

[Joshua Root]

On 2016-6-1 03:34 , Mojca Miklavec wrote:

On 27 March 2016 at 17:33, Rainer Müller wrote:

On 2016-03-27 16:57, René J.V. Bertin wrote:

Can someone please summarise the exact priority rules used in
resolving the file to be included when using a PortGroup statement in
a port?


1. _resources/port1.0/group/*.tcl in ports tree of this port
2. _resources/port1.0/group/*.tcl in default ports tree

This is here in the base source:

proc PortGroup:
https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=147064#L2561

porc getportresourcepath/getdefaultportresourcepath:
https://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?rev=147103#L1637

The _resource directory is meant to contain files that are specific to
this ports tree. This allows local modifications to port groups in a
ports tree without influencing other ports trees.


Can you please explain if the following behaviour is intended by
design or if it is a bug?

"port something portname" works like you describe
"port something ./[path/to/]portname" uses the default portgroup


A concrete example. I modified livecheck in the perl5 PortGroup in the
local svn checkout. Then I tested the following:

$ cd /path/to/local/checkout
$ portindex
$ port -d livecheck perl/p5-b-c # uses *global* resources
$ port -d livecheck perl/p5-* # uses *global* resources
$ cd perl
$ port -d livecheck p5-b-c # uses local resources
$ port -d livecheck p5-* # uses local resources
$ port -d livecheck ./p5-b-c # uses *global* resources
$ cd p5-b-c
$ port -d livecheck ./ # uses local resources
$ port -d livecheck # uses local resources

These examples seem somewhat strange to me.


It's more like a limitation of the information that is available when 
you parse an arbitrary Portfile, whether implicitly using the current 
directory or specifying a path. You don't even know the port's name 
until you parse it once. If you're not going via the PortIndex, you 
don't know what repo (if any) it belongs to and thus whether it has any 
local resources. So the default ones get used.


I guess with enough effort you could figure out when some arbitrary path 
is inside a sources.conf repo, but is it worth it when you can easily 
fix the problem by looking up via the index?


Cf. also  which is sort of the 
opposite problem.


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

Re: Help with py-tz download location

[Joshua Root]

On 2016-5-30 21:36 , Mojca Miklavec wrote:

On 29 May 2016 at 21:42, Joshua Root wrote:

On 2016-5-30 04:44 , Adam Mercer wrote:


Hi

py-tz has been updated, to version 2016.4) and it seems that the
download location for the source has changed, it now seems to include
some kind of hash in the URL and I can't workout how to specify this
in the Portfile besides using:

master_sites
https://pypi.python.org/packages/f4/7d/7c0c85e9c64a75dde11bc9d3e1adc4e09a42ce7cdb873baffa1598118709

Does anyone know of a neater way to do this?


Use pypi in master_sites like so:

master_sitespypi:p/pytz/


Would it be an overkill to document some options like pypi,
sourceforce etc. in "man portfile"?


A pointer to where they are defined might be helpful at least.

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

Re: Help with py-tz download location

[Joshua Root]

On 2016-5-30 04:44 , Adam Mercer wrote:

Hi

py-tz has been updated, to version 2016.4) and it seems that the
download location for the source has changed, it now seems to include
some kind of hash in the URL and I can't workout how to specify this
in the Portfile besides using:

master_sites 
https://pypi.python.org/packages/f4/7d/7c0c85e9c64a75dde11bc9d3e1adc4e09a42ce7cdb873baffa1598118709

Does anyone know of a neater way to do this?


Use pypi in master_sites like so:

master_sitespypi:p/pytz/

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

Re: Howto inspect Portfile variables to debug install

[Joshua Root]

On 2016-5-30 04:19 , Chris Gorman wrote:

Hello,

I was wondering how to inspect variables in a port file.  Specifically, I want 
to apply a patch conditionally if perl is version 5.10.0.

I'm trying something like

if { ${configure.perl} eq "/usr/bin/perl" && [vercmp ${perl5.version} 5.10.0] < 
0 } {
patchfiles-append patch-man_Makefile.in.diff
}

in the Portfile. This doesn't work and I would like to inspect configure.perl 
and perl5.version to see what they are.  Is there any way to do this?  I'm 
looking for a solution like using printf in c, or echo in a shell script.


The Tcl command you're looking for is 'puts', e.g.

puts "configure.perl = ${configure.perl}"

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

Re: support for older HardWare and Mac OS X

[Joshua Root]

On 2016-5-23 17:17 , Bjarne D Mathiesen wrote:

I've got 2 older Mac Mini systems I'm using as headless servers:

#=> system_profiler SPHardwareDataType SPSoftwareDataType
Hardware:
  Hardware Overview:
Model Name  : Mac mini  Mac mini
Model Identifier: Macmini2,1Macmini1,1
Processor Name  : Intel Core 2 Duo  Intel Core Duo
Processor Speed : 1,83 GHz  1,83 GHz
Number Of Processors: 1 1
Total Number Of Cores   : 2 2
L2 Cache: 2 MB  2 MB
Memory  : 2 GB  2 GB
Bus Speed   : 667 MHz   667 MHz
Boot ROM Version: MM21.009A.B00 MM11.0055.B08
SMC Version (system): 1.19f21.3f4

Software:
  System Software Overview:
System Version  : Mac OS X 10.6.8 (10K549)  Mac OS X 10.6.8 (10K549)
Kernel Version  : Darwin 10.8.0 Darwin 10.8.0
Boot Mode   : NormalNormal
Secure Virtual Memory   : Not Enabled   Not Enabled
64-bit Kernel and Extensions: NoNo

How much interest is there in still holding such old stuff supported in
MacPorts ??? Presently, I've got some issues with some core packages
I'ld like to get resolved :-)


Snow Leopard is officially a legacy platform, meaning base still runs on 
it but you should not have an expectation that issues in ports will 
necessarily be fixed.


It's entirely up to the individual maintainer, but my experience is that 
a fair number will still work on issues affecting 10.6 (in fact more 
than 10.7). 32-bit processors, less so.


It always helps a lot if you can debug the issue yourself and supply a 
patch -- it's very rare that such a fix will be rejected as long as it 
looks sane and doesn't affect the supported platforms. :-)


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

Re: Change in paths to packages on PyPI

[Joshua Root]

Apparently the URL to use is now:

https://files.pythonhosted.org/packages/source/p/prompt_toolkit/

and that scheme should work for the foreseeable future. (The pypi.io 
version will just redirect to the above.)


- Josh

On 2016-5-14 13:33 , Ivan Larionov wrote:

I just run into this issue.

Can confirm that change like this works:

-master_siteshttps://pypi.python.org/packages/source/p/prompt_toolkit/
+master_siteshttps://pypi.io/packages/source/p/prompt_toolkit/

Has anyone updated pypi master_sites?

--
With best regards, Ivan Larionov.


On Apr 26, 2016, at 10:28 AM, Rainer Müller  wrote:

On 2016-04-23 13:04, Davide Liessi wrote:

There has been a recent update in the way PyPI handles paths to
packages [1] that will require to manually update master_sites for
every update (fortunately old paths seem to be still valid).

There's already an issue at PyPA's tracker [2], but I don't know if
they'll be willing to revert the change.
(Maybe voting the issue on the tracker would help...)


According to the upstream issue tracker, they now provide a translator
from the old URL scheme to the new at their pre-release version at
https://pypi.io/.

I did not do much testing, so I would be glad if someone could give the
attached patch some more testing, especially if this breaks fetching any
of the old ports.

Also a quick grep returned quite a lot of ports not using the pypi:
mirror sites, but instead hardcode pypi.python.org. Although it still
works, they should probably all be changed to allow control of the
mirrors at a single place.

Rainer
___



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

Re: tk +quartz -x11 dependency on libX11. Why?

[Joshua Root]

On 2016-5-14 00:10 , Vincent Habchi wrote:

Hi there,

why does tk +quartz -x11 depend on libX11? I commented out that line in the 
Portfile and it compiled fine.
Leaving that (dangling) dependency alive means installing a lot of cruft.


As the comment in the quartz variant in the portfile says:
# tk.h still includes and uses types from X11/Xlib.h

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

Re: os.major etc. on Linux

[Joshua Root]

On 2016-5-13 18:13 , Ryan Schmidt wrote:


On May 13, 2016, at 3:07 AM, René J.V. Bertin wrote:


On Friday May 13 2016 15:21:53 Joshua Root wrote:


Side-ways related: why is os_arch reset to i386 from x86_64 on line 636? >From 
what I've seen that causes packages to be labelled and registered as i386 (i.e. 
32bit) when built on 64bit linux.


In MacPorts, os_arch is i386 on all Intel Macs (32-bit and 64-bit), and ppc on 
all PowerPC Macs (32-bit and 64-bit). Changing that now would break all ports 
that rely on the existing long-standing behavior.


I was just asking why, apparently that's a historic choice that was made when 
64-bit Intel Macs weren't on the horizon yet?


os_arch is the way ports and probably MacPorts base differentiates an Intel 
computer from a PowerPC computer. It is not a mechanism to determine the 
bitness; if you need to determine bitness, use other methods, such as 
build_arch and universal_archs. build_arch and universal_arch determines how a 
package is registered when installed; os_arch doesn't enter into it, as far as 
I know.


If build_arch is not set then os.arch is used as a fallback. No doubt we 
don't detect an appropriate default for build_arch on Linux.


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

Re: os.major etc. on Linux

[Joshua Root]

On 2016-5-13 14:39 , Ryan Schmidt wrote:


On May 12, 2016, at 5:37 AM, René J.V. Bertin wrote:


On Thursday May 12 2016 11:57:21 Rainer Müller wrote:


I would consider this a bug.


Me too, if we're sure it isn't a feature ;)


We take this directly from
$tcl_platform(osVersion), which is equivalent to `uname -r`.

As this assumption is wrong for Linux, this is the place where it needs
to be fixed:

https://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?rev=147347#L633


Looks familiar indeed. That's where I hard-code os_major to 3.
Do you have any suggestion on how to fix this, so I can propose a patch?

Side-ways related: why is os_arch reset to i386 from x86_64 on line 636? >From 
what I've seen that causes packages to be labelled and registered as i386 (i.e. 
32bit) when built on 64bit linux.


In MacPorts, os_arch is i386 on all Intel Macs (32-bit and 64-bit), and ppc on 
all PowerPC Macs (32-bit and 64-bit). Changing that now would break all ports 
that rely on the existing long-standing behavior.


This corresponds to `uname -p` BTW.

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

Re: buildbots with old ssl (snowleopard, mtln)

[Joshua Root]

Yeah. Unfortunately there are rather a lot of not-that-old systems and 
devices out there that can't use 1.1. But, also unfortunately, version 
1.0 is pretty broken.


Probably the best fix on our end would be to reinstate the immediate 
mirroring that used to happen from a post-commit hook. And possibly make 
the build block until the mirroring is done. In fact, maybe the 
mirroring could be triggered from one of the first steps in the build.


- Josh

On 2016-5-4 06:03 , Daniel J. Luke wrote:

This is probably caused by the site now requiring TLS 1.1 or better:

https://www.ssllabs.com/ssltest/analyze.html?d=openssl.org=194.97.150.234

Since PCI compliance is requiring the phasing out of TLS 1.0 support, this is probably 
going to become much more common in the near future (PCI requirements tend to drive a lot 
of "standard" configurations even for systems that don't process credit cards).


On May 3, 2016, at 3:32 PM, Daniel J. Luke  wrote:
It looks like the snowleopard and mtln buildbots can't download current openssl:

DEBUG: Fetching distfile failed: Unknown SSL protocol error in connection to 
www.openssl.org:443

Is it time to retire the buildbots for these old OS versions? Should we set 
them up to use the squid proxy I host for any https url (or just for anything 
if that's easier)? Some other solution?

[Noticed from clamav build failures
http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/41753
http://build.macports.org/builders/buildports-mtln-x86_64/builds/29275]




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

Re: [148264] trunk/dports/net/snort/Portfile

[Joshua Root]

On 2016-5-3 15:48 , Ryan Schmidt wrote:



On May 1, 2016, at 6:55 PM, m...@macports.org wrote:

Revision
148264
Author
m...@macports.org
Date
2016-05-01 16:55:29 -0700 (Sun, 01 May 2016)
Log Message

snort 2.9.8.2: add openssl dependency (missing headers) for El Cap
Modified Paths

• trunk/dports/net/snort/Portfile



+platform darwin 15 {
+#El Capitan lacks openssl headers
+depends_lib-append  port:openssl
+}


If this port uses openssl, it should have a dependency on port:openssl on all 
operating systems, not just darwin 15.


And if it just needs headers as implied by the comment, it should 
presumably be depends_build rather than depends_lib.


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

Re: registry backup (and upgrade --force)

[Joshua Root]

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

Josh's answer sounds like it's not that much effort. I don't know,
however, I'm not very familiar with that part of MacPorts base.


I was more going for "Something could be done, but the situation is 
perhaps more complex than you think, so do your homework before you go 
changing anything." :)


But yeah, the actual implementation probably wouldn't be that hard, once 
one figures out what should in fact be done.


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

Re: registry backup (and upgrade --force)

[Joshua Root]

On 2016-4-3 22:41 , Clemens Lang wrote:

I agree, upgrade --force should imply only rebuilding the given ports.


Not if they have outdated dependencies. Upgrade without -n is a 
recursive operation. Not passing the --force flag on to the deps by 
default would be ok I guess, but what if the user wants that?


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

Re: html and postscript viewer

[Joshua Root]

BTW, the author of that guide also seems to be under the mistaken 
impression that Xcode includes GCC 5.1...


- Josh

On 2016-4-2 20:45 , Joshua Root wrote:

Sounds like they could use some help with their code. If you want to
make your own version of a function like abs that behaves differently to
the stdlib one, defining a macro with the same name is not the way to go
about it. It's likely to misbehave regardless of which compiler you use,
just because of the way C preprocessing works.

Have you tried just compiling with clang and seeing what happens?

- Josh

On 2016-4-2 18:04 , Mark Brethen wrote:

 From their installation guide:

For the compilation of cgx, therefore, the unmodified GCC 4.9 is
required because the modified (by Apple) GCC for several reasons is not
suitable for the compilation of cgx … The modified GCC includes the
individual compilers: gcc (GNU c compiler), g++ and clang. Because the
modified GCC has a problem with function overloading it is not suitable
for the 2compilation of cgx.

2In particular, the compilation of function: #define abs(x) ((x) >= 0 ?
(x) : -(x)) in the cgx-routine: “extUtil.h“ causes a compiler error. A
bug fix for the compiler was not available at the time the installation
of cgx was tested.


I have looked at that link but it doesn’t explain how, for example, to
set a default compiler. The compilers group gives more instruction, but
it’s not completely clear to me. I guess something like

compilers.choosecc cxx cpp
configure.cc <http://configure.cc> macports-gcc-4.9



On Apr 1, 2016, at 11:59 PM, Ryan Schmidt <ryandes...@macports.org
<mailto:ryandes...@macports.org>> wrote:


On Apr 1, 2016, at 23:03, Mark Brethen <mark.bret...@gmail.com
<mailto:mark.bret...@gmail.com>> wrote:

I’ve run into a snag building calculix. glut and libSNL are libraries
that calculix uses. I set

"compiler.whitelist  macports-gcc-4.9”

per the developers instructions.


Why? We usually do not want to use FSF GCC.


However there isn’t a configure so I’m not sure what else needs to be
passed.

subport ${name}-cgx {
  revision0
  master_sites http://www.dhondt.de/
  distnamecgx_${version}.all

  checksums   rmd160
 02302101f16c2b4cdd570e81986cc4d36c2110d8 \
  sha256
64810dab1c22152c7946282fac5763cc36b9e31e309f962c23b8bf8238537c7e

  depends_run-append  port:openbrowser

  worksrcdir  CalculiX
  build.dir   ${worksrcpath}/cgx_${version}/src
  build.target

  compiler.whitelist  macports-gcc-4.9

  patchfiles  patch-cgx-build.diff \
  patch-libSNL-build.diff
  patch.dir   ${workpath}

  post-patch {
  reinplace "s|@@PREFIX@@|${prefix}|g" \
  ${worksrcpath}/cgx_${version}/src/cgx.h
  }

  use_configure   no

livecheck.regex {ccx_${version}.all}
}


When you set "use_configure no", you must add code to use the right
compiler and -arch flags and offer a universal variant. See:

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






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

Re: html and postscript viewer

[Joshua Root]

Sounds like they could use some help with their code. If you want to 
make your own version of a function like abs that behaves differently to 
the stdlib one, defining a macro with the same name is not the way to go 
about it. It's likely to misbehave regardless of which compiler you use, 
just because of the way C preprocessing works.


Have you tried just compiling with clang and seeing what happens?

- Josh

On 2016-4-2 18:04 , Mark Brethen wrote:

 From their installation guide:

For the compilation of cgx, therefore, the unmodified GCC 4.9 is
required because the modified (by Apple) GCC for several reasons is not
suitable for the compilation of cgx … The modified GCC includes the
individual compilers: gcc (GNU c compiler), g++ and clang. Because the
modified GCC has a problem with function overloading it is not suitable
for the 2compilation of cgx.

2In particular, the compilation of function: #define abs(x) ((x) >= 0 ?
(x) : -(x)) in the cgx-routine: “extUtil.h“ causes a compiler error. A
bug fix for the compiler was not available at the time the installation
of cgx was tested.


I have looked at that link but it doesn’t explain how, for example, to
set a default compiler. The compilers group gives more instruction, but
it’s not completely clear to me. I guess something like

compilers.choosecc cxx cpp
configure.cc  macports-gcc-4.9



On Apr 1, 2016, at 11:59 PM, Ryan Schmidt > wrote:


On Apr 1, 2016, at 23:03, Mark Brethen > wrote:

I’ve run into a snag building calculix. glut and libSNL are libraries
that calculix uses. I set

"compiler.whitelist  macports-gcc-4.9”

per the developers instructions.


Why? We usually do not want to use FSF GCC.


However there isn’t a configure so I’m not sure what else needs to be
passed.

subport ${name}-cgx {
  revision0
  master_sites http://www.dhondt.de/
  distnamecgx_${version}.all

  checksums   rmd160
 02302101f16c2b4cdd570e81986cc4d36c2110d8 \
  sha256
64810dab1c22152c7946282fac5763cc36b9e31e309f962c23b8bf8238537c7e

  depends_run-append  port:openbrowser

  worksrcdir  CalculiX
  build.dir   ${worksrcpath}/cgx_${version}/src
  build.target

  compiler.whitelist  macports-gcc-4.9

  patchfiles  patch-cgx-build.diff \
  patch-libSNL-build.diff
  patch.dir   ${workpath}

  post-patch {
  reinplace "s|@@PREFIX@@|${prefix}|g" \
  ${worksrcpath}/cgx_${version}/src/cgx.h
  }

  use_configure   no

livecheck.regex {ccx_${version}.all}
}


When you set "use_configure no", you must add code to use the right
compiler and -arch flags and offer a universal variant. See:

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




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

Re: Conflicting ports

[Joshua Root]

On 2016-3-30 15:40 , Mark Brethen wrote:

I’m working on a Calculix cgx port that uses a modified netgen for tet meshing. 
A modified file “ng_vol.cpp” (provided) is used to build Netgen. Since this 
would conflict with the Netgen port, how should this be implement as a helper 
app to cgx?


Can you install it in a different place than vanilla netgen?

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

Re: Support for users with older versions of Xcode that what's on the build slaves

[Joshua Root]

On 2016-3-19 19:28 , Mojca Miklavec wrote:

Hi,

Recently a user issued a ticket with a problem that was most likely
triggered by using an older version of Xcode than the one used for
creating the binary package for Perl:
 https://trac.macports.org/ticket/50894

Perl does a number of configure-time checks and then hardcodes both
the compiler and the flags to be used when installing C[++] code from
CPAN.

(ROOT does something similar which I find a bit annoying at times.)

(a) One solution would be to unconditionally remove that flag for
everyone (I don't know yet what the flag does, but I would assume it
was added for some valid reason, so it would probably be desirable to
keep it for systems that support it).
(b) One solution would be to conditionally force removal of that flag
(with some weird code; I don't know what condition would be best
used).
(c) One solution would be to close the ticket as 'wontfix' and ask the
user to either:
 - upgrade Xcode
 - manually remove the flag
 - install Perl from source or simply set "buildfromsource always"
to avoid similar problems in the future

The reverse problem can actually also happen after upgrading Xcode (if
a flag would be removed from compiler and the user compiled perl
before the upgrade, installing cpan modules could then fail because
the new compiler would no longer accept the flag that was OK for the
older one).

I would be in favour of (c), but other opinions are welcome.


"Update your Xcode" is certainly the easiest resolution, and we have 
always recommended that users do that.


We've had several discussions in the past about compiler settings for 
use at runtime being baked in at build time, and why that's a bad idea. 
See e.g.  and the linked ML 
thread, and this thread from later in the same year: 



So it's also an upstream bug. You could patch perl to remove use of 
-fstack-protector-strong or replace it with -fstack-protector; that 
won't prevent anything from running since it's a hardening measure. 
Whether it "breaks" anything is a harder question. (Used on a bug-free 
program, it would do nothing but make it slightly slower.) Whether perl 
should even be choosing its own CFLAGS like this is left as an exercise 
for the reader. ;)


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

[146817] trunk/dports/devel/git/Portfile

[Joshua Root]

Revision: 146817
  https://trac.macports.org/changeset/146817
Author:   ciserlohn at macports.org
Date: 2016-03-18 06:57:43 -0700 (Fri, 18 Mar 2016)
Log Message:
---
git: blacklist gcc-4.2 (should fix #50869)

Modified Paths:
--
trunk/dports/devel/git/Portfile

Modified: trunk/dports/devel/git/Portfile
===
--- trunk/dports/devel/git/Portfile 2016-03-18 13:48:10 UTC (rev 146816)
+++ trunk/dports/devel/git/Portfile 2016-03-18 13:57:43 UTC (rev 146817)
@@ -3,6 +3,7 @@

 PortSystem  1.0
 PortGroup   perl5 1.0
+PortGroup   compiler_blacklist_versions 1.0

 namegit
 version 2.7.4
@@ -56,6 +57,8 @@

 variant universal   {}

+compiler.blacklist *gcc-4.2


Couple things:

This doesn't just blacklist gcc-4.2, but all compilers whose names end 
in "gcc-4.2", including llvm-gcc-4.2. Is that what you meant to do?


Also, you're including compiler_blacklist_versions but not using any of 
its functionality.


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

Re: [MacPorts] #50311: gmt5: build fails on Mavericks: error: conflicting types for 'dsyev_'

[Joshua Root]

On 2016-3-19 15:18 , Takeshi Enomoto wrote:

Hi,

I’m trying to fix the problem reported for gmt5.

gmt5 fails due to the incompatibility of pointer type
on a call to dsyev_ of CLPACK in Accelerate.

The reporter runs Mavericks on an i386 machine
(I didn’t know that i386 is supported).


I don't think it could be an i386 machine, since the kernel has been 
x86_64 only since 10.8. If you see "arch i386" in the platform 
identification line in the log, that just corresponds to the output from 
'uname -p'.


However the reporter is building with +universal, which you can see 
later in the log means x86_64 and i386.



According to the error message in main.log, int * is passed to long *.

incompatible pointer types passing 'int *' to parameter of type '__CLPK_integer 
*' (aka 'long *’)

It should be int * because it is 4-byte integer of Fortran.

I suspect the compiler doesn’t compile the source with __LP64__ symbol on i386.
Perhaps is this a problem of Xcode clang?
Would put this clang version to blacklist help?


All compilers will define __LP64__ if and only if compiling for a 64-bit 
target. This is correct.


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

Re: Checking for problems before committing

[Joshua Root]

On 2016-3-11 08:41 , David Evans wrote:

On 3/10/16 12:29 PM, Ryan Schmidt wrote:


On Mar 10, 2016, at 12:48 AM, Mojca Miklavec wrote:


On 10 March 2016 at 05:48, Ryan Schmidt wrote:


Obviously nobody is going to commit something they believe is broken, but it 
does sometimes end up being the case for some subset of users. When it does, 
and we learn that it has happened, we try to fix it. If everybody had to test 
everything on a clean system on every version of OS X and every version of 
Xcode before committing, nobody would ever commit anything because nobody has 
the time and resources to do all that testing. We do have automated build 
machines that do build every commit on a clean system with no ports installed 
with several versions of OS X and the latest version of Xcode for those 
systems. That automated system did catch this webkit2-gtk build problem on El 
Capitan,



When I was testing wxWidgets, discovered a problem and submitted a
patch, I noticed what they are doing now (which is some light years
more advanced compared to what they did a few years back when most of
the tickets were stuck ignored at their Trac; similar to what happens
in many cases in MacPorts).

- user submits a patch
- the system checks whether the patch applies cleanly
- the system automatically builds wxWidgets on Windows in 6 different
ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
VS 9, msbuild), on Linux in five different ways (one is with clang
3.5), and on OS X 10.9
- I'm not sure whether wxWidgets does it as well, but it is also
possible to run tests as part of the build

The developers then only apply the patch if all of the checks mentioned pass.

The point is that this is all done *in advance* and avoids a lot of
problems. I would love to see something similar being done for patches
submitted to our Trac. Of course they would have to be submitted in a
different way and I'm aware that this is not really trivial to set up.
But it would be extremely helpful.


Yes, this would be helpful. I intend to look into doing something like this. 
However right now and for the next several weeks there are a lot of other more 
pressing issues I need to be working on for Mac OS Forge.


One approach I have thought about is this:

Establish a "testing" instance of the port repository and have maintainers 
commit to it.  The buildbots would then build
from changes to this repo and, upon a successful build, move (copy, merge, whatever) the 
port to the "live" repository.
The rsync server would publish from the "live" repository.


I've thought about this too. One issue I can see is that a successful 
port update can still break dependents (see openssl). So unless you 
rebuild all dependents on every commit, you still don't have any sort of 
guarantee that the ports in the live repo work at any given time.



This is not a detailed proposal but you get the idea and I think could be 
implemented without too much work. The plus is
that it would be relatively automated without too many false positives.  Exception cases 
are ports that "fail" building
but are considered "good."

   * ports that "fail" because they require non-default dependencies (+quartz 
is one class, gtk-osx-application for instance)
   * ports that "fail" because they are meant to (obsolete ports, graveyards)
   * you can probably think of more

Not a really original idea but at least it would be some filter between 
maintainer commits and what the user gets


Another approach would be to add a 'try' scheduler to our buildbot config.



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

Re: Inconsistent criteria of success on the buildbot

[Joshua Root]

On 2016-2-25 18:18 , Mojca Miklavec wrote:

Hi,

A while ago I committed a new subport for geant4.10.2 which is
currently broken (in the meantime I lacked time/motivation to look
into it; and nobody else complained so far either):
 https://trac.macports.org/ticket/50426

The initial builds failed, see for example:
 https://build.macports.org/builders/buildports-mtln-x86_64/builds/27442
but judging from
 http://packages.macports.org/geant4.10.2/
it seems as if the "build all ports" picked up and uploaded the
"broken" package with "no questions asked".

Shouldn't this be fixed somehow? (Not just the port, but also the
behaviour.) Or did the package automagically start to work properly?

I don't dare to even start parsing the logs from the all-ports build.
The progress log from the same buildslave
 
https://build.macports.org/builders/buildports-mtln-x86_64/builds/28037/steps/compile/logs/progress
says "package found, not building again".


That happens if installation succeeded but activation failed, or 
rev-upgrade failed afterwards. What behaviour are you wanting? For it to 
uninstall the port in this case?


I agree it's not really ideal, but it does speed things up for users as 
archives are intended to do, even though in this case what they end up 
with is broken either way. And you'll need a version or revision bump to 
fix it, so uninstalling and attempting the build again in future doesn't 
really help.


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

Re: WP-CLI

[Joshua Root]

On 2016-2-22 20:00 , Takeshi Enomoto wrote:
> Hi,
> 
> I created a Portfile for WP-CLI,
> which is very useful installing and managing WordPress sites.
> 
> 
> 
> It is just a compressed PHP script so it might not worth packaging,
> but Homebrew has a formula and it is mentioned at the WP-CLI web site
> as and alternative method to install.
> So I thought we should also provide a Portfile.
> 
> - The script runs with php that it finds. Is this OK?

If it works fine with any version of php this may be OK. If not,
variants adding a dependency on different php ports may be appropriate.
Does this script need to use the same php as the wordpress installation
it manages?

> - The script in phar does not require the extract phase. Can I
> destroot directly from ${distpath}?

Yes, that's fine.

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

Re: What to do with old versions of Python, Perl, PHP, Apache1 (and others)?

[Joshua Root]

On 2016-2-5 03:52 , Mojca Miklavec wrote:
> (for Python it's not entirely clear which ones are EOL)

Search for "Release Schedule" in the list of PEPs:


2.6 is no longer getting any updates at all. 2.7 is being maintained
with bug fixes until 2020 and possibly security fixes for some time
after that. 3.2 is just reaching the end of its security update period.
Later versions are still getting updates.

> The question is: what should be the general policy with these ports?
> How long should we keep them around?

As long as they still build on some OS X version that base works on. If
they break and nobody steps up to fix them, that's a pretty good
indication that it's time for them to go.

As you mentioned, there are all kinds of reasons why people have to test
against old versions. A deprecation warning in the description and notes
would be a good idea.

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

Re: -v being a bit too chatty

[Joshua Root]

On 2016-1-30 21:16 , René J.V. Bertin wrote:
> Hi,
> 
> My qt5-kde port has the following bit of code that adds the appropriate -sdk 
> option to configure.args:
> 
> {{{
> # default: build for the current OS version, requesting the 
> corresponding SDK explicitly
> if {[catch {system "xcrun --show-sdk-path -sdk 
> macosx10.${OSX_MINOR}"} result]} {
> ui_debug "Couldn't find preferred SDK macosx10.${OSX_MINOR}: 
> ${result}"
> # the preferred matching SDK isn't available; check if the 
> default SDK is
>   SNIP
> } else {
> ui_debug "Using SDK macosx10.${OSX_MINOR} : ${result}"
> configure.args-append \
> -sdk [string tolower "macosx10.${OSX_MINOR}"]
> }
> }}}
> 
> I had been noticing that `port {-vy install|-v info} somePortDependingOnQT5` 
> printed the full path to the preferred SDK, and finally traced that back to 
> the `catch {system "xcrun ..."}]` statement above.
> 
> 2 questions:
> - why is the Qt5-kde Portfile parsed when port:qt5-kde is uptodate?
> - is there a way to silence output from `catch {system ...` even with the -v 
> option? I thought the role of the catch function was also to ... catch the 
> called function's output?

If you don't want the output printed and logged, don't use 'system',
that's what it's for.

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

Re: VLC cannot play MKV files?

[Joshua Root]

On 2016-1-27 04:04 , Daniel J. Luke wrote:
> On Jan 26, 2016, at 11:55 AM, Ryan Schmidt  wrote:
>> There were performance concerns earlier in the discussion but I'm not sure 
>> if the latest version of the patch attached there resolves them.
> 
> the latest comment that mentions it says it's a 2x slowdown (better than the 
> original 10x slowdown).
> 
> As mentioned in the ticket - this is really something that needs to be 
> configurable if it's added (I can see how one might want this on a small SSD, 
> but I  don't want it set on my large disk array...)

Not really thrilled by the inline hex file and shelling out to run a
command pipeline before every extract either. Seems like this could be a
configure check for the system bsdtar supporting the feature instead.

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Joshua Root]

On 2016-1-27 04:55 , Rainer Müller wrote:
> -stdlib=... is a linker flag not for ld itself, but for the clang++ to
> pass the correct library to ld.
> 
> I think this should be added to configure.ldflags in the same way it is
> handled for configure.cxxflags.

Does that work (or even make sense) when linking is not being done with
clang++?

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

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Joshua Root]

On 2016-1-27 05:52 , Rainer Müller wrote:
> On 2016-01-26 19:13, Joshua Root wrote:
>> On 2016-1-27 04:55 , Rainer Müller wrote:
>>> -stdlib=... is a linker flag not for ld itself, but for the clang++ to
>>> pass the correct library to ld.
>>>
>>> I think this should be added to configure.ldflags in the same way it is
>>> handled for configure.cxxflags.
>>
>> Does that work (or even make sense) when linking is not being done with
>> clang++?
> 
> How else would you link C++ code if not with clang/clang++?

LDFLAGS is not only used when linking C++ code.

> The -stdlib=libc++ option is already specific to clang/clang++,
> gcc/g++ do not understand it.

But the current check only considers the value of configure.cxx.

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

Re: How to find all dependents of go?

[Joshua Root]

On 2016-1-16 01:03 , Christoph Iserlohn wrote:
> Hi Josh,
> 
> Am 15.01.16 um 03:01 schrieb Joshua Root:
>> On 2016-1-15 10:36 , Daniel J. Luke wrote:
>> You can construct a better regex like: port echo 'depends:\:go(\s|$)'
> Thanks, that worked. I thought the regex matches against a list of (port) 
> names,
> but apparently it matches literally against the contents of depends_* in the
> portfiles(s).
> 
> Still wondering why
> 
> $ port dependents go
> 
> doesn't work. It works fine for other ports:
> 
> $ port dependents erlang
> 
> couchdb depends on erlang
> 
> elixir depends on erlang
> 
> rebar depends on erlang

I would guess you just don't have any ports installed that have a
runtime dependency on go. Ports that only need it at build time are not
dependents.

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

Re: [144621] trunk/dports/python/py-numpy/Portfile

[Joshua Root]

On 2016-1-16 05:54 , Sean Farley wrote:
> 
> Joshua Root <j...@macports.org> writes:
> 
>> On 2016-1-15 05:51 , Sean Farley wrote:
>>>
>>> Joshua Root <j...@macports.org> writes:
>>>
>>>>> Revision: 144621
>>>>>   https://trac.macports.org/changeset/144621
>>>>> Author:   sean at macports.org
>>>>> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
>>>>> Log Message:
>>>>> ---
>>>>> py-numpy: numpy needs fortran, so require it
>>>>
>>>> We've been through this before; numpy does not need fortran, its fortran
>>>> support is optional.
>>>
>>> No, it is not optional. Trying running 'numpy.test()'. Or try compiling
>>> with 'atlas +nofortran'. Not having fortran will generate a broken numpy
>>> library.
>>>
>>> Side note: We should consider getting rid of 'atlas +nofortran'. I
>>> haven't found a port that depends on atlas but works without fortran.
>>
>> What you're saying is that to use fortran with numpy you need to enable
>> its fortran support. Well, yes.
>>
>> If you're just using, say, pyopengl, then no, you don't need fortran
>> support.
> 
> While a project *might* not need numpy's fortran, numpy expects a
> fortran compiler:
> 
> "you’ll also need a FORTRAN 77 compiler installed." [1]
> 
> This means any dependent of numpy is correct in assuming that the python
> compiler wrappers that numpy provide will have fortran. The amount of
> headache this solves for us, I believe, far outweighs not having
> fortran.
> 
> Until we can reliably depend on variants, I don't want a broken numpy
> library installed (same with my feelings of removing atlas +nofortran).
> It just causes too much headache.
> 
> [1] http://docs.scipy.org/doc/numpy-1.10.1/user/install.html

Installing all of gcc when you don't need it is a bit of a headache too.
Whatever, I can just revert this locally, though I would guess there are
other users in the same position.

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

Re: [144621] trunk/dports/python/py-numpy/Portfile

[Joshua Root]

On 2016-1-15 05:51 , Sean Farley wrote:
> 
> Joshua Root <j...@macports.org> writes:
> 
>>> Revision: 144621
>>>   https://trac.macports.org/changeset/144621
>>> Author:   sean at macports.org
>>> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
>>> Log Message:
>>> ---
>>> py-numpy: numpy needs fortran, so require it
>>
>> We've been through this before; numpy does not need fortran, its fortran
>> support is optional.
> 
> No, it is not optional. Trying running 'numpy.test()'. Or try compiling
> with 'atlas +nofortran'. Not having fortran will generate a broken numpy
> library.
> 
> Side note: We should consider getting rid of 'atlas +nofortran'. I
> haven't found a port that depends on atlas but works without fortran.

What you're saying is that to use fortran with numpy you need to enable
its fortran support. Well, yes.

If you're just using, say, pyopengl, then no, you don't need fortran
support.

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

Re: How to find all dependents of go?

[Joshua Root]

On 2016-1-15 10:36 , Daniel J. Luke wrote:
> On Jan 14, 2016, at 6:31 PM, David Evans  wrote:
>> On 1/14/16 3:25 PM, Clemens Lang wrote:
>>> Hi,
>>>
>>> On Thu, Jan 14, 2016 at 09:28:48PM +0100, Christoph Iserlohn wrote:
 But
 $ port dependents go
 returns
 go has no dependents.
 which is clearly wrong. I have several ports depending on go installed, 
 e.g.:
 $ port installed go-tools
 The following ports are currently installed:
  go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0 (active)

It's only a build dependency, so once go-tools is installed, go is no
longer required.

 No luck with port search either:
 $ port search --exact --depends_lib --depends_build go
 No match for go found
>>>
>>> Try port echo depends:go.
>>>
>>
>> This is not too useful as it returns a list of ports whose dependencies
>> have 'go' in their names.  So you get the desired dependents plus ports
>> that depend on pango, etc.

You can construct a better regex like:

port echo 'depends:\:go(\s|$)'

> port echo dependentof:go 
> 
> or
>  
> port echo rdependentof:go

That queries the registry just like 'port dependents'.

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

[144621] trunk/dports/python/py-numpy/Portfile

[Joshua Root]

> Revision: 144621
>   https://trac.macports.org/changeset/144621
> Author:   sean at macports.org
> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
> Log Message:
> ---
> py-numpy: numpy needs fortran, so require it

We've been through this before; numpy does not need fortran, its fortran
support is optional.

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

[144426] trunk/doc-new/guide/xml/portfile-tcl.xml

[Joshua Root]

> Revision: 144426
>   https://trac.macports.org/changeset/144426
> Author:   dstrubbe at macports.org
> Date: 2016-01-08 12:16:33 -0800 (Fri, 08 Jan 2016)
> Log Message:
> ---
> doc-new: Add comments on locale in reinplace.
> 
> Modified Paths:
> --
> trunk/doc-new/guide/xml/portfile-tcl.xml
> 
> Modified: trunk/doc-new/guide/xml/portfile-tcl.xml
> ===
> --- trunk/doc-new/guide/xml/portfile-tcl.xml  2016-01-08 19:39:53 UTC (rev 
> 144425)
> +++ trunk/doc-new/guide/xml/portfile-tcl.xml  2016-01-08 20:16:33 UTC (rev 
> 144426)
> @@ -275,7 +275,9 @@
>the command with the replacement text, in all files
>specified.
>  
> -  Use -locale to set the locale
> +  Use -locale to set the locale. For example, locale 
> -C
> +   if a non-ASCII file is being modified (which may otherwise give 
> the error
> +   "sed: RE error: illegal byte sequence").

Setting a locale is not needed for all non-ASCII files, just non-UTF-8
ones (as the default locale is "en_US.UTF-8"). It may also be worth
mentioning that using "C" will only allow ASCII characters to be
processed correctly by the reinplace, so if you need it to work on
non-ASCII characters you need to set a locale with the correct charset
for the file, e.g. "en_US.ISO8859-1".

Also, it should be "-locale C" not "locale -C".

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

Re: build.args

[Joshua Root]

On 2016-1-9 08:21 , David Strubbe wrote:
> Hi all,
> 
> Is there a way to get the value of build.args in a Portfile? I would
> like to do something like
> 
> pre-test {
>test.args-append   ${build.args}
> }
> 
> but there is no such variable.

The variable doesn't exist if it has not been set. In that case, there
is of course no value to get. You can test for its existence with
[exists build.args].

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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Joshua Root]

On 2016-1-8 05:12 , Eric A. Borisch wrote:
> Bringing this back to the original point, it looks like there was some
> discussion (I think) in this thread of making alocation (possibly
> integrated in terms of access accounts with svn commit access)
> available to store a 'snapshot' of a 'distfile' for instances like
> this (where the source performs nightly refreshes of the tarball
> without version information in the name.)
> 
> So is that going to happen (soon), or is the desire I bake something
> else up (drafting off curl-ca-bundle or graphviz-devel) for now?

I wonder if sourceforge's rules would allow making another project
called something like "macports-distfiles" and giving all our committers
the ability to add files to it. From a quick look at the terms of use,
it appears that uploaded content just needs to have a license "compliant
with the Open Source Initiative (“OSI”)’s Open Source Definition".

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

Re: Survey: How do you commit?

[Joshua Root]

On 2016-1-3 07:38 , Ryan Schmidt wrote:
> 
> On Jan 2, 2016, at 6:22 AM, Joshua Root wrote:
> 
>> Works pretty well for the most part. Would be nice if it had commit
>> shelving <https://issues.apache.org/jira/browse/SVN-3625>.
> 
> The closest feature that exists is the changelist: 
> http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.changelist.html

While that's certainly useful in some situations, it doesn't help for
the use case I have in mind. Suppose you're working on some relatively
lengthy changes to a file, when you spot an unrelated bug that can
easily be fixed with a small change. The unrelated bugfix should be in
its own changeset, so the ideal workflow here is to shelve the partially
completed changes, fix the bug, commit, then unshelve and continue working.

You can emulate this in various ways of course, and I do when needed, it
would just be nice if it was built in.

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

Re: "port install" for subport

[Joshua Root]

On 2015-12-31 07:09 , David Strubbe wrote:
> Hi all,
> 
> If you are in the directory of a Portfile, you can use "port install" or
> "port install current" to install the port described by the Portfile.
> But what if the Portfile contains a subport? Is there a way to install
> the subport in this way? It would be helpful for testing purposes.

Add subport=whatever to the end of the command.

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

Re: libffi's weird packaging

[Joshua Root]

On 2015-12-28 19:54 , Mojca Miklavec wrote:
> Hi,
> 
> I wonder if there is any special reason for this weird packaging of
> libffi (the include files in particular; does it conflicts with other
> libraries?):
> 
> Port libffi contains:
>   /opt/local/lib/libffi-3.2.1/include/ffi.h
>   /opt/local/lib/libffi-3.2.1/include/ffitarget.h
>   /opt/local/lib/libffi.6.dylib
>   /opt/local/lib/libffi.a
>   /opt/local/lib/libffi.dylib
>   /opt/local/lib/libffi.la
>   /opt/local/lib/pkgconfig/libffi.pc
>   /opt/local/share/info/libffi.info
>   /opt/local/share/man/man3/ffi.3.gz
>   /opt/local/share/man/man3/ffi_call.3.gz
>   /opt/local/share/man/man3/ffi_prep_cif.3.gz
>   /opt/local/share/man/man3/ffi_prep_cif_var.3.gz
> 
> When building moarvm which needs ffi.h and apparently doesn't care
> about "libffi.pc" yet, I had to add the following to the Portfile
> which looks like a relatively bad idea to me:
> 
> configure.cflags-append "-I${prefix}/lib/libffi-3.2.1/include"

I guess you mean it's a bad idea because of the hardcoded version? This
isn't a bad construct in general, apart from that (though normally
cppflags is more appropriate). It's better to use pkgconfig of course.

> Can someone suggest me what to do (other than asking moarvm
> maintainers to fix the libffi detection and use)?

You may need to ask upstream why they install the headers in that
unusual place. I can't think of a problem that could be caused by at
least linking them into ${prefix}/include/libffi, but then I don't know
why they're not somewhere like that in the first place.

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

Re: portindex ignores (filters out) unchanged port

[Joshua Root]

On 2015-12-29 00:33 , Mojca Miklavec wrote:
> Somewhat off-topic: One problem that I'm often experiencing is that
> PortIndex doesn't *remove* the port from the index.
> 
> Example: I created a new port under "sysutils" without checking
> whether such a port already existed in MacPorts. In fact that port was
> already under "lang" and I suddenly had two port with the same name
> under two categories. I removed the one I created, but I wasn't able
> to do anything with the old port.
> 
> The only recovery I was able to come up with was deleting PortIndex,
> but that meant waiting for that horrible p5-graveyard to finish the
> work.
> 
> Am I the only one experiencing the problem that entries don't get
> removed from the index once the files are gone?

In this situation, the newer Portfile gets indexed and replaces the
entry for the older one. After you delete the duplicate, you usually
have to touch the remaining one so it is newer than the PortIndex.

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

Warnings when parsing hdfeos5 Portfile

[Joshua Root]

I noticed that doing anything that parses the hdfeos5 Portfile, even
just 'port info hdfeos5', produces this output:

Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5 mpich
""] fails.
Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5
mpich_devel ""] fails.
Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5
openmpi ""] fails.
Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5
openmpi_devel ""] fails.

It looks like this is harmless, but it's ugly and likely to alarm users.
Would it be possible to avoid it?

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

Re: [MacPorts] #49961: fetch for port hdfeos failed

[Joshua Root]

On 2015-12-19 18:13 , take...@macports.org wrote:
> Hi,
> 
> I’d like to manually upload the source of hdfeos
> because the FTP server of master_sites is down.
> 
> Could you instruct me how to do this?

If you don't have anywhere else to host it I can upload it to our
sourceforge project for you.

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

[143602] trunk/dports

[Joshua Root]

> Revision: 143602
>   https://trac.macports.org/changeset/143602
> Author:   devans at macports.org
> Date: 2015-12-15 10:48:47 -0800 (Tue, 15 Dec 2015)
> Log Message:
> ---
> ports with perl variants: increment revision to reset default variant to 
> +perl5_22.

What do you mean by this exactly? I can't figure out what these rev
bumps would have accomplished.

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

[143598] trunk/dports/python/py-ckanapi/Portfile

[Joshua Root]

> Revision: 143598
>   https://trac.macports.org/changeset/143598
> Author:   petr at macports.org
> Date: 2015-12-15 10:21:49 -0800 (Tue, 15 Dec 2015)
> Log Message:
> ---
> py-ckanapi: minor edit to trigger py35 build

You don't need to modify the file to trigger a build, you can do that
from the buildbot web interface.

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

Re: [143602] trunk/dports

[Joshua Root]

On 2015-12-16 13:24 , David Evans wrote:
> On 12/15/15 4:30 PM, Joshua Root wrote:
>>> Revision: 143602
>>>   https://trac.macports.org/changeset/143602
>>> Author:   devans at macports.org
>>> Date: 2015-12-15 10:48:47 -0800 (Tue, 15 Dec 2015)
>>> Log Message:
>>> ---
>>> ports with perl variants: increment revision to reset default variant to 
>>> +perl5_22.
>>
>> What do you mean by this exactly? I can't figure out what these rev
>> bumps would have accomplished.
>>
>> - Josh
>>
> 
> Well, I could say just to get a response -- and it worked! :-)
> 
> Actually this is poorly phrased.  I just wanted to force a rebuild
> of these ports so that the archived binary would have the +perl5_22
> variant (now the default) rather than perl5_16.

The logic for deciding whether to skip a build looks at the archive
filename, so just triggering a build would make an archive with the new
default variants available.

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

Re: Warning: All compilers are either blacklisted or unavailable

[Joshua Root]

On 2015-12-3 04:05 , Mojca Miklavec wrote:
> Hi,
> 
> When upgrading Qt5 I'm greeted with:
> 
> --->  qt5-mac is replaced by qt5
> Warning: All compilers are either blacklisted or unavailable;
> defaulting to first fallback option
> 
> I guess this is because of the cxx11 PortGroup, even though I'm not 100% sure.
> 
> But the main question is: why are all compilers blacklisted or rather:
> can something be done to have some compiler in the fallback that would
> work (like mp-clang-3.4)? Lion's clang (425) usually works, even
> though there are some problems with it (not all C++11 code works).

The qt5 portgroup sets 'compiler.whitelist clang'.

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

Re: Warning: All compilers are either blacklisted or unavailable

[Joshua Root]

On 2015-12-3 11:42 , Marcus Calhoun-Lopez wrote:
> Does blacklisting clang < 500 in the  cxx11 PortGroup completely
> preclude 10.7?

Looks like it, yes:


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

Re: 32-bit builds?

[Joshua Root]

On 2015-11-27 14:37 , Mark Brethen wrote:
> 
>> On Nov 26, 2015, at 4:51 PM, Ryan Schmidt  wrote:
>>
>>
>> On Nov 26, 2015, at 9:03 AM, Mark Brethen wrote:
>>
>>> The error message:
>>>
>>> :info:build ld: symbol(s) not found for architecture x86_64
>>> :info:build clang: error: linker command failed with exit code 1 (use -v to 
>>> see invocation)
>>> :info:build make[1]: *** [astgen] Error 1
>>>
>>> says "symbol(s) not found for architecture x86_64" instead of "symbol(s) 
>>> not found for architecture i386”. Can I tweak my build settings to allow a 
>>> 32-bit build?
>>
>> This error message means you are building for x86_64, and the symbols were 
>> not found for that architecture. It does not make any statement as to 
>> whether the symbols would be found for any other architecture nor whether 
>> the software supports or does not support x86_64. It might mean you forgot 
>> to specify the name of the library in which the symbols are found, or it 
>> could indicate a libc++/libstdc++ incompatibility. Or it could mean there is 
>> an architecture mismatch between the program and the library it's using, but 
>> since Macs have been x86_64 for many years that's not the first place I'd 
>> look.
>>
>>
> 
> The last update of elkhound by the original developer was in 2006. Since 
> then, there have been a few updates by other parties. I think the one I was 
> using has some issues. I tried building another today that is bundled with 
> oink-stack (https://github.com/dsw/oink-stack). This one was updated in june 
> and gets to the last build phase with these errors:
> 
> :info:build /usr/bin/clang++ -o elkhound -DGRAMANL_MAIN -g -Wall 
> -Wno-deprecated -D__UNIX__ -O2 -DNDEBUG -I. -I../smbase -I../ast -Ic 
> -fno-strict-aliasing gramanl.cc gramexpl.o asockind.o grammar.o emitcode.o 
> mlsstr.o genml.o gramast.ast.gen.o gramlex.yy.o grampar.o grampar.tab.o 
> parsetables.o -g -Wall -Werror ../ast/libast.a ../smbase/libsmbase.a
> :info:build In file included from gramanl.cc:4:
> :info:build In file included from ./gramanl.h:20:
> :info:build ./grammar.h:197:18: error: 'Terminal::toString' hides overloaded 
> virtual function [-Werror,-Woverloaded-virtual]
> :info:build   virtual string toString(bool quoteAliases = false) const;
> :info:build  ^

It's good to fix warnings, but make sure you remove -Werror from the
build commands in the final version of the port.

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

Re: Portfile newbie questions

[Joshua Root]

On 2015-11-20 07:04 , Terry Barnum wrote:
> My first post to macports-dev so please pardon the newbie questions.
> 
> I've wanted to try my hand at creating a Portfile for the pypolicyd-spf 
> package . Postfix or Sendmail uses it 
> to check a sender's SPF domain record to see if it's spoofed email.
> 
> pypolicyd-spf's README says it depends on v2.0.9+ of the python-spf library 
> , which isn't in ports, and also 
> depends on v2.1.10+ of the python ipaddr module, which is in ports but is an 
> older version (v2.1.9). Current is 2.1.11 
> .
> 
> Referencing the Macports docs, I created a local repository and successfully 
> created local Portfiles to install the pymilter and ipaddr packages but then 
> ran into warnings with the pypolicyd-spf port being installed into /etc. I 
> think this means I need a patch file for its setup.py. Are there more 
> examples of patchfiles? Like maybe a Dummy's Guide? ;) Or is it best just to 
> look at other python Portfiles and see what they're doing?

There isn't a standard way to do this, mostly because having to patch
build systems for this sort of reason is generally because the standard
way of doing things doesn't work. It's just a matter of going through
the code and finding out where the install location is defined, and
figuring out how to get our install location there instead.

> Also, what's the convention for when to name a port just py-* versus py2?-* 
> or py3?-*

The python portgroup handles creating a subport per supported python
version for you. You put 'name py-something' and 'python.versions 27 35'
and you will get subports py27-something and py35-something.

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