Re: info
On Fri, Nov 27, 2020 at 11:01 AM Artem Loenko via macports-users < macports-users@lists.macports.org> wrote: > Hello, > > I am in the same boat (and have switched from HomeBrew to MacPorts a few > weeks ago, so, maybe I am wrong). > > MacPorts as a tool works just fine on Macs with Apple Silicon, but many > ports are “broken” and have to be fixed. Most of them just do not compile > for `arm64`, and it is not MacPorts fault, some - do > quick question: is Apple using more or less the same stack and toolchain i.e. Mach + FBSD backbone and LLVM, etc. ? or has something very important changed for Apple silicon? What you are saying suggests that nothing major has changed except the LLVM target to arm64, is this correct? TIA, and pardon my ignorance on the matter. Best, -- Alex
Re: problem with perl's `PAR' module
On Sat, Nov 9, 2019 at 12:04 PM Werner LEMBERG wrote: [...] > Perl lib version (5.26.3) doesn't match executable > 'perl' version (5.26.1) at > /opt/local/lib/perl5/5.26/darwin-thread-multi-2level/Config.pm line 62. > Compilation failed in require at > /opt/local/lib/perl5/site_perl/5.26/PAR.pm line 7. > > It could be a Perl port maintainer's issue or a texlive port issue, or even farther upstream in Perl 5.26 and the PAR maintainer on CPAN. Try installing the PAR port before texlive and see if that pulls the right dependency. The version requirement is so close you could probably get away by relaxing the requirement at /opt/local/lib/perl5/site_perl/5.26/PAR.pm line 7 to just 5.26 Best, Aklex
Re: license query
On Thu, Mar 7, 2019 at 4:41 PM Dave Horsfall wrote: [...] > Oh, and I've always regarded the GNU licence as being both a virus (it > compels to use it in your own stuff) and restrictive (you are forced to > adopt certain conditions); for that reason, I avoid GNU software where > possible. > > Agreed. IIRC up to GPL 2.2 the viral effects were not clear and you could still get away with the linking issue the way Torvalds did with Linux ... but the friction between Torvalds and RMS started revealing some of the cracks around GPL in Linux' early days; that's why the Linux kernel remained under a *very* specific version of ti. But with v3 it seems pretty much game over for the GPL... IMHO, anyway. In several discussions with RMS throughout the years, I have always asked about business models around GPL, even once in circa 2000 in visit to the FSF HQ and the answer from them was: we're still trying to figure that out. hmmm. It wasn't until much later with ESR's CATB (and other books) and the birth of the OSI that people were actually trying to understand how to reconcile OSS with making a living. Anyway *BSD has never had this problem but sadly FreeBSD was released after Linux so the damage was already done. At least FBSD met a better fate than Minix who also tried to catch the OSS wave but that one was definitively too little too late. Beside's Tanenbaum (hence Minix) had been marked by the stench of the Tanenbaum–Torvalds debate in 1992. In any case a fascinating topic. Best, Alejandro Imass > -- Dave >
Re: A general philosophical question about MacPorts
On Wed, Feb 20, 2019 at 10:48 AM Mojca Miklavec wrote: > On Wed, 20 Feb 2019 at 16:33, Bill Cole wrote: > > > > The departure of MacPorts from Mac OS Forge as it was > > being wound down was announced in > > > https://lists.macports.org/pipermail/macports-dev/2016-August/033405.html > > While I wouldn't mind if Apple continued to provide hardware building > capacity, the move to GitHub probably saved (and boosted) the project. > > Exactly my point. There is no such "abandonment" from Apple to MacPorts, or any Open Source projects around macOS or anything like that. As I understood in the initial posting, the OP was implying that somehow Apple was departing from supporting MacPorts (and by transitivity Homebrew) and I don't think that is accurate. The two references mentioned so far, namely: 1) The MacPorts History 2) The departure of MacPorts from Mac OS Forge [to GitHub] are not new history nor do they reflect any radical changes in Apple's attitude or support for MacPorts or OSS in general. IMHO, anyway. So the sentence in the original post "Recently, given the overall Apple direction for MacOS" is misleading because there is no such recently nor there is any change in Apple's direction towards MacPorts, Homebrew, XQuartz or any other interfacing with the OSS world. If there are pls. point to them. On the contrary, I think they've always had a pretty clear cut relationship with OSS and participate and/or maintain in hundreds of OSS described here: https://opensource.apple.com and here: https://developer.apple.com/opensource/index.html best, -- Alex > Mojca >
Re: A general philosophical question about MacPorts
On Tue, Feb 19, 2019 at 8:13 AM S. L. Garwood via macports-users < macports-users@lists.macports.org> wrote: > First let me say I have used MacPorts since 10.6.8. > > [...] > I appreciate all the work the developers have put into MacPorts but to me > the handwriting on the wall was when Apple pulled the MacPorts informal > support they provided for years. > Not sure what this means. What do you mean informal support, when did they provide such support and when did they pull it? >
Re: Anyone running X11 apps on Mojave?
I run DIA on Mojave and just run it from XTerm once XQuartz starts up. On Fri, Jan 18, 2019 at 5:40 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > Can you open the X11.app application by double-clicking on it in > /Applications/MacPorts ? > > If so, under the X11 applications menu, choose the first option to open a > terminal, and then open your application that way. > > Can you open it like this, from a terminal? > > open /Applications/MacPorts/X11.app > > > It is not terribly unusual for the automatic launching of the X11.app (ie > when you try to run an application that needs it from the command line) to > get a bit confused. > > About every few months one of my machines gets confused about this --- no > doubt my fault somehow -- but I mess around with this and that for an hour, > often using google for advice, and it usually works itself out, whatever it > is I do to mess it up. (That's not great advice, I know...) > > > Ken > > > > > On 2019-01-18, at 8:32 AM, Pierre Malard wrote: > > I have X11-server installed from MacPorts. An Aqua App is installed in > /Applications/MacPorts/X11.app. When I want to launch it, nothing since my > update to Mojave :-( > > The only way I found is to execute the binary directly from a Terminal > like that: > $ /Applications/MacPorts/X11.app/Contents.MacOS/X11.bin & > It’s not really fun. > > Is anyone have a solution? > > >
Re: apache 2.4: some virtual hosts OK, others load default apache index.html - TYPOS FIXED
On Tue, Oct 24, 2017 at 4:09 PM Murray Eisenberg wrote: > Just a couple of typos in my original message fixed below. > > > On 24 Oct2017, at 4:07 PM, Murray Eisenberg > wrote: > > > > In apache 2.4 I have several virtual hosts configured — properly, I > believe — in /opt/local/etc/apache2/extra/httpd-vhosts.conf. > > > > One of the virtual hosts works just fine, but others do not. > > > > ** This one works ** > > > > For example, once apache is running, in the browser I CAN load > “myhomepage.local” thanks to this part of httpd-vhosts.conf: > > > > > > ServerAdmin someb...@somewhere.com > > DocumentRoot "/Users/me/Sites/MyHomePage" The docs on the apache virtual hosts are pretty clear and FreeBSD’s file layout is very standard. So some of your questions may be answered just by RTFM, but here are some pointers that may help: 1) make sure httpd-vhosts.conf is actually being included. They are usually commented in httpd.conf so search that file for the commented Include directive (search file for “vhost”) 2) If using aliases I think you need to also uncomment vhost_alias module in that same file. 3) When Apache cannot make a match it will default to the first vhost defined (this is explicit in the apache docs). So a good practice is to reserve the first defined vhost precisely for non-matching sites. AFAICR once you use vhost you cannot mix-match conf with global settings. 4) If this server is sitting behind a reverse proxy make sure you are passing all the appropriate headers so the inner server can determine the original request’s domain. Look at ProxyPreserveHost and/or rewrite your headers manually YMMV. Hope some of it helps. — Alex >
