Re: fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)

On Wed, Mar 4, 2015 at 10:53 PM, Rainer Müller wrote: > On 2015-03-04 22:27, Mojca Miklavec wrote: >>> I agree with you, creating the distfiles from VCS would be possible. >>> >>> There could be a target to be run on 'port mirror' that downloads and >>> creates a tarball if a non-default fetch.type

Re: fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)

On 2015-03-04 22:27, Mojca Miklavec wrote: >> I agree with you, creating the distfiles from VCS would be possible. >> >> There could be a target to be run on 'port mirror' that downloads and >> creates a tarball if a non-default fetch.type is used. That alone would >> reduce multiple downloads and

Re: fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)

On Wed, Mar 4, 2015 at 12:02 PM, Rainer Müller wrote: > On 2015-03-04 10:10, Mojca Miklavec wrote: >> On Mon, Mar 2, 2015 at 11:37 AM, Rainer Müller wrote: >>> On 2015-03-02 10:40, Clemens Lang wrote: FWIW, the textmate2 Portfile has the same problem, and I've just used fetch.

Re: port upgrade outdated order

On Mar 4, 2015, at 10:46 AM, René J.V. Bertin wrote: >> Also, you'd have to make sure that foo-B builds correctly or, if >> it fails, activate foo-A again after it failed. I don't know whether >> MacPorts base can do this. I doubt it does. > > No, I think it can't. However, if a conflict is not

Re: port upgrade outdated order

On 04.03.2015 07:59 PM, René J.V. Bertin wrote: > @ larry >> Base doesn't have a concept of equivalence. [...] We could >> implement virtual ports or something like that, but that's a rather >> larger project. > Would be more like Debian's "replaces", no? [...] Mind you, Debian's > implementation i

Re: port upgrade outdated order

On Mar 4, 2015, at 1:59 PM, René J.V. Bertin wrote: > @ larry >> Base doesn't have a concept of equivalence. It doesn't know that qt5-mac and >> qt5-mac-devel are interchangeable. We could implement virtual ports or >> something like that, but that's a rather larger project. > > Would be more li

Re: port upgrade outdated order

On Wednesday March 04 2015 17:32:59 Chris Jones wrote: > > As to fixing ... the experience many of use have had with /usr/local can > > probably serve as an example/metaphor for why it's not always feasible to > > avoid including the wrong version of a header... (and I guess it should be > > ea

Re: port upgrade outdated order

On Wednesday March 04 2015 18:52:27 Mihai Moldovan wrote: > Probably because it has never been implemented. Patches welcome, I > guess? Probably requiring more knowledge of the internals than I currently have ... > Also, you'd have to make sure that foo-B builds correctly or, if > it fails, acti

Re: port upgrade outdated order

Hi *, please stop spamming so fast, I can't keep up with the responses. - On 4 Mar, 2015, at 17:52, René J.V. Bertin rjvber...@gmail.com wrote: > On a related note: it'd be nice if MacPorts could be a little bit more > proactive > in deactiving conflicting ports. Like when installing a subp

Re: port upgrade outdated order

On Mar 4, 2015, at 11:52 AM, René J.V. Bertin wrote: > On a related note: it'd be nice if MacPorts could be a little bit more > proactive in deactiving conflicting ports. Like when installing a subport > that conflicts with one of its siblings. If both are at the same version I > don't see why

Re: port upgrade outdated order

On 04.03.2015 06:29 PM, René J.V. Bertin wrote: > On Wednesday March 04 2015 17:34:32 Mihai Moldovan wrote: > >>> Aren't you relying on the assumption that all ports register all the files >>> they install? >> >> They really should. If they don't, that's arguably a bug. Exceptions may >> apply. >

Re: port upgrade outdated order

On 04.03.2015 05:52 PM, René J.V. Bertin wrote: > On Wednesday March 04 2015 17:16:29 Mihai Moldovan wrote: > >> Our current workaround for this is the conflicts_build PortGroup, which >> bails out and asks the user to deactivate the port in question. This is >> ugly for several reasons: >> - it

Re: port upgrade outdated order

On 04/03/15 17:24, René J.V. Bertin wrote: On Wednesday March 04 2015 16:52:50 Chris Jones wrote: If upstream cannot/wont fix, then if we want to keep the port in MacPorts, it should be worked around. trace mode (or anything that does the same thing, hides the installed version) strikes me as p

Re: port upgrade outdated order

> On Mar 4, 2015, at 12:39 PM, Chris Jones wrote: >> Let me clarify: do all ports register all files that are somehow related >> (not necessarily installed; possibly created afterwards, etc). This came up >> when we discussed using the archive tarballs to reinstall a port, or to >> recreate tho

Re: port upgrade outdated order

On Wed, Mar 4, 2015 at 12:39 PM, Chris Jones wrote: > Hmm, I did not realise this. I thought that it was the opposite way > around, so only files explicitly registered are made visible. Whats the > reason it doesn't work this way ? Some technical limitation or by choice > (for some reason I don't

