Re: Port and patch submissions via ticket vs. via PR.

[Ryan Schmidt]

On Apr 4, 2018, at 07:18, Mojca Miklavec wrote:

>>> Also, Mojca brought the question of the hundreds of open tickets with
>>> port submissions a while back. It might be neat if we had some code
>>> that caused a special Github account to generate a PR for a port
>>> submission in trac. I wouldn't want this automatically invoked (at
>>> least not yet!), but if a human (like me!) could manually invoke it on
>>> a few ports at a time when they had free time, it might help to
>>> clear out the backlog.
>> 
>> In my experience, port submissions, especially by new contributors, require 
>> more cleanup than port updates. It's not uncommon for a submission to have 
>> half a dozen or more things wrong with it. So you could either develop an 
>> automated system for copying a Portfile submitted on Trac into a pull 
>> request -- and then have to check out that PR branch into your git clone, 
>> fix all the problems, amend the commit, force push it -- or you could just 
>> download the Portfile from Trac yourself, put it into your git clone, fix 
>> it, commit it, and either send a PR or push to master. And either way, 
>> you're going to want to make sure it builds locally first. It doesn't seem 
>> like the former saves you that much time over the latter, plus of course 
>> you've had to spend all that time developing the automated Trac-to-PR system.
> 
> The time saved comes from the author doing the cleanup based on
> feedback (which you can leave while waiting for a bus or while going
> for a walk :) vs. one of us having to do all the changes, fiddling
> with branches.

Fiddling with branches only becomes necessary if we implement this Trac-to-PR 
plan! Fiddling with branches wasn't necessary when we committed to our old 
Subversion repository, and it's not necessary if a committer just downloads the 
patches from Trac into their Git clone of macports-ports, fixes the port, and 
commits it to master.


> In my opinion we should:
> (a) create a page (either or Trac or on GitHub) explaining benefits of
> Pull requests (+ excuse for the delay processing trac tickets)

It should be in the guide, along with our other documentation.

> (b) leave a comment on all submission tickets pointing to that page (I
> guess this can be done automatically)
> 
> I expect some 10-20% of those submissions to be turned into pull
> requests by original authors, but that's already a lot. If we end up
> with 20 submissions one day, I don't mind going over all the twenty of
> them manually, but this is "hopeless" with hundreds of them.
> 
> Alternatively / in addition, what we currently lack is a page
> explaining how random unskilled users willing to spend some time
> helping us could do. If we were able to communicate clearly what such
> users can do when they just feel like helping us, this could be one of
> the suitable tasks. (Other tasks include fixing ports with wrong
> checksums after github switch their algorithm etc.)

How would an automated Trac-to-PR tool write a good commit message? If we're 
just talking about submissions, maybe that's easier. But what if the ticket 
contains multiple revisions of the Portfile? Trac automatically appends a 
number to the file if that filename has already been used, unless the attacher 
clicks the "Replace existing attachment of the same name" checkbox. What about 
multiple patchfiles? Multiple revisions of multiple patchfiles? What if some 
patchfiles became unnecessary during the development of the ticket?

I'm dubious of the quality of some of the submissions in Trac. Certainly some 
are good and have simply been forgotten. But I feel like many have had reviews 
already posted, and the required changes have not been made. Creating a PR for 
the incomplete work would disassociate the work from the existing reviews. 
Would you remember to click the link for each auto-created PR to see what 
existing discussion had occurred? Would repeating that feedback in the PR have 
any effect -- if the submitter ignored it originally, why will posting it again 
in a PR make them respond to it now?

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Ryan Schmidt]

On Apr 4, 2018, at 11:59, Rainer Müller wrote:

> On 2018-04-04 17:19, Rainer Müller wrote:
>> Now that we execute the mirror step before attempting a build, we should
>> make the buildbot use a master_site_local pointing to a local mirror, as
>> we cannot expect the upload to be completed at the time the build runs.
>> Right now we are downloading all files twice.
> 
> I split the fetch phase into a separate command. This should make it
> easier to see that the dependency failed because it was unable to fetch
> the distfiles.
> 
> https://github.com/macports/mpbb/commit/639def5ad990ecf1e227e377e5a46124c447ca94
> 
> This will also no longer update the failcache, as fetching could be a
> temporary problem.

Thanks!


> This should also remedy the situation on legacy systems for now.
> Installation as a dependency will be retried even if a previous run
> failed due to fetching. By that time, the distfile was hopefully
> uploaded to the mirror.
> 
> We should still investigate in adding a master_site_local, as this
> involves more fetches from the internet than necessary at the moment.

