Re: Addressing Port submission failures on Travis

[Andrew L. Moore]

I’m thinking that rebasing against my GitHub fork of MacPorts is what sent my 
pull request into a tail spin (second question below).  If so, then it appears 
that I need to maintain two MacPorts clones: a private one for rebasing that 
only I see, and another on GitHub for submitting pull requests.  Is there a 
more efficient workflow?
-AM

> On Dec 20, 2017, at 2:22 AM, Andrew L. Moore  wrote:
> 
> Hi,
> A couple weeks ago, I made a couple Port submissions (devel/libwebsockets and 
> net/mosquitto).  Travis is reporting build failures for Xcode 7 and 8.  I 
> don’t, unfortunately, have the resources to easily test on other systems, and 
> the Travis report doesn’t seem to offer much guidance what the issue is, at 
> least that I could see.  How to proceed?
> 
> On a separate note,  I notice that my pull request appears to be tracking my 
> entire macports-ports fork, which includes changes to several other ports.  
> Should I create a new fork for each pull request?
> 
> For reference, here’s what i did:
> 
> * Created a fork of macports-ports on GitHub
> 
> * Cloned that fork to my local system
> 
> * Added  an upstream reference 
> (https://github.com/macports/macports-ports.git)
> 
> * Then to sync with upstream, I use:
> 
>  git fetch upstream
>  git rebase upstream/master
> 
> * And to push to my GitHub fork, I just use:
> 
>  git push
> 
> Got now my pull request appears to have picked up all that activity.  Where 
> did I go wrong?
> -AM
> 
> 

Re: Addressing Port submission failures on Travis

[Joshua Root]

On 2017-12-20 18:22 , Andrew L. Moore wrote:
> Hi,
> A couple weeks ago, I made a couple Port submissions (devel/libwebsockets and 
> net/mosquitto).  Travis is reporting build failures for Xcode 7 and 8.  I 
> don’t, unfortunately, have the resources to easily test on other systems, and 
> the Travis report doesn’t seem to offer much guidance what the issue is, at 
> least that I could see.  How to proceed?

Do you have a link to the Travis log? If there's an actual build
failure, there should be a link to a pastebin with the full log (due to
Travis limits on log size). It may have simply taken longer than Travis
allows (and will say so in that case).

> On a separate note,  I notice that my pull request appears to be tracking my 
> entire macports-ports fork, which includes changes to several other ports.  
> Should I create a new fork for each pull request?

Not a new fork, but a new branch.

> For reference, here’s what i did:
> 
> * Created a fork of macports-ports on GitHub
> 
> * Cloned that fork to my local system
> 
> * Added  an upstream reference 
> (https://github.com/macports/macports-ports.git)
> 
> * Then to sync with upstream, I use:
> 
>   git fetch upstream
>   git rebase upstream/master
> 
> * And to push to my GitHub fork, I just use:
> 
>   git push
> 
> Got now my pull request appears to have picked up all that activity.  Where 
> did I go wrong?

That's all fine as far as it goes. You just need to make a new branch to
hold your work for each PR. After the PR is merged, you can delete the
branch (and the GitHub web UI even has a button for that).

- Josh

Re: I did something stupid and now can't uninstall a port

[Ken Cunningham]

No luck with either -- thanks for suggestion. K

On 2017-12-19, at 6:32 PM, Jeremy Lavergne wrote:

> Just a couple shell things to try:
> 
> Have you tried using single quotes around the portname?
> 
> How about using a double hyphen before portname e.g. `-- portname`?
> 
> On 12/19/2017 08:24 PM, Ken Cunningham wrote:
>> I have a port I'm working on, with a gui subport:
>> 
>> sheepshaver
>> sheepshaver-gui
>> 
>> I accidentally made a typo installing the subport, and I typed this:
>> 
>> sudo port -v install  subport=sheepshaver=gui
>> 
>> 
>> now I have a port installed like this:
>> 
>> $ port -v installed | grep sheep
>> sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
>> date='2017-12-19T16:50:16-0800'
>> 
>> 
>> and I can't uninstall it:
>> 
>> $ sudo port uninstall sheepshaver=gui
>> 
>> (does nothing)
>> 
>> $ sudo port uninstall sheepshaver
>> 
>> (does nothing)
>> 
>> $ port -v installed | grep sheep
>> sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
>> date='2017-12-19T16:50:16-0800'
>> 
>> 
>> I can't seem to uninstall, deactivate, or otherwise work with this port.
>> 
>> If I install sheepshaver, and then try to 
>> 
>> $ sudo port uninstall sheepshaver=gui
>> 
>> it uninstalls sheepshaver, but leaves sheepshaver=gui behind.
>> 
>> Weirdness.
>> 
>> Ken
>> 
> 

Re: I did something stupid and now can't uninstall a port

[Joshua Root]

On 2017-12-20 12:24 , Ken Cunningham wrote:
> I have a port I'm working on, with a gui subport:
> 
> sheepshaver
> sheepshaver-gui
> 
> I accidentally made a typo installing the subport, and I typed this:
> 
> sudo port -v install  subport=sheepshaver=gui
> 
> 
> now I have a port installed like this:
> 
> $ port -v installed | grep sheep
>  sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
> date='2017-12-19T16:50:16-0800'
> 
> 
> and I can't uninstall it:
> 
> $ sudo port uninstall sheepshaver=gui

Well, that's unfortunate. We probably shouldn't allow port names that
parseFullPortSpec doesn't recognise as such. (Or add a syntax to
explicitly specify name,version,revision,variants separately and
unambiguously.)

This particular case at least isn't possible in master any more, since
specifying nonexistent subports causes an error.

If you add the mistake-name to the index, you should be able to select
it for uninstallation with an expression like "installed and
sheepshaver\*". Just need to add

subport sheepshaver=gui {}

to the portfile and run portindex.

- Josh

Re: I did something stupid and now can't uninstall a port

[Jeremy Lavergne]

Just a couple shell things to try:

Have you tried using single quotes around the portname?

How about using a double hyphen before portname e.g. `-- portname`?

On 12/19/2017 08:24 PM, Ken Cunningham wrote:
> I have a port I'm working on, with a gui subport:
> 
> sheepshaver
> sheepshaver-gui
> 
> I accidentally made a typo installing the subport, and I typed this:
> 
> sudo port -v install  subport=sheepshaver=gui
> 
> 
> now I have a port installed like this:
> 
> $ port -v installed | grep sheep
>  sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
> date='2017-12-19T16:50:16-0800'
> 
> 
> and I can't uninstall it:
> 
> $ sudo port uninstall sheepshaver=gui
> 
> (does nothing)
> 
> $ sudo port uninstall sheepshaver
> 
> (does nothing)
> 
> $ port -v installed | grep sheep
>  sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
> date='2017-12-19T16:50:16-0800'
> 
> 
> I can't seem to uninstall, deactivate, or otherwise work with this port.
> 
> If I install sheepshaver, and then try to 
> 
> $ sudo port uninstall sheepshaver=gui
> 
> it uninstalls sheepshaver, but leaves sheepshaver=gui behind.
> 
> Weirdness.
> 
> Ken
> 

I did something stupid and now can't uninstall a port

[Ken Cunningham]

I have a port I'm working on, with a gui subport:

sheepshaver
sheepshaver-gui

I accidentally made a typo installing the subport, and I typed this:

sudo port -v install  subport=sheepshaver=gui


now I have a port installed like this:

$ port -v installed | grep sheep
 sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
date='2017-12-19T16:50:16-0800'


and I can't uninstall it:

$ sudo port uninstall sheepshaver=gui

(does nothing)

$ sudo port uninstall sheepshaver

(does nothing)

$ port -v installed | grep sheep
 sheepshaver=gui @20171215_0 (active) platform='darwin 10' archs='x86_64' 
date='2017-12-19T16:50:16-0800'


I can't seem to uninstall, deactivate, or otherwise work with this port.

If I install sheepshaver, and then try to 

$ sudo port uninstall sheepshaver=gui

it uninstalls sheepshaver, but leaves sheepshaver=gui behind.

Weirdness.

Ken

Patch to upgrade TAO CORBA package

[Thomas G Lockhart]

Hi all. Could someone take a look at issue #55466 to do a significant bump in 
version number for the TAO port? The patch is there and should be good to go 
(though if someone wants to give advice on the daemondo startup scheme that 
would be welcome).

The previous version in the port had unexpected breakage in the server startup 
but I think the new version starts up correctly.

Thanks!

- Tom

Re: ansible replacement by py-ansible

[db]

Is it possible to use pip with git? I couldn't find a portfile using, for 
example, git+https.

https://pip.readthedocs.io/en/latest/reference/pip_install/#vcs-support

Re: How often does the ports web page get rebuilt...

[Ryan Schmidt]

On Dec 19, 2017, at 08:20, Rainer Müller wrote:

> On 2017-12-19 04:39, Perry E. Metzger wrote:
>> I've noticed
>> https://www.macports.org/ports.php
>> doesn't yet reflect some changes I made a few days ago. How often
>> does it get rebuilt?
> 
> At the moment, it is only updated when I run the buildbot job manually
> on my local machine from time to time. The last update was about a month
> ago, but I just started another run.
> 
> The buildbot job has been ready for over a year, but it still was not
> deployed to build.macports.org. Same for updating the website and guide.
> My latest status on this is that we still need a builder to run these
> kind of jobs.
> 
> Maybe we should look into moving these jobs to Travis CI instead...

I would like to deploy this configuration to the buildbot and leave Travis CI 
out of our infrastructure as much as possible, because I don't understand 
anything about it.

Re: trace mode fails with sh: /usr/bin/tar: No such file or directory

[Joshua Root]

On 2017-12-20 01:09 , Rainer Müller wrote:
> On 2017-12-18 00:20, Clemens Lang wrote:
>> We debugged this on IRC recently. Turns out the culprit is
>>   
>> https://github.com/macports/macports-base/commit/3d4c9b342d28abd0b7aaf7eb70fa4862e898542c#diff-94a7b4a6e8f8c93116146f83a92a7f44
>>
>> /usr/bin/tar is a symlink to bsdtar. copyfile(3) copies the symlink, the
>> previous method opened the file (dereferencing the symlink) and copied
>> its contents.
>>
>> When the symlink is copied (because copyfile(3) is used), the
>> destination of the symlink is not copied, which eventually leads to file
>> not found.
> 
> According to the documentation of copyfile(3), it should always follow
> the symlink unless COPYFILE_NOFOLLOW was specified. I even checked its
> implementation [1]. Internally, clonefileat(2) will only be called with
> CLONE_NOFOLLOW when COPYFILE_NOFOLLOW was given – and we do not do that.
> 
> I did a quick test with the following code snippet which should be
> roughly equivalent to what we use in our sip_copy_proc.c:
> 
> ---8<---
> 
> #include 
> #include 
> 
> int main(int argc, char *argv[]) {
> int ret;
> 
> ret = copyfile("/usr/bin/tar", "/tmp/tar", NULL,
>   COPYFILE_ALL | COPYFILE_CLONE);
> if (ret) {
> perror("copyfile");
> return 1;
> }
> 
> return 0;
> }
> 
> --->8---
> 
> I could not reproduce the problem as described on 10.12.6 Sierra. After
> running this program, /tmp/tar is a regular file and contains the same
> contents as /usr/bin/bsdtar.
> 
> I also tested on a VM with 10.13.0 High Sierra, as I still had that
> around. It also works there as expected.
> 
> Does this mean Apple has a regression how copyfile(3) works with
> symlinks on macOS 10.13.2? Can somebody with 10.13.2 please test the
> code above and confirm this?

Yep, looks like it. :(

% ls -l /tmp/tar
lrwxr-xr-x  1 josh  wheel  6  1 Oct 06:07 /tmp/tar -> bsdtar

- Josh

Re: How often does the ports web page get rebuilt...

[Rainer Müller]

On 2017-12-19 04:39, Perry E. Metzger wrote:
> I've noticed
> https://www.macports.org/ports.php
> doesn't yet reflect some changes I made a few days ago. How often
> does it get rebuilt?

At the moment, it is only updated when I run the buildbot job manually
on my local machine from time to time. The last update was about a month
ago, but I just started another run.

The buildbot job has been ready for over a year, but it still was not
deployed to build.macports.org. Same for updating the website and guide.
My latest status on this is that we still need a builder to run these
kind of jobs.

Maybe we should look into moving these jobs to Travis CI instead...

Rainer

Re: how to install php composer?

[Ryan Schmidt]

> On Dec 16, 2017, at 11:45, macpo...@parvis.nl wrote:
> 
> 
> without macports, it should be something like this:
> 
> curl -sS https://getcomposer.org/installer | php
> sudo mv composer.phar /usr/local/bin/composer
> 
> but i am afraid that this way interfers with macports.
> 
> -
> 
> then i found the following:  https://github.com/sjorek/MacPorts-PHP
> 
> it looks it works like a local port installation.
> 
> as this isnt a formal port i think i cannot create a ticket.
> 
> this is what happens:
> 
> # port install composer composer-php56 composer-select +iconv +openssl
> --->  Cleaning composer
> --->  Computing dependencies for composer-php56
> --->  Building composer-php56
> Error: Failed to build composer-php56:
> Warning: PHP Startup: Unable to load dynamic library 
> '/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gd.so' - 
> dlopen(/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gd.so, 9): 
> image not found in Unknown on line 0
> 
> Warning: PHP Startup: Unable to load dynamic library 
> '/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gdchart.so' - 
> dlopen(/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gdchart.so, 
> 9): image not found in Unknown on line 0
> All settings correct for using Composer
> PHP Warning:  PHP Startup: Unable to load dynamic library 
> '/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gd.so' - 
> dlopen(/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gd.so, 9): 
> image not found in Unknown on line 0
> PHP Warning:  PHP Startup: Unable to load dynamic library 
> '/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gdchart.so' - 
> dlopen(/opt/local/lib/php56/extensions/no-debug-non-zts-20131226/gdchart.so, 
> 9): image not found in Unknown on line 0
> Error: See 
> /opt/local/var/macports/logs/_Users_paul_Develop_macports_MacPorts-PHP_php_composer/composer-php56/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port composer-php56 failed
> 
> so it probably isnt the right way too.
> 
> -
> 
> could anybody please tell me the right way to install/use php composer with 
> macports ?

The simple answer is: PHP composer is not in MacPorts. If you want it in 
MacPorts, file a ticket in our issue tracker.

Since someone has already created a separate ports repository on GitHub, you 
might ask them why they did that, and if they would consider instead submitting 
their ports to our official ports collection.

Re: [macports-ports] 02/02: fix maintainer line

[Rainer Müller]

On 2017-12-17 01:55, Perry E. Metzger wrote:
> On Sat, 16 Dec 2017 18:19:39 -0600 Ryan Schmidt
>  wrote:
>>> -maintainers {@pmetzger piermont.com:perry} openmaintainer
>>> +maintainers pmetzger openmaintainer  
>>
>> We want maintainers to list both their MacPorts handle and their
>> GitHub handle, so ideally you would write:
>>
>> maintainers {pmetzger @pmetzger} openmaintainer
> 
> Is that needed even if they're the same?

Yes. Unfortunately we do not have any shorter syntax if the GitHub
username and the MacPorts email address are the same.

I guess we just did not think of this case when designing the new
maintainer syntax, although it is very common...

Rainer

Re: trace mode fails with sh: /usr/bin/tar: No such file or directory

[Rainer Müller]

On 2017-12-18 00:20, Clemens Lang wrote:
> We debugged this on IRC recently. Turns out the culprit is
>   
> https://github.com/macports/macports-base/commit/3d4c9b342d28abd0b7aaf7eb70fa4862e898542c#diff-94a7b4a6e8f8c93116146f83a92a7f44
> 
> /usr/bin/tar is a symlink to bsdtar. copyfile(3) copies the symlink, the
> previous method opened the file (dereferencing the symlink) and copied
> its contents.
> 
> When the symlink is copied (because copyfile(3) is used), the
> destination of the symlink is not copied, which eventually leads to file
> not found.

According to the documentation of copyfile(3), it should always follow
the symlink unless COPYFILE_NOFOLLOW was specified. I even checked its
implementation [1]. Internally, clonefileat(2) will only be called with
CLONE_NOFOLLOW when COPYFILE_NOFOLLOW was given – and we do not do that.

I did a quick test with the following code snippet which should be
roughly equivalent to what we use in our sip_copy_proc.c:

---8<---

#include 
#include 

int main(int argc, char *argv[]) {
int ret;

ret = copyfile("/usr/bin/tar", "/tmp/tar", NULL,
  COPYFILE_ALL | COPYFILE_CLONE);
if (ret) {
perror("copyfile");
return 1;
}

return 0;
}

--->8---

I could not reproduce the problem as described on 10.12.6 Sierra. After
running this program, /tmp/tar is a regular file and contains the same
contents as /usr/bin/bsdtar.

I also tested on a VM with 10.13.0 High Sierra, as I still had that
around. It also works there as expected.

Does this mean Apple has a regression how copyfile(3) works with
symlinks on macOS 10.13.2? Can somebody with 10.13.2 please test the
code above and confirm this?

Rainer

[1] https://opensource.apple.com/source/copyfile/

Re: Installing a Python wheel (whl) file using a port - Tensorflow

[Joshua Root]

On 2017-12-19 09:16 , Enrico Maria Crisostomo wrote:
> Ah ok, I saw this. If I understand it correctly it's a subset of it.
> I've also tried to build it from source but I'm not sure at all I would
> solve the primary issue: according to the official documentation, the
> output of the build is the whl file:
> 
> https://www.tensorflow.org/install/install_sources
> 
> So, even if we update the port to build from source, we end up exactly
> with the same issue: how to install the whl file.
> 
> Or perhaps my Python-foo is so weak I'm not seeing something obvious.

This is indeed an unusual situation; most packages on PyPI have a source
archive that can be built with 'python setup.py install'. The python
portgroup has no support for installing from wheels. As you found, the
first complication there is that there is no longer just one distfile…

If you have to install a wheel, pip is the tool for doing that. Whether
you have to in this case is another question.

I haven't tried it, but I wouldn't think their build system would
produce *only* a wheel. The files that go into the wheel would probably
be there in some build directory too. It looks like building from source
has its own complications though. You need Bazel, which needs JDK 8. You
also need the CUDA SDK for Nvidia GPU support.

- Josh

Re: Adding dependencies using qt5 portgroup

[Ryan Schmidt]

On Dec 14, 2017, at 19:02, Ryan Schmidt wrote:

> I understand that when I'm using the qt5 portgroup and I want to add a 
> library dependency on a Qt component, I should use qt5.depends_component 
> instead of depends_lib-append, and that when I want to add a build dependency 
> I should use qt5.depends_build_component instead of depends_build-append.
> 
> I'm trying to make those changes in the QupZilla port, but I currently add a 
> runtime dependency on qt5-sqlite-plugin. I don't see a way in the qt5 
> portgroup to add a runtime dependency on a Qt component. What should I do?

Any guidance on this?

Re: New ocaml category?

[Ryan Schmidt]

On Dec 16, 2017, at 19:36, Perry E. Metzger wrote:

> There are currently over 300 ocaml packages in devel/
> 
> I would like to create a new "ocaml" category and move them all into
> a top level "ocaml" directory.
> 
> Questions:
> 
> 0) If I am not mistaken, all that needs to be done to create the new
> category is to create the "ocaml" directory. Is there any file
> etc. that needs updating?

Right, you only need to create the directory, move the portfile directories 
into it, and update the categories line in those portfile. There is no separate 
file that lists categories.

> 1) I believe it would be appropriate to do the move with a single git
> commit. Is this correct?

