> On Dec 6, 2016, at 10:33 AM, Rainer Müller wrote:
>
> (e) add "Closes: #XYZ" to the commit message
When commits close PRs implicitly (by merging the PR branch) instead of
explicitly (by using "closes #XYZ" in the message), the PR is remembered
internally by GitHub and displayed on the websit
> On Dec 6, 2016, at 10:33 AM, Rainer Müller wrote:
>
>> On 2016-12-06 14:36, Mojca Miklavec wrote:
>>
>> When someone submits a pull request (let's assume that it's already
>> perfect) and a committer fetches it, rebases it and commits it to the
>> master, then the PR is not automatically linke
On Monday December 12 2016 00:39:37 Marko Käning wrote:
> So, now only 10.6-10.8 fail completely (which had to be expected, I am afraid)
Yes, for QtCurve-qt5 .
I keep forgetting that 10.8 also doesn't have libc++ standard...
> but qtcurve-gtk2 fails also for the newer ones…
I think I found the
On 12 Dec 2016, at 00:42 , René J.V. Bertin wrote:
> On Monday December 12 2016 00:26:05 Marko Käning wrote:
>
>> Given the fact that “port lint" didn’t spot the missing "port:” in front of
>> the qt5-qtsvg:
>> ---
>> -depends_lib-append qt5-qtsvg
>> +depends_l
On Monday December 12 2016 00:26:05 Marko Käning wrote:
> Given the fact that “port lint" didn’t spot the missing "port:” in front of
> the qt5-qtsvg:
> ---
> -depends_lib-append qt5-qtsvg
> +depends_lib-append port:qt5-qtsvg
> ---
> one might think that “port li
On 12 Dec 2016, at 00:20 , Marko Käning wrote:
> Buildbots are finally picking it all up. :)
So, now only 10.6-10.8 fail completely (which had to be expected, I am afraid)
but qtcurve-gtk2 fails also for the newer ones…
Good night,
Marko
On 12 Dec 2016, at 00:03 , René J.V. Bertin wrote:
> and lint finds no errors in my local copy
Given the fact that “port lint" didn’t spot the missing "port:” in front of the
qt5-qtsvg:
---
-depends_lib-append qt5-qtsvg
+depends_lib-append port:qt5-qtsvg
---
o
Turns out that the depspec had to be mended for depends_lib-append…
Fixed now.
Buildbots are finally picking it all up. :)
On Sunday December 11 2016 23:51:20 Marko Käning wrote:
> Just seeing that all buildbot fail for qtcurve after the merge, here e.g.
> Sierra:
>
>
> https://build.macports.org/builders/ports-10.12_x86_64-watcher/builds/2384
>
> Subports search returns with an error:
>
> ./mpbb/mpbb:
On Sun, Dec 11, 2016 at 08:14:13PM +0100, René J.V. Bertin wrote:
> > > Just as machine readable as this line.
> >
> > Wrong, since 'port -q info --line --$fieldname' by definition only
> > contains information on $fieldname, whereas your message contains
> > natural language.
>
> Clutching at st
On Sunday December 11 2016 19:17:13 Clemens Lang wrote:
>> Just as machine readable as this line.
>
>Wrong, since 'port -q info --line --$fieldname' by definition only
>contains information on $fieldname, whereas your message contains
>natural language.
Clutching at straws much? :)
Regardless,
On Sun, Dec 11, 2016 at 04:53:13PM +0100, René J.V. Bertin wrote:
> > 'port info' output is already parsed by scripts today. It's output is
> > already machine-readable when using -q info --line --$fieldname. Your
> > change breaks this.
>
> Just as machine readable as this line.
Wrong, since 'p
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.
Examples include tickets like "replace no_x11 with x11", "switch to
perl5.26", ...
On Sunday December 11 2016 17:37:36 Mojca Miklavec wrote:
> Maybe the compilers portgroup indeed does part of what you want, but
> you would still have to provide the logic to tell when to switch to a
> particular variant.
No, on 10.6 and 10.6 alone I'd be checking for *a* gcc variant, and raisin
On 11 December 2016 at 16:53, René J.V. Bertin wrote:
>
> Let me ask once more: is there anything currently available that makes it
> easier/less work to add variants that select a gcc compiler? I've been
> looking at the compilers PG, but cannot assess from the preamble comments
> whether it's
On Sunday December 11 2016 15:59:13 Clemens Lang wrote:
> 'port info' output is already parsed by scripts today. It's output is
> already machine-readable when using -q info --line --$fieldname. Your
> change breaks this.
Just as machine readable as this line.
This is mostly as a reaction to Mo
On Sun, Dec 11, 2016 at 03:38:14PM +0100, René J.V. Bertin wrote:
> > Because it runs 'port -q info --line --subports' and parses the
> > result. The flags to info guarantee that only the list of subports
> > is printed.
>
> Portindex? I'm pretty sure I've had a ui_msg for a while in one of my
> P
Hi Wilhelm - Thanks for the reply.
doxygen has no dependency on qt5. "doxygen +wizard" depends on qt4-mac,
and that's the only Qt dependency for doxygen, according to 'port', of
course. It is certainly possible that doxygen has been updated to find
and require Qt5 & that "stealth" change has not b
On Sunday December 11 2016 14:56:23 Clemens Lang wrote:
> Two options:
>
> 1. Modify port(1) to print notes before installation of a port
I've volunteered to help find a solution to this situation, but with the
underwhelming reception that got I'm not that enchanted to insist.
> Because it ru
On 11 December 2016 at 13:59, Joshua Root wrote:
> On 2016-12-11 23:30 , René J.V. Bertin wrote:
>> On Sunday December 11 2016 12:45:44 Marko Käning wrote:
>>
>>> My goodness, what happened here???
>>
>> That seems to come from this line
>>
>> ui_msg "This port only builds with
>> configure
On Sun, Dec 11, 2016 at 02:28:14PM +0100, René J.V. Bertin wrote:
> > A Portfile should not should not print anything in response to it
> > simply being opened. (Think about it, does a user really want to see
> > this message whenever they run 'port info'
>
> Yes they are supposed to! Cf. #52981
On Sunday December 11 2016 23:59:08 Joshua Root wrote:
> A Portfile should not should not print anything in response to it simply
> being opened. (Think about it, does a user really want to see this
> message whenever they run 'port info'
Yes they are supposed to! Cf. #52981
This message shoul
Hi,
thanks for your feedback.
When installing the port it began building the oxygen package, which
failed until I installed qt5 first.
The gqrx is the first port I installed after installing macports.
Thanks
Wilhelm
Am 10.12.16 um 21:53 schrieb MacPorts:
> #53049: gqrx dependency missing
> -
On 2016-12-11 23:30 , René J.V. Bertin wrote:
On Sunday December 11 2016 12:45:44 Marko Käning wrote:
My goodness, what happened here???
That seems to come from this line
ui_msg "This port only builds with configure.compiler=macports-gcc-4.7 (from
port:gcc47) or newer on OS X 10.6"
On Sunday December 11 2016 12:45:44 Marko Käning wrote:
> My goodness, what happened here???
That seems to come from this line
ui_msg "This port only builds with configure.compiler=macports-gcc-4.7
(from port:gcc47) or newer on OS X 10.6"
I put that in instead of simply invoking the c
25 matches
Mail list logo
