Re: [151216] contrib/buildbot-test/master.cfg

[Mojca Miklavec]

On 11 August 2016 at 08:20, Lawrence Velázquez wrote:
>> On Aug 11, 2016, at 2:07 AM, Ryan Schmidt wrote:
>>> On Aug 10, 2016, at 11:56 PM, Mojca Miklavec wrote:
>>>
>>> I changed that in r151249 and 151258. I don't know any "official" way
>>> to construct PATH though and it wouldn't work on Windows anyway, so
>>> the whole point of changing this is a bit moot.
>>>
>>> Figuring out why
>>>   workdir=os.path.join(portwatcher_factory.workdir, "mpbb")
>>> didn't work and
>>>   workdir=portwatcher_factory.workdir+"/mpbb"
>>> was ok is left as an exercise to the reader.
>>
>> What happened when you tried to use it there?
>
> Mojca showed me this failure in the IRC channel:
>
>> exceptions.AttributeError: 'str' object has no attribute 'path'
>
> Which is unexpected to say the least. It's because "os" gets hijacked as a 
> variable name, around line 440:
>
> for plat in build_platforms:
> os_match = extract_os.search(plat)
> os = os_match.group(0) if os_match else plat
>
> This variable must be renamed.

Thank you, fixed.

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

Re: [151216] contrib/buildbot-test/master.cfg

[Ryan Schmidt]

> On Aug 11, 2016, at 1:20 AM, Lawrence Velázquez  wrote:
> 
>> On Aug 11, 2016, at 2:07 AM, Ryan Schmidt  wrote:
>> 
>> 
>>> On Aug 10, 2016, at 11:56 PM, Mojca Miklavec  wrote:
>>> 
>>> I changed that in r151249 and 151258. I don't know any "official" way
>>> to construct PATH though and it wouldn't work on Windows anyway, so
>>> the whole point of changing this is a bit moot.
>>> 
>>> Figuring out why
>>>  workdir=os.path.join(portwatcher_factory.workdir, "mpbb")
>>> didn't work and
>>>  workdir=portwatcher_factory.workdir+"/mpbb"
>>> was ok is left as an exercise to the reader.
>> 
>> What happened when you tried to use it there?
> 
> Mojca showed me this failure in the IRC channel:
> 
>> exceptions.AttributeError: 'str' object has no attribute 'path'
> 
> Which is unexpected to say the least. It's because "os" gets hijacked as a 
> variable name, around line 440:
> 
>for plat in build_platforms:
>os_match = extract_os.search(plat)
>os = os_match.group(0) if os_match else plat
> 
> This variable must be renamed.

See, that would be my fault for adding that os variable. I don't know why you 
people let me anywhere near Python code when I don't know how to Python. :)

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

Re: [151216] contrib/buildbot-test/master.cfg

[Lawrence Velázquez]

> On Aug 11, 2016, at 2:07 AM, Ryan Schmidt  wrote:
> 
> 
>> On Aug 10, 2016, at 11:56 PM, Mojca Miklavec  wrote:
>> 
>> I changed that in r151249 and 151258. I don't know any "official" way
>> to construct PATH though and it wouldn't work on Windows anyway, so
>> the whole point of changing this is a bit moot.
>> 
>> Figuring out why
>>   workdir=os.path.join(portwatcher_factory.workdir, "mpbb")
>> didn't work and
>>   workdir=portwatcher_factory.workdir+"/mpbb"
>> was ok is left as an exercise to the reader.
> 
> What happened when you tried to use it there?

Mojca showed me this failure in the IRC channel:

> exceptions.AttributeError: 'str' object has no attribute 'path'

Which is unexpected to say the least. It's because "os" gets hijacked as a 
variable name, around line 440:

for plat in build_platforms:
os_match = extract_os.search(plat)
os = os_match.group(0) if os_match else plat

This variable must be renamed.

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

Re: [151215] contrib/mp-buildbot

[Mojca Miklavec]

