Re: [151267] contrib/mp-buildbot

[Mojca Miklavec]

Hi,

On 11 August 2016 at 22:04, Clemens Lang  wrote:
> On Thu, Aug 11, 2016 at 01:03:06AM -0700, mo...@macports.org wrote:
>> Revision: 151267
>>   https://trac.macports.org/changeset/151267
>> Author:   mo...@macports.org
>> Date: 2016-08-11 01:03:06 -0700 (Thu, 11 Aug 2016)
>> Log Message:
>> ---
>> mp-buildbot: add (not too helpful) progress for the port watcher
>>
>> Modified Paths:
>> --
>> contrib/mp-buildbot/mpbb-install-dependencies
>> contrib/mp-buildbot/mpbb-install-port
>> contrib/mp-buildbot/mpbb-list-subports
>
> I don't think the changes in mpbb-list-subports are very helpful. The
> new file is basically the same as the stdout of the task and does not
> provide a lot of additional value, unless you want to somehow extend or
> automatically parse it?

The idea was to end up with a *single* file that summarises the
progress from one portwatcher task that would eventually be also used
for figuring out who should get emails from failed builds. So
basically a replacement of the status files from the old buildbot.

I'm 100% sure that this could be programmed in master.cfg, but I have
no clue how to iterate through the triggered builds from the
portwatcher.

What would be the best way to prepare the summary of the builds at the
end of the portwatcher?

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) ...

[Fred Wright]

On Thu, 11 Aug 2016, Lawrence Velázquez wrote:

> > On Aug 11, 2016, at 3:40 PM, Fred Wright  wrote:
> >
> > Well, leaving something alone that's working just fine is hardly much
> > of a maintenance burden.
>
> As Josh noted, this approach is fine for CPython itself, but less so
> for modules. As they work to keep their modules up to date, maintainers
> can hardly be expected to support subports for Python versions that
> don't build on recent OSes (although they are certainly welcome to if
> they wish).

But often the subports work fine as well.  For example, here I have local
versions of seven py-xxx ports just to expand the version lists.  In five
of the cases, expanding the version lists "just worked".  The other two
ports each had a set of version-specific files (for no obvious reason,
given the content) which just needed to be trivially and obviously
expanded for the added versions.

Fred Wright
___
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

[David Evans]

On 8/10/16 1:37 AM, Ryan Schmidt wrote:
> 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?
> 

OK, I just tumbled to what you're saying here.  As you say, the indexed version 
of this port will be determined by the
value of configure.cxx_stdlib on the machine that is doing the indexing and, 
for those that use the rsynced indexes,
that machine may not be running the same C++ configuration (or even the same OS 
version) as the user's machine.  This
works for me because, as a maintainer, I use subversion to fetch Portfiles and 
regenerate the PortIndex myself.  In that
context this works fine.

As you say, the world is quickly moving on. Even projects like Inkscape, which 
has been slow to update to C++11 and gtk3
has announced that the upcoming 0.92 release will be the last to support C++98 
(libstdc++) and gtk2.  Trunk development
has already moved to requiring C++11 and libc++ to build.

Similarly, glibmm, gtkmm3 and friends have required C++11 (libc++) to build for 
two stable release cycles now and are
proposing requiring C++14 in the next based on the fact that that is the 
default standard for gcc6.  So, while I have
been tracking the latest releases in my C++11 respositories,  I have been 
holding back on some of these releases for a
while pondering how to handle this libstdc++/libc++ dichotomy.

Personally, given time and resouces, I would rather dispense with maintaining 
outdated versions of GNOME ports
altogether and just use the cxx11 PortGroup where applicable.  It makes sense 
to me that we should put pressure on
users with older platforms to configure themselves to use libc++ where they 
possibly can rather than giving them further
excuses to stay with libstdc++ and C++98.  Maybe put the onus on those who want 
to stay with the older systems to curate
a separate repository(ies) altogether of ports whose versions are cherry picked 
to be compatible with their systems.
You could even provide separate buildbots for these systems.

So, before coming up with more complex indexing systems, etc, maybe we need to 
take a clear look at what we can really
afford to support.  At the very least, the newer standards should have a higher 
priority for support over the older.
Right now I feel like it's the other way round.