The buildbot has always fetched from the local private distfiles mirror. I 
didn't know about master_site_local, so I accomplished this by having 
distfiles.macports.org, packages.macports.org and rsync.macports.org resolve to 
the local mirror's IP on the network that the build machines are on.

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Andrew Moore]

> On Apr 4, 2018, at 12:18 PM, Mojca Miklavec  wrote
> It also failed on 10.7 and 10.8.

That’s more a problem with my eyes :). 

> I triggered new builds of mosquitto now that libpsl has been built on
> all systems.

Okay, so no buildbot notifications since then.  Not being familiar with 
buildbot, I’m curious if there’s an easy way to confirm a successful build?  If 
I go to, for instance, https://build.macports.org/console, the format looks 
promising, but the content is limited.  Google doesn’t seem to help either, 
e.g., searching `mosquitto site:build.macports.org’ produces no results, which 
begs another question:  would it be possible/worthwhile to make 
build.macports.org “search-engine optimized”?
-AM

Re: Changing default cxx_stdlib to libc++

[Ryan Schmidt]

On Apr 3, 2018, at 21:27, Andrew Moore wrote:

> With Apple now planning to phase out Server.app, might they be open to 
> supporting MacPorts once again?  Going forward, I would hope they recognize a 
> vested interest in seeing that the open-source community continues to support 
> them…

As you know, Apple divested themselves of their responsibility for MacPorts, by 
hiring me for one year to be the macOS forge administrator and to plan the 
transition away from Apple infrastructure, which was completed in November 
2016. Apple has not contacted us since then to indicate any desire to 
re-involve themselves. Individual Apple employees continue to contribute to 
MacPorts development as their time and interests permit. It is possible that 
Apple or other companies who value MacPorts might want to contribute 
financially, but MacPorts is not currently set up as a legal entity, so we do 
not currently accept financial donations.

Re: [macports-ports] branch master updated: gdal: enable sqlite3 and spatialite support by default

[Ryan Schmidt]

On Apr 4, 2018, at 07:46, Vincent wrote:

> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/868fe5bdde5d2d59389663dbb33af319cec4126f
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 868fe5b  gdal: enable sqlite3 and spatialite support by default
> 
> 868fe5b is described below
> 
> 
> commit 868fe5bdde5d2d59389663dbb33af319cec4126f
> 
> Author: Veence
> AuthorDate: Wed Apr 4 14:46:10 2018 +0200
> 
> 
> gdal: enable sqlite3 and spatialite support by default

This changes what gets installed, so the revision must be increased. I've done 
that now:

https://github.com/macports/macports-ports/commit/8b26fdca8cb56de5d0c162dcd22056526caecbea

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Ryan Schmidt]

On Apr 4, 2018, at 21:25, Andrew Moore wrote:

> On Apr 4, 2018, at 12:18 PM, Mojca Miklavec wrote
>> It also failed on 10.7 and 10.8.
> 
> That’s more a problem with my eyes :). 
> 
>> I triggered new builds of mosquitto now that libpsl has been built on
>> all systems.
> 
> Okay, so no buildbot notifications since then.  Not being familiar with 
> buildbot, I’m curious if there’s an easy way to confirm a successful build?  
> If I go to, for instance, https://build.macports.org/console, the format 
> looks promising, but the content is limited.  Google doesn’t seem to help 
> either, e.g., searching `mosquitto site:build.macports.org’ produces no 
> results, which begs another question:  would it be possible/worthwhile to 
> make build.macports.org “search-engine optimized”?

It is a proposed Google Summer of Code project this year to create a new 
MacPorts web site with a better view onto this data.

https://trac.macports.org/wiki/SummerOfCode#build-stats

Re: MySQL 5.7 fails to build

[Ryan Schmidt]

On Apr 4, 2018, at 04:17, Bjarne D Mathiesen wrote:

> Craig Treleaven wrote:
>>> The main.log file is here : http://www.mathiesen.info/macports
>> 
>> The log shows the following:
>> 
>> :info:build 
>> /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql57/mysql57/work/mysql-5.7.17/sql/item_geofunc_internal.cc:37:63:
>>  error: no type named 'self_ip_exception' in namespace 
>> 'boost::geometry::detail::self_get_turn_points'
>> :info:build   catch (const 
>> boost::geometry::detail::self_get_turn_points::self_ip_exception &)
>> :info:build~~~^
>> 
>> I don’t have time to dig a lot further but I wonder if the issue is related 
>> to the bundled copy of boost 1.59 in the mysql57 port?

>> Also, I note the following open ticket:
>> 
>> https://trac.macports.org/ticket/55238
>> 
>> I haven’t looked into it to see if it is a similar issue.
> 
> I'm simply not proficient in reading log files; but I'll supplement my
> experience to that bug