On 11 August 2016 at 05:56, Ryan Schmidt wrote:
>> On Aug 10, 2016, at 1:25 PM, Mojca Miklavec wrote:
>>
>> Alternatively logdir could simply remain hardcoded as
>> ${option_workdir}/logs. There's no need for an extra layer of
>> complexity that doesn't really serve anyone.
>
> Yeah the log directory doesn't really need to be configurable, does it? It 
> can just be in the workdir.

I vote for removal of my own code :)

We can define a variable, but we don't need configurability.

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

Re: [151216] contrib/buildbot-test/master.cfg

[Ryan Schmidt]

> On Aug 10, 2016, at 11:56 PM, Mojca Miklavec  wrote:
> 
> I changed that in r151249 and 151258. I don't know any "official" way
> to construct PATH though and it wouldn't work on Windows anyway, so
> the whole point of changing this is a bit moot.
> 
> Figuring out why
>workdir=os.path.join(portwatcher_factory.workdir, "mpbb")
> didn't work and
>workdir=portwatcher_factory.workdir+"/mpbb"
> was ok is left as an exercise to the reader.

What happened when you tried to use it there?


> I also removed /usr/local/bin from PATH. I guess we don't really need
> that

Agreed.


> I also added a new log listing the contents of the port.

Should this use the -q flag? "port -q contents"?

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

Re: [151216] contrib/buildbot-test/master.cfg

[Mojca Miklavec]

On 11 August 2016 at 03:45, Ryan Schmidt wrote:
>> On Aug 10, 2016, at 8:44 PM, Lawrence Velázquez wrote:
>>> On Aug 10, 2016, at 9:37 PM, Ryan Schmidt wrote:
>>>
 On Aug 10, 2016, at 1:13 PM, mo...@macports.org wrote:

 --- contrib/buildbot-test/master.cfg2016-08-10 18:09:29 UTC (rev 
 151215)
 +++ contrib/buildbot-test/master.cfg2016-08-10 18:13:02 UTC (rev 
 151216)
 @@ -368,6 +368,7 @@

 portbuilder_factory = BuildFactory()
 portbuilder_factory.workdir = '../build'
 +logdir = "{}/logs".format(portbuilder_factory.workdir)
>>>
>>> Is this different from:
>>>
>>> logdir = portbuilder_factory.workdir + "/logs"
>>>
>>> ?
>>
>> Technically, they are different. For instance, if
>> portbuilder_factory.workdir were (for some reason) not a string, the
>> former would still work but the latter would not.
>>
>> Practically, they probably produce the same result.
>>
>> But neither is the "right" way:
>>
>>import os
>>logdir = os.path.join(portbuilder_factory.workdir, "logs")

I knew that, but felt too lazy to use it.

> Ok, there are other places where we had used "+" to concatenate strings to 
> make paths; we should change them all to use os.path.join.

I changed that in r151249 and 151258. I don't know any "official" way
to construct PATH though and it wouldn't work on Windows anyway, so
the whole point of changing this is a bit moot.

Figuring out why
workdir=os.path.join(portwatcher_factory.workdir, "mpbb")
didn't work and
workdir=portwatcher_factory.workdir+"/mpbb"
was ok is left as an exercise to the reader.

I also removed /usr/local/bin from PATH. I guess we don't really need
that one unless we want to support the other package manager :)

I also added a new log listing the contents of the port.

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

Re: [151215] contrib/mp-buildbot

[Ryan Schmidt]

> On Aug 10, 2016, at 1:25 PM, Mojca Miklavec  wrote:
> 
> Alternatively logdir could simply remain hardcoded as
> ${option_workdir}/logs. There's no need for an extra layer of
> complexity that doesn't really serve anyone.

Yeah the log directory doesn't really need to be configurable, does it? It can 
just be in the workdir.

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

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

[Joshua Root]

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

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


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


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


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


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


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

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

[Joshua Root]

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

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

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


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


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

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


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


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


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

