Re: port listed to be upgraded but not upgraded

On 2018-9-10 14:23 , Ryan Schmidt wrote: > > > On Sep 9, 2018, at 23:21, Joshua Root wrote: > >> On 2018-9-10 13:23 , Ryan Schmidt wrote: >>> It is fine for ports to offer different versions to different platforms. Up >>> to now, a "platform" was the combination of an operating system name,

Re: TeXLive distribution and macports

On Sep 9, 2018, at 10:23, Christopher Jones wrote: > Note that MacPorts has a policy of not using external libraries, as far as > possible (apart from obvious system ones) so if you aim is to have a port > that basically allows something externally externally to pretend to be > something

Re: port listed to be upgraded but not upgraded

On Sep 9, 2018, at 23:21, Joshua Root wrote: > On 2018-9-10 13:23 , Ryan Schmidt wrote: >> It is fine for ports to offer different versions to different platforms. Up >> to now, a "platform" was the combination of an operating system name, major >> version number, and architecture (PowerPC

Re: port listed to be upgraded but not upgraded

On 2018-9-10 13:23 , Ryan Schmidt wrote: > It is fine for ports to offer different versions to different platforms. Up > to now, a "platform" was the combination of an operating system name, major > version number, and architecture (PowerPC or Intel). It has been proposed > that the C++

Re: compilers on Lion

On Sep 8, 2018, at 16:31, Werner LEMBERG wrote: >>> * Where can I get a concise and up-to-date description of >>> portfiles? `portfiles.7' seems to be heavily out of date... >> >> What would you like to know? > > A list of all available variables/keywords, with a description. Yup, that's

Re: port listed to be upgraded but not upgraded

On Sep 8, 2018, at 20:00, Joshua Root wrote: > Riccardo Mottola wrote: >> I finished "port upgrade outdated" successfully (on Lion) and in fact >> I can re-run it and no action happens. >> >> Kaiserin:~ multix$ sudo port -v upgrade outdated >> Password: >> ---> Scanning binaries for linking

Re: Configuring MacPorts to work via a proxy

On Sep 9, 2018, at 13:49, Andrew Luke Nesbit wrote: > I am preparing to install and configure MacPorts on a new machine that > has been supplied by my employer. It will be used in a corporate > network with strict access controls between the intranet and the Internet. > > The only option is

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

Hi, Thank you both for the answers. In the end I ended up using Ryan's command that excludes xattr and that worked perfectly. Thanks again! Regards, Gijs Op za 8 sep. 2018 om 02:54 schreef Ken Cunningham < ken.cunningham.web...@gmail.com>: > > On 2018-09-07, at 5:33 PM, Ryan Schmidt wrote: >

Configuring MacPorts to work via a proxy

Dear all, I am preparing to install and configure MacPorts on a new machine that has been supplied by my employer. It will be used in a corporate network with strict access controls between the intranet and the Internet. The only option is to configure MacPorts to use HTTPS through the official

Re: Requesting new variant for octave and arpack

Hi, For feature requests please either file a feature request in MacPorts Trac, or even better implement the change yourself and submit a Pull Request to GiHub with the changes. mails to this list are far from guaranteed to have any impact in these cases. Chris > On 9 Sep 2018, at 5:49 pm,

Requesting new variant for octave and arpack

Greetings! Please see the discussion here: https://github.com/opencollab/arpack-ng/issues/149#issuecomment-419715128 http://octave.1599824.n4.nabble.com/Issues-with-eigs-td4689314.html#a4689334

Re: TeXLive distribution and macports

Yeah, this is specifically prohibited by our guidelines and the overall workings of the program. There is a TeXlive minimum install, and if you could make one smaller that works with lily pond I’m sure we’d consider it. But this is basically a non-starter with MacPorts. —Mark On Sun, Sep 9, 2018

Re: TeXLive distribution and macports

>> Ah, I assumed too much knowledge, sorry. TeXLive itself comes with >> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and >> recent versions, i.e., 10.10-10.13). By simply prepending the path >> to those binaries to PATH, the `texlive-*' ports from MacPorts >> would be

Re: TeXLive distribution and macports

> On 9 Sep 2018, at 4:46 pm, Werner LEMBERG wrote: > > >>> [...] For example, I want to create a replacement for >>> `texlive-basic' that does nothing except fulfilling the dependency. >>> This is, after installing this dummy `texlive-basic', `port' shall >>> believe that `texlive-basic' is

Re: TeXLive distribution and macports

Hi, Then I am not sure what you intention here is. Note that MacPorts has a policy of not using external libraries, as far as possible (apart from obvious system ones) so if you aim is to have a port that basically allows something externally externally to pretend to be something MacPorts

Re: TeXLive distribution and macports

> If I understand what you are asking correctly, you are asking how to > setup a port that does nothing other than depend on other ports, so > installing it drags in all the dependencies, in one go? No, I want the opposite. For example, I want to create a replacement for `texlive-basic' that

Re: TeXLive distribution and macports

Hi, If I understand what you are asking correctly, you are asking how to setup a port that does nothing other than depend on other ports, so installing it drags in all the dependencies, in one go ? If so we have plenty of these in MacPorts. The first that springs to mind for instance is

TeXLive distribution and macports

My computer for daily use is an openSuSE GNU/Linux box; for TeX processing, however, I'm directly using tlmgr.[*] Regardless of this I don't have any dependency issues with `zypper', openSuSE's package manager, since I'm using the nifty `texlive-dummy-opensuse' package,

Re: compilers on Lion

On 2018-09-08, at 10:45 PM, Werner LEMBERG wrote: > > Ken, > > > What about adding this your explanation to the `LibcxxOnOlderSystems' > page? In particular, people who are mainly interested in porting C++ > GNU software to the Mac (and using it, of course) should rather stay > with