That ticket doesn't seem to have anything to do with the problem you're 
experiencing. I'd file a new ticket instead.

Re: jmol haspatch maintainer - please commit #56106

[Ryan Schmidt]

On Apr 3, 2018, at 11:40, Peter Brommer wrote:

> Does trac remain in use for “proper” bug reports?

Yes, Trac is still our bug tracker.

Re: Port and patch submissions via ticket vs. via PR.

[Ryan Schmidt]

On Apr 1, 2018, at 11:02, Perry E. Metzger wrote:

> As some of you have noticed, I've been trying to keep the PR queue
> relatively clear.

Thanks very much for that!


> I'm wondering if we should therefore encourage people to submit github
> PRs if they have working patches (or are submitting new ports) rather
> than trac tickets. (Not suggesting we should _prevent_ the latter,
> just that maybe we should explicitly encourage the former.)

Yes, I think encouraging PRs instead of ticket attachments, when the submitter 
already has specific changes in mind, would be a good idea.


> Also, Mojca brought the question of the hundreds of open tickets with
> port submissions a while back. It might be neat if we had some code
> that caused a special Github account to generate a PR for a port
> submission in trac. I wouldn't want this automatically invoked (at
> least not yet!), but if a human (like me!) could manually invoke it on
> a few ports at a time when they had free time, it might help to
> clear out the backlog.

In my experience, port submissions, especially by new contributors, require 
more cleanup than port updates. It's not uncommon for a submission to have half 
a dozen or more things wrong with it. So you could either develop an automated 
system for copying a Portfile submitted on Trac into a pull request -- and then 
have to check out that PR branch into your git clone, fix all the problems, 
amend the commit, force push it -- or you could just download the Portfile from 
Trac yourself, put it into your git clone, fix it, commit it, and either send a 
PR or push to master. And either way, you're going to want to make sure it 
builds locally first. It doesn't seem like the former saves you that much time 
over the latter, plus of course you've had to spend all that time developing 
the automated Trac-to-PR system.

Re: Include file search path problem building py-grpcio with setuptools

[Enrico Maria Crisostomo]

> On 2 Apr 2018, at 19:50, Joshua Root  wrote:
> 
> On 2018-4-3 02:12 , Enrico Maria Crisostomo wrote:
>> How is the compiler include file search path set up in this case?  The 
>> /opt/local/include/openssl path should come from MacPorts, but I don't know 
>> where it's set and how I can override it.
> 
> It's not: src/boringssl/err_data.c says #include . So
> apparently it's putting -I/opt/local/include before its internal
> boringssl include path.
> 
> MacPorts normally passes -I${prefix}/include in CPPFLAGS, but that's not
> done for setup.py builds. Perhaps it comes from python, though the only
> place -I flags occur in sysconfig are the CPPFLAGS and PY_CFLAGS
> variables, which I don't think are normally used by distutils. But I
> could be wrong. I guess that leaves cython or some other dependency?
> 
> - Josh

Thank you very much Joshua.

BTW, I just discovered Google Mail was sending your mails into the spam folder. 
 I hope it's fixed now.

Thank you for the overview.  Yes, I also think it's cython.  I'm still 
inspecting the build files though: I'll bump this thread.

Re: Port and patch submissions via ticket vs. via PR.

[Mojca Miklavec]

