Re: Now Accepting GSoC 2016 Mentor Organization Applications

[Bradley Giesbrecht]

Me too.

Regards,
Bradley Giesbrecht (pixilla)


> On Feb 15, 2016, at 4:25 PM, Michael Dickens  wrote:
> 
> I've enjoyed being a mentor thus far, so I'm game for seeing what comes
> up if others are. Is SNC going to lead the way again? - MLD
> 
> On Fri, Feb 12, 2016, at 07:56 AM, Rainer Müller wrote:
>> Paging those who handled this last year, is there any interest to 
>> participate again?
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: GSoC port-util project

[Bradley Giesbrecht]

> On Feb 15, 2016, at 6:59 PM, Michael Dickens  wrote:
> 
> On Mon, Feb 15, 2016, at 09:33 PM, Mihai Moldovan wrote:
>> On 16.02.2016 01:34 AM, Michael Dickens wrote:
>>> An example would be a "check and try update" task that would: do a
>>> livecheck and if found to be old then automatically try to do the
>>> update: change the version, download the distfile, update the checksums
>>> in the Portfile, try to upgrade using -s -k to specify from source and
>>> to keep stuff around if successful.
>> 
>> Just a thought on this particular item... maybe it's just me OCDing, but
>> I don't
>> think a procedure like this should be sanctioned. Blindly updating like
>> this is
>> dangerous, because you run into problems with also updated dependencies,
>> which
>> you might not even see.
>> 
>> I generally diff the old and new version (if possible using SCM as that's
>> more
>> comfortable) and look through what might have changed within the
>> autotools files
>> (or whatever build system the port is using.)
>> 
>> It's a tedious task, but you risk missing changes otherwise.
> 
> I somehow doubt that most of us Portfile-level developers do a lot of
> SCM diffing between versions. I know for myself that there's just not
> enough time in the day to do so for every port I maintain. For some
> ports I do do this, just just a few. That said, if any specific MP dev
> want to do SCM diffing then that's his/her right IMHO. I don't think
> this MO should be required of all MP devs on all ports.
> 
> I see this particular item as a quick way to test to see if a port needs
> updating, and if so then test to see if it is easily updatable. It has
> everything to do with buildability, and nothing to do with diffing
> between versions.
> 
> All of this said, I think we're talking hypotheticals here anyway. I'm
> not even sure this is what pixilla meant in the first place. - MLD

This is along the lines of what I had in mind.

I have a bunch of scripts for creating patches, checking for updates, checking 
trac for tickets, svn {st,diff,ci} etc…, and I know others do to. I don’t know 
if TCL has this capability but I would be handy at times to dump all declared 
vars instead of hunting through port groups, man pages and other portfiles. And 
env vars.

Ideally a port-util that could act like port (load the same libs) but be 
extended via plugins to included things best left out of the port command.

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

Re: GSoC port-util project

[Brandon Allbery]

On Mon, Feb 15, 2016 at 9:33 PM, Mihai Moldovan  wrote:

> > An example would be a "check and try update" task that would: do a
> > livecheck and if found to be old then automatically try to do the
> > update: change the version, download the distfile, update the checksums
> > in the Portfile, try to upgrade using -s -k to specify from source and
> > to keep stuff around if successful.
>
> Just a thought on this particular item... maybe it's just me OCDing, but I
> don't
> think a procedure like this should be sanctioned. Blindly updating like
> this is
> dangerous, because you run into problems with also updated dependencies,
> which
> you might not even see.


I could see it making a copy of the Portfile, rather than updating in
place. As such it becomes a quick test to see how much work updating will
be.

-- 
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: GSoC port-util project

[Michael Dickens]

On Mon, Feb 15, 2016, at 09:33 PM, Mihai Moldovan wrote:
> On 16.02.2016 01:34 AM, Michael Dickens wrote:
> > An example would be a "check and try update" task that would: do a
> > livecheck and if found to be old then automatically try to do the
> > update: change the version, download the distfile, update the checksums
> > in the Portfile, try to upgrade using -s -k to specify from source and
> > to keep stuff around if successful.
> 
> Just a thought on this particular item... maybe it's just me OCDing, but
> I don't
> think a procedure like this should be sanctioned. Blindly updating like
> this is
> dangerous, because you run into problems with also updated dependencies,
> which
> you might not even see.
> 
> I generally diff the old and new version (if possible using SCM as that's
> more
> comfortable) and look through what might have changed within the
> autotools files
> (or whatever build system the port is using.)
> 
> It's a tedious task, but you risk missing changes otherwise.

