Re: unsigned kexts on Yosemite

On 2014-10-30 13:21 , Joshua Root wrote: > So, this is interesting: > > > > Unless the author missed a step, it appears to be saying that kextload > will load unsigned kexts. Can anyone confirm or deny? (I do

Re: dylib paths

Josh, Lawrence, Clemens, Brandon, Thanks for your responses. I was able to fish “LINKSHARED=...-install_name $libdir/\$(@F)” out of the configure.in file to be able to proceed. -Sterling On Jun 2, 2015, at 12:45PM, Clemens Lang wrote: > Hey, > > - On 2 Jun, 2015, at 19:53, Brandon Allbe

Re: fetching a generated patch from github

On Tuesday June 02 2015 17:23:36 Lawrence Velázquez wrote: > I knew that patches could have ancillary text at the top. What I didn't know > was that said text could be interspersed between hunks as well. I was just trying to say that this follows from the format. I wouldn't put metadata between

Re: fetching a generated patch from github

On Jun 2, 2015, at 3:38 PM, René J.V. Bertin wrote: > On Tuesday June 02 2015 15:09:48 Lawrence Velázquez wrote: > >> Okay; I wasn't sure if patch could deal with them. > > Patchfiles (at least unified diffs) have context, which is why you get those > weird @@ lines in them: they describe wher

Re: dylib paths

Hey, - On 2 Jun, 2015, at 19:53, Brandon Allbery allber...@gmail.com wrote: > I do wonder if something, perhaps as part of trace mode, might run over the > generated destroot and warn about objects that appear to point to things in > the > build or destroot path. (Automatically fixing might

Re: fetching a generated patch from github

On Tuesday June 02 2015 15:09:48 Lawrence Velázquez wrote: > > Does one need a checksum (seems contradictory to using "master" as the > > patch end-point...)? > > Yes, you need a checksum. You shouldn't use "master" or any symbolic > reference; I only did so as an example. That's probably the

Re: fetching a generated patch from github

On Tue, Jun 2, 2015 at 3:09 PM, Lawrence Velázquez wrote: > Okay; I wasn't sure if patch could deal with them. > Historically one of the points of patch was to automatically deal with headers (mail or Usenet news) in a patch (the original use case was to pipe a message from mail/news reader to p

Re: fetching a generated patch from github

On Jun 2, 2015, at 3:00 PM, René J.V. Bertin wrote: > Does that work when there are other patchfiles too, or at least when there's > only a single patchfile to be downloaded? Should work fine with multiple patches; just be sure to avoid overwriting `patchfiles`. In general, base will try to do

Re: fetching a generated patch from github

On Tuesday June 02 2015 14:24:25 Lawrence Velázquez wrote: > patch_sites https://github.com/larryv/llvm/compare > patchfiles 4c919af...master.diff Does that work when there are other patchfiles too, or at least when there's only a single patchfile to be downloaded? Does one need a ch

Re: GSoC Project: Revitalizing Pallet

Hey Guido, Last year I tried to update my work on both Github and Trac, but that involved using git-svn and lots of hair tearing out (so many merge conflicts...). So rather than go through that nightmare again, I intend to just use Trac and then once the project is completed to push it to my perso

Re: fetching a generated patch from github

On Jun 2, 2015, at 1:58 PM, René J.V. Bertin wrote: > Is there a way to get a patchfile from github other than in a pre-patch or > post-fetch step with a statement like > > wget "https://github.com/user/repo/compare/hashA...hashB.patch"; You should be able to do something like this. patch

Perl 5.22

Dear all, Perl 5.22 has just been released. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

fetching a generated patch from github

Is there a way to get a patchfile from github other than in a pre-patch or post-fetch step with a statement like wget "https://github.com/user/repo/compare/hashA...hashB.patch"; that gets a full patch without redistributing even a single diff of code? I've seen examples in the guide how to fetc

Re: dylib paths

On Tue, Jun 2, 2015 at 1:49 PM, Lawrence Velázquez wrote: > > Is that not something that macports does automatically? > > We can't know what any particular broken build system intends to do. > I do wonder if something, perhaps as part of trace mode, might run over the generated destroot and warn

Re: dylib paths

On Jun 2, 2015, at 1:42 PM, Sterling Smith wrote: > I am trying to create a port for the MDSplus library. I have beat the > library’s make process into submission to make use of DESTDIR and other > standard directories. So now it creates several dylibs and executables in > the proper directo

Re: dylib paths

On 2015-6-3 03:42 , Sterling Smith wrote: > I am trying to create a port for the MDSplus library. I have beat the > library’s make process into submission to make use of DESTDIR and other > standard directories. So now it creates several dylibs and executables in > the proper directories, but

dylib paths

I am trying to create a port for the MDSplus library. I have beat the library’s make process into submission to make use of DESTDIR and other standard directories. So now it creates several dylibs and executables in the proper directories, but for which otool -L yields the build directory for

Re: cloudflare/zlib on OS X

On Jun 2, 2015, at 4:40 AM, René J.V. Bertin wrote: > Do you verify that with every bit of code that is available through MacPorts? We make reasonable attempts to make sure that the legal business is kosher. > I'm sorry, but you're making a way too big fuss out of this. The modified > code is

Re: [137005] trunk/dports/aqua/qt4-mac

On Tuesday June 02 2015 09:46:13 Ryan Schmidt wrote: >A user who tries to use qt4-mac with libjpeg-turbo will get a crashing >program, if they got a binary of qt4-mac from the packages server, which was >build with jpeg. No, I don't think so. The binary package from the buildbots (or any other

Re: LaTeXML update stalled

On 6/2/15 7:14 AM, Bruce Miller wrote: Hi all; with all due respect, is it possibly to move forward on https://trac.macports.org/ticket/46896#comment:13 ? Thanks; bruce ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.mac

Re: Easy access to external repositories.

Hi Artur, Since you are discussing the question of ensuring the reliability of results, let me point out that you can add a "test"phase in the Portfile, to run a testsuite with the command "port test". I am developing and maintaining several software package for condensed-matter physics and have f

Re: [137005] trunk/dports/aqua/qt4-mac

On Jun 2, 2015, at 9:42 AM, René J.V. Bertin wrote: > On Tuesday June 02 2015 09:38:42 Ryan Schmidt wrote: > >> Can't do that right now; they don't have the same library version. You >> should put it back to "port:jpeg". > > What's wrong with already using a path:libjpeg.dylib dependency? Bec

Re: [137005] trunk/dports/aqua/qt4-mac

On 02.06.2015 04:38 PM, Ryan Schmidt wrote: > >> On Jun 2, 2015, at 8:48 AM, michae...@macports.org wrote: >> [...] >> + allow for jpeg or jpeg-turbo; > > Can't do that right now; they don't have the same library version. You should > put it back to "port:jpeg". It's okay. Installing jpeg-turbo

Re: [137005] trunk/dports/aqua/qt4-mac

On Tuesday June 02 2015 09:38:42 Ryan Schmidt wrote: >Can't do that right now; they don't have the same library version. You should >put it back to "port:jpeg". What's wrong with already using a path:libjpeg.dylib dependency? R ___ macports-dev mailin

Re: [137005] trunk/dports/aqua/qt4-mac

> On Jun 2, 2015, at 8:48 AM, michae...@macports.org wrote: > > Revision > 137005 > Author > michae...@macports.org > Date > 2015-06-02 06:48:05 -0700 (Tue, 02 Jun 2015) > Log Message > > qt4-mac: > + update to 4.8.7, removing patches and related post-patch code for fixed > code; > + whitespace

LaTeXML update stalled

Hi all; with all due respect, is it possibly to move forward on https://trac.macports.org/ticket/46896#comment:13 ? Thanks; bruce ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-de

Re: GSoC Project: Revitalizing Pallet

On Tue, Jun 2, 2015 at 6:21 AM, René J.V. wrote: > Actually, MacPorts is a clone or descendant of BSD port, no? Isn't there a > BSD variant (FreeBSD, OpenBSD, PC-BSD, ...) that already developed a GUI > interface to the CLI command that could be ported (and not necessarily to > Cocoa). It's not

Re: cloudflare/zlib on OS X

That's the problem. On Jun 2, 2015, at 4:40 AM, René J.V. Bertin wrote: > I can safely assume ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GSoC Project: Revitalizing Pallet

On 02 Jun 2015 René J.V. Bertin wrote: > Actually, MacPorts is a clone or descendant of BSD port, no? > Isn't there a BSD variant (FreeBSD, OpenBSD, PC-BSD, ...) that > already developed a GUI interface to the CLI command that could > be ported (and not necessarily to Cocoa). pkgng isn’t anymor

Re: GSoC Project: Revitalizing Pallet

On Tuesday June 02 2015 14:34:09 Ian Wadham wrote: >Watch out for the "evolutionary" changes in Cocoa/OSX/ObjectiveC across >successive versions of OS X !!! I was particularly having problems figuring >out +++ ObjC would be a great language if it weren't so tightly coupled to an OS :-/ Which a

Re: Easy access to external repositories.

Le 02/06/2015 11:32, Artur Szostak a écrit : >> Do you already have commit access to the repository? > > No, and it is not clear that I should be the one with such access for ESO. > This is something we have to decide here at ESO first. > > >> If not I can act as a sponsor for those packages, u

RE: Easy access to external repositories.

> Do you already have commit access to the repository? No, and it is not clear that I should be the one with such access for ESO. This is something we have to decide here at ESO first. > If not I can act as a sponsor for those packages, until you get it. > > My duty cycle will be more in the r

Re: cloudflare/zlib on OS X

On Monday June 01 2015 21:55:46 Jeremy Lavergne wrote: >Did you verify that this employ is actually empowered to dictate the company's >licensing? Do you verify that with every bit of code that is available through MacPorts? I'm sorry, but you're making a way too big fuss out of this. The modifi

Re: Easy access to external repositories.

Le 01/06/2015 22:54, Artur Szostak a écrit : > Our software is all open source (GPL) so thats not the problem. > What is the duty cycle or delay for the buildslaves to build these packages? > I have seen a number of occasions where MacPorts cannot seem to find the > binary for a Portfile from the d