(I noticed that my previous email was flying to some strange address.
I'm sorry if this is the second post, I cannot see the other one in
mail archive, so I'm not sure if it went through.)

On 4 April 2018 at 16:28, Jonathan Stickel wrote:
>
> Some instructions about
> recommended procedures for pull requests would be helpful to me to
> transition to that approach. If anything already exists, please point me to
> it!

I'm not sure if we have written anything. This is upstream documentation:

https://help.github.com/articles/creating-a-pull-request/

Now that I read what I wrote below it sounds more complicated than it
actually is.


The basic idea is that:

- You need an account on GitHub, make sure you add your ssh public key there
  (if you use website for editing, your primary email set there will
appear as commit author)
- Log in to GitHub, fork https://github.com/macports/macports-ports
- (You might want to delete any branch in your  fork that's not
"master", but that's optional)

- Clone repo to your machine:
git clone g...@github.com:macports/macports-ports.git
git remote add some-easy-name
g...@github.com:your-username/macports-ports.git
the name of remote can be changed in .git/config.

- It might help to use that git checkout as the main source specified in
/opt/local/etc/macports/sources.conf

- Then try to remember not to ever commit to the master branch, but
always use a separate branch for each pull request.
# each time before changing anything make sure you have everything
up to date
git fetch --all # optional
git checkout master # make sure you switch to master branch
git pull origin master [--rebase] # update, you don't need rebase
if you don't pollute your master

# make the edits, do all the testing
git branch update-2.19 # create a branch
git checkout update-2.19 # switch to that branch (you may combine
these two steps)
git add path/to/Portfile
git commit # write commit message
git push some-easy-name # use same name as above; this will push
the changes to your fork

- Usually, when you navigate back to
https://github.com/macports/macports-ports you will see a yellow box
asking you if you want to open a pull request.

There are a few other useful commands:
git commit --amend # to make changes to last commit
git push -f some-easy-name # will force-push changes to the PR in
case you fix existing commits
git rebase -i HEAD~N # where N is the number of the last few
commits you want to change

If you opened a pull request which takes a long time to merge for one
reason or another and you want to bring that branch in sync with
master, it's
git checkout update-2.19
git rebase master
Then you'll have the latest version from master with that commit with
update on top.

Mojca

Re: Port and patch submissions via ticket vs. via PR.

[Mark Anderson]

I like the idea of a trac to PR script or something to make things easier.
The github API is pretty easy to use, but I’m not a trac expert by any
means. That said, I’d be willing to help.

—Mark

On Wed, Apr 4, 2018 at 8:18 AM Mojca Miklavec  wrote:

> On 4 April 2018 at 13:15, Ryan Schmidt wrote:
> > On Apr 1, 2018, at 11:02, Perry E. Metzger wrote:
> >
> >> As some of you have noticed, I've been trying to keep the PR queue
> >> relatively clear.
> >
> > Thanks very much for that!
>
> Indeed. What you are doing is simply amazing.
>
> >> Also, Mojca brought the question of the hundreds of open tickets with
> >> port submissions a while back. It might be neat if we had some code
> >> that caused a special Github account to generate a PR for a port
> >> submission in trac. I wouldn't want this automatically invoked (at
> >> least not yet!), but if a human (like me!) could manually invoke it on
> >> a few ports at a time when they had free time, it might help to
> >> clear out the backlog.
> >
> > In my experience, port submissions, especially by new contributors,
> require more cleanup than port updates. It's not uncommon for a submission
> to have half a dozen or more things wrong with it. So you could either
> develop an automated system for copying a Portfile submitted on Trac into a
> pull request -- and then have to check out that PR branch into your git
> clone, fix all the problems, amend the commit, force push it -- or you
> could just download the Portfile from Trac yourself, put it into your git
> clone, fix it, commit it, and either send a PR or push to master. And
> either way, you're going to want to make sure it builds locally first. It
> doesn't seem like the former saves you that much time over the latter, plus
> of course you've had to spend all that time developing the automated
> Trac-to-PR system.
>
> The time saved comes from the author doing the cleanup based on
> feedback (which you can leave while waiting for a bus or while going
> for a walk :) vs. one of us having to do all the changes, fiddling
> with branches.
>
> In my opinion we should:
> (a) create a page (either or Trac or on GitHub) explaining benefits of
> Pull requests (+ excuse for the delay processing trac tickets)
> (b) leave a comment on all submission tickets pointing to that page (I
> guess this can be done automatically)
>
> I expect some 10-20% of those submissions to be turned into pull
> requests by original authors, but that's already a lot. If we end up
> with 20 submissions one day, I don't mind going over all the twenty of
> them manually, but this is "hopeless" with hundreds of them.
>
> Alternatively / in addition, what we currently lack is a page
> explaining how random unskilled users willing to spend some time
> helping us could do. If we were able to communicate clearly what such
> users can do when they just feel like helping us, this could be one of
> the suitable tasks. (Other tasks include fixing ports with wrong
> checksums after github switch their algorithm etc.)
>
> The pull request queue is now amazingly short. Cutting down all other
> queues one by one could be our next goal.
>
> Mojca
>
-- 
Sent from Gmail Mobile on iPhone

Using qt59 instead of qt5 (latest release)

[Vincent Habchi]

Hi there,