I somehow doubt that most of us Portfile-level developers do a lot of
SCM diffing between versions. I know for myself that there's just not
enough time in the day to do so for every port I maintain. For some
ports I do do this, just just a few. That said, if any specific MP dev
want to do SCM diffing then that's his/her right IMHO. I don't think
this MO should be required of all MP devs on all ports.

I see this particular item as a quick way to test to see if a port needs
updating, and if so then test to see if it is easily updatable. It has
everything to do with buildability, and nothing to do with diffing
between versions.

All of this said, I think we're talking hypotheticals here anyway. I'm
not even sure this is what pixilla meant in the first place. - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GSoC port-util project

[Mihai Moldovan]

On 16.02.2016 01:34 AM, Michael Dickens wrote:
> +1: I like this idea, or at least what I think you're getting at. I'd
> love to have a MP-sanctioned port related utility app for doing common
> tasks -for developers-.
> 
> An example would be a "check and try update" task that would: do a
> livecheck and if found to be old then automatically try to do the
> update: change the version, download the distfile, update the checksums
> in the Portfile, try to upgrade using -s -k to specify from source and
> to keep stuff around if successful.

Just a thought on this particular item... maybe it's just me OCDing, but I don't
think a procedure like this should be sanctioned. Blindly updating like this is
dangerous, because you run into problems with also updated dependencies, which
you might not even see.

I generally diff the old and new version (if possible using SCM as that's more
comfortable) and look through what might have changed within the autotools files
(or whatever build system the port is using.)

It's a tedious task, but you risk missing changes otherwise.



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GSoC port-util project

[Michael Dickens]

+1: I like this idea, or at least what I think you're getting at. I'd
love to have a MP-sanctioned port related utility app for doing common
tasks -for developers-.

An example would be a "check and try update" task that would: do a
livecheck and if found to be old then automatically try to do the
update: change the version, download the distfile, update the checksums
in the Portfile, try to upgrade using -s -k to specify from source and
to keep stuff around if successful.

Another would be an "extract and prep to patch" task: "port extract foo
+variants", "pushed port work foo", "sudo chmod -R a+rw .", cd into the
worksrcdir, "git init", "git add * .[a-zA-Z0-9]*", "git commit -a -m
"init" > /dev/null" -- so that I'm ready to do editing / patching & can
track the changes.

Yes, I can create my own scripts to do tasks like these (and, I have),
but having them in a MP-sanctioned "port-util" into which I could add
others would be awesome.

My US$0.02 worth. - MLD

On Sun, Feb 14, 2016, at 07:41 PM, Bradley Giesbrecht wrote:
> I would like to propose a port-util dev tools project for GS0C 2016.
> 
> Over time people have suggested adding functionality to port that would
> aid in MacPorts development.
> To keep port lean and user friendly many of these ideas have not made it
> into base.
> 
> The port-util tool would tap into base for core logic and provide a
> pluggable architecture for extending that functionality for audiences
> beyond end users.
>
> RFC
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Fwd: Now Accepting GSoC 2016 Mentor Organization Applications

[Michael Dickens]

I've enjoyed being a mentor thus far, so I'm game for seeing what comes
up if others are. Is SNC going to lead the way again? - MLD

On Fri, Feb 12, 2016, at 07:56 AM, Rainer Müller wrote:
> Paging those who handled this last year, is there any interest to participate 
> again?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CFITSIO's Fortran interface

[Ryan Schmidt]

> On Feb 15, 2016, at 2:07 AM, Sébastien Maret  
> wrote:
> 
>> 
>> Le 11 févr. 2016 à 16:19, Ryan Schmidt  a écrit :
>> 
>> On Feb 11, 2016, at 2:00 AM, Sébastien Maret wrote:
>>> 
 Le 10 févr. 2016 à 16:23, Ryan Schmidt  a écrit :
 
 On Feb 10, 2016, at 8:52 AM, Sébastien Maret wrote:
 
> I am maintaining the Gildas port which depends on the CFITSIO library. 
> CFITSIO has a Fortran interface but it is not built by default: one need 
> to select a specific variant (e.g. +gcc 5) for this. This is a problem 
> for the Gildas because the compilation fails without the Fortran 
> interface:
> https://trac.macports.org/ticket/50543
> 
> Is there a way for a port to depend on a specific variant of another 
> port? If not then how can I solve this?
 
 The require_active_variants procedure in the active_variants 1.1 port 
 group.