END OF DAVE'S (mini) RANT FOR TODAY :-)

GETTING BACK TO REALITY:

So, I wonder, rather than trying to design and disseminate a single PortIndex 
that will work for all circumstances, have
you considered modifying port selfupdate to regenerate the PortIndex on the 
user's system after rsyncing ports rather
than including it prebuilt?  Speaking as one who does this on a regular basis, 
the additional overhead isn't much if
people keep relatively up-to-date.

Or would it really be a disaster if we took a hard stand on only supporting 
10.9+?  I see the new buildbots already
label 10.8 and earlier as legacy so maybe we're half way there already.

> 
> 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 

Re: [151267] contrib/mp-buildbot

[Clemens Lang]

Hi Mojca,

On Thu, Aug 11, 2016 at 01:03:06AM -0700, mo...@macports.org wrote:
> Revision: 151267
>   https://trac.macports.org/changeset/151267
> Author:   mo...@macports.org
> Date: 2016-08-11 01:03:06 -0700 (Thu, 11 Aug 2016)
> Log Message:
> ---
> mp-buildbot: add (not too helpful) progress for the port watcher
> 
> Modified Paths:
> --
> contrib/mp-buildbot/mpbb-install-dependencies
> contrib/mp-buildbot/mpbb-install-port
> contrib/mp-buildbot/mpbb-list-subports
> 
> Modified: contrib/mp-buildbot/mpbb-install-dependencies
> ===
> --- contrib/mp-buildbot/mpbb-install-dependencies 2016-08-11 06:56:46 UTC 
> (rev 151266)
> +++ contrib/mp-buildbot/mpbb-install-dependencies 2016-08-11 08:03:06 UTC 
> (rev 151267)
> [...]
>
> Modified: contrib/mp-buildbot/mpbb-install-port
> ===
> --- contrib/mp-buildbot/mpbb-install-port 2016-08-11 06:56:46 UTC (rev 
> 151266)
> +++ contrib/mp-buildbot/mpbb-install-port 2016-08-11 08:03:06 UTC (rev 
> 151267)
> [...]
>  
> Modified: contrib/mp-buildbot/mpbb-list-subports
> ===
> --- contrib/mp-buildbot/mpbb-list-subports2016-08-11 06:56:46 UTC (rev 
> 151266)
> +++ contrib/mp-buildbot/mpbb-list-subports2016-08-11 08:03:06 UTC (rev 
> 151267)

I don't think the changes in mpbb-list-subports are very helpful. The
new file is basically the same as the stdout of the task and does not
provide a lot of additional value, unless you want to somehow extend or
automatically parse it?

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

Re: [151264] contrib/mp-buildbot/mpbb-install-port

[Clemens Lang]

Hi Mojca,

On Wed, Aug 10, 2016 at 11:48:51PM -0700, mo...@macports.org wrote:
> Revision: 151264
>   https://trac.macports.org/changeset/151264
> Author:   mo...@macports.org
> Date: 2016-08-10 23:48:51 -0700 (Wed, 10 Aug 2016)
> Log Message:
> ---
> mp-buildbot/install-port: add basic statistics and main.log (not sure if 
> useful, port -d is more verbose)
> 
> +# TODO: printing statistics (and installing the port + dependencies)
> +#   only makes sense when the port hasn't been installed previously
> +# log: statistics
> +echo "time:$(($time_stop - $time_start))s" >> "$log_port_stats"

Inside $(( )), dollar signs are not required for variables.
$((time_stop - time_start)) works just fine.

> +# log: main.log
> +local port_mainlog=$("${option_prefix}/bin/port" logfile 
> "${option_port}")
> +if [ -f $port_mainlog ]; then

$port_mainlog should be quoted here.


-- 
Clemens
___
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 11, 2016, at 3:40 PM, Fred Wright  wrote:
> 
> Well, leaving something alone that's working just fine is hardly much
> of a maintenance burden.

As Josh noted, this approach is fine for CPython itself, but less so
for modules. As they work to keep their modules up to date, maintainers
can hardly be expected to support subports for Python versions that
don't build on recent OSes (although they are certainly welcome to if
they wish).