I recently wanted to experiment with linking one of the ports I maintain 
(Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the 
glitches and crashes everyone experiences with that application. 

However, in order to do so, I’d have to rebuild several dependents such as 
py36-qt5 or qwt-qt5 (inter alia). Are those able to deal with a Qt5 version 
other than the last one?

TIA,
Vincent

Re: Using qt59 instead of qt5 (latest release)

[Craig Treleaven]

> On Apr 4, 2018, at 9:54 AM, Vincent Habchi  wrote:
> 
> Hey Craig,
> 
>> I am considering a similar move for mythtv.28.  
> 
> […]
> 
> Thanks for that useful info. French has a saying which goes like this (more 
> or less, it’s difficult to translate): “The best is oftentimes the good’s 
> enemy”.
> In any case, yeah, I suppose this will mean at least writing variants. What I 
> am more weary of is py-qt5. I hope the latest version is backwards compatible 
> with earlier releases of Qt5.
> 
> Probably going to do that later in the week.
> 

I was wondering if the Qt5 portgroup could be modified so that dependent ports 
don’t automatically upgrade to the absolute latest version of Qt 5.  Just 
spitballing, but what if the portgroup had a directive like:

prefer_QT5_version -1

If the currently released version is 5.10, this would indicate that we want to 
use 5.9.  When 5.11 is released, presumably 5.10 would be mature enough that it 
would be safe to upgrade to it.

Or perhaps:

prefer_Qt5_LTS_version [-1]

Qt 5.9 is the current long term support version and Qt 5.6 is the previous LTS. 
 

Thoughts?  Are most Qt5-dependent ports happy to keep up to the latest Qt 
release?  It appears to be a concern for Vincent and myself.

Craig

Re: Using qt59 instead of qt5 (latest release)

[Vincent Habchi]

Hey Craig,

> I am considering a similar move for mythtv.28.  

[…]

Thanks for that useful info. French has a saying which goes like this (more or 
less, it’s difficult to translate): “The best is oftentimes the good’s enemy”.
In any case, yeah, I suppose this will mean at least writing variants. What I 
am more weary of is py-qt5. I hope the latest version is backwards compatible 
with earlier releases of Qt5.

Probably going to do that later in the week.

Once again, thanks for chiming in.

Have a great day!
Vincent

Re: Port and patch submissions via ticket vs. via PR.

[Mojca Miklavec]

On 4 April 2018 at 13:15, Ryan Schmidt wrote:
> On Apr 1, 2018, at 11:02, Perry E. Metzger wrote:
>
>> As some of you have noticed, I've been trying to keep the PR queue
>> relatively clear.
>
> Thanks very much for that!

Indeed. What you are doing is simply amazing.

>> Also, Mojca brought the question of the hundreds of open tickets with
>> port submissions a while back. It might be neat if we had some code
>> that caused a special Github account to generate a PR for a port
>> submission in trac. I wouldn't want this automatically invoked (at
>> least not yet!), but if a human (like me!) could manually invoke it on
>> a few ports at a time when they had free time, it might help to
>> clear out the backlog.
>
> In my experience, port submissions, especially by new contributors, require 
> more cleanup than port updates. It's not uncommon for a submission to have 
> half a dozen or more things wrong with it. So you could either develop an 
> automated system for copying a Portfile submitted on Trac into a pull request 
> -- and then have to check out that PR branch into your git clone, fix all the 
> problems, amend the commit, force push it -- or you could just download the 
> Portfile from Trac yourself, put it into your git clone, fix it, commit it, 
> and either send a PR or push to master. And either way, you're going to want 
> to make sure it builds locally first. It doesn't seem like the former saves 
> you that much time over the latter, plus of course you've had to spend all 
> that time developing the automated Trac-to-PR system.

The time saved comes from the author doing the cleanup based on
feedback (which you can leave while waiting for a bus or while going
for a walk :) vs. one of us having to do all the changes, fiddling
with branches.

In my opinion we should:
(a) create a page (either or Trac or on GitHub) explaining benefits of
Pull requests (+ excuse for the delay processing trac tickets)
(b) leave a comment on all submission tickets pointing to that page (I
guess this can be done automatically)

I expect some 10-20% of those submissions to be turned into pull
requests by original authors, but that's already a lot. If we end up
with 20 submissions one day, I don't mind going over all the twenty of
them manually, but this is "hopeless" with hundreds of them.

Alternatively / in addition, what we currently lack is a page
explaining how random unskilled users willing to spend some time
helping us could do. If we were able to communicate clearly what such
users can do when they just feel like helping us, this could be one of
the suitable tasks. (Other tasks include fixing ports with wrong
checksums after github switch their algorithm etc.)

The pull request queue is now amazingly short. Cutting down all other
queues one by one could be our next goal.

Mojca

Re: Using qt59 instead of qt5 (latest release)

[Craig Treleaven]

