Re: [macports-ports] 02/03: python34: backport patch from #44288. Part of #51939. Maintainer timeout.
> On Dec 17, 2016, at 06:12, Mihai Moldovan wrote:
>
> Mihai Moldovan (Ionic) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/3685fbde7a2c25d2d4caed7d1e281ddefb45
>
> commit 3685fbde7a2c25d2d4caed7d1e281ddefb45
>
> Author: Mihai Moldovan
> AuthorDate: Sat Dec 17 13:08:25 2016 +0100
>
>
> python34: backport patch from #44288. Part of #51939. Maintainer timeout.
Now that we're on GitHub, you can't use "#123" to refer to Trac ticket 123
anymore. ("#123" now refers to GitHub pull request 123.) To refer to a Trac
ticket, paste the complete URL of the MacPorts Trac ticket into the commit
message. Make sure the first line of your commit message does not exceed 50
characters. To succeed in meeting this restriction, put ticket references into
subsequent paragraphs, with each paragraph separated from the first line and
from other paragraphs by a blank line.
Re: [macports-ports] branch master updated: hidapi-devel: new port, version 0.8.0-20160920
> On Dec 19, 2016, at 7:41 AM, Rainer Müller wrote:
>
> Rainer Müller (raimue) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/aa798fc4244895c46159cdd054769c73da3fa271
>
> The following commit(s) were added to refs/heads/master by this push:
>
> new aa798fc hidapi-devel: new port, version 0.8.0-20160920
>
> aa798fc is described below
>
>
> commit aa798fc4244895c46159cdd054769c73da3fa271
>
> Author: Rainer Müller
> AuthorDate: Mon Dec 19 14:40:05 2016 +0100
>
>
> hidapi-devel: new port, version 0.8.0-20160920
>
>
>
> A library for interacting with HID-class devices.
>
>
>
> Adding as *-devel port as upstream releases are infrequent,
>
> but master contains valuable fixes for macOS.
>
> ---
> comms/hidapi-devel/Portfile | 36
> +++
> comms/hidapi-devel/files/patch-appbundle.diff | 15 +++
> 2 files changed, 51 insertions(+)
>
>
> diff --git a/comms/hidapi-devel/Portfile b/comms/hidapi-devel/Portfile
>
> new file mode 100644
>
> index 000..0d68423
>
> --- /dev/null
>
> +++ b/comms/hidapi-devel/Portfile
>
> @@ -0,0 +1,36 @@
>
> +# -*- 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
>
> +
>
> +PortSystem 1.0
>
> +PortGroup github 1.0
>
> +
>
> +github.setupsignal11 hidapi a6a622ffb680c55da0de787ff93b80280498330f
>
> +namehidapi-devel
>
> +set portversion 20160920
>
> +set version 0.8.0-${portversion}
"set" shouldn't be used with "version" or other options.
MacPorts base uses a variable called "portversion" in many places; I don't know
if it's a problem to use that variable name for a different purpose in a
portfile.
Re: Tickets affecting multiple ports and committers & "annoying" commits
> 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
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: py-pyqt4: fix for the depends_lib reset caused by the Python PortGroup
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
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
