Re: Mac OS Forge Migration update
Josh
The rsync command that is failing is something like this
buildbot@build buildbot]$ grep rsync deploy_archives.sh
rsync -rlDzv --ignore-existing ${ULPATH}/ ${DLHOST}:${DLPATH}
rsync -rlDzv --ignore-existing ${ULPATH}/ ${DLPATH}
[buildbot@build buildbot]$
I need some help in running a strace on it and providing support the out put.
The command will look like.
# strace -f -t -T -o /tmp/rsync-rlDzv.trc rsync -rlDzv --ignore-existing
${ULPATH}/ ${DLHOST}:${DLPATH}
I have done this by using test directory and test files between build.macports
and packages.macports but it did not encounter any errors.
Shree
On Mar 17, 2014, at 11:12 PM, Joshua Root j...@macports.org wrote:
On 2014-3-18 06:43 , Shreeraj Karulkar wrote:
3) Buildbot/Slaves: While all the build-slaves seem to be compiling fine you
are probably referring to the deploy_archives.sh is failing for Mavericks
right? I have tried send a file via rsync with similar options (-rlDzv) from
build.macports to rsync.macports and it went through successfully. I also
did a su to user buildbot and sent a test file through successfully. It did
prompt me to accept the RSA key though. Can you check if it has worked?
There is also a reference to use -e in the rsync options to pass ssh options
like the --ignore-existing” optionthat is being used in the script. However
the script has not changed 2013 so I am not sure it thats an issue.
I am still working on this and would appreciate any clues from anyone, sorry
for the delay in the resolution of these issues.
There are three buildbot-related issues remaining:
1. buildslaves can't selfupdate (possibly they can't connect to
rsync.macports.org).
https://build.macports.org/builders/buildports-mavericks-x86_64/builds/2211/steps/sync/logs/stdio
2. buildmaster can't connect to packages.macports.org with rsync.
https://build.macports.org/builders/buildports-mavericks-x86_64/builds/2210/steps/deploy%20archives/logs/stdio
3. buildmaster is not receiving any changesets. These should come from
the post-commit hook which presumably runs on svn.macports.org.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Arrival of new MacPorts version including mpstats
Hi MacPorts devs, how is the schedule for release of the next MP release which will - I gather - include the opt-in-able mpstats? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Buildbot fails to upload packages...
After it's fixed I'll re-run all the port builds since it broke. - Josh On 2014-3-20 05:29 , Shreeraj Karulkar wrote: Nope, I am looking into it. Shree On Mar 19, 2014, at 8:56 AM, Eric A. Borisch ebori...@macports.org mailto:ebori...@macports.org wrote: Just making sure this hasn't dropped off the radar. Just picking the latest build: https://build.macports.org/builders/buildports-lion-x86_64/builds/18908/steps/deploy%20archives/logs/stdio - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Hi, Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas – feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Migrating to a completely new system for version control and tickets would probably be either very difficult or lossy (or both). And the workflow would need to be redefined completely. I'm not saying that I oppose the idea if someone is actually willing to spend time to do it right, just saying that current system works nice and that git or hg probably wouldn't add that much. (For me, Tcl is the one that's often limiting my contributions a lot more than anything else because I don't have much experience writing code in it.) That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). Btw, we now have: - Fink: CVS + Perl - MacPorts: SVN + Tcl - HomeBrew: GIT + Ruby We desperately need the fourth package manager using HG + Python ;) Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Where do I find a good example of a tests variant (which is really installing the tests on the system)?
I would like to introduce a tests variant for a port.
Can someone point me to a port which successfully installs a test variant?
I know that I can build and run tests when building ports (i.e. when I only run
“sudo port build; cd build; ctest …”).
But I want that all needed test files get actually installed in the system and
not only built and removed again.
So, I’d like to know where to place which files below ${destroot}.
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC 2014 - Interactive Port Command and
On 2014-3-20 12:29 , Marcus Santos wrote: Can you help me with some questions I have about base/src/port/port.tcl and base/src/macports1.0.tcl? First of all I need to understand how they work together and what is the role of each one. I have been around the code of the progress bar to understand how it works and trying to realize how can I do the interaction between the user and macports, and where to assess the input from the user. Second, how can I use the interface of macports1.0 to allow asking user questions? port.tcl is the port(1) command. It also contains a fair bit of code that could be factored out and used by multiple front ends (if we had them). This script is responsible for parsing and evaluating the command line arguments and running the appropriate actions. UI stuff, basically. macports.tcl provides an API (but no UI) for running targets on ports, as well as some other stuff like selfupdate. First you mportinit, then you mportlookup to find the port you want, then you mportopen it, then you mportexec one or more targets on it, then when you're done you mportclose it. You wouldn't really use macports1.0 to ask the user questions, that would be the role of the new interactive UI that you're going to write. You would attempt to do things using the macports1.0 API, then if they don't succeed, you would examine the error code and offer the user appropriate choices depending on the situation. You may or may not need to modify macports1.0 to give the front end more information to support this. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC 2014 - Interactive Port Command and
Hi, On 2014-3-20 12:29 , Marcus Santos wrote: Can you help me with some questions I have about base/src/port/port.tcl and base/src/macports1.0.tcl? First of all I need to understand how they work together and what is the role of each one. I have been around the code of the progress bar to understand how it works and trying to realize how can I do the interaction between the user and macports, and where to assess the input from the user. Second, how can I use the interface of macports1.0 to allow asking user questions? [...] You wouldn't really use macports1.0 to ask the user questions, that would be the role of the new interactive UI that you're going to write. You would attempt to do things using the macports1.0 API, then if they don't succeed, you would examine the error code and offer the user appropriate choices depending on the situation. You may or may not need to modify macports1.0 to give the front end more information to support this. Actually I was thinking of modifying port.tcl in a way that passes a callback to macports1.0 that would subsequently be used in every situation where asking the user a question makes sense. Of course that should only be done when there is a callback function (i.e. only when port.tcl is used interactively). So, you'd have to identify: - What requirements and API would such a conversation function have - Where can this be used and what type of feedback should the user be able to provide? Yes/No questions? Choices from a list of options? Dot graphs? (the latter would be a little unexpected, though ;)) From a mail a sent to a different student on the code structure in macports base: 8 8 8 8 8 8 8 8 8 Just as a very simple primer: - port/ contains the tools you run from the command line Those should take care of argument parsing and output presentation - macports1.0/ is the core of MacPorts It knows where all the Portfiles are, manages settings, opens and runs Portfiles, etc. - port1.0/ is the API available to Portfiles and some helper functions All commands available in Portfiles are defined there, along with some helpers we use to simplify running Portfiles. Most of this code is usually run in a sub-interpreter created in macports1.0. - package1.0/ manages all the binary archive downloading and packaging If something extracts, packages or downloads a binary archive, it's probably using this code. - pextlib1.0/ is a collection of helper functions exported to Tcl Most of these would otherwise not be available in Tcl and export a Tcl command that's used elsewhere. - registry2.0/ and cregistry/ are helpers related to the registry They provide a Tcl abstraction of the C routines used to talk to the SQLite database of installed ports and files. The rest are rather minor packages: - machista1.0/ is a helper library to parse Mach-O binaries It is used in rev-upgrade to check for linking errors - darwintracelib1.0/ contains a library needed for trace mode These are the source files that will be injected into each process using DYLD_INSERT_LIBRARIES when using trace mode. - programs/ contains helpers, e.g. for launchd plists - tcjobjc1.0/ and cflib1.0/ are currently unused Those were supposed to be bridges between Tcl and Objective-C or CoreFoundation for other (mostly GUI) software to use. So, e.g. the progress information for downloads is generated in pextlib1.0/curl.c where the cURL API is used to download files. pextlib1.0/curl.c exports a Tcl command called curl, which is used in port1.0 and package1.0 for downloads. To implement the progress bar, this command got a new parameter to define a Tcl callback proc to be called with the updated information. However, since port/port.tcl should take care of how the progress bar should be displayed, the callback needs to be provided by this file. To get the correct callback from port/port.tcl to port1.0 and package1.0 where it is passed to pextlib1.0, it needs to go through macports1.0 (as you have seen). Always imagine that it should be possible to replace port/port.tcl with a GUI client (rendering a GUI progress bar). 8 8 8 8 8 8 8 8 8 HTH, -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [117817] trunk/dports/devel/automake
On Thu, Mar 20, 2014 at 12:11 AM, David Evans dev...@macports.org wrote:
If that is what is happening then you must be using the MacPorts Python
ports as well.
Yes I am.
The intent of the patch is for the macro to determine the
correct Python installation paths for whichever Python is passed in env var
PYTHON or failing that whichever Python it finds in the current search path.
So if you are building a non-MacPorts project you should be using a
non-MacPorts
Python that is built to expect your installed Python modules where ever you
plan to install them.
Why? That means that MacPorts python can only be used for MacPorts, so
are you saying that now I should install another version of python
along with all the required dependencies for third party code outside
of MacPorts? That makes no sense, the whole point of MacPorts is to
ease installation of software now you're essentially saying it can
only be used to install dependencies for other MacPorts ports?
That's not very clear, is it? I hope you understand my point. You want
these paths
to point to where the Python in use will search for modules, not just in
the arbitrary
locations ${prefix} and ${exec_prefix} (although that's the norm for
non-MacPorts installations).
I agree that MacPorts should install libraries in this path but we
need be able to use MacPorts to build other software on our systems.
Cheers
Adam
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
Brining back to dev list; seems like the right place.
On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote:
Adam Mercer r...@macports.org writes:
On Thu, Mar 20, 2014 at 2:55 PM, Sean Farley s...@macports.org wrote:
I tend to agree with you but need help seeing how this worked
before. What path did automake pick up before this change?
If you look at the patch you can see the original paths:
http://trac.macports.org/browser/trunk/dports/devel/automake/files/patch-m4-python.m4.diff
The original paths are:
AC_SUBST([PYTHON_PREFIX], ['${prefix}'])
AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])
Just to clarify this isn't the MacPorts prefix but the prefix for the
running configure process.
Right, sorry, I meant more along the lines of:
Before: my project installed into /path/foo/a
After: my project installed into /path/foo/b
I think the issue here is that automake is getting patched to *only*
support MacPorts-managed builds, but really automake should still be
available for use to build non-MP software.
What was broken that needed fixing (by the original change)? Is there a
particular port that needed the change? Is there another way to fix it
without modifying automake?
Assuming the change is/was needed (and the best solution), perhaps setting
an environment variable during MP managed builds could be used here to
switch the behavior? Something along the lines of:
AC_SUBST([PYTHON_PREFIX], [`[ ${__MP_BUILD__} ] $PYTHON -c import sys;
sys.stdout.write(sys.prefix); || echo -n ${prefix}`])
where __MP_BUILD__=1 during a managed build, and undefined otherwise?
This way when a user outside of MacPorts is installing a
python-using-software (built against MP-provided python) and they have set
$prefix via configure, it doesn't get crowbarred into /opt/local/ (or
wherever MP is installed.) (Granted, as the .m4 file notes, they will need
to set PYTHONPATH or tell python about it in some manner to use it.)
- Eric
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote: Before: my project installed into /path/foo/a After: my project installed into /path/foo/b Got you, if I configured using: ./configure --prefix=$HOME/opt the the Python modules would be installed in: $HOME/opt/lib/python2.7/site-packages After the change it wants to install them in: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch ebori...@macports.org wrote:
I think the issue here is that automake is getting patched to *only* support
MacPorts-managed builds, but really automake should still be available for
use to build non-MP software.
Agreed, that's one of the main concerns I have with this.
What was broken that needed fixing (by the original change)? Is there a
particular port that needed the change? Is there another way to fix it
without modifying automake?
Assuming the change is/was needed (and the best solution), perhaps setting
an environment variable during MP managed builds could be used here to
switch the behavior? Something along the lines of:
AC_SUBST([PYTHON_PREFIX], [`[ ${__MP_BUILD__} ] $PYTHON -c import sys;
sys.stdout.write(sys.prefix); || echo -n ${prefix}`])
where __MP_BUILD__=1 during a managed build, and undefined otherwise?
Seems that would work, but I'm not sure I like the idea of hacking the
autotools. At work I've run into a lot of bizarre problems that I
eventually traced back to different OS vendors making changes to the
autotools.
This way when a user outside of MacPorts is installing a
python-using-software (built against MP-provided python) and they have set
$prefix via configure, it doesn't get crowbarred into /opt/local/ (or
wherever MP is installed.) (Granted, as the .m4 file notes, they will need
to set PYTHONPATH or tell python about it in some manner to use it.)
In the past when I've needed to ensure that python libraries, provided
by MacPorts, end up in the correct location I've used something like
the following:
set pythondir
${frameworks_dir}/Python.framework/Versions/2.7/lib/python2.7/site-packages
destroot.args-append \
pythondir=${pythondir} \
pyexecdir=${pythondir} \
pkgpythondir=${pythondir}/${name} \
pkgpyexecdir=${pythondir}/${name}
It's a bit of a hack but gives full control and doesn't break things
for non MacPorts use.
Cheers
Adam
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
Adam Mercer r...@macports.org writes: On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote: Before: my project installed into /path/foo/a After: my project installed into /path/foo/b Got you, if I configured using: ./configure --prefix=$HOME/opt the the Python modules would be installed in: $HOME/opt/lib/python2.7/site-packages After the change it wants to install them in: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ Ok, yeah, that's what I was wondering. Hacking autotools to change this behavior is ludicrous. This change most certainly needs to be reverted. Honestly, I don't know why we're messing with automake at all. If this is just to make installing ports (from the perspective of the portfile author) easier then why can't this type of change go in the python portgroup? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
MacPorts automake and python
On Thursday, March 20, 2014, Sean Farley s...@macports.orgjavascript:_e(%7B%7D,'cvml','s...@macports.org'); wrote: Adam Mercer r...@macports.org writes: On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote: Before: my project installed into /path/foo/a After: my project installed into /path/foo/b Got you, if I configured using: ./configure --prefix=$HOME/opt the the Python modules would be installed in: $HOME/opt/lib/python2.7/site-packages After the change it wants to install them in: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ Ok, yeah, that's what I was wondering. Hacking autotools to change this behavior is ludicrous. This change most certainly needs to be reverted. Honestly, I don't know why we're messing with automake at all. If this is just to make installing ports (from the perspective of the portfile author) easier then why can't this type of change go in the python portgroup? That's what I was trying to get at - my guess it is not py-* ports that benefitted from the change, but ports that include some pythonic parts. Fixing one or two problem ports would be a better fix than patching the build environment (automake). devans@macports, what was the reason for the change? I don't see a ticket referenced? - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
Eric A. Borisch ebori...@macports.org writes: On Thursday, March 20, 2014, Sean Farley s...@macports.orgjavascript:_e(%7B%7D,'cvml','s...@macports.org'); wrote: Adam Mercer r...@macports.org writes: On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote: Before: my project installed into /path/foo/a After: my project installed into /path/foo/b Got you, if I configured using: ./configure --prefix=$HOME/opt the the Python modules would be installed in: $HOME/opt/lib/python2.7/site-packages After the change it wants to install them in: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ Ok, yeah, that's what I was wondering. Hacking autotools to change this behavior is ludicrous. This change most certainly needs to be reverted. Honestly, I don't know why we're messing with automake at all. If this is just to make installing ports (from the perspective of the portfile author) easier then why can't this type of change go in the python portgroup? That's what I was trying to get at - my guess it is not py-* ports that benefitted from the change, but ports that include some pythonic parts. Fixing one or two problem ports would be a better fix than patching the build environment (automake). Yes, I wholeheartedly agree. Having ./configure --prefix=$HOME install python parts into MacPorts' prefix is just plain bananas. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
On 3/20/14 2:57 PM, Adam Mercer wrote: On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote: Before: my project installed into /path/foo/a After: my project installed into /path/foo/b Got you, if I configured using: ./configure --prefix=$HOME/opt the the Python modules would be installed in: $HOME/opt/lib/python2.7/site-packages After the change it wants to install them in: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev Sorry for not responding sooner. I have been busy with non-MacPorts issues today myself. This answers one of my questions as well. The second related question is what exactly is being installed in site-packages? If it's a python extension module and you expect it to be available to MacPorts python27 via import or the like, I appears to me that you would get an error that the module can't be found because it's not in Pythons true installation prefix. What's your motivation for installing it elsewhere? Trying to understand but I guess I'm being dense. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
On Thu, Mar 20, 2014 at 5:57 PM, David Evans dev...@orindasoftware.com wrote: What's your motivation for installing it elsewhere? Trying to understand but I guess I'm being dense. Simply because I'm installing manually from source, it isn't part of MacPorts and shouldn't be installed in the MacPorts prefix. I work on a project that has releases available via MacPorts, I have the releases installed via MacPorts and install from the VCS locally, with this change the development python libraries will overwrite the release python libraries and cause a whole host of problems. Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Where do I find a good example of a tests variant (which is really installing the tests on the system)?
On Mar 20, 2014, at 03:07, mk-macpo...@techno.ms wrote:
I would like to introduce a tests variant for a port.
Can someone point me to a port which successfully installs a test variant?
I know that I can build and run tests when building ports (i.e. when I only
run “sudo port build; cd build; ctest …”).
But I want that all needed test files get actually installed in the system
and not only built and removed again.
So, I’d like to know where to place which files below ${destroot}.
I’m not aware of any ports that do that, or any tests that are designed to work
that way.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
David Evans dev...@orindasoftware.com writes: On 3/20/14 2:57 PM, Adam Mercer wrote: On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley s...@macports.org wrote: Before: my project installed into /path/foo/a After: my project installed into /path/foo/b Got you, if I configured using: ./configure --prefix=$HOME/opt the the Python modules would be installed in: $HOME/opt/lib/python2.7/site-packages After the change it wants to install them in: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev Sorry for not responding sooner. I have been busy with non-MacPorts issues today myself. This answers one of my questions as well. The second related question is what exactly is being installed in site-packages? If it's a python extension module and you expect it to be available to MacPorts python27 via import or the like, I appears to me that you would get an error that the module can't be found because it's not in Pythons true installation prefix. What's your motivation for installing it elsewhere? Trying to understand but I guess I'm being dense. The motivation is simple: I told ./configure to install everything into $HOME/opt. Period. Patching automake to change this behavior is Very Bad™. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that’s something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas – feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the “haspatch” keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don’t remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Where do I find a good example of a tests variant (which is really installing the tests on the system)?
On 21 Mar 2014, at 00:14 , Ryan Schmidt ryandes...@macports.org wrote: I’m not aware of any ports that do that, or any tests that are designed to work that way. OK, in just now I have made it work by simply chown'ing the port’s work directory and executing ctest by the logged in user. That finally did the job. (And yes, you are right, the tests wouldn’t work if one would install the tests someplace. The test apps need to sit in the build directory in order to access additional files outside it. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
sync certainly works with git as well. --Mark ___ Mark E. Anderson e...@emer.net On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that's something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas - feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the haspatch keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don't remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
On 3/20/14 3:01 PM, Adam Mercer wrote:
On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch ebori...@macports.org
wrote:
I think the issue here is that automake is getting patched to *only* support
MacPorts-managed builds, but really automake should still be available for
use to build non-MP software.
Agreed, that's one of the main concerns I have with this.
I don't see this as MacPorts specific. Instead it correctly determines
the default PYTHON_PREFIX
for the Python in use. This is a MacPorts path only because you are
using a MacPorts Python port
= 2.5. If you were using a Python that was installed using the
traditional installation path then
this would return ${prefix} as the original did.
For instance using python24 returns /opt/local (which is ${prefix) by
our standard and others as well).
Using /usr/bin/python (Apple build) returns
/System/Library/Frameworks/Python.framework/Versions/2.7
So the original AM_PYTHON_PATH only returns the correct result if the
Python in use is installed in the
'standard' place. Doesn't work any Python installed in a non-standard
place.
Looking at the comments surrounding this code in python.m4 the upstream
authors acknowledge this.
dnl Use the values of $prefix and $exec_prefix for the corresponding
dnl values of PYTHON_PREFIX and PYTHON_EXEC_PREFIX. These are made
dnl distinct variables so they can be overridden if need be. However,
dnl general consensus is that you shouldn't need this ability.
What was broken that needed fixing (by the original change)? Is there a
particular port that needed the change? Is there another way to fix it
without modifying automake?
The answer is yes, any port that uses AM_PYTHON_PATH to discover the
Python install
prefix will fail on MacPorts (or any other installation of Python into a
non-standard path)
without intervention and there are quite a few.
In the past this has been handled typically by applying a similar patch
to the configure file
provided with each project being ported. This works and the patch here
does not interfere
with this because the configure file is not being regenerated.
However, increasingly, ports need to use autoreconf or even autogen.sh
to regenerate configuration
files prior to build for some other reason (intltool perl issues for
instance). This again effects a
large number of ports. In this case, patching of the configure file is
impractical and the required
patch to configure.ac amounts to replacing AM_PYTHON_PATH with custom
code that is often
package specific. This change to automake makes that unnecessary.
Have to head home now but will follow up later this evening. In the
meantime, please don't revert
this change on your own as there are many ports that WILL be broken.
If, we, as a group decide
that that is the preferred approach, I will make the change after the
effected ports have been re-written.
Thanks
PS What ever happened to the doctrine that if you mix code in other
installation prefixes with MacPorts
ports, all bets are off and results are not guaranteed?
Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118041] trunk/dports/databases/mysql56
I submitted the patch that was committed in r118041.
I will try to explain my tortured logic.
mysql was already silently using g++ as the C++ compiler for 32-bit builds.
Apparently, clang caused a problem at some point (See #42943 for more details).
Some possible solutions were:
1) Blacklist clang for 32-bit builds, in which case MacPorts would fallback to
llvm-gcc42.
Since llvm-gcc42 is not working on Mavericks (#42849), this did not
seem like an optimal choice.
2) For 32-bit builds, blacklist versions of clang in use at the time the
problem was first reported.
Since there is no guarantee that subsequent version of clang (or mysql)
fixed the problem,
this also seemed less than ideal.
3) Set configure.compiler gcc”
4) Let mysql continue to use whichever g++ it could find.
This is more or less the same as setting configure.compiler gcc
At least setting configure.compiler makes the ambiguity obvious.
Is that a virtue?
Solution 4 seemed to be the lesser of the evils.
I hope I did not miss an obvious solution.
-Marcus
On Mar 20, 2014, at 10:27 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Mar 19, 2014, at 19:28, pixi...@macports.org wrote:
Revision
118041
Author
pixi...@macports.org
Date
2014-03-19 17:28:20 -0700 (Wed, 19 Mar 2014)
Log Message
databases/mysql56:
- Fix universal build. Closes #42938
- Use the right compiler. Closes #42943
Modified: trunk/dports/databases/mysql56/Portfile (118040 = 118041)
+# Don't allow mysql to set the compiler to g++
+# See
http://bazaar.launchpad.net/~mysql/mysql-server/5.6/revision/4223.1.4
+# See also #42943
+patchfiles-append patch-CMakeLists.txt.diff
+if { (![variant_isset universal] ${build_arch} eq i386) ||
([variant_isset universal] [lsearch ${universal_archs} i386] != -1) } {
+# Disallow clang versions older than the clang version which caused
the problem
+#compiler.blacklist {clang 425}
+
+# Disallow all clang versions
+#compiler.blacklist *clang*
+
+# switch to /usr/bin/gcc and /usr/bin/g++
+# closest to SET(CMAKE_CXX_COMPILER g++) removed in the patchfile
+configure.compiler gcc
+}
“gcc” could be anything — from gcc 4.0 or 4.2 to llvm-gcc to clang, depending
on the Xcode version. Setting configure.compiler to “gcc” is the exact
opposite of using the right compiler. MacPorts shouldn’t even have that as a
value for configure.compiler.
What is the real problem that you’re trying to solve here?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118041] trunk/dports/databases/mysql56
On Mar 20, 2014, at 19:13, Marcus Calhoun-Lopez wrote: I submitted the patch that was committed in r118041. I will try to explain my tortured logic. mysql was already silently using g++ as the C++ compiler for 32-bit builds. Apparently, clang caused a problem at some point (See #42943 for more details). Some possible solutions were: 1) Blacklist clang for 32-bit builds, in which case MacPorts would fallback to llvm-gcc42. Since llvm-gcc42 is not working on Mavericks (#42849), this did not seem like an optimal choice. That must be a new problem. I have llvm-gcc42 installed on Mavericks. 2) For 32-bit builds, blacklist versions of clang in use at the time the problem was first reported. Since there is no guarantee that subsequent version of clang (or mysql) fixed the problem, this also seemed less than ideal. #42943 says the problem was Clang on 32 bit causes non-debug server to crash”. So we should reproduce that problem, then figure out if newer versions of clang fix it. If so, blacklist older clang. If not, blacklist all clang. And also poke the MySQL developers about what they’re planning on doing about this issue. 3) Set configure.compiler gcc” But “gcc” *is* clang as of Xcode 5. If all versions of clang cause the crash, then this is not helping anything. And if this version of clang does not cause this crash, then blacklist older clang. 4) Let mysql continue to use whichever g++ it could find. This is more or less the same as setting configure.compiler gcc At least setting configure.compiler makes the ambiguity obvious. Is that a virtue? Solution 4 seemed to be the lesser of the evils. I hope I did not miss an obvious solution. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that's something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas - feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the haspatch keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread...) MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don't remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts automake and python
David Evans dev...@macports.org writes:
On 3/20/14 3:01 PM, Adam Mercer wrote:
On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch ebori...@macports.org
wrote:
I think the issue here is that automake is getting patched to *only* support
MacPorts-managed builds, but really automake should still be available for
use to build non-MP software.
Agreed, that's one of the main concerns I have with this.
I don't see this as MacPorts specific. Instead it correctly determines
the default PYTHON_PREFIX
for the Python in use. This is a MacPorts path only because you are
using a MacPorts Python port
= 2.5. If you were using a Python that was installed using the
traditional installation path then
this would return ${prefix} as the original did.
For instance using python24 returns /opt/local (which is ${prefix) by
our standard and others as well).
Using /usr/bin/python (Apple build) returns
/System/Library/Frameworks/Python.framework/Versions/2.7
So the original AM_PYTHON_PATH only returns the correct result if the
Python in use is installed in the
'standard' place. Doesn't work any Python installed in a non-standard
place.
Looking at the comments surrounding this code in python.m4 the upstream
authors acknowledge this.
dnl Use the values of $prefix and $exec_prefix for the corresponding
dnl values of PYTHON_PREFIX and PYTHON_EXEC_PREFIX. These are made
dnl distinct variables so they can be overridden if need be. However,
dnl general consensus is that you shouldn't need this ability.
What was broken that needed fixing (by the original change)? Is there a
particular port that needed the change? Is there another way to fix it
without modifying automake?
The answer is yes, any port that uses AM_PYTHON_PATH to discover the
Python install
prefix will fail on MacPorts (or any other installation of Python into a
non-standard path)
without intervention and there are quite a few.
In the past this has been handled typically by applying a similar patch
to the configure file
provided with each project being ported. This works and the patch here
does not interfere
with this because the configure file is not being regenerated.
However, increasingly, ports need to use autoreconf or even autogen.sh
to regenerate configuration
files prior to build for some other reason (intltool perl issues for
instance). This again effects a
large number of ports. In this case, patching of the configure file is
impractical and the required
patch to configure.ac amounts to replacing AM_PYTHON_PATH with custom
code that is often
package specific. This change to automake makes that unnecessary.
Have to head home now but will follow up later this evening. In the
meantime, please don't revert
this change on your own as there are many ports that WILL be broken.
If, we, as a group decide
that that is the preferred approach, I will make the change after the
effected ports have been re-written.
Thanks
PS What ever happened to the doctrine that if you mix code in other
installation prefixes with MacPorts
ports, all bets are off and results are not guaranteed?
That is not the issue here. It is *real* simple, son: ./configure
--prefix=$HOME doesn't work anymore. The change needs to be reverted
immediately and some other workaround provided.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 20, 2014, at 19:21, Eric Gallager wrote: That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread…) Why is a github mirror of the git repository desirable? Why can’t users who want a git version of our repository use the one Mac OS Forge provides? Is it just to help users discover the existence of the repository or what? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
