> On Dec 13, 2016, at 7:56 AM, Luc Bourhis wrote:
>
> file://path/to/my/clone/of/macports-ports [default]
Note that you have to use three slashes at the beginning of this line because
the "/" that begins the absolute path is distinct from the "://" that separates
the protocol. So:
file:///pat
> On 13 Dec 2016, at 20:14, Mojca Miklavec wrote:
>
> On 13 December 2016 at 20:08, Luc Bourhis wrote:
>>
>>> (Ruby is completely outdated and only the interpreter works, packaging
>>> is completely unmaintained.
>>
>> MacPorts provide ruby 2.3, which is not outdated, is it?
>
> Ruby is fine,
On 13 December 2016 at 20:08, Luc Bourhis wrote:
>
>> (Ruby is completely outdated and only the interpreter works, packaging
>> is completely unmaintained.
>
> MacPorts provide ruby 2.3, which is not outdated, is it?
Ruby is fine, the rest is questionable.
For example
rb-rails @2.3.5_1
rb
Hi Mojca,
> On 13 December 2016 at 16:32, Luc Bourhis wrote:
>> Hi,
>>
>> I am writing an update for the fsharp port (F# language), which is very
>> outdated. This requires an update to the mono port, from version 3 to 4. One
>> could make the case to support every x.y version of Mono and F# as
Hi,
May I attract some attention to a rather interesting issue building ruby2+?
https://trac.macports.org/ticket/53045
Thanks,
R.
Hi,
On 13 December 2016 at 16:32, Luc Bourhis wrote:
> Hi,
>
> I am writing an update for the fsharp port (F# language), which is very
> outdated. This requires an update to the mono port, from version 3 to 4. One
> could make the case to support every x.y version of Mono and F# as MacPorts
> d
Hi,
I am writing an update for the fsharp port (F# language), which is very
outdated. This requires an update to the mono port, from version 3 to 4. One
could make the case to support every x.y version of Mono and F# as MacPorts
does for python, ruby, etc and then to let the user choose with po
On Wednesday December 14 2016 02:17:40 Joshua Root wrote:
>I couldn't quite parse that sentence, but install does indeed do
>rev-upgrade at the end.
Indeed, I just saw it doing that, but I'm still quite certain it does not do
this systematically.
>Every long option can be abbreviated as much a
On 2016-12-14 01:13 , René J.V. Bertin wrote:
On Wednesday December 14 2016 00:26:18 Joshua Root wrote:
It was probably always fairly safe to interrupt rev-upgrade in report
mode. Any database writes it does to update the binary flag are in a
sqlite transaction.
I bet, but I've already found
On Wednesday December 14 2016 00:26:18 Joshua Root wrote:
> It was probably always fairly safe to interrupt rev-upgrade in report
> mode. Any database writes it does to update the binary flag are in a
> sqlite transaction.
I bet, but I've already found myself with a corrupted registry which can
>> Thanks. Do I need to run `portindex` in that directory
>> //path/to/my/clone/of/macports-ports ?
>
> Yes, although that will be done for you as part of 'port sync' (which is part
> of selfupdate).
>
>>> Another option is to have a repo with just the ports you're working on and
>>> set it up
On 2016-12-14 00:19 , Luc Bourhis wrote:
On 13 Dec 2016, at 14:13, Joshua Root wrote:
On 2016-12-13 23:56 , Luc Bourhis wrote:
I was considering to only fork macports-ports so that I can use pull requests
for ports, without having to build macports core from source. But then what is
the
On 2016-12-14 00:11 , René J.V. Bertin wrote:
Hi,
I understand that the latest update introduced better handling of interrupts.
Is it now safe to interrupt the rev-upgrade process done after a `port upgrade`
(knowing that I configured it to check only)?
2.3.5 does not have signal handling. O
On 2016-12-13 23:56 , Luc Bourhis wrote:
Hi,
I was considering to only fork macports-ports so that I can use pull requests
for ports, without having to build macports core from source. But then what is
the best way to configure macports on my system? Shall I replace the line
rsync://rsync.mac
Hi,
I understand that the latest update introduced better handling of interrupts.
Is it now safe to interrupt the rev-upgrade process done after a `port upgrade`
(knowing that I configured it to check only)?
I often miss an option to skip that step (esp. the first of the day which
always takes
On Tuesday December 13 2016 12:46:39 Mojca Miklavec wrote:
> The hack sounds better to me, but it's eventually your choice.
> Maintainer will be the one that will have to handle all tickets on
> Trac :)
PS: in this case it'll be better to check for the epoch (after setting it
globally, not just
Hi,
I was considering to only fork macports-ports so that I can use pull requests
for ports, without having to build macports core from source. But then what is
the best way to configure macports on my system? Shall I replace the line
rsync://rsync.macports.org/release/tarballs/ports.tar [defau
On Tuesday December 13 2016 12:46:39 Mojca Miklavec wrote:
> If something goes wrong during the build, it won't deactivate the old
> port. It would only be a "problem" if there would be an additional
> error during activation of qtcurve-extra. And even then one could
> always activate the old port
On 13 December 2016 at 11:45, René J.V. Bertin wrote:
> On Tuesday December 13 2016 11:22:09 Mojca Miklavec wrote:
>
>>So:
>>- you have an old qtcurve installed
>>- the new qtcurve will have a new runtime dependency qtcurve-extra
>>- qtcurve-extra doesn't depend on qtcurve, but fails to activate if
On Tuesday December 13 2016 11:22:09 Mojca Miklavec wrote:
>So:
>- you have an old qtcurve installed
>- the new qtcurve will have a new runtime dependency qtcurve-extra
>- qtcurve-extra doesn't depend on qtcurve, but fails to activate if
>qtcurve is already installed?
>
>Or did I misunderstand som
On 13 December 2016 at 10:54, René J.V. Bertin wrote:
> On Tuesday December 13 2016 10:30:24 Mojca Miklavec wrote:
>
>>See:
>>https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
>
> Ah, yes, I forgot about that link, though I did consider deactivating in the
> pre-activate phase. It'
On Tuesday December 13 2016 10:30:24 Mojca Miklavec wrote:
>See:
>https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
Ah, yes, I forgot about that link, though I did consider deactivating in the
pre-activate phase. It'll be a bit trickier here because I'd be deactivating an
older
On 13 December 2016 at 10:05, René J.V. Bertin wrote:
> Marko Käning wrote on 20161213::06:29:51
>
>>Was easy to fix by uninstalling qtcurve.
>>Yet it would have been nicer to recommend the uninstallation of a too old
>>qtcurve in qtcurve-extra.
>
> This is the kind
Marko Käning wrote on 20161213::06:29:51 re: "qtcurve update failure"
>Just got this:
>--> Computing dependencies for qtcurve-extra
>---> Activating qtcurve-extra @1.8.18_2
>Error: org.macports.activate for port qtcurve-extra returned: Image error:
>/opt
On 13 December 2016 at 06:02, Marko Käning wrote:
> Hi MacPorts core devs,
>
> I was wondering whether it is possible to configure the buildbots in such a
> way
> that they can observe if a just rebuilt port is a dependency of other ports
> which
> haven’t been built successfully yet. If such a c
25 matches
Mail list logo