Re: [151216] contrib/buildbot-test/master.cfg

[Ryan Schmidt]

> On Aug 10, 2016, at 8:44 PM, Lawrence Velázquez  wrote:
> 
>> On Aug 10, 2016, at 9:37 PM, Ryan Schmidt  wrote:
>> 
>>> On Aug 10, 2016, at 1:13 PM, mo...@macports.org wrote:
>>> 
>>> --- contrib/buildbot-test/master.cfg2016-08-10 18:09:29 UTC (rev 
>>> 151215)
>>> +++ contrib/buildbot-test/master.cfg2016-08-10 18:13:02 UTC (rev 
>>> 151216)
>>> @@ -368,6 +368,7 @@
>>> 
>>> portbuilder_factory = BuildFactory()
>>> portbuilder_factory.workdir = '../build'
>>> +logdir = "{}/logs".format(portbuilder_factory.workdir)
>> 
>> Is this different from:
>> 
>> logdir = portbuilder_factory.workdir + "/logs"
>> 
>> ?
> 
> Technically, they are different. For instance, if
> portbuilder_factory.workdir were (for some reason) not a string, the
> former would still work but the latter would not.
> 
> Practically, they probably produce the same result.
> 
> But neither is the "right" way:
> 
>import os
>logdir = os.path.join(portbuilder_factory.workdir, "logs")

Ok, there are other places where we had used "+" to concatenate strings to make 
paths; we should change them all to use os.path.join.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [151222] users/petr/ports

[Ryan Schmidt]

> On Aug 10, 2016, at 4:03 PM, p...@macports.org wrote:
> 
> Revision
> 151222
> Author
> p...@macports.org
> Date
> 2016-08-10 14:03:00 -0700 (Wed, 10 Aug 2016)
> Log Message
> 
> globus: add port group
> Added Paths
> 
>   • users/petr/ports/_resources/
>   • users/petr/ports/_resources/port1.0/
>   • users/petr/ports/_resources/port1.0/group/
>   • users/petr/ports/_resources/port1.0/group/globus-1.0.tcl
> Diff
> 
> Added: users/petr/ports/_resources/port1.0/group/globus-1.0.tcl (0 => 151222)
> 
> --- users/petr/ports/_resources/port1.0/group/globus-1.0.tcl  
> (rev 0)
> +++ users/petr/ports/_resources/port1.0/group/globus-1.0.tcl  2016-08-10 
> 21:03:00 UTC (rev 151222)
> 
> @@ -0,0 +1,168 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +# $Id$
> +#
> +# Copyright (c) 2012-2013 The MacPorts Project
> +# All rights reserved.

Should probably be 2016 instead.


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

Re: [151216] contrib/buildbot-test/master.cfg

[Lawrence Velázquez]

> On Aug 10, 2016, at 9:37 PM, Ryan Schmidt  wrote:
> 
>> On Aug 10, 2016, at 1:13 PM, mo...@macports.org wrote:
>> 
>> --- contrib/buildbot-test/master.cfg 2016-08-10 18:09:29 UTC (rev 151215)
>> +++ contrib/buildbot-test/master.cfg 2016-08-10 18:13:02 UTC (rev 151216)
>> @@ -368,6 +368,7 @@
>> 
>> portbuilder_factory = BuildFactory()
>> portbuilder_factory.workdir = '../build'
>> +logdir = "{}/logs".format(portbuilder_factory.workdir)
> 
> Is this different from:
> 
> logdir = portbuilder_factory.workdir + "/logs"
> 
> ?

Technically, they are different. For instance, if
portbuilder_factory.workdir were (for some reason) not a string, the
former would still work but the latter would not.

Practically, they probably produce the same result.

But neither is the "right" way:

import os
logdir = os.path.join(portbuilder_factory.workdir, "logs")

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

Re: [151216] contrib/buildbot-test/master.cfg

[Ryan Schmidt]

