Re: lldb ...

Sent from my iPhone... On Sep 9, 2016, at 14:46, Lawrence Velázquez wrote: >> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia >> wrote: >> >>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote: >>> >>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is >>> o

Re: newbie python - cmake build problem I can't seem to fix...

> On Sep 9, 2016, at 3:06 PM, Ken Cunningham wrote: > >> >> It's not *bad*, just not ideal. If the build system doesn't respect >> PYTHON_EXECUTABLE, then upstream should fix that. > > True. > > As it turns out, I learned how to re-write the python to be compatible with > 3.x, and fixed the

Re: lldb ...

> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia > wrote: > >> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote: >> >> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is >> owned by a ${macports_operator} who's got admin rights (= myself) and >> reserve use of

Re: lldb ...

> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote: > > On Friday September 09 2016 12:10:05 Rainer Müller wrote: > > >>> different than your case either. Either way, the debugger and all >>> its dependencies need to be signed by a valid certificate. >> >> That does not seem to be the case.

Re: newbie python - cmake build problem I can't seem to fix...

> > It's not *bad*, just not ideal. If the build system doesn't respect > PYTHON_EXECUTABLE, then upstream should fix that. True. As it turns out, I learned how to re-write the python to be compatible with 3.x, and fixed the port that way. So that's probably the best outcome, and I'll submit

Re: newbie python - cmake build problem I can't seem to fix...

> On Sep 9, 2016, at 2:44 PM, Ken Cunningham > wrote: > > I would -- but I haven't quite finished writing the portfile that would need > the ticket filed against it! Aren't you modifying this? https://trac.macports.org/browser/trunk/dports/emulators/hatari/Portfile > I'll see if I can fix it

Re: newbie python - cmake build problem I can't seem to fix...

> > You should also file a ticket against hatari. I would -- but I haven't quite finished writing the portfile that would need the ticket filed against it! I'll see if I can fix it without monkeying with the $PATH -- I knew nobody would like that idea... there's something amiss in the python c

Re: newbie python - cmake build problem I can't seem to fix...

> On Sep 9, 2016, at 1:56 PM, Ken Cunningham > wrote: > > I might dig into the build script and see what's going on in there, but > before I do that is there a way to monkey with the $PATH for the build only, > and then set it back to the user's $PATH when we're done? > > That's cheating, I k

Re: newbie python - cmake build problem I can't seem to fix...

Thanks. Not working so well so far. I might dig into the build script and see what's going on in there, but before I do that is there a way to monkey with the $PATH for the build only, and then set it back to the user's $PATH when we're done? That's cheating, I know.. but I could put ${prefix}/

Re: [MacPorts] #45251: request for lldb

On Friday September 09 2016 17:07:48 MacPorts wrote: > I'm ok with splitting up the port and would be happy do to so if we can > avoid build time regressions and setup sane dependencies. Building a redistributable, standalone libclang is a bit of a separate issue, no? That said, it's also su

Re: lldb ...

On Friday September 09 2016 12:12:34 Lawrence Velázquez wrote: > I don't know why that would happen, unless drastic changes are released > (which does happen sometimes). It's not inherent to base; I update from trunk > all the time with no problems. Yeah, well. I like stability in things that f

Re: newbie python - cmake build problem I can't seem to fix...

On Sep 9, 2016, at 10:32, Ken Cunningham wrote: > > Hi all, thanks in advance for the ongoing education, and I apologize for the > newbie questions. > > > I'm working on updating a port (hatari) that only builds with python2.7 (or > more accurately, doesn't build with python35 selected , but

Re: newbie python - cmake build problem I can't seem to fix...

On 2016-09-09 17:32, Ken Cunningham wrote: > I'm working on updating a port (hatari) that only builds with > python2.7 (or more accurately, doesn't build with python35 selected , > but does build with python27 selected). it uses cmake, and > FindPythonInterp to find python. >

Re: lldb ...

> On Sep 9, 2016, at 10:28 AM, René J.V. Bertin wrote: > >> On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote: >> >> If our release process is too cumbersome and infrequent, we should change >> that. I don't see reason to divide base's functionality more than it already >> is. > >

newbie python - cmake build problem I can't seem to fix...

Hi all, thanks in advance for the ongoing education, and I apologize for the newbie questions. I'm working on updating a port (hatari) that only builds with python2.7 (or more accurately, doesn't build with python35 selected , but does build with python27 selected). it uses cmake, and FindPyth

Re: Binary archives are never fetched for files in my local port repository

