On Apr 19, 2018, at 00:08, Helmut K. C. Tessarek wrote:
> On 2018-04-19 00:08, Ryan Schmidt wrote:
>> Note that there is a ticket requesting this update:
>>
>> https://trac.macports.org/ticket/43844
>>
>> There isn't any work done there, but there is
I can't seem to use Expect in a portfile. Using the following minimal portfile:
PortSystem 1.0
name foo
version 1
fetch {
system "expect -c 'spawn echo hello; interact;'"
}
And running:
sudo port fetch
I get this unexpected output:
The system has no more ptys. Ask your system adminis
On Apr 19, 2018, at 06:49, Rainer Müller wrote:
> On 2018-04-19 13:31, Ryan Schmidt wrote:
>> I can't seem to use Expect in a portfile. [...]
>>
>> The system has no more ptys. Ask your system administrator to create more.
>
> This is probably due to sandboxi
On Apr 19, 2018, at 07:54, Rainer Müller wrote:
> On 2018-04-19 12:44, Ryan Schmidt wrote:
>> If I try to build minivmac in trace mode (sudo port -t install minivmac) it
>> fails because:
>>
>> Warning: The following existing files were hidden from the bui
On Apr 19, 2018, at 07:19, Rainer Müller wrote:
> On 2018-04-19 13:58, Ryan Schmidt wrote:
>>
>> On Apr 19, 2018, at 06:49, Rainer Müller wrote:
>>
>>> On 2018-04-19 13:31, Ryan Schmidt wrote:
>>>> I can't seem to use Expect in a portfile. [..
On Apr 23, 2018, at 08:36, Leonardo Brondani Schenkel wrote:
> Leonardo Brondani Schenkel (lbschenkel) pushed a commit to branch icu
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/0c47ec4d30dc02c085dd851262cf2fcbbb0b1521
>
> commit 0c47ec4d30dc02c085dd8
On Apr 23, 2018, at 14:19, Perry E. Metzger wrote:
> I'm thinking of adding the following to the MacPorts guide because we
> often have problems with people picking invalid license names in
> Portfile submissions.
>
> That said, I'm not sure this is the best text for it. Thoughts?
I don't want
On Apr 23, 2018, at 14:46, Jan Stary wrote:
Man, you sure love to argue about stuff.
> The asciidoc is what you don't see on you terminal.
> The resulting man(7) page is what you see, rendered
> by either groff (typically) or mandoc.
Asciidoc is what we see in an editor when we edit the manual
On Apr 23, 2018, at 16:21, Perry E. Metzger wrote:
> On Mon, 23 Apr 2018 15:24:20 -0500 Ryan Schmidt wrote:
>> On Apr 23, 2018, at 14:19, Perry E. Metzger wrote:
>>
>>> I'm thinking of adding the following to the MacPorts guide
>>> because we often hav
On Apr 24, 2018, at 11:37, Artur Szostak wrote:
>>> So then there is a bug from what I understand, or cfitsio in MacPorts is
>>> being built incorrectly. Compare file names for the newer Cfitsio:
>>> /opt/local/lib/libcfitsio.6.3.44.dylib
>>> /opt/local/lib/libcfitsio.6.dylib -> libcfitsio.6.3
On Apr 25, 2018, at 10:10, Joshua Root wrote:
> On 2018-4-26 00:25 , Perry E. Metzger wrote:
>> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root wrote:
>>> On 2018-4-25 03:56 , Ken Cunningham wrote:
Waiting for the maintainer to review the ticket submission
someday often resulted in months
On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
>> Portfile authors need to manually "revbump" the library's dependent
>> ports when supporting libraries change significantly.
>>
>> It's not automatically figured out by MacPorts.
>
>
On Apr 25, 2018, at 11:31, Chris Jones wrote:
> Personally, I would like to see MacPorts go in exactly the opposite
> direction, so migrate away from using trac for anything much. I also happen
> to think, one way or another this will naturally happen as people get used
> to, and see all the a
On Apr 25, 2018, at 11:23, Chris Jones wrote:
> I don't think there is any need to re-invent our own system here. There is an
> already standard why of dong this, which is to declare the request as 'Work
> In Progress'. This is trivially done by adding 'WIP' to the start of the PR
> title.
Wou
On Apr 25, 2018, at 13:02, Chris Jones wrote:
> On 25 Apr 2018, at 5:46 pm, Ryan Schmidt wrote:
>
>>> On Apr 25, 2018, at 11:31, Chris Jones wrote:
>>>
>>> Personally, I would like to see MacPorts go in exactly the opposite
>>> direction, so migrate
On Apr 25, 2018, at 13:12, Chris Jones wrote:
> Labels are fine. A label can be used to mark a MR as WIP. my point is we
> should mark them in a standard way, that triggers github to correctly treat
> the MR as ‘work in progress’ the same way as every other project on github
> does...
Sure.
On Apr 25, 2018, at 14:14, Perry E. Metzger wrote:
> I don't know that this is needed. As I noted, there are other package
> systems that just note that they have to rebuild dependents if a
> package they depend on has a major version bump.
>
> Or maybe I don't understand the problem well enough
On Apr 25, 2018, at 14:26, Perry E. Metzger wrote:
> So the package in question is "rethinkdb",
> packages.macports.org doesn't seem to show the package there. Does
> that mean it indeed hasn't built in a long time?
In this case, it means rethinkdb is not distributable.
On Apr 25, 2018, at 17:14, Jan Stary wrote:
> On Apr 25 10:34:47, Ryan Schmidt wrote:
>
>> On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
>>> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
>>>> Portfile authors need to manually "revbump&qu
On Apr 25, 2018, at 16:50, Jan Stary wrote:
> On Apr 25 14:44:51, Ryan Schmidt wrote:
>
>> On Apr 25, 2018, at 14:26, Perry E. Metzger wrote:
>>
>>> So the package in question is "rethinkdb",
>>
>>> packages.macports.org doesn't see
On Apr 25, 2018, at 20:07, Zero King wrote:
> On Wed, Apr 25, 2018 at 11:47:21AM -0500, Ryan Schmidt wrote:
>> On Apr 25, 2018, at 11:23, Chris Jones wrote:
>>
>>> I don't think there is any need to re-invent our own system here. There is
>>> an already
I'm not working on this problem. There are far too many other things that I
already intend to be working on. My questions were just meant to prompt thought
about whether MacPorts currently provides the information required to implement
the feature. My belief is that it does not, but I am not spe
On Apr 26, 2018, at 10:00, Perry E. Metzger wrote:
> On Thu, 26 Apr 2018 23:54:49 +1000 Joshua Root wrote:
>>> So rather than just guessing based on things like major version
>>> of a library whether dependents need to be bumped, I would
>>> suggest we add an "abiversion" keyword. Changing it in
On Apr 26, 2018, at 10:12, Perry E. Metzger wrote:
> On Thu, 26 Apr 2018 10:03:59 -0500 Ryan Schmidt wrote:
>> On Apr 26, 2018, at 10:00, Perry E. Metzger wrote:
>>
>>> On Thu, 26 Apr 2018 23:54:49 +1000 Joshua Root wrote:
>>>>> So rather than just gues
On Apr 26, 2018, at 00:48, Jan Stary wrote:
> On Apr 26 03:16:37, Rainer Mueller wrote:
>> On 2018-04-26 00:11, Jan Stary wrote:
>>> On Apr 24 09:31:04, ken.cunningham.web...@gmail.com wrote:
Portfile authors need to manually "revbump"
the library's dependent ports when
supporting
On Apr 26, 2018, at 01:03, Jan Stary wrote:
> BTW, what's with the version numbers in e.g.
> otool -L /opt/local/bin/openssl:
> /opt/local/lib/libssl.45.dylib (compatibility version 46.0.0, current version
> 46.1.0)
>
> libssl.45.dylib is what the vanilla tarball itself produces.
> Where exactl
On Apr 26, 2018, at 10:15, Ken Cunningham wrote:
> On 2018-04-26, at 8:09 AM, Joshua Root wrote:
>
>> Detecting this situation and rebuilding locally is automatic. Actually
>> increasing the revision of the dependents so updated archives are made
>> available is not.
>
> There's next years GS
On Apr 26, 2018, at 10:15, Joshua Root wrote:
> On 2018-4-27 01:07 , Renee Otten wrote:
>> I am looking at updating some (nonmaintained) python ports and have two
>> questions for now:
>>
>> 1. if a project releases both on GitHub and PyPI is there a preference for
>> using one over the other
On Apr 26, 2018, at 01:52, Mojca Miklavec wrote:
> 3.) This is not a problem for new issues, but for migration of old
> issues: When attempting the initial migration, GitHub would not let us
> keep the original ticket numbering and would assign a semi-random
> number to the issues.
Providing a r
I am working on implementing https://trac.macports.org/ticket/56055. As a
result, I have a number of generated files in the /dist/ directory that I was
working with, and a number of hand-crafted variations of those files for
experimentation.
I needed to take a break from this task, and switch t
On Apr 26, 2018, at 15:48, Rainer Müller wrote:
> On 2018-04-26 22:31, Clemens Lang wrote:
>> | Error: Checksum (rmd160) mismatch for coffee-script-1.3.3.tar.gz
>> | Portfile checksum: coffee-script-1.3.3.tar.gz rmd160
>> 22cf20180c06c92f5fdc223180ba94bb96b6ff7b
>> | Distfile checksum: coffee-sc
On Apr 26, 2018, at 20:38, Michael wrote:
> On 2018-04-26, at 5:01 PM, Ryan Schmidt wrote:
>
>> To do this, I was first required to stash or commit my unfinished work. I
>> used git stash, followed by git checkout my-other-branch. After finishing
>> work there, I
On Apr 27, 2018, at 08:18, Clemens Lang wrote:
> Clemens Lang (neverpanic) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/28e47077426b9b63f4d10ca07af9e0547a13dd69
>
> The following commit(s) were added to refs/heads/mast
On Apr 27, 2018, at 08:10, Joshua Root wrote:
> 'move' still handles some case-sensitivity issues, but indeed 'copy' and
> 'delete' are just aliases these days. I think we don't need to
> discourage the use of 'file', since if you hit the one fairly rare case
> where there's a difference you'll
On Apr 27, 2018, at 16:11, Joshua Root wrote:
> On 2018-4-28 06:25 , Ryan Schmidt wrote:
>
>> On Apr 27, 2018, at 08:10, Joshua Root wrote:
>>
>>
>>> 'move' still handles some case-sensitivity issues, but indeed 'copy' and
>>>
On Apr 27, 2018, at 16:22, Rainer Müller wrote:
> On 27 April 2018 23:12:31 GMT+02:00, Ryan Schmidt wrote:
>>
>> On Apr 27, 2018, at 16:11, Joshua Root wrote:
>>
>>> On 2018-4-28 06:25 , Ryan Schmidt wrote:
>>>
>>>> On Apr 27, 2018, at 08:10
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
>> n
On Apr 27, 2018, at 18:24, Rainer Müller wrote:
> destroot {} is exactly meant for this kind of code. If muniversal cannot
> handle it, supporting +universal is not important enough for me to maintain
> this.
muniversal does not support overridden destroot blocks. It requires the ability
to r
I know this was already reverted from master because you meant to do it on a
branch, but:
On Apr 27, 2018, at 17:33, Marcus Calhoun-Lopez wrote:
> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macp
On Apr 27, 2018, at 22:27, Helmut K. C. Tessarek wrote:
> On 2018-04-27 22:34, Perry E. Metzger wrote:
>> It was a bunch of work figuring out exactly what to do (it took me
>> almost an hour) but I think I've done a proper revert commit.
>
> If you have any git related questions, please drop me
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 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 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 21:04, Ken Cunningham wrote:
> The problem is that it is rarely clear that pkg-config is the missing thing.
> This script did say so. Often it just errors out with missing things that are
> clearly there.
It's true I have been doing this awhile, but it doesn't seem like it
On Apr 18, 2018, at 03:15, Jan Stary wrote:
> On Apr 17 14:33:12, Rainer Mueller wrote:
>>> https://lists.macports.org/pipermail/macports-dev/2018-March/037750.html
>>
>> The previous code always used /usr/bin/git, even if the git port was
>> installed. Only old versions of macOS got to use the
On Apr 28, 2018, at 04:31, Joshua Root wrote:
> On 2018-4-28 13:04 , Ryan Schmidt wrote:
>> According to WikiPedia, "All rights reserved" has no effect in any legal
>> jurisdiction:
>>
>> https://en.wikipedia.org/wiki/All_rights_reserved
>>
>&
On Apr 29, 2018, at 22:49, Helmut K. C. Tessarek wrote:
> On 2018-04-29 22:02, Ryan Schmidt wrote:
>> Nothing hmm. The port doesn't declare a dependency on pkgconfig, therefore
>> trace mode hides the pkg-config executable from the build system. The build
>> system ne
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
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 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 refs/heads/m
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 refs/head
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 base
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 refs/heads/
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 refs/heads/mast
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 refs/heads/mast
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 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:
https://github.com/macports/macports-po
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 refs/heads/m
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 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.* {*gcc-5.[0-3
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 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 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 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 varia
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 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 built w
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 che
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 183d848728bcdec1ac30dce5260f0437fe
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 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 refs/heads
On May 7, 2018, at 15:35, Perry E. Metzger wrote:
> On Mon, 7 May 2018 09:55:17 -0500 Ryan Schmidt wrote:
>> When I submit a PR to add a maintainer's GitHub handle to their
>> ports, I assign the ticket to them (if I can; if I can't, because
>> they're not in
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 refs/heads/m
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 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 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 l
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 sh
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 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 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 uncondition
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: Zero
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 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 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 t
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 ch
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 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 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 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.
Why is macports_version a proc and not an option?
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
On May 20, 2018, at 12:55, Vincent wrote:
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/e20fd1d6c0ea4426f9c0f73261b9669fc41a7252
>
> The following commit(s) were added to refs/heads/master by this pus
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 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
> "/opt/local/var/macports/build/_macports-ports_graphics_ch
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
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 "co
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 are
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 pus
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 pus
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 refs/heads/mas
On May 25, 2018, at 08:54, Rainer Müller wrote:
> On 2018-05-24 20:56, Vincent Habchi wrote:
>>> I don’t understand the licensing requirements, but I find this to be a
>>> convenient port for getting Mr. Sid support with the MacPorts gdal. I find
>>> it useful and hope that it can remain as lon
101 - 200 of 1750 matches
Mail list logo