> On Aug 10, 2016, at 1:13 PM, mo...@macports.org wrote:
> 
> Revision
> 151216
> Author
> mo...@macports.org
> Date
> 2016-08-10 11:13:02 -0700 (Wed, 10 Aug 2016)
> Log Message
> 
> buildbot-test: show the short log with the progress of installing dependencies
> Modified Paths
> 
>   • contrib/buildbot-test/master.cfg
> Diff
> 
> Modified: contrib/buildbot-test/master.cfg (151215 => 151216)
> 
> --- contrib/buildbot-test/master.cfg  2016-08-10 18:09:29 UTC (rev 151215)
> +++ contrib/buildbot-test/master.cfg  2016-08-10 18:13:02 UTC (rev 151216)
> @@ -368,6 +368,7 @@
>  
>  portbuilder_factory = BuildFactory()
>  portbuilder_factory.workdir = '../build'
> +logdir = "{}/logs".format(portbuilder_factory.workdir)

Is this different from:

logdir = portbuilder_factory.workdir + "/logs"

?


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

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

[Clemens Lang]

On Wed, Aug 10, 2016 at 04:47:25PM -0500, Ryan Schmidt wrote:
> On Aug 10, 2016, at 13:18, Peter Danecek  wrote:
> > 
> > However, how would we procede in this case, when we have no explicit
> > replacement to indicate?
> 
> I believe the obsolete 1.0 portgroup can accommodate this: include the
> portgroup but don't set replaced_by. 
> 
> However, do first consider whether this needs to be done, or whether
> the port can instead be left as is. 

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

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

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

[Joshua Root]

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

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


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


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


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


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

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

[Lawrence Velázquez]

On Aug 10, 2016, at 2:18 PM, Peter Danecek  wrote:

> In the process of deprecating `py26` subports, I am just looking at
> some very old python packages which were never moved to Python 2.7. It
> seems that in most cases there is a "good reason" why this did not
> occur. They are just not used anymore.
> 
> Some of these packages are deprecated explicitly upstream in favour of
> substitutes. Sometimes the homepage or the sources can not be found
> found, or are extremely outdated. So rather than just keeping them
> alive in Macports (by moving them to Python 2.7 even if they build),
> I would propose to remove them completely.

What ports are these?

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

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

[Lawrence Velázquez]

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

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

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

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

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

[Ryan Schmidt]

On Aug 10, 2016, at 13:18, Peter Danecek  wrote:
> 
> However, how would we procede in this case, when we have no explicit 
> replacement to indicate?

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

However, do first consider whether this needs to be done, or whether the port 
can instead be left as is. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: our buildslaves' Python and bash

[Lawrence Velázquez]

On Aug 10, 2016, at 5:20 PM, Ryan Schmidt 
wrote:

> Buildbot and buildbot-slave are installed using MacPorts in a second
> prefix, so they're using MacPorts python27. 
> 
> mpbb is probably using the system bash because I don't recall
> installing bash, but it's no problem for us to install MacPorts bash
> to get a newer version and consistency across servers.

On Aug 10, 2016, at 5:20 PM, Clemens Lang  wrote:

> It's very likely the OS-provided bash, since mpbb's shebang says
> /bin/bash. As for Python, I think there's a separate MacPorts
> installation in a non-default path that installs buildbot from our
> buildbot port, which should also come with MacPorts Python.
> 
> We could make mpbb use MacPorts bash, but I'm not sure we need any
> Bash 4 features at the moment.

Thanks to both; I just wanted to keep the versions in mind before
I started poking around.

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

Re: ports.tar update frequency on new mirror

[Ryan Schmidt]

