On Sep 4, 2018, at 08:13, Mojca Miklavec wrote:
> Dear Joshua,
>
> On Tue, 4 Sep 2018 at 14:04, Joshua Root wrote:
>> On 2018-9-4 19:15 , Mojca Miklavec wrote:
>>> Hi,
>>>
>>> I would like to ask for some help making a little trick work. Here's
>>> my attempt of a PR:
>>>
On Aug 22, 2018, at 13:46, Jan Stary wrote:
> On Aug 21 22:58:07, j...@macports.org wrote:
>> On 2018-8-18 06:06 , Clemens Lang wrote:
>>> I think the idea of the size keyword is to start to use it to display
>>> download progress bars for servers that do not send a Content-Length
>>> HTTP
On Aug 22, 2018, at 20:30, Perry E. Metzger wrote:
> After seeing a security advisory on one of the xorg ports and
> realizing that we hadn't updated a bunch of them in a while and that
> xquartz (the project) seems pretty dead, I started going in and
> updating various things in xorg-* that
On Aug 17, 2018, at 15:06, Clemens Lang wrote:
> I think the idea of the size keyword is to start to use it to display
> download progress bars for servers that do not send a Content-Length
> HTTP header (or do not have an equivalent of such a header due to the
> used protocol). This is
On Aug 15, 2018, at 01:35, Andrew Stromnov wrote:
> Andrew Stromnov (stromnov) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/efcf55361d5dd2a42f115372c8f741ac4ec8f674
>
> commit
On Aug 11, 2018, at 15:58, René J.V. Bertin wrote:
>> " Some Portfile authors have used large epoch values that look like a date,
>> but there is no reason to do so"
>
> nor is there a reason not to (that's not based on an ad-hoc decision) ...
>
> The doc reads a bit as if the epoch is
On Aug 11, 2018, at 10:13, René J.V. Bertin wrote:
> I've been using non-integer (but numerical) epochs in a few of my ports just
> because it made sense to set it e.g. to 5.1 when I started using the 5.1
> branch in a port. AFAIK the property is purely internal so it could be
> anything
On Aug 8, 2018, at 10:11, Craig Treleaven wrote:
> I ran across an article this morning describing how Homebrew was hacked with
> a few minutes effort:
>
> https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab
>
> Has anybody checked to see if we have
On Aug 3, 2018, at 18:01, David B. Evans wrote:
> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/7d5300f0703c626ec2f649b38c023bbd42093236
>
> commit 7d5300f0703c626ec2f649b38c023bbd42093236
>
On Aug 2, 2018, at 08:03, Vincent wrote:
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/a3f753c7a496641b4c85d6494806eee3951eb59b
>
> The following commit(s) were added to refs/heads/master by this
On Jul 29, 2018, at 13:59, Chris Jones wrote:
> On 29 Jul 2018, at 7:29 pm, Ryan Schmidt wrote:
>
>> clang does not work on PowerPC.
>
> Ah, right. I was just looking at
>
> http://packages.macports.org/clang-3.4/
>
> And saw the last versions had a Darwin
I am hoping instead it also defaults to
> clang-3.4 (or we can convince it to). Its also true that gcc9/libgcc-devel is
> only a snapshot, so things might improve in before a final release (which is
> why right now I don’t think its a big deal).
>
> Chris
>
>> On 29 Jul
On Jul 29, 2018, at 11:32, Chris Jones wrote:
> Is there anyone who has a PPC machine running Darwin 9 (OSX 10.5) that would
> be willing to run a test of the PR
>
> https://github.com/macports/macports-ports/pull/2296
>
> ? For the reasons outlined in the PR it would be useful to know if
On Jul 24, 2018, at 13:51, Mark Moll wrote:
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/d5637d824ed07189a10a3e32dc135fe909192f8c
>
> commit d5637d824ed07189a10a3e32dc135fe909192f8c
>
> Merge:
On Jul 19, 2018, at 17:46, Mark Moll wrote:
> The py-graph-tool port doesn’t compile on High Sierra (10.13) due to a linker
> error that happens during the configure stage [1]:
>
>
> configure:19051: checking consistency of all components of python development
> environment
> 2037
On Jul 17, 2018, at 10:54, Scott Cantor wrote:
> Scott Cantor (scantor) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/2ef05daf9bd5363708c60a6ddf04ac8a02221356
>
> The following commit(s) were added to
On Jul 13, 2018, at 21:33, Jeremy L wrote:
> On 07/05/2018 01:29 AM, Ryan Schmidt wrote:
>> On Jul 4, 2018, at 14:07, Jeremy L wrote:
>>> Jeremy L (nerdling) pushed a commit to branch master
>>> in repository macports-ports.
>>>
>>>
>>
On Jul 7, 2018, at 07:28, Perry E. Metzger wrote:
> I strongly suggest that you simply fix the issues in question. Were
> it not for the fact that I've had a lot of unavoidable drains on my
> time recently, I would have hand-fixed all of the issues and
> committed the (correct) changes myself,
On Jun 28, 2018, at 12:47, tomio-arisaka wrote:
> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/f564833fda44e715f61fe9c5e34e521a7ddc1882
>
> The following commit(s) were added to
On Jul 6, 2018, at 00:00, Eitan Adler wrote:
> Eitan Adler (grimreaper) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/6935f6ab1cf8b99c9ca0cdaa2f8d03a5566b4e73
>
> The following commit(s) were added to
On Jul 4, 2018, at 10:41, Christopher Jones wrote:
> I am just curious, has anyone else signed up for the 10.14 beta and played
> with it and MacPorts ?
>
> I have been doing this myself, in a VM, and whilst we cannot discuss anything
> here on list, as per the NDA, I would be interested to
On Jul 4, 2018, at 14:07, Jeremy L wrote:
> Jeremy L (nerdling) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/0ef87ed1231742cf86a026814f6e866fef4268db
>
> commit 0ef87ed1231742cf86a026814f6e866fef4268db
>
> Author:
On Jun 27, 2018, at 15:25, Rainer Müller wrote:
> Just to add to the previous discussion, /usr/bin/grep used to be
> GNU grep on older versions of macOS. That is probably the reason why it
> does not implement the g* prefix like the other ports for GNU tools yet.
>
> On 2018-06-27 21:14,
ritz || +1 206 659-8617 || rmfri...@gmail.com
>
> On Tue, Jun 19, 2018 at 5:04 PM, Randolph M. Fritz wrote:
> Wow, thanks.
>
>
>
> --
> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com
>
> On Tue, Jun 19, 2018 at 2:46 PM, Ryan Schmidt wrote:
>
&
On Jun 21, 2018, at 03:44, George Plymale II wrote:
Why are we offering this? Selecting this variant would break any port that
depends on this port. We should strive not to provide users with ways of
shooting themselves in the foot.
>>>
>>> Besides this breaking change,
On Jun 20, 2018, at 23:15, Blair Zajac wrote:
> On Jun 20, 2018, at 7:21 PM, Ryan Schmidt wrote:
>
>> On Jun 20, 2018, at 05:45, George Plymale II wrote:
>>
>>> Marius Schamschula (Schamschula) pushed a commit to branch master
>>> in repository macports-por
On Jun 20, 2018, at 05:45, George Plymale II wrote:
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/35915ffebeb3fc380ca45cdbde23e8ed9a8eb51d
>
> The following commit(s) were added to
On Jun 19, 2018, at 12:15, Randolph M. Fritz wrote:
> Ryan Schmidt – Portfile attached.
Thanks. It references the patchfile cmakelists_patches.diff; could you attach
that too? I want to try to build the port.
On Jun 18, 2018, at 14:20, Randolph M. Fritz wrote:
> This is what I ended up with. I don't like it at all.
>
> pre-destroot {
> # This fixes what may be a cmake error
> catch {
> # look for DESTDIR in the fixup_bundle arguments
> exec grep -q {fixup_bundle.*DESTDIR}
>
On Jun 14, 2018, at 21:05, Mark Moll wrote:
>
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/38cd410e2856185b53446dabe2667cd47969fcce
>
> The following commit(s) were added to refs/heads/master by
On Jun 5, 2018, at 02:29, Jeremy Huddleston Sequoia wrote:
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-base.
>
>
> https://github.com/macports/macports-base/commit/87faa2b7c04210924a051170d46d5577ec5695e8
>
> The following commit(s) were
On Jun 2, 2018, at 16:51, Marius Schamschula wrote:
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/4c13d30353d2d95d746769aad50070aebdb4b688
>
> The following commit(s) were added to
On May 31, 2018, at 12:21, iEFdev wrote:
> I have some 5-6 ports that show this (gptfdisk, flac, etc.).
gptfdisk: https://github.com/macports/macports-ports/pull/1910
flac: I do not see anything wrong with the port. Every invocation of the
clang++ already specifies the -stdlib flag. If
On May 31, 2018, at 10:44, Dr M J Carter wrote:
> On Thu, May 31, 2018 at 07:49:23AM -0700, Ken Cunningham wrote:
>>
>> On 2018-05-30, at 11:04 PM, Joshua Root wrote:
>>
>>> On 2018-5-31 15:39 , Ken Cunningham wrote:
gcc5 is using libstdc++ (this installation is configured to use libc++)
On May 31, 2018, at 00:39, Ken Cunningham wrote:
> pbzip2 is using libstdc++ (this installation is configured to use libc++)
> dylibbundler is using libstdc++ (this installation is configured to use
> libc++)
> lzma is using libstdc++ (this installation is configured to use libc++)
>
On May 30, 2018, at 16:31, macpo...@parvis.nl wrote:
> On 2018-05-30, at 21:47, MacPorts wrote:
>
>> #56562: jbig2dec @0.14: checksum mismatch
>> ---+--
>> Reporter: pdvnl | Owner: (none)
>> Type: defect| Status: new
>> Priority:
On May 29, 2018, at 13:31, macpo...@parvis.nl wrote:
> I'm trying to work as much as possible with scripted procedures.
>
> After an initial install of a new/modified port, I need to apply/change
> patches.
>
> My workflow is:
>
> port install munin
>
> #- cycle start
> port clean
On May 28, 2018, at 21:10, Zero King wrote:
> Hi,
>
> On Thu, May 10, 2018 at 03:58:11PM +1000, Joshua Root wrote:
>> Source code and pkgs for MacPorts 2.5.0-beta1 are now
>> available [1]. Testing of either of these install methods is helpful.
>
> Now that 2.5.0 is released, we should
On May 26, 2018, at 14:38, Ken Cunningham wrote:
> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote:
>
>> The error occurs when there is a mismatch between which C++ standard library
>> a port says it uses (by setting configure.cxx_stdlib, or by leaving it set
>&
On May 26, 2018, at 11:48, Ken Cunningham wrote:
> Well I think you did the cmake finaggeling last time Not sure you could
> find a better way, but I wait to see...
I don't recall what you're referring to.
On May 26, 2018, at 11:15, Ken Cunningham wrote:
> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote:
>
>> It's "broken" in that it links with libstdc++, even though MacPorts believes
>> it will link with libc++ on your system. The rev-upgrade code in previous
On May 25, 2018, at 21:28, Renee Otten wrote:
> On May 25, 2018, at 3:48 PM, Ryan Schmidt wrote:
>
>> Replacement doesn't work (doesn't show up in "port outdated") unless the
>> version or revision of the replacement is higher. So you want "0.7.6_1"
On May 24, 2018, at 09:06, Renee Otten wrote:
> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/bf5b0c8d47ccb5ebd6ea008744708aef2ea6020c
>
> commit bf5b0c8d47ccb5ebd6ea008744708aef2ea6020c
>
On May 25, 2018, at 12:57, Zero King wrote:
> On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:
>> It's been a week with no new tickets filed against base. I'll give it
>> one more week and then, if nothing comes up, tag a release candidate.
>>
>> - Josh
>
> I tried the rc1, and
On May 24, 2018, at 23:15, Ken wrote:
> Ken (kencu) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/5cb3bb12990f7ea682e4b964eb86269923521397
>
> The following commit(s) were added to refs/heads/master by this push:
>
>
On May 24, 2018, at 16:30, Eric Hall wrote:
> ghosthound pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/fd863dfac229f861d7c2245f7e25a0fabc07b814
>
> The following commit(s) were added to refs/heads/master by this push:
On May 22, 2018, at 17:56, David B. Evans wrote:
> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/72943fb126dd2cdb71d5651a42cb9d65398963ef
>
> The following commit(s) were added to
On May 22, 2018, at 06:41, Vincent wrote:
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/73f6c980bb02dcd3cda694f6732b45136b4c6a4f
>
> The following commit(s) were added to refs/heads/master by this
On May 22, 2018, at 04:40, Vincent wrote:
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/9ec4b7c7ec6336ddc0829eeaeb9d03db0de0f122
>
> The following commit(s) were added to refs/heads/master by this
On May 22, 2018, at 06:22, Clemens Lang wrote:
> On 22 May, 2018, at 13:12, Ryan Schmidt wrote:
>
>> I'm confused by the inconsistency between variables like macosx_version and
>> xcodeversion, and the macports_version proc.
>
> xcodeversion and macosx_version ar
On May 22, 2018, at 06:11, Clemens Lang wrote:
>>> The cleanest way of defining a global const variable that I’ve come across
>>> is
>>> with trace, tying the variable to a write command with an explicit error
>>> message.
>>>
>>> But the Tcl wiki page that I linked to previously notes that
On May 22, 2018, at 00:45, Andrew Moore wrote:
> On May 21, 2018, at 5:32 AM, Ryan Schmidt wrote:
>
>> Yes I'm talking about $xcodeversion, and I'm wondering why we don't have a
>> corresponding $macports_version. Why do we have to call a procedure to get
>> the M
On May 21, 2018, at 04:04, Vincent Habchi wrote:
>>> +worksrcdir team-charls-charls-6fa4f2b
>>
>> You should remove this line. The github portgroup handles this for you.
>
> Nope. If I do, I get an error:
>
> Executing: cd
>
On May 21, 2018, at 04:28, Andrew Moore wrote:
> On May 20, 2018, at 9:45 PM, Ryan Schmidt wrote:
>
>> On May 20, 2018, at 17:04, Andrew Moore wrote:
>>
>>> On May 20, 2018, at 8:23 AM, Ryan Schmidt wrote:
>>>
>>>> Why is macports_version a proc
On May 20, 2018, at 17:04, Andrew Moore wrote:
> On May 20, 2018, at 8:23 AM, Ryan Schmidt wrote:
>
>> Why is macports_version a proc and not an option?
>
> To make it read-only? It seems procs and trace are Tcl’s way of defining
> constants.
Variables can be easi
Why is macports_version a proc and not an option?
On May 14, 2018, at 14:31, macpo...@parvis.nl wrote:
> Is it possible to create several startupitems for a single port?
As of MacPorts 2.5.0, yes. 2.5.0 has not yet been released, but a beta just was.
On May 14, 2018, at 00:46, Joshua Root wrote:
> On 2018-5-14 15:31 , Ryan Schmidt wrote:
>>
>> On May 13, 2018, at 23:55, Joshua Root wrote:
>>
>>> On 2018-5-14 14:30 , Ryan Schmidt wrote:
>>>>
>>>> On May 13, 2018, at 22:39, Joshua R
On May 13, 2018, at 23:55, Joshua Root wrote:
> On 2018-5-14 14:30 , Ryan Schmidt wrote:
>>
>> On May 13, 2018, at 22:39, Joshua Root wrote:
>>
>>> Perhaps by recommending the use
>>> of return receipts
>>
>> Email has no such feature.
>
On May 13, 2018, at 22:39, Joshua Root wrote:
> Perhaps by recommending the use
> of return receipts
Email has no such feature.
On May 11, 2018, at 22:17, Ryan Schmidt wrote:
> As for why a dependency on pep8 is being written in path:-style, I don't
> know. I don't see a py-pep8-devel port. I don't know if there is another port
> that provides the same files as py-pep8.
I should have checked the histo
On May 11, 2018, at 21:57, Renee Otten wrote:
> I am trying to understand why in some Python ports the run dependencies are
> declared using path instead of port statements - is there an
> advantage/preference for one over the other?
>
> For example, in the py-spyder-devel Portfile (but also
On May 11, 2018, at 18:34, Zero King wrote:
> On Fri, May 11, 2018 at 12:07:38PM -0500, Ryan Schmidt wrote:
>>
>> On May 10, 2018, at 20:37, Zero King wrote:
>>
>>> Zero King (l2dy) pushed a commit to branch master
>>> in repository macports-ports.
&g
On May 10, 2018, at 07:49, Andrew Stromnov wrote:
> Andrew Stromnov (stromnov) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/ee6a6268d651d4e42247b4f466c51599647a3228
>
> commit ee6a6268d651d4e42247b4f466c51599647a3228
On May 10, 2018, at 20:37, Zero King wrote:
> Zero King (l2dy) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/5836a5624ac40d04cb12a73c4ef219c377100a16
>
> commit 5836a5624ac40d04cb12a73c4ef219c377100a16
>
> Author:
On May 10, 2018, at 20:00, macpo...@parvis.nl wrote:
> - So I propose to change the enforced backend in cairo from quartz to
> fontconfig.
How would that be accomplished?
I thought the quartz variant was only supposed to add optional functionality to
cairo. I turned the variant on
On May 10, 2018, at 19:44, Marcus Calhoun-Lopez wrote:
> On May 9, 2018, at 11:07 AM, Ryan Schmidt wrote:
>
>> My understanding of the fact that they conflict is that there is some latest
>> version of Qt that is compatible with each version of macOS, and that by
>>
On May 9, 2018, at 13:03, Ryan Schmidt wrote:
> The variant needs to contain the "conflicts unixODBC" line, doesn't it?
>
> The unixODBC port still declares that it conflicts with libiodbc. Now it only
> conflicts with libiodbc if the libodbc variant is used, but we
On May 8, 2018, at 13:53, Rainer Müller wrote:
> I appreciate that you stepped up as the maintainer of poedit after I had
> given up on it! [1]
>
> However, the poedit port now bundles full builds of other software, including
> zlib, gettext, boost, icu, and even wxWidgets.
>
> That really
On May 9, 2018, at 07:18, Craig Treleaven wrote:
> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote:
>
>> I was in the process of modifying the Qt5 Port group to allow for choosing
>> the Qt version one wants to link an application against using variants.
>> However, before I go further, I’d
On May 7, 2018, at 10:39, Jeremy L wrote:
> Jeremy L (nerdling) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/c175b9ba889d42decf33b787906eb70801265031
>
> The following commit(s) were added to refs/heads/master by this
On May 8, 2018, at 08:49, Nicolas Pavillon wrote:
> NicosPavlov pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/f578df0c2a5e1479fa834624b11e487ed79b23cb
>
> The following commit(s) were added to refs/heads/master by this
On May 7, 2018, at 16:18, Jackson Isaac wrote:
> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/1b77897c4010309d7346607ff5b5728dac50dd88
>
> The following commit(s) were added to
On May 7, 2018, at 09:22, Perry E. Metzger wrote:
> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/6c30941ab56093c30c52cd10c87cd0b776b0232c
>
> The following commit(s) were added to
On May 7, 2018, at 08:06, Marius Schamschula wrote:
> What is the proper way of dealing with obsoleted subports?
For each subport, mark it replaced by its replacement.
The py-cherrypy3 port shows one way that this could be accomplished.
On May 5, 2018, at 10:14, Marius Schamschula wrote:
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/183d848728bcdec1ac30dce5260f0437feeda485
>
> commit
On May 7, 2018, at 07:41, Perry E. Metzger wrote:
> When pull requests come in, users are asked to fill out a short
> checklist. I'd like to add a reminder to squash your commits into it
> -- this has become a frequent issue with pull requests from new
> contributors.
>
> Where do I find the
On May 6, 2018, at 15:34, Joshua Root wrote:
> On 2018-5-6 20:37 , Ryan Schmidt wrote:
>>
>> On May 5, 2018, at 20:54, Joshua Root wrote:
>>
>>> We record what stdlib it was *asked*
>>> to build with in the registry. The stdlib it actually was bui
On May 5, 2018, at 20:54, Joshua Root wrote:
> On 2018-5-6 10:05 , Ryan Schmidt wrote:
>>
>> On May 5, 2018, at 19:04, Joshua Root wrote:
>>
>>> On 2018-5-6 09:55 , Ryan Schmidt wrote:
>>>>
>>>> On May 5, 2018, at 16:36, Jackson Isaac wr
On May 4, 2018, at 08:05, Perry E. Metzger wrote:
> Yesterday, Ryan pointed out in the course of a pull request that the
> port in question still had support for python 2.5(!).
It needn't be a surprise that the ports (InsightToolkit*) have python 2.5
support. The ports simply offer python
On May 6, 2018, at 05:27, Chris Jones wrote:
> On 6 May 2018, at 11:19 am, Ryan Schmidt wrote:
>
>> On May 6, 2018, at 05:18, Rainer Müller wrote:
>>
>>> On 2018-05-06 12:07, Ryan Schmidt wrote:
>>>
>>>> On May 5, 2018, at 19:36, Craig Treleav
On May 6, 2018, at 05:18, Rainer Müller wrote:
> On 2018-05-06 12:07, Ryan Schmidt wrote:
>>
>> On May 5, 2018, at 19:36, Craig Treleaven wrote:
>>
>>> A couple of times recently, I’ve noticed boilerplate in ports that require
>>> C++14. After in
On May 4, 2018, at 17:33, Rainer Müller wrote:
> On 2018-05-03 09:14, Zero King wrote:
>> On Thu, May 03, 2018 at 08:51:49AM +0200, Mojca Miklavec wrote:
>>> On 1 May 2018 at 16:11, Rainer Müller wrote:
The guide uses "Portfile-rrdtool.diff" as an example filename [1]. Some
users
On May 5, 2018, at 19:36, Craig Treleaven wrote:
> A couple of times recently, I’ve noticed boilerplate in ports that require
> C++14. After including the compiler_blacklist_versions portgroup, they then
> do some gymnastics like:
>
> compiler.blacklist *gcc-3.* *gcc-4.*
On May 5, 2018, at 19:04, Joshua Root wrote:
> On 2018-5-6 09:55 , Ryan Schmidt wrote:
>>
>> On May 5, 2018, at 16:36, Jackson Isaac wrote:
>>
>>> +## Upstream binary seems to be built using libstdc++
>>>
>>> +# Port keeps failing on rev-upgra
On May 5, 2018, at 16:36, Jackson Isaac wrote:
> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/efaaa894e2e0a8af5e9918d296889db9929e7103
>
> The following commit(s) were added to
> On May 2, 2018, at 03:43, Chris Jones wrote:
>
>> You don't really need [expr] here, do you?
>
> It seemed to work, and I think I just copied the pattern above from another
> Portfile...
I've submitted a PR to remove that pattern from the other ports:
On May 1, 2018, at 12:52, Chris Jones wrote:
> +# Enable variants that only seem to work when not using macports clang...
> +if [expr ![string match macports-clang-* ${configure.compiler}] ] {
> +default_variants-append +veccore +davix
> +}
You don't really need [expr] here, do you?
On Apr 30, 2018, at 23:17, David Strubbe wrote:
> David Strubbe (dstrubbe) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/16798c052e98961df280c859023ed49a9ab0cab5
>
> The following commit(s) were added to
On Apr 30, 2018, at 23:37, David Strubbe wrote:
> David Strubbe (dstrubbe) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/78bce97dd6c1368229e320435a4dbf20c4fd4aed
>
> The following commit(s) were added to
On Apr 28, 2018, at 01:10, Takeshi Enomoto wrote:
> Takeshi Enomoto (tenomoto) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/218d3fd276c65f9e22e19f7ec3ef686322e6a156
>
> The following commit(s) were added to
On Apr 30, 2018, at 20:16, Rainer Müller wrote:
> However, why do we add a license header to the port groups at all?
> We also do not add it to each Portfile. I think we should drop the
> license headers from all port groups.
Files in base have the copyright header. Portgroups used to be in
On Apr 30, 2018, at 10:06, Perry E. Metzger wrote:
> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/6b1fe110a0a558d323ebc8b62ca8fb9938d824c1
>
> The following commit(s) were added to
On Apr 30, 2018, at 15:12, Jackson Isaac wrote:
> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/5624f07530e7dc202fd9d57b378232dd3fa4b1bf
>
> The following commit(s) were added to
On Apr 30, 2018, at 13:09, Zero King wrote:
> I'd like to mirror unar's distfile for backup, but "it has already been
> built and uploaded" so mirror was skipped if I force build the port on a
> portwatcher and I can't force a mirror job directly.
Yes, we need to allow forcing the mirroring job
On Apr 29, 2018, at 22:26, Ryan Schmidt wrote:
> I'm not talking about removing or altering Apple's copyright notices; of
> course they should remain. I'm talking about clause 3 of the license, the
> non-endorsement clause.
>
> I didn't claim we should add a second slightly di
On Apr 29, 2018, at 20:23, Helmut K. C. Tessarek wrote:
> On 2018-04-29 07:23, Joshua Root wrote:
>> Were dependencies declared on the ports providing those libraries? If
>> not, trace mode was just doing its job.
>
> $ sudo port build -vst fontforge
> ---> Computing dependencies for fontforge
On Apr 29, 2018, at 20:53, Ken Cunningham wrote:
> We should probably just make pkg-config a default dependency for _every_
> build and save everyone a pile of heartburn.
No, obviously not. Declare a dependency on pkg-config when pkg-config is
required. Simple.
On Apr 29, 2018, at 18:21, David B. Evans wrote:
> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/513f00900b7bf397b5d8206ca676481c09f9d84b
>
> commit 513f00900b7bf397b5d8206ca676481c09f9d84b
>
On Apr 26, 2018, at 10:16, Ryan Schmidt wrote:
>> Not quite. I'm noting that the package version isn't a reliable
>> indication of the ABI version, and neither (sadly, see the current
>> protobuf issues and the issues with LibreSSL) is the library dylib
>> name. Th
801 - 900 of 1515 matches
Mail list logo