>>> 
>>> Thanks. I’ve added the cfitsio +gcc5 in require_active_variants and this 
>>> solves the problem on Yosemite:
>>> https://trac.macports.org/changeset/145605
>>> 
>>> However the compilation fails on older MacOS versions because the +gcc5 
>>> variant is not available.
>> 
>> Why isn't the gcc5 variant available on older Mac OS versions?
> 
> I don’t know. The build bot log for Mountain Lion says:
> 
> DEBUG: cfitsio is installed with the following variants: 
> DEBUG:   required: gcc5, forbidden: 
> DEBUG:   rejected, because required variant gcc5 is missing
> Error: org.macports.configure for port gildas returned: cfitsio must be 
> installed with +gcc5.
> 
> https://build.macports.org/builders/buildports-mtln-x86_64/builds/27804/steps/compile/logs/stdio/text
> 
> so I thought that the cfitsio +gcc5 variant was missing on that platform. But 
> perhaps I misunderstand the build bot log?

I think you misunderstand. This message is generated by the active_variants 1.1 
portgroup. It means that gildas requires the cfitsio port to be installed with 
the +gcc5 variant, but the user (in this case, the buildbot) did not do that 
(in this case, because it is not a default variant, and the buildbot only 
builds default variants). So, nothing about this situation should really be OS 
X-version-specific.

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

Re: Trac down?

[Daniel J. Luke]

On Feb 14, 2016, at 5:21 PM, Ryan Schmidt  wrote:
>> On Feb 13, 2016, at 11:37, Ryan Schmidt  wrote:
>> This time, the problem was "just" the server running out of memory. (The VM 
>> has enough memory for its normal tasks; I don't know what caused its memory 
>> use to spike yesterday.) When this happens, Oracle Linux starts killing 
>> processes, trying to free memory. Once of the processes it killed was 
>> probably the process that was syncing the svn repository from the svn 
>> server. Thus the marker that svnsync leaves on r0 to indicate that a sync is 
>> in progress never got cleared, and had to be cleared manually to allow a new 
>> sync to start.
> 
> Happened again today. The problem isn't a single large process; problem is 
> hundreds of Apache httpd processes, each of which take a bit of memory. Trac 
> server restarted again. 

You should consider changing the apache configuration to not spawn so many 
processes ;-)

-- 
Daniel J. Luke



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

Re: CFITSIO's Fortran interface

[Sébastien Maret]

> Le 11 févr. 2016 à 16:19, Ryan Schmidt  a écrit :
> 
> On Feb 11, 2016, at 2:00 AM, Sébastien Maret wrote:
>> 
>>> Le 10 févr. 2016 à 16:23, Ryan Schmidt  a écrit :
>>> 
>>> On Feb 10, 2016, at 8:52 AM, Sébastien Maret wrote:
>>> 
 I am maintaining the Gildas port which depends on the CFITSIO library. 
 CFITSIO has a Fortran interface but it is not built by default: one need 
 to select a specific variant (e.g. +gcc 5) for this. This is a problem for 
 the Gildas because the compilation fails without the Fortran interface:
 https://trac.macports.org/ticket/50543
 
 Is there a way for a port to depend on a specific variant of another port? 
 If not then how can I solve this?
>>> 
>>> The require_active_variants procedure in the active_variants 1.1 port group.
>> 
>> Thanks. I’ve added the cfitsio +gcc5 in require_active_variants and this 
>> solves the problem on Yosemite:
>> https://trac.macports.org/changeset/145605
>> 
>> However the compilation fails on older MacOS versions because the +gcc5 
>> variant is not available.
> 
> Why isn't the gcc5 variant available on older Mac OS versions?

I don’t know. The build bot log for Mountain Lion says:

DEBUG: cfitsio is installed with the following variants: 
DEBUG:   required: gcc5, forbidden: 
DEBUG:   rejected, because required variant gcc5 is missing
Error: org.macports.configure for port gildas returned: cfitsio must be 
installed with +gcc5.

https://build.macports.org/builders/buildports-mtln-x86_64/builds/27804/steps/compile/logs/stdio/text

so I thought that the cfitsio +gcc5 variant was missing on that platform. But 
perhaps I misunderstand the build bot log?

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