Re: port upgrade outdated order

Hi, On 04/03/15 17:29, René J.V. Bertin wrote: On Wednesday March 04 2015 17:34:32 Mihai Moldovan wrote: Aren't you relying on the assumption that all ports register all the files they install? They really should. If they don't, that's arguably a bug. Exceptions may apply. Let me clarify:

Re: port upgrade outdated order

On Wednesday March 04 2015 17:34:32 Mihai Moldovan wrote: > > Aren't you relying on the assumption that all ports register all the files > > they install? > > They really should. If they don't, that's arguably a bug. Exceptions may > apply. Let me clarify: do all ports register all files that a

Re: port upgrade outdated order

On Wednesday March 04 2015 16:52:50 Chris Jones wrote: > If upstream cannot/wont fix, then if we want to keep the port in > MacPorts, it should be worked around. trace mode (or anything that does > the same thing, hides the installed version) strikes me as perfect here. Agreed - and that's exac

Re: port upgrade outdated order

OK, I'll rephrase then. It seems OK for a port to opt into tracemode, if needed to fix bugs like this, but if the user has tracemode globally disabled ports should not be allowed to opt out. ^ enabled . ___ macports-dev mailing list macp

Re: port upgrade outdated order

On 04/03/15 16:43, René J.V. Bertin wrote: On Wednesday March 04 2015 16:22:16 Chris Jones wrote: When a port fails to build because the project/package/whatever it provides doesn't support building with a previous version present, is that a port bug? As far as I am concerned its a bug in th

Re: port upgrade outdated order

On Wednesday March 04 2015 16:57:19 Mihai Moldovan wrote: > > You have a lot of faith in this mode, and the extent to which it is > > possible to let it handle each and every case appropriately for each and > > every (potential) port out there. > > Yes, we do. Because trace mode is doing the ri

Re: port upgrade outdated order

On 04/03/15 16:10, René J.V. Bertin wrote: On Wednesday March 04 2015 09:26:10 Brandon Allbery wrote: Port bugs are never OK. A diagnostic/debugging mode that is forced on in some port as a hackaround for port bugs instead of fixing the port is *also* never OK. When a port fails to build beca

Re: port upgrade outdated order