On 7 September 2016 at 09:25, Joshua Root wrote: > On 2016-9-6 23:58 , Brandon Allbery wrote: >> On Tue, Sep 6, 2016 at 5:56 AM, Mojca Miklavec wrote: >> >> I recently figured out that ports that I have in my local repository >> are *never* updated from the binary archives, but always compi

Re: lldb ...

On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote: >> I know there's been talk about making at least parts of "base" updateable as >> a port; this could be an easy alternative. > >If our release process is too cumbersome and infrequent, we should change >that. I don't see reason to d

Re: lldb ...

> On Sep 9, 2016, at 6:00 AM, Rainer Müller wrote: > >> On 2016-09-09 03:38, Jeremy Sequoia wrote: >> You are describing a system to automatically create and automatically >> trust a code signing certificate that contains a private key in a file >> on disk that is not encrypted with a passphrase

Re: lldb ...

> On Sep 9, 2016, at 7:38 AM, René J.V. Bertin wrote: > > I do a lot of development on projects for which I also maintain ports; in > fact, development that's tightly coupled to the fact the code is available > via a port. Doing all that work "as myself" only to transfer it to the port > after

Re: [152443] trunk/dports/science/gildas/Portfile

> On Sep 9, 2016, at 3:10 AM, sma...@macports.org wrote: > > Revision > 152443 Author > sma...@macports.org Date > 2016-09-09 02:10:21 -0700 (Fri, 09 Sep 2016) > Log Message > > gildas: Update to version 201609a. > Modified

Re: lldb ...

> On Sep 9, 2016, at 4:17 AM, René J.V. Bertin wrote: > > As a side-thought: it shouldn't be particularly difficult to implement a > "base" feature which defines a set of PortGroups to be included by default by > every port, if such a thing doesn't already exist. As Josh has said previously, t

Re: lldb ...

On Friday September 09 2016 14:25:53 Rainer Müller wrote: >I think you misunderstand this sentence. codesign will search in this >keychain for the certificate itself, but the keychain will not be used >to find other certificates in the certificate chain (all intermediates >up to a root CA). With a

Re: [152440] trunk/dports/net

On Friday, September 9, 2016, Ryan Schmidt wrote: > > > On Sep 8, 2016, at 11:28 PM, ebori...@macports.org wrote: > > > > Revision > > 152440 > > Author > > ebori...@macports.org > > Date > > 2016-09-08 21:28:04 -0700 (Thu, 08 Sep 2016) > > Log Message > > > > zabbix3: New port. > > > > Added P

Re: lldb ...

On 2016-09-09 13:38, René J.V. Bertin wrote: >> At least on OS X 10.10 Yosemite, I can use any path to a keychain with >> `codesign --keychain`. This keychain does not have to be listed in >> `security list-keychains`. > > Does `man codesign` still mention the search list requirement in the > do

Re: lldb ...

On Friday September 09 2016 12:10:05 Rainer Müller wrote: > > different than your case either. Either way, the debugger and all > > its dependencies need to be signed by a valid certificate. > > That does not seem to be the case. In my testing on OS X 10.10 Yosemite, > it is enough to sign /opt

Re: lldb ...

On 2016-09-09 10:17, René J.V. Bertin wrote: > On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote: > >> That's not really necessary. All that is relevant is that the macports user >> has read access to the file. > > The fact that codesign only accepts keychain file arguments

Re: lldb ...

On 2016-09-09 11:26, Jeremy Huddleston Sequoia wrote: > Yes. The fact that we aren't doing that for the binary packages that > we ship is quite embarrassing. We should solve this problem more > generally such that we can ship properly signed binaries for every > port. Users installing the binary

Re: lldb ...

On 2016-09-09 03:38, Jeremy Sequoia wrote: > You are describing a system to automatically create and automatically > trust a code signing certificate that contains a private key in a file > on disk that is not encrypted with a passphrase and only depends on file > system ACLs to protect it. > > Th

Re: lldb ...

One more thought: if indeed we're going to try to codesign everything at some point, in the post-destroot, we'll probably want to ignore errors during that particular step, i.e. catch the codesign return code and simply raise a warning instead of bailing out. Ports that *require* signing (and on

Re: lldb ...

> On Sep 9, 2016, at 01:17, René J.V. Bertin wrote: > > On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote: > >> That's not really necessary. All that is relevant is that the macports user >> has read access to the file. > > If memory serves me well I had to set read acce

Re: lldb ...

On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote: >That's not really necessary. All that is relevant is that the macports user >has read access to the file. If memory serves me well I had to set read access on ~macports, ~macports/Library and ~macports/LibraryKeychains to