On Aug 10, 2016, at 16:03, Clemens Lang wrote:
> 
> Hi Ryan,
> 
> I'm wondering what update frequency I can expect for ports.tar on the
> new main mirror.
> 
> I have a cronjob set up that regularly checks whether ports.tar has not
> been updated in a while; it came in handy a couple of times because most
> developers usually sync using SVN and would not notice the rsync mirror
> becoming stale. For the last few days, it has been sending me a regular
> stream of emails warning me about old tarballs, even though eventually a
> new update was pushed.
> 
> The top spot is a mail from around noon today, where ports.tar had not
> been updated for 12.5 hours. Is this normal? Should I change my warning
> level?

That's my fault. I'll get it syncing every 30 minutes again. 

But one of the improvements I want to make is to only regenerate ports.tar 
after changes to ports have been committed, rather than on a set schedule. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Fred Wright]

On Wed, 10 Aug 2016, Sterling Smith wrote:

> I am all in favor of removing cruft.  However, would it be worthwhile to
> ping the user email list about the ports that will be deprecated (give a
> specific list), to see if anyone will complain, or is it better to just
> remove them, and then when someone complains tell them how to go back to
> an old version of a Port?

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

Python 2.6 here:

MacPro:~ fw$ port installed|egrep 'py(|thon)26'
  py26-cairo @1.10.0_3 (active)
  py26-pip @8.1.2_0 (active)
  py26-readline @6.2.4.1_1 (active)
  py26-setuptools @25.1.0_0 (active)
  python26 @2.6.9_4 (active)

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

Re: our buildslaves' Python and bash

[Clemens Lang]

Hi,

On Wed, Aug 10, 2016 at 04:52:02PM -0400, Lawrence Velázquez wrote:
> Are the buildslaves using the OS-provided bash (for mpbb) and
> MacPorts' python27 (for Buildbot), or what?

It's very likely the OS-provided bash, since mpbb's shebang says
/bin/bash. As for Python, I think there's a separate MacPorts
installation in a non-default path that installs buildbot from our
buildbot port, which should also come with MacPorts Python.

We could make mpbb use MacPorts bash, but I'm not sure we need any Bash
4 features at the moment.

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

Re: our buildslaves' Python and bash

[Ryan Schmidt]

On Aug 10, 2016, at 15:52, Lawrence Velázquez  wrote:
> 
> Are the buildslaves using the OS-provided bash (for mpbb) and MacPorts' 
> python27 (for Buildbot), or what?

Buildbot and buildbot-slave are installed using MacPorts in a second prefix, so 
they're using MacPorts python27. 

mpbb is probably using the system bash because I don't recall installing bash, 
but it's no problem for us to install MacPorts bash to get a newer version and 
consistency across servers. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

ports.tar update frequency on new mirror

[Clemens Lang]

Hi Ryan,

I'm wondering what update frequency I can expect for ports.tar on the
new main mirror.

I have a cronjob set up that regularly checks whether ports.tar has not
been updated in a while; it came in handy a couple of times because most
developers usually sync using SVN and would not notice the rsync mirror
becoming stale. For the last few days, it has been sending me a regular
stream of emails warning me about old tarballs, even though eventually a
new update was pushed.

The top spot is a mail from around noon today, where ports.tar had not
been updated for 12.5 hours. Is this normal? Should I change my warning
level?

- Forwarded message from Cron Daemon  -

Date: Wed, 10 Aug 2016 13:37:01 +0200
From: Cron Daemon 
To: dadad...@xoxoxo.neverpanic.de
Subject: Cron  nice -n20 ionice -c3 
/var/www/virtual/macports/home/portsynccheck.sh

rsync://rsync.macports.org/release/tarballs/ports.tar is outdated:
  last updated 12h 35m 17s ago
  at 2016-08-10 01:01:44.0 +0200

- End forwarded message -

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

our buildslaves' Python and bash

[Lawrence Velázquez]

Are the buildslaves using the OS-provided bash (for mpbb) and MacPorts' 
python27 (for Buildbot), or what?

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

Re: [151215] contrib/mp-buildbot

[Clemens Lang]

Hi Mojca,

a couple of review comments inline below.