> On Apr 4, 2018, at 8:33 AM, Vincent Habchi  wrote:
> 
> Hi there,
> 
> I recently wanted to experiment with linking one of the ports I maintain 
> (Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the 
> glitches and crashes everyone experiences with that application. 
> 
> However, in order to do so, I’d have to rebuild several dependents such as 
> py36-qt5 or qwt-qt5 (inter alia). Are those able to deal with a Qt5 version 
> other than the last one?
> 

I am considering a similar move for mythtv.28.  

Looking at qwt-qt5, I think you’re going to have a problem.  As the port now 
stands, it does not appear to support any Qt5 versions other than the latest:

$ port info qwt-qt5
qwt-qt5 @6.1.3_2 (graphics, science)
Sub-ports:qwt-qt5-examples
…
Library Dependencies: qt5-qtbase, qt5-qtsvg, qt5-qttools
…

Another issue is Qt5 v. macOS versions.  When I last looked, a couple of months 
ago, it appears that Qt 5 has NO official support for macOS 10.13.  Has that 
changed?

Qt 5.7 and 5.8 were no longer officially supported.

Qt 5.6 is supported until next March (2019) but not on macOS 10.12 or later.

Qt 5.9 is supported until 2020 on 10.10, 10.11 and 10.12.  

I don’t follow the Qt5 project that closely; I don’t know what the practical 
implications of “official support’ really are.  It certainly appears that 
various versions of Qt5 “work” on High Sierra.  OTOH, I think there are 
interface problems with MythTV under Qt 5.10.  I hope these will go away by 
rolling back to, say Qt 5.6.  

BTW, out of about 2,900 MythTV Linux systems using Qt5 (in their voluntary 
reporting system), nearly 2,200 are running Qt 5.5.  Another 300 are running Qt 
5.7.  Only 3 are running Qt 5.10.  A further 1,000 users are still running 
older versions of Myth that require Qt 4.

Craig

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Rainer Müller]

On 2018-04-04 16:36, Andrew Moore wrote:
> If I’m reading correctly the attached report from build...@macports.org
> , port net/mosquitto fails for OS X <=
> 10.6 due to indirect dependency: libpsl.  If so, this is presumably a
> known issue, since many ports depend upon libpsl?

The failed libpsl build is this one (you can find it in the log of the
install-dependencies step). The build failed because libpsl cannot be
fetched on systems that do not support modern TLS protocol versions.
This is a well known problem.

https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/61220

Now that we execute the mirror step before attempting a build, we should
make the buildbot use a master_site_local pointing to a local mirror, as
we cannot expect the upload to be completed at the time the build runs.
Right now we are downloading all files twice.

Rainer

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Andrew Moore]

If I’m reading correctly the attached report from build...@macports.org, port 
net/mosquitto fails for OS X <= 10.6 due to indirect dependency: libpsl.  If 
so, this is presumably a known issue, since many ports depend upon libpsl?

I don’t have the time or resources to debug the issue on legacy systems at the 
moment.  What to do?  Thank you!
-AM

> Begin forwarded message:
> 
> From: build...@macports.org
> Subject: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto
> Date: April 3, 2018 at 10:05:42 AM EDT
> To: slew...@gmail.com
> Cc: macports-bui...@lists.macports.org
> Reply-To: nore...@macports.org
> 
> Status:   Failure
> Build slave:  ports-10.6_x86_64_legacy
> Full logs:
> https://build.macports.org/builders/ports-10.6_x86_64_legacy-watcher/builds/13869
> Build reason: The SingleBranchScheduler scheduler named 'ports' triggered 
> this build
> Port list:mosquitto
> Subport list:
>   - mosquitto
> Variants: None
> Revision: 7099171b51ebc15193f167486955d9f60e13baa4
> Build time:   0:04:24
> Author:   Andrew L. Moore 
> 
> Log from failed builds:
>   Building 'mosquitto' ... [ERROR] (failed to install dependency 'libpsl')
>   > maintainers: slew...@gmail.com.
> 
> Broken ports:
>   - libpsl
>   - mosquitto
> 
> Responsible maintainers:
>   - slew...@gmail.com
> 
> Links to individual build jobs:
> - jobs-mirror #6592
>  https://build.macports.org/builders/jobs-mirror/builds/6592
> 
> -- 
> Best regards,
> MacPorts Buildbot
> https://build.macports.org/
> 

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Ken Cunningham]

You're not expected to fix it.

It would be nice perhaps to make a ticket about it if you like, so someone who 
uses that OS cersion might dig in.

Best, Ken

