> On Jan 13, 2017, at 18:22, Marius Schamschula wrote:
>
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
>
> https://github.com/macports/macports-ports/commit/34767d74a27ef02f00bde27cb79a762f46bd6b00
>
> The following commit(s) were added to
For reference, I assume we're talking about the patch proposed in this ticket:
https://trac.macports.org/ticket/52144
On 2017-1-14 07:28 , Daniel J. Luke wrote:
On Jan 13, 2017, at 3:01 PM, Craig Treleaven wrote:
Suppose I create an mpkg installer just for mariadb-server. The scripts are
included for the mariadb-server component, as expected. However, when ‘port
mpkg’ builds the installer component for the
On Jan 13, 2017, at 3:01 PM, Craig Treleaven wrote:
> Suppose I create an mpkg installer just for mariadb-server. The scripts are
> included for the mariadb-server component, as expected. However, when ‘port
> mpkg’ builds the installer component for the mariadb (client) software is
> ALSO in
Hi:
A few months ago, I had been working on a new mpkg installer for my mythtv.28
ports and I’m trying to get back to it. A new element was using Preinstall and
Postinstall scripts to automate some of initialization steps. I was puzzled as
the installer log showed that these scripts were bein
--- a/python/py-jinja2/Portfile
+++ b/python/py-jinja2/Portfile
@@ -4,7 +4,7 @@ PortSystem 1.0
PortGroup python 1.0
namepy-jinja2
-version 2.8.1
+version 2.9.4
categories-append devel
license BSD
maintainers jmr
On 2017-1-14 03:02 , Mark Moll wrote:
On Jan 13, 2017, at 1:24 AM, Ryan Schmidt wrote:
@@ -100,6 +100,10 @@ if {${name} ne ${subport}} {
if {${python.version} eq "27"} {
configure.env-append PYTHON_EXTRA_LIBS="-u _PyMac_Error"
}
+# Something similar is happening with pyth
> On Jan 13, 2017, at 1:24 AM, Ryan Schmidt wrote:
>
>
>> On Jan 11, 2017, at 08:56, Mark Moll wrote:
>>
>> Mark Moll (mamoll) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/ac9a9ab102bc2026808f6a869d6fdbed4143452
> Is "sqlite3 CLI shell" the 'sqlite3' binary that is already installed by the
> sqlite3 port?
Yes. So as a separate port I would skip that binary and provide only sqldiff
and sqlite3_analyzer.
> I would think a separate port (or subport) would be better. A non-default
> variant would not be a
On 2017-1-12 18:58 , Aaron Madlon-Kay wrote:
Hi all. I was hoping to get some advice:
I want to make the sqlite3-tools package available via MacPorts
(binaries available at https://sqlite.org/download.html); this package
contains three binaries: sqlite3 CLI shell, sqldiff, and sqlite3_analyzer.
> Whatever you choose, anytime you move a file from being provided by one port
> to being provided by another port, don't forget to use the deactivate hack in
> the new port:
>
> https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
Thanks for pointing this out.
I added this, but I won
You might also consider changing the dependency to a
bin:something:texinfo type rather than port:texinfo as I did in
https://trac.macports.org/ticket/49746 for LyX.
Russell
On 13/01/17 11:52, Vincent Habchi wrote:
Josh,
thanks for the pointer. What I’ll do (since texlive seems to be require
Josh,
thanks for the pointer. What I’ll do (since texlive seems to be required only
to build the doc) is to add a doc variant that will pull the dependencies in
but only when required.
However, I’m not sure how to build the docs :) So I guess I’ll have to dredge a
bit deeper.
Thanks again,
Vi
On 2017-1-13 22:42 , Vincent Habchi wrote:
Folks,
I was in the process of upgrading ffmpeg when I suddenly jumped out of my
chair: the build was trying to pull in the bloated texlive source.
I traced that spurious dependency to libunistring. Commenting out the
dependency on texlive-basic does
Folks,
I was in the process of upgrading ffmpeg when I suddenly jumped out of my
chair: the build was trying to pull in the bloated texlive source.
I traced that spurious dependency to libunistring. Commenting out the
dependency on texlive-basic does not produce any side effect (AFAIK): the
p
On 2017-01-13 03:16, Ryan Schmidt wrote:
> I know. And we want the history of our main repository to be reasonable, so
> it's necessary to fix PRs before merging.
Definitely should have been squashed into a single commit. At the moment
this needs to be done by the person taking the pull request i
16 matches
Mail list logo