Yes, a single commit would be good.

> 2) Should I explicitly add the "ocaml" category to the categories line
> of all these packages at the same time? Or should that be a distinct
> commit?

I would do it in the same commit.

> 3) Many of the packages list themselves as being in an "ml"
> category. Given that OCaml really isn't standard ML at all, I'm
> thinking of removing that category from them. Is that okay?

Needs someone with knowledge of these ports to make that decision. Sounds like 
you're that person! So go ahead with what you think is best.

Re: help needed with figuring out an odd github source URL

[Ryan Schmidt]

On Dec 16, 2017, at 18:05, Perry E. Metzger wrote:

> Coq has moved to github for releases, and the form of the release
> url I need to produce is:
> 
>   https://github.com/coq/coq/archive/V8.7.1.tar.gz
> 
> What "github.setup" magic do I need for this?
> 
> If I do
> 
>   github.setupcoq coq 8.7.1
> 
> it tries to get https://github.com/coq/coq/tarball/8.7.1/coq-8.7.1.tar.gz
> which isn't what I need.
> 
> (And I wish I understood the github portgroup stuff better. :( )

The github portgroup documents itself fairly well in comments; read them. 
Someone has also recently converted those comments into proper guide markup; 
it's in the pull requests but I don't think it's been merged yet.

The github portgroup does not support archive URLs. See 
https://trac.macports.org/ticket/40518. If you can think of a reason why it 
should, please let me know. Until then, allow the portgroup to use the tarball 
URL.

Yes, the portgroup handles livecheck for you.