Re: Tickets affecting multiple ports and committers & "annoying" commits

[Ryan Schmidt]

> On Dec 11, 2016, at 12:13 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> After some cool features have been enabled on Trac, in particular the
> "See:" and "Closes:" syntax that automatically adds a comment, I
> wonder what to do with tickets that affect many ports and maintainers.

I would prefer to avoid such tickets as much as possible.

> Examples include tickets like "replace no_x11 with x11", "switch to
> perl5.26", ...
>https://trac.macports.org/ticket/39383
> etc.

I agree those are the types of tickets where it is necessary to list many ports.

> If we subscribe 100 maintainers with 100 ports, each maintainer will
> receive an email every time any port gets fixed.

We should not make / allow each maintainer to fix their own port for this 
issue. There should be a single pull request that makes the correct fix for all 
ports. Maintainers can be given an amount of time to voice objections to the 
change. After objections have been dealt with and the time expires, the pull 
request can be merged as one commit which will generate just one notification.

> Some time ago we had a volunteer who kept following the commit logs
> and modified just his own comment. But now it would be nice to have a
> better solution.
> 
> Just about the only thing that comes to my mind is a checkbox on each
> ticket that stops sending emails on each commit while keeping sending
> emails when writing other comments. Not that I particularly like that
> option either.
> 
> Any ideas?
> 
> Mojca

Re: py-pyqt4: fix for the depends_lib reset caused by the Python PortGroup

[Joshua Root]

Doesn't even parse here:

Failed to parse file python/py-pyqt5/Portfile: can't read 
"python.version": no such variable


On 2016-12-20 12:35 , Marko Käning wrote:

Turns out there is a double dep on qt5-qtbase now:
---
$ port deps py\*-pyqt5
Full Name: py-pyqt5 @5.6_3
Build Dependencies:   pkgconfig
Library Dependencies: py27-pyqt5, qt5-qtbase
--
Full Name: py27-pyqt5 @5.6_3
Build Dependencies:   pkgconfig
Library Dependencies: qt5-qtbase, python27, qt5-qtbase, py27-sip, dbus-python27
--
Full Name: py34-pyqt5 @5.6_3
Build Dependencies:   pkgconfig
Library Dependencies: qt5-qtbase, python34, qt5-qtbase, py34-sip, dbus-python34
--
Full Name: py35-pyqt5 @5.6_3
Build Dependencies:   pkgconfig
Library Dependencies: qt5-qtbase, python35, qt5-qtbase, py35-sip, dbus-python35
---

I closed https://trac.macports.org/ticket/53090 obviously too quickly. :(

Re: Requiring a specific variant in depends_lib

[Mojca Miklavec]

On 18 December 2016 at 02:28, Ryan Schmidt wrote:
> On Dec 17, 2016, at 09:06, Akim Demaille wrote:
>>
>> So my question is: how can I specify that requirement in the Portfile?
>> Currently it reads:
>>
>> depends_lib port:boost \
>>   path:bin/ccache:ccache \
>>   port:gmp \
>>   port:python${python_version}
>>
>> and I’d like to have something like "port:boost + python${python_version}",
>> but it does not work.
>
> Correct, MacPorts base doesn't have this controversial feature. You can fake 
> it using the active_variants portgroup, which you're already doing. It prints 
> the above error telling the user how to resolve the problem manually by 
> installing the correct variant of the dependency, but it cannot be resolved 
> automatically.
>
>> Or if I can’t say that, what can I do so that vcsn is properly built
>> on your buildfarm?
>
> You can't, unless you can eliminate the dependency variant requirement.

There is a limited number of alternatives (none of which apply at the moment).

(1.) Wait until the dependency calculations are polished and released:
https://trac.macports.org/wiki/SummerOfCode2015Libsolv

I'm not sure about the status of this code though. From what I
understood there is still some work to be done before the code is
ready to be fully integrated and released.

(2.) It wouldn't work automatically, but one could probably build the
port manually if we implemented support for variants on the buildbot:
https://trac.macports.org/ticket/52742

(3.) It might be possible to add some logic to install/activate "boost
+ python35" on the buildbot if we had slightly more advanced logic and
parsed which variants of dependencies are needed for the port in
question. But this would only put a patch on the wound. If another
port depends on vcsn, this "advanced poor-man's logic" would fail
again unless/until we fully implement full dependency tracking
mentioned in (1).

(4.) Figure out if there is a way to install python support for boost
separately from boost itself. And if there is a way to install that
support for each version of python individually. Then you could add a
dependency on py35-boost. Judging from
https://packages.debian.org/wheezy/amd64/libboost-python1.49-dev/filelist
I would guess that Debian developers figured out how to do that.

If you have time, motivation and some basic skillset to do it, I would
suggest you to look at #4. (Or #1: with a greater impact, but probably
steeper learning curve.)

Mojca