> On Apr 4, 2018, at 07:36, Andrew Moore  wrote:
> 
> If I’m reading correctly the attached report from build...@macports.org, port 
> net/mosquitto fails for OS X <= 10.6 due to indirect dependency: libpsl.  If 
> so, this is presumably a known issue, since many ports depend upon libpsl?
> 
> I don’t have the time or resources to debug the issue on legacy systems at 
> the moment.  What to do?  Thank you!
> -AM
> 
>> Begin forwarded message:
>> 
>> From: build...@macports.org
>> Subject: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto
>> Date: April 3, 2018 at 10:05:42 AM EDT
>> To: slew...@gmail.com
>> Cc: macports-bui...@lists.macports.org
>> Reply-To: nore...@macports.org
>> 
>> Status:   Failure
>> Build slave:  ports-10.6_x86_64_legacy
>> Full logs:
>> https://build.macports.org/builders/ports-10.6_x86_64_legacy-watcher/builds/13869
>> Build reason: The SingleBranchScheduler scheduler named 'ports' triggered 
>> this build
>> Port list:mosquitto
>> Subport list:
>>  - mosquitto
>> Variants: None
>> Revision: 7099171b51ebc15193f167486955d9f60e13baa4
>> Build time:   0:04:24
>> Author:   Andrew L. Moore 
>> 
>> Log from failed builds:
>>  Building 'mosquitto' ... [ERROR] (failed to install dependency 'libpsl')
>>  > maintainers: slew...@gmail.com.
>> 
>> Broken ports:
>>  - libpsl
>>  - mosquitto
>> 
>> Responsible maintainers:
>>  - slew...@gmail.com
>> 
>> Links to individual build jobs:
>> - jobs-mirror #6592
>>  https://build.macports.org/builders/jobs-mirror/builds/6592
>> 
>> -- 
>> Best regards,
>> MacPorts Buildbot
>> https://build.macports.org/
>> 
> 

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Rainer Müller]

On 2018-04-04 17:19, Rainer Müller wrote:
> Now that we execute the mirror step before attempting a build, we should
> make the buildbot use a master_site_local pointing to a local mirror, as
> we cannot expect the upload to be completed at the time the build runs.
> Right now we are downloading all files twice.

I split the fetch phase into a separate command. This should make it
easier to see that the dependency failed because it was unable to fetch
the distfiles.

https://github.com/macports/mpbb/commit/639def5ad990ecf1e227e377e5a46124c447ca94

This will also no longer update the failcache, as fetching could be a
temporary problem.

This should also remedy the situation on legacy systems for now.
Installation as a dependency will be retried even if a previous run
failed due to fetching. By that time, the distfile was hopefully
uploaded to the mirror.

We should still investigate in adding a master_site_local, as this
involves more fetches from the internet than necessary at the moment.

Rainer

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

[Mojca Miklavec]

On 4 April 2018 at 17:19, Rainer Müller wrote:
> On 2018-04-04 16:36, Andrew Moore wrote:
>> If I’m reading correctly the attached report from buildbot
>> port net/mosquitto fails for OS X <=
>> 10.6 due to indirect dependency: libpsl.  If so, this is presumably a
>> known issue, since many ports depend upon libpsl?

It also failed on 10.7 and 10.8.

> The failed libpsl build is this one (you can find it in the log of the
> install-dependencies step). The build failed because libpsl cannot be
> fetched on systems that do not support modern TLS protocol versions.
> This is a well known problem.

I triggered new builds of mosquitto now that libpsl has been built on
all systems.

Mojca

Re: Gsoc 18 Project | Collect build statistics

[Vishnu]

Hello

I wanted to get feedback on the demo project i submitted

https://drive.google.com/open?id=1LbMnyHjaRCbg7IrAUMM042eD7O2Br-jU


Thanks


On Wed, Apr 4, 2018, 11:08 AM Mojca Miklavec  wrote:

> Dear Vishnu,
>
> On 3 April 2018 at 23:54, Vishnu wrote:
> >
> > Hello
> >
> > I have finished the mini project given to me.
> > I am now successfully able to scrape data from json into the database.
> > And have integrated the database and website to display all the ports
> and their basic information as it was required
> > All the images and files are attached.
> > Please go through the link.
> > https://drive.google.com/open?id=1LbMnyHjaRCbg7IrAUMM042eD7O2Br-jU
>
> Thank you very much.
>
> As far as I am concerned this serves ok as a demo.
> (The database would ideally be filled with Django as well, but that's
> ok for now.)
> I don't know if other mentors have any further questions.
>
> > On 4 April 2018 at 03:19, Vishnu wrote:
> >>
> >> Hello
> >>
> >> I have finished the mini project given to me.
> >> I am successfully able to scrape data from json into the database.
> >> And have integrated the database and website to display all the ports
> and their basic information as it was required
> >> All the images and files are attached.
> >>
> >> My last 3 mails got rejected due to large size.
> >> Hence uploaded all the images as attachment..
>
> You can see which emails reached the mailing list by looking at
>
> https://lists.macports.org/pipermail/macports-dev/2018-April/thread.html
>
> I'm not absolutely sure, but I think this email did not reach others
> either because the images were still present inline (in quoted
> messages) when you hit the "reply to" button and thus the email size
> was still prohibitively large.
>
> In the future try not to send anything but trivial/small text
> attachments (or super small images like a logotype), any screenshots
> should better go to some other place where only those interested in
> the topic will go to check them out, while hundreds of other
> subscribers to the mailing list would not get their mailboxes filled.
>
> Mojca
>
>
>
> >> On 4 April 2018 at 03:06, Vishnu  wrote:
> >>>
> >>> In the last mail it was working but by taking portid from url.
> >>>
> >>> Now i created my custom view which will take the text after "port/"
> and search it in port table and return all its properties.
> >>>
> >>> Please look at the url.This is what our final result would want.
> >>>
> >>> Thanks
> >>>
> >>>
> >>> On 4 April 2018 at 02:06, Vishnu  wrote:
> 
>  Hello
> 
>  I have succesfully integrated django & sqlite3 .
>  Also am able to display the content on web.
>  Following Screenshots will explain :
> 
> 
> 
>  Databse :
> 
> 
> 
>  Is my progress fine?
> 
>  I think this would be enough as my proof of skill.
> 
>  Thanks
> 
> 
> 
>  On 4 April 2018 at 01:12, Vishnu  wrote:
> >
> > Hello
> >
> >
> > Yes that's what I have been doing.
> > Its almost ready.. Now integrating it with my front-end website.so
> that table is updated automatically.
> > Will be mailing you very soon. All the screenshots.
> >
> > On Wed, Apr 4, 2018, 1:05 AM Mojca Miklavec 
> wrote:
> >>
> >> Dear Vishnu,
> >>
> >> On 3 April 2018 at 20:10, Vishnu wrote:
> >> >
> >> > Hello
> >> >
> >> > Yes portindex.json is very useful.
> >> >
> >> > I tried my hands with python and sql.
> >> > And am successfully able to parse the json and store the data
> into the table .
> >>
> >> Thank you very much. The initial steps look promising.
> >>
> >> Now, try to integrate this into a simple django app with the
> database
> >> abstraction layer. A simple tutorial is here to demonstrate how to
> >> define simple python classes that automatically interoperate with
> >> database (so no need to write direct sql code at this step):
> >> https://docs.djangoproject.com/en/2.0/intro/tutorial01/
> >>
> >> Using SQLite is fine (for the production we would probably want to
> go
> >> for PostgreSQL, but now it doesn't make any difference).
> >>
> >> Mojca
>

Re: MySQL 5.7 fails to build

[Bjarne D Mathiesen]

Craig Treleaven wrote:
>> The main.log file is here : http://www.mathiesen.info/macports
> 
> The log shows the following:
> 
> :info:build 
> /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql57/mysql57/work/mysql-5.7.17/sql/item_geofunc_internal.cc:37:63:
>  error: no type named 'self_ip_exception' in namespace 
> 'boost::geometry::detail::self_get_turn_points'
> :info:build   catch (const 
> boost::geometry::detail::self_get_turn_points::self_ip_exception &)
> :info:build~~~^
> 
> I don’t have time to dig a lot further but I wonder if the issue is related 
> to the bundled copy of boost 1.59 in the mysql57 port?

This is from a computer that had never had any previous installation of
MySQL ever :

root@i7 05:06:23 ~
#=> port install mysql57-server
--->  Computing dependencies for mysql57-server
The following dependencies will be installed:
 mysql57
 mysql_select
Continue? [Y/n]:
--->  Fetching distfiles for mysql_select
--->  Verifying checksums for mysql_select
--->  Extracting mysql_select
--->  Configuring mysql_select
--->  Building mysql_select
--->  Staging mysql_select into destroot
--->  Installing mysql_select @0.1.2_3
--->  Activating mysql_select @0.1.2_3
--->  Cleaning mysql_select
--->  Fetching distfiles for mysql57
--->  Attempting to fetch mysql-5.7.17.tar.gz from ...
--->  Attempting to fetch mysql-5.7.17.tar.gz from
http://sunsite.icm.edu.pl/mysql/Downloads/MySQL-5.7
--->  Attempting to fetch boost_1_59_0.tar.gz from
http://kent.dl.sourceforge.net/project/boost/boost/1.59.0
--->  Verifying checksums for mysql57

--->  Extracting mysql57
--->  Applying patches to mysql57
--->  Configuring mysql57
--->  Building mysql57
Error: Failed to build mysql57: command execution failed
...
Error: Processing of port mysql57-server failed

so it downloads boost and doesn't seem to rely on the bundled version

> 
> Also, I note the following open ticket:
> 
> https://trac.macports.org/ticket/55238
> 
> I haven’t looked into it to see if it is a similar issue.

I'm simply not proficient in reading log files; but I'll supplement my
experience to that bug

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
macOS 10.13.4 High Sierra (17E199)
2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC
ATI Radeon HD 5770 1024 MB