On Wed, Aug 10, 2016 at 11:09:30AM -0700, mo...@macports.org wrote:
> Revision: 151215
>   https://trac.macports.org/changeset/151215
> Author:   mo...@macports.org
> Date: 2016-08-10 11:09:29 -0700 (Wed, 10 Aug 2016)
> Log Message:
> ---
> mp-buildbot: create a log file with progress of installed dependencies
> 
> +# prepare the log file
> +if ! [[ -d "${option_logdir}" ]] ; then
> +mkdir -p "${option_logdir}"
> +fi

The double brackets aren't necessary here. Additionally, testing and
then creating a directory has an implicit race condition (somebody else
could create it in between), so it's good that you use -p here, but then
you could just do mkdir -p directly and avoid the if completely.

> +log_status_dependencies=${option_logdir}/dependencies-progress.txt
> +# make ure to start with an empty file

Typo, should be make *s*ure.

> +echo -n "" > $log_status_dependencies

Instead of explicitly printing nothing into a file, you can just run
 > "$log_status_dependencies"
which does the same thing. Note that you should quote the redirect
target, just in case $option_logdir contains spaces. This applies to all
other uses of $log_status_dependencies as well.

> +echo "" >> $log_status_dependencies

echo "" is the same as just using echo without argument.

> +text="Installing dependency ($dependencies_counter of 
> $dependencies_count) '${depname}', variants: '${depvariants}'"
> +echo "> ${text}"
> +echo -n "${text}' ... " >> $log_status_dependencies

You have an additional closing single quote after ${text} here, which
leads to
 Installing dependency (41 of 205) 'xorg-xcb-proto', variants: '+python27'' ... 
 [OK]


Thanks for the work on this, though; it's much easier to read!

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

Re: [151215] contrib/mp-buildbot

[Lawrence Velázquez]

On Aug 10, 2016, at 2:25 PM, Mojca Miklavec  wrote:

> Thanks a lot for catching this.
> 
> Would you be willing to fix this properly before I make a bunch of
> other mistakes? In particular I'm not absolutely sure how to handle
> cases like this one in an elegant way:
>./mpbb something --logdir /tmp/a --workdir /tmp/b
> This should keep logdir at /tmp/a.

Sure, I can work on this in a bit.

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

Re: [151215] contrib/mp-buildbot

[Mojca Miklavec]

On 10 August 2016 at 20:17, Lawrence Velázquez wrote:
>
> --- contrib/mp-buildbot/mpbb 2016-08-10 16:13:48 UTC (rev 151214)
> +++ contrib/mp-buildbot/mpbb 2016-08-10 18:09:29 UTC (rev 151215)
> @@ -77,6 +79,10 @@between builds. Your MacPorts installation in --prefix
> needs to be able to
> access this location. Defaults to your current directory, or
> /tmp/mp-buildbot if \$PWD isn't set.
> +
> + --logdir LOGDIR
> +   A temporary folder for storing log files to be read by the master.
> Defaults to
> +   WORKDIR/logs.
>  EOF
>
>
> This description is not true in the current implementation because the value
> of ${option_logdir} does not track the value of ${option_workdir}. That is,
> if mpbb is invoked with --workdir FOO, ${option_logdir} will not have the
> value FOO/logs. To make this work, you'd have to set option_logdir after the
> option parsing.

Thanks a lot for catching this.

Would you be willing to fix this properly before I make a bunch of
other mistakes? In particular I'm not absolutely sure how to handle
cases like this one in an elegant way:
./mpbb something --logdir /tmp/a --workdir /tmp/b
This should keep logdir at /tmp/a.

Alternatively logdir could simply remain hardcoded as
${option_workdir}/logs. There's no need for an extra layer of
complexity that doesn't really serve anyone.


To be honest I'm not even sure if this is the best possible approach,
so other suggestions (or simply fixes) to improve the whole commit are
also welcome.

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

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

[Sterling Smith]

Petr,