On Wed, Mar 4, 2015 at 11:43 AM, René J.V. wrote: > I used to think like that, until I reported this kind of issue in one of > Qt's component. It was not very delicately pointed out to me that it's > common practice to build things without previous versions present (cf. the > Debian and Ubuntu bu

Re: port upgrade outdated order

On Wednesday March 04 2015 17:16:29 Mihai Moldovan wrote: > Our current workaround for this is the conflicts_build PortGroup, which > bails out and asks the user to deactivate the port in question. This is > ugly for several reasons: > - it requires interactivity > - a deactivated port is not

Re: [133521] trunk/dports/devel/gecode/Portfile

Thanks for reviewing. Fixed in r133528. Cheers! Frank On Mar 3, 2015, at 6:14 PM, Ryan Schmidt wrote: > >> On Mar 3, 2015, at 5:05 PM, m...@macports.org wrote: >> >> Revision >> 133521 >> Author >> m...@macports.org >> Date >> 2015-03-03 15:05:17 -0800 (Tue, 03 Mar 2015) >> Log Message >>

Re: port upgrade outdated order

On Wednesday March 04 2015 16:22:16 Chris Jones wrote: > > When a port fails to build because the project/package/whatever it provides > > doesn't support building with a previous version present, is that a port > > bug? > > As far as I am concerned its a bug in the port, or a bug in the upstre

Re: port upgrade outdated order

On 04.03.2015 12:29 PM, René J.V. Bertin wrote: > Aren't you relying on the assumption that all ports register all the files > they install? They really should. If they don't, that's arguably a bug. Exceptions may apply. > What happens to files installed because of some port C that are used by

Re: port upgrade outdated order

On 04/03/15 15:57, Mihai Moldovan wrote: On Wednesday March 04 2015 08:58:17 Chris Jones wrote: ports themselves cannot opt in or out, and nor should they be able to. Its up to the user running the port command to decide. That's too dogmatic. I have presented a case where the options are either

Re: port upgrade outdated order

On 04.03.2015 03:26 PM, Brandon Allbery wrote: > On Wed, Mar 4, 2015 at 6:29 AM, René J.V. > wrote: > > So to you it's OK if a port fails to build because it pulls in > things from an earlier, installed version of itself that were not > blocked because the f

Re: port upgrade outdated order

On Wednesday March 04 2015 09:26:10 Brandon Allbery wrote: > Port bugs are never OK. A diagnostic/debugging mode that is forced on in > some port as a hackaround for port bugs instead of fixing the port is > *also* never OK. When a port fails to build because the project/package/whatever it provi

Re: port upgrade outdated order

> On Wednesday March 04 2015 08:58:17 Chris Jones wrote: >> ports themselves cannot opt in or out, and nor should they be able to. >> Its up to the user running the port command to decide. That's too dogmatic. I have presented a case where the options are either using trace mode to successfully bu

Re: Trace mode (was Re: port upgrade outdated order)

Hi, - On 4 Mar, 2015, at 15:47, Arno Hautala a...@alum.wpi.edu wrote: > I remember discussions about enabling trace mode by default and > concerns that it included a performance hit. I also seem to remember > discussion about this penalty being reduced recently. Is there any > reason that tra

Re: Re: subversion access

On Wed, Mar 4, 2015 at 3:33 PM, Jerry wrote: > Thanks Mojca! svn.macosforge.org is from the README. I had tried before > asking on the mailing list and did not notice the discrepancy between > macosforge|macports. Thanks a lot for noticing. I'm aware that everything else written there is pretty

Fwd: Re: subversion access

Thanks Mojca! svn.macosforge.org is from the README. I had tried before asking on the mailing list and did not notice the discrepancy between macosforge|macports. Forwarded Message Subject: Re: subversion access Date: Wed, 4 Mar 2015 15:23:01 +0100 From: Mojca Miklavec To:

Trace mode (was Re: port upgrade outdated order)

On Wed, Mar 4, 2015 at 6:52 AM, Chris Jones wrote: > > trace mode, which blocks access to files a port should not be using (because > they have not declared a dependency) is a great tool at providing this > reproducibility. I do not see any use case for an individual port being able > to by itself

Re: port upgrade outdated order

On Wed, Mar 4, 2015 at 6:29 AM, René J.V. wrote: > So to you it's OK if a port fails to build because it pulls in things from > an earlier, installed version of itself that were not blocked because the > feature was not enabled, and do so without as much as an explanation? Port bugs are never O

New Portfile: MoarVM

Portfile for installing MoarVM; needed as part of Perl 6 toolchain. https://trac.macports.org/ticket/46903 Cleaned up the portfile already with help from IRC; If someone could review and commit it, I'd appreciate it. Thanks. -- Will "Coke" Coleda ___

Re: subversion access

On 3/3/15 6:14 PM, Ryan Schmidt wrote: On Mar 3, 2015, at 11:04 AM, Rainer Müller wrote: On 2015-03-03 15:54, Jerry wrote: Is there anonymous or readonly access to subversion? or how could I try the MacPorts_Framework code? Yes, that would be here: https://svn.macports.org/repository/macpor

Re: port upgrade outdated order

On 04/03/15 11:29, René J.V. Bertin wrote: On Wednesday March 04 2015 10:51:06 Chris Jones wrote: Personally, I think what it does is *always* correct. Aren't you relying on the assumption that all ports register all the files they install? yes. If they don't that should be regarded as a b

Re: port upgrade outdated order

On Wednesday March 04 2015 10:51:06 Chris Jones wrote: > Personally, I think what it does is *always* correct. Aren't you relying on the assumption that all ports register all the files they install? What happens to files installed because of some port C that are used by port A while it builds,

Re: fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)

On 2015-03-04 10:10, Mojca Miklavec wrote: > On Mon, Mar 2, 2015 at 11:37 AM, Rainer Müller wrote: >> On 2015-03-02 10:40, Clemens Lang wrote: >>> >>> FWIW, the textmate2 Portfile has the same problem, and I've just used >>> >>> fetch.type git >>> post-fetch { >>> system -W ${worksrcpath}

Re: port upgrade outdated order

On 04/03/15 10:37, René J.V. Bertin wrote: On Wednesday March 04 2015 08:58:17 Chris Jones wrote: I think I understood that ports can opt out from this mode, no? Can they also activate it? ports themselves cannot opt in or out, and nor should they be able to. Its up to the user running the p

Re: port upgrade outdated order

On Wednesday March 04 2015 08:58:17 Chris Jones wrote: >> I think I understood that ports can opt out from this mode, no? Can they >> also activate it? > >ports themselves cannot opt in or out, and nor should they be able to. >Its up to the user running the port command to decide. You have a lo

fetch.type git & GitHub submodules (was: [133168] trunk/dports/sysutils)

On Mon, Mar 2, 2015 at 11:37 AM, Rainer Müller wrote: > On 2015-03-02 10:40, Clemens Lang wrote: >> >> FWIW, the textmate2 Portfile has the same problem, and I've just used >> >> fetch.type git >> post-fetch { >> system -W ${worksrcpath} "${git.cmd} submodule update --init" >> } >> >> t

Re: port upgrade outdated order

note that trace mode fixes this ;-) How so? By masking files that aren't part of the operating system, Xcode, or port dependencies. Hmmm, can't say the term "trace" evokes that for me :) I think I understood that ports can opt out from this mode, no? Can they also activate it? ports t

Re: [133494] trunk/dports/sysutils/pypi2port/Portfile

On Wed, Mar 4, 2015 at 6:09 AM, Ryan Schmidt wrote: > > It looks like you also made whitespace changes to the whole file. If you make > whitespace changes, you should make a separate commit with only whitespace > changes. That way, such commits can be more easily ignored, and functional > change