> BTW, there's some erroneous information that making code compatible
> with both Python 2 and Python 3 requires 2.7.  I have yet to encounter
> any issues with "polyglot" code per se on Python 2.6.  Anything
> earlier is definitely problematic, however.

For sure. Maintaining source compatibility between 2.6 and 3.x is
annoying but far from impossible.

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) ...

[Fred Wright]

On Wed, 10 Aug 2016, 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.

Well, leaving something alone that's working just fine is hardly much of a
maintenance burden.

BTW, there's some erroneous information that making code compatible with
both Python 2 and Python 3 requires 2.7.  I have yet to encounter any
issues with "polyglot" code per se on Python 2.6.  Anything earlier is
definitely problematic, however.

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

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

[Brandon Allbery]

On Thu, Aug 11, 2016 at 12:09 PM, Russell Jones <
russell.jo...@physics.ox.ac.uk> wrote:

> Python has a concept of "we're all consenting adults here"


Who deposed Guido? Python's usual concept is "This Is The One True Way and
we reserve the right to mock you for writing Perl in Python and then make
what you did an error". (And I've seen it in action far too many times.
It's fine to have standards, but *lose the attitude*.)

That said, you don't have the module namespace conflated that badly with
the variable namespace in Java, Perl, C, Haskell, ... and I *really*
dislike "spooky action at a distance" in languages.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Russell Jones]

On 11/08/16 16:36, Brandon Allbery wrote:
On Thu, Aug 11, 2016 at 2:20 AM, Lawrence Velázquez 
> wrote:


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


And I have another reason to dislike Python. *Why* are those in 
the same namespace?! You basically cannot trust code that might decide 
to reuse some part of module space as a local variable, and the 
resulting errors are inscrutable.
Where else would they go? How do you refer to a namespace except by name 
(other than the default)?
I guess there could be some kind of protection of imports, but if you 
get there aren't the error message is understandable. Note you can say 
"print = 3" if you want (just as you can in, say, JavaScript and Ruby, 
though Ruby appears to silently ignore it-- possibly that's a name 
resolution thing). However, Python has a concept of "we're all 
consenting adults here" 
https://mail.python.org/pipermail/tutor/2003-October/025932.html You can 
change whatever you want however you want-- you just shouldn't.


It's not too hard to deal with

1) Look for the import statements in the file you're in (grep import my.py)
2) Don't use the imported names, or import them as something else, e.g. 
"import os as _os"




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

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

[Brandon Allbery]

On Thu, Aug 11, 2016 at 2:20 AM, Lawrence Velázquez 
wrote:

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


And I have another reason to dislike Python. *Why* are those in the
same namespace?! You basically cannot trust code that might decide to reuse
some part of module space as a local variable, and the resulting errors are
inscrutable.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
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

[Rainer Müller]

On 2016-08-10 20: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.

Other variables that make archives incompatible, such as the prefix,
applications_dir, or frameworks_dir, are already not visible in the
filename.

Perhaps all of this should be part of the +CONTENTS file in the archive?

Rainer
___
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

[Mojca Miklavec]

On 10 August 2016 at 10:37, Ryan Schmidt wrote:
>
> 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++/.

Some time back I opened a ticket at
https://trac.macports.org/ticket/50448
During the MacPorts meeting the suggestion was to start using a
different path/prefix, to add an additional variable to the database
(and certainly not to mix this with changes of the compression
format).

We could brainstorm (or at least summarize the discussion happinging
on the mailing list) in that ticket.

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

(I admit that I wasn't even aware that this could also be a problem
for PortIndex.)

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

Re: [151222] users/petr/ports

[Peter Danecek]

> On 11 Aug 2016, at 03:44, Ryan Schmidt  wrote:
> 
> 
>> 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.

Thanks for the hint!
Fixed in r151269
~petr



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

Re: [151222] users/petr/ports

[Peter Danecek]

> On 11 Aug 2016, at 03:44, Ryan Schmidt  wrote:
> 
> 
>> 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.

Ryan, you are referring to the copyright note, right?
I’ll fix this.
~petr


___
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 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