I am all in favor of removing cruft.  However, would it be worthwhile to ping 
the user email list about the ports that will be deprecated (give a specific 
list), to see if anyone will complain, or is it better to just remove them, and 
then when someone complains tell them how to go back to an old version of a 
Port?

-Sterling


On Aug 10, 2016, at 11:18AM, Peter Danecek  wrote:

> 
> Hi all,
> 
> In the process of deprecating `py26` subports, I am just looking at some very 
> old python packages which were never moved to Python 2.7. It seems that in 
> most cases there is a "good reason" why this did not occur. They are just not 
> used anymore.
> 
> Some of these packages are deprecated explicitly upstream in favour of 
> substitutes. Sometimes the homepage or the sources can not be found found, or 
> are extremely outdated. So rather than just keeping them alive in Macports 
> (by moving them to Python 2.7 even if they build), I would propose to remove 
> them completely. 
> 
> However, how would we procede in this case, when we have no explicit 
> replacement to indicate?
> Just replace it by a stub?
> Just removing it the fast way?
> 
> Thanks!
> ~petr
> 
> ___
> 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

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

[Peter Danecek]

Hi all,

In the process of deprecating `py26` subports, I am just looking at some very 
old python packages which were never moved to Python 2.7. It seems that in most 
cases there is a "good reason" why this did not occur. They are just not used 
anymore.

Some of these packages are deprecated explicitly upstream in favour of 
substitutes. Sometimes the homepage or the sources can not be found found, or 
are extremely outdated. So rather than just keeping them alive in Macports (by 
moving them to Python 2.7 even if they build), I would propose to remove them 
completely. 

However, how would we procede in this case, when we have no explicit 
replacement to indicate?
Just replace it by a stub?
Just removing it the fast way?

Thanks!
~petr

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

Re: [151215] contrib/mp-buildbot

[Lawrence Velázquez]

On Aug 10, 2016, at 2:09 PM, mo...@macports.org  
wrote:

> Revision
> 151215 Author
> mo...@macports.org Date
> 2016-08-10 11:09:29 -0700 (Wed, 10 Aug 2016)
> Log Message
> 
> mp-buildbot: create a log file with progress of installed dependencies
> Modified Paths
> 
> contrib/mp-buildbot/mpbb 
> contrib/mp-buildbot/mpbb-install-dependencies 
> 
> Diff
> 
>  <>Modified: contrib/mp-buildbot/mpbb (151214 => 151215)
> 
> --- contrib/mp-buildbot/mpbb  2016-08-10 16:13:48 UTC (rev 151214)
> +++ contrib/mp-buildbot/mpbb  2016-08-10 18:09:29 UTC (rev 151215)
> @@ -77,6 +79,10 @@
> between builds. Your MacPorts installation in --prefix needs to be able to
> access this location. Defaults to your current directory, or
> /tmp/mp-buildbot if \$PWD isn't set.
> +
> + --logdir LOGDIR
> +   A temporary folder for storing log files to be read by the master. 
> Defaults to
> +   WORKDIR/logs. 
>  EOF
>  
This description is not true in the current implementation because the value of 
${option_logdir} does not track the value of ${option_workdir}. That is, if 
mpbb is invoked with --workdir FOO, ${option_logdir} will not have the value 
FOO/logs. To make this work, you'd have to set option_logdir after the option 
parsing.

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

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

[Lawrence Velázquez]

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

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

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

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

Re: Determine before installation whether a port can be installed

[Mojca Miklavec]

On 27 July 2016 at 06:09, Ryan Schmidt wrote:
>
> One solution that occurs to me is to define a new "preflight" phase, to be 
> run before dependencies are computed. Ports can override that phase and do 
> whatever checks they need and exit with "return -code error" if needed. This 
> seems like the most straightforward and flexible solution.

Independent of whether or not this phase would be used for this
purpose, I would find it useful.

At the moment there is no way to "just do something (not even useful)"
with the port. I can run "port fetch", but then this would fetch the
distfile even if the binary package already exists and fetching could
be skipped, so even fetching is "wasting resources".

