Re: SSL Issues and PortGroup GitHub
On Dec 16, 2016, at 3:09 PM, John Patrick wrote: > I'm having issues with mac ports using the github PortGroup. > > I've raised two tickets over the past year and basically got told it > wasn't an issue with the port itself. > > https://trac.macports.org/ticket/49539 > > https://trac.macports.org/ticket/51381 > > Basically via "port install X", I get and error "SSL certificate > problem: Couldn't understand the server certificate format". > > If I manually perform the git clone task which is reported in the log > file, it works for me. > > Does anyone know of any mac port that uses the github PortGroup and > works? All ports I've tried fail with the same SSL certificate > problem. The above problems all relate to git cloning, and only occur on some users' systems. (Not mine, for example.) Most ports using the github portgroup do not clone using git, but instead fetch a tarball, and so are not affected by this problem. > How can I help debug this issue and attempt a patch? > > The ansible github project has release here > https://github.com/ansible/ansible/archive/v2.2.0.0-1.tar.gz as an > example. But the github.tarball_from option doesn't appear to have any > options to use that archive Note that that is not a "release" (in the sense of "github.tarball_from releases") but is instead only a tag (in the sense of "github.tarball_from tags" which is the default). If that will work, absolutely we should be using that instead. But all ports that fetch using git clone, rather than a tarball, do so because using the automatically-generated tarball doesn't work: these projects use a feature called git submodules, and the automatically-generated github tarballs do not contain the contents of the submodules, so those tarballs are incomplete and cannot build the software. The problem would be solved if the project would produce actual github releases and attach manually-created complete tarballs, but the developers of ansible have not done that. If you would like to begin a dialog with them about doing that, that would be great. The fact that the github portgroup's github.tarball_from deals with tarball-style URLs but does not offer the option to deal with archive-style URLs is orthogonal -- implementing support for archive URLs will not help your situation -- but that issue is tracked at https://trac.macports.org/ticket/40518
Re: SSL Issues and PortGroup GitHub
On Dec 16, 2016, at 4:09 PM, John Patrick wrote: > If I manually perform the git clone task which is reported in the log > file, it works for me. when you manually perform it, are you using /usr/bin/git (like the log on #50469 says) or are you just typing 'git' and maybe getting a MacPorts installed git? -- Daniel J. Luke
SSL Issues and PortGroup GitHub
hiya, I'm having issues with mac ports using the github PortGroup. I've raised two tickets over the past year and basically got told it wasn't an issue with the port itself. https://trac.macports.org/ticket/49539 https://trac.macports.org/ticket/51381 Basically via "port install X", I get and error "SSL certificate problem: Couldn't understand the server certificate format". If I manually perform the git clone task which is reported in the log file, it works for me. Does anyone know of any mac port that uses the github PortGroup and works? All ports I've tried fail with the same SSL certificate problem. How can I help debug this issue and attempt a patch? The ansible github project has release here https://github.com/ansible/ansible/archive/v2.2.0.0-1.tar.gz as an example. But the github.tarball_from option doesn't appear to have any options to use that archive Cheers, John
Re: Branching for 2.4
On 2016-12-16 12:47, Joshua Root wrote: > On 2016-12-16 05:08 , Rainer Müller wrote: >> # port diagnose >> >> 'port diagnose' seems completely broken. The ports tree resources do not >> contain definitions for valid Xcode versions on macOS 10.11 or 10.12. >> Therefore the command errors out very early and is not useful. Overall, >> it looks like this was not tested at all recently. >> >> Do we still want to fix this and polish it for 2.4, or should we just >> skip this new feature for 2.4 and move it to 2.5? > > I don't think there's any harm in shipping it as-is, as it's a single > separate action that doesn't change anything. Best case we just need to > add some more version info, worst case we can say that diagnose is > experimental. It does not do harm, but announcing such a command when it is known to be broken will be bad user experience. I tried to look into these checks quickly, but I do not understand how some of them are even supposed to work. For example 'port diagnose' requires sudo, but wants to check the users PATH, which is just incompatible. The easiest and least-invasive way to get rid of this feature would be to remove the action from the port client after branching. The rest of it would be dead code, but at least the entry point would be gone. >> # usealtworkpath / altprefix >> >> A few years ago I already proposed to rip out usealtworkpath and >> altprefix completely [1], but Joshua wanted to keep it for destroot >> testing. This feature is what enables building in user's ~/.macports >> without sudo. >> >> In my opinion there is no use for this feature anymore and it just adds >> unnecessary complexity. Now that trace mode is even working with SIP >> again, the 2.4 release would be a another opportunity to get rid of this. > > I agreed that there was no more need for this after sandboxing was > added. I wouldn't delay the release for it though. Call it deprecated in > this release? Marking it deprecated by actually informing users with a message at runtime or just with a ChangeLog entry? >> # Update Tcl and other libraries >> >> We should update Tcl and the other libraries to the latest available >> version before branching. I held this back until we resolved PR#6 [2] >> first. > > I guess you mean the latest Tcl 8.5.x. Probably a good idea. Yes, I meant updating to the latest Tcl 8.5.x. Ignoring any of the discussion, we can just add full compressed tarballs once again: https://github.com/macports/macports-base/pull/11 Rainer
Re: [MacPorts] #53049: gqrx dependency missing
On Dec 11, 2016, at 8:49 AM, Michael Dickens wrote:
> It -is- true that, if you are installing 'port' from scratch, then
> doxygen almost always fails to build the first time (I don't recall why;
> nor if I've looked into this issue; nor if anybody has tried to fix this
> issue). The solution is to do:
> {{{
> sudo port clean doxygen
> sudo port install doxygen
> }}}
> and, then go back to the original install, which should now work (seems
> to be 100% reliable in user testing for people working with me in this
> regard). In particular, this happens when installing any GNU Radio port,
> which would include Gqrx.
Given that gnuradio has almost 300 dependencies, the cause of this problem is
probably:
https://trac.macports.org/ticket/50986
Re: Branching for 2.4
On 2016-12-16 05:08 , Rainer Müller wrote: On 2016-12-15 16:39, Joshua Root wrote: If nobody can think of anything else, I'll go ahead and create the branch and tag beta1 this weekend. Some more thoughts on the current state of master: # port diagnose 'port diagnose' seems completely broken. The ports tree resources do not contain definitions for valid Xcode versions on macOS 10.11 or 10.12. Therefore the command errors out very early and is not useful. Overall, it looks like this was not tested at all recently. Do we still want to fix this and polish it for 2.4, or should we just skip this new feature for 2.4 and move it to 2.5? I don't think there's any harm in shipping it as-is, as it's a single separate action that doesn't change anything. Best case we just need to add some more version info, worst case we can say that diagnose is experimental. # usealtworkpath / altprefix A few years ago I already proposed to rip out usealtworkpath and altprefix completely [1], but Joshua wanted to keep it for destroot testing. This feature is what enables building in user's ~/.macports without sudo. In my opinion there is no use for this feature anymore and it just adds unnecessary complexity. Now that trace mode is even working with SIP again, the 2.4 release would be a another opportunity to get rid of this. I agreed that there was no more need for this after sandboxing was added. I wouldn't delay the release for it though. Call it deprecated in this release? # Update Tcl and other libraries We should update Tcl and the other libraries to the latest available version before branching. I held this back until we resolved PR#6 [2] first. I guess you mean the latest Tcl 8.5.x. Probably a good idea. - Josh