The problem (that could be solved on both buildbot and user
installation if we had such a phase) is that currently running "sudo
port install " would happily install all
dependencies even if the port itself cannot be installed.

On the buildbot we could run
sudo port preflight portname
# then install dependencies
sudo port install portname
and if the first one fails, there's no need to continue.

For regular users this step could also prevent installing dependencies
if it could be executed "cheap enough".


If I want to bring the port to a state when main.log is created, so
that it could be retrieved with "port logfile " without
actually trying to fetch/extract/configure anything, this is probably
not possible at the moment.

Given how much trickery is currently already present in the buildbot
setup, a failing preflight phase could be sufficient to filter out
false negatives and avoid sending emails about (knowingly) broken
builds.

I'm not saying that we shouldn't implement better ways to signal
obsolete and known-to-be-broken ports. I'm just saying that
implementing some initial phase (that doesn't do anything) would be
helpful.

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

port install v port mpkg | mdmg

[Craig Treleaven]

Hi:

Is it possible for a port to take different actions depending on whether the 
user has initiated ‘port install’ v. 'port mpkg’ (or ‘port mdmg’)?

My mythtv-pkg.27 is intended to be used to create an all-in-one installer 
package for MythTV.  I have a VM with a custom prefix for this.  The resulting 
mpkg needs daemondo, so I created the nasty hack in MacPorts_daemondo.  
However, mythtv-pkg.27 could be a nice shortcut for a MacPorts user that wants 
to install a complete MythTV system in one go.  In such case, they don’t need 
MacPorts_daemondo.

So, can the port detect ‘port mpkg’ or ‘port mdmg’ and only add the dependency 
on MacPorts_daemondo in such cases?

Thanks,

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

A separate PortIndex for libc++ on older systems

[Ryan Schmidt]

On Jul 31, 2016, at 3:25 AM, dev...@macports.org wrote:

> Revision
> 150854
> Author
> dev...@macports.org
> Date
> 2016-07-31 01:25:57 -0700 (Sun, 31 Jul 2016)
> Log Message
> 
> gnome-maps: update to version 3.20.2, 3.18.3 for systems that don't support 
> libc++, now uses maps from MapBox.
> Modified Paths
> 
>   • trunk/dports/gnome/gnome-maps/Portfile

>  platform darwin {
> 
>  if {${configure.cxx_stdlib} eq "libstdc++"} {
> 
> -version 3.18.2
> -revision1
> -checksums   rmd160  aecfc78e6299cea8328a8803037141ee15f13fc2 \
> -sha256  
> 693ff1559252eabe5d8c9c7354333b5aa1996e870936456d15706a0e0bac9278
> 
> +version 3.18.3
> +set branch  [join [lrange [split ${version} .] 0 1] .]
> +master_sites gnome:sources/${name}/${branch}/
> +checksums   rmd160  48567c80b517e8982a57b3e3e9ed6b8d126dd31e \
> +sha256  
> b164eda021a88cc7ec6773fd48428d102334b98cc196d69fa0186258b9c8b6ed
> 


Currently, there is only one PortIndex file generated on the server, and 
published to the rsync server, for each OS name/version/endianness combination. 
So for example, there is one PortIndex for Darwin 12 Intel. There is not 
currently a separate PortIndex for Darwin 12 Intel with libc++, so anyone with 
e.g. OS X 10.8 with libc++ syncing from the rsync server will see the version 
of this port as 3.20.2 not 3.18.3 when querying the index, for example when 
running port info or port outdated. If we're going to change Portfile 
attributes such as version that get stored in the index based on the C++ 
library, and I agree this is a situation that would arise more and more as 
newer versions of software require libc++, should we make a separate libc++ 
PortIndex for 10.6/10.7/10.8?


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

Once we decide that, then do we adopt the same strategy for naming and placing 
the PortIndex files?

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