Re: MacPorts and Anaconda

[Ruben Di Battista]

This can be applied also to virtualenv. What you need to do, imho, is to
just create conda envs. They're isolated from system interpreters and they
should not collide with anything. In these envs you can install whatever
you want... And keep it from interfering with system packages...



On Mon, 12 Aug 2019, 07:55 Fielding, Eric J (US 329A) via macports-users, <
macports-users@lists.macports.org> wrote:

> I saw the discussion the last few days about the problems with using both
> HomeBrew and MacPorts on the same system. I was wondering about problems
> with using MacPorts and Anaconda to install different packages. I have been
> using MacPorts for a long time with few problems, but sometimes I need
> newer versions of Python packages or I need to install something that is
> available as a conda package. It seems that Anaconda is specifically
> designed to keep separate copies of the things it needs and switch between
> environments, so I assume that there should be fewer problems with MacPorts
> than using something like HomeBrew.
>
>
>
> Thanks,
>
> ++Eric
>
> Pasadena, California
>

port-tclsh script for checking if tests exist

[Artur Szostak]

Hi all,


Could someone with more knowledge please indicate how to test if a Portfile has 
the test phase coded in Tcl. I need to pragmatically check if a Portfile has 
either the test.run set to 'yes' or if the 'test {}' code block exists in a 
Portfile. I was trying to prepare a script to run in port-tclsh, by deciphering 
what the MacPorts code is doing. But without the design documents, trying to 
reverse engineer this is proving to be a challenge.


Best regards.


Artur

Re: MacPorts and Anaconda

[Mark Anderson]

Yeah, I've found pyenv works for this as well, and rvm also works for ruby.

—Mark

On Mon, Aug 12, 2019 at 3:22 AM Ruben Di Battista 
wrote:

> This can be applied also to virtualenv. What you need to do, imho, is to
> just create conda envs. They're isolated from system interpreters and they
> should not collide with anything. In these envs you can install whatever
> you want... And keep it from interfering with system packages...
>
>
>
> On Mon, 12 Aug 2019, 07:55 Fielding, Eric J (US 329A) via macports-users, <
> macports-users@lists.macports.org> wrote:
>
>> I saw the discussion the last few days about the problems with using both
>> HomeBrew and MacPorts on the same system. I was wondering about problems
>> with using MacPorts and Anaconda to install different packages. I have been
>> using MacPorts for a long time with few problems, but sometimes I need
>> newer versions of Python packages or I need to install something that is
>> available as a conda package. It seems that Anaconda is specifically
>> designed to keep separate copies of the things it needs and switch between
>> environments, so I assume that there should be fewer problems with MacPorts
>> than using something like HomeBrew.
>>
>>
>>
>> Thanks,
>>
>> ++Eric
>>
>> Pasadena, California
>>
>

Re: port-tclsh script for checking if tests exist

[Clemens Lang]

Hi,

- On 12 Aug, 2019, at 14:30, Artur Szostak aszos...@partner.eso.org wrote:

> Could someone with more knowledge please indicate how to test if a Portfile 
> has
> the test phase coded in Tcl. I need to pragmatically check if a Portfile has
> either the test.run set to 'yes' or if the 'test {}' code block exists in a
> Portfile. I was trying to prepare a script to run in port-tclsh, by 
> deciphering
> what the MacPorts code is doing. But without the design documents, trying to
> reverse engineer this is proving to be a challenge.

It's probably complicated to check whether the test {} block is set, but 
checking
whether test.run is yes should be simple enough.

The most recent examples of using the macports1.0 API are available from in our
build automation scripts at [1]. Specifically, [2] might be helpful: You can 
keep
almost the entire script as-is, but only replace the
  $workername eval get_portimage_path
statement at the end. Everything you put after the "eval" will run in the 
Portfile
context, i.e. just as if you were putting it directly into a Portfile. test.run 
is
what MacPorts calls an "option" [3]. Options are implemented as global variables
(inside the Portfile context), which gives you two methods to access them: 
Either
by using
  [option test.run]
or using
  ${test.run}.

Additionally, you can re-use the same approach [4] uses to test whether 
test.run is
true:
  puts [$workername eval {tbool test.run}]
should give you what you want (although I'm not sure on the quoting of the 
argument
of eval).


 [1] https://github.com/macports/mpbb/blob/master/tools/
 [2] https://github.com/macports/mpbb/blob/master/tools/archive-path.tcl
 [3] 
https://github.com/macports/macports-base/blob/master/src/port1.0/porttest.tcl#L16
 [4] 
https://github.com/macports/macports-base/blob/master/src/port1.0/porttest.tcl#L34


HTH,
-- 
Clemens Lang

To root or not to root?

[Gerben Wierda]

As I’m working my way to somewhat knowing what I’m doing, I have a question.

I always set the timeout on sudo on my systems to 0 seconds. So, for every sudo 
command I enter, I have to type the password. This is somewhat safer than 
having a timeout (normally 300sec).

This becomes tedious when there are many sudo commands to perform, so in that 
case, I often revert to running sudo -s or sudo -i, do my work as root and kill 
the subshell. This has risks too (e.g. doing a wrong rm command, but I’m pretty 
paranoiac about stuff like rm)

For my first steps with macports, I’ve run everything as root that way, because 
I expected there would be changes in /Library/LaunchDaemons etc and I did not 
want toe be typing my password all the time.

But I’m wondering if I should move back to running everything as ordinary user.

Are there disadvantages to running to port commands as root?

If I want to revert, what should I chown to that user? How should ownership in 
/opt be?

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: To root or not to root?

[Mojca Miklavec]

Dear Gerben,

We have a FAQ entry on that, I just couldn't find it right now.

On Mon, 12 Aug 2019 at 22:40, Gerben Wierda wrote:
>
> But I’m wondering if I should move back to running everything as ordinary 
> user.

No.

What if one of the ports has "rm -rf $HOME" inside the Makefile?
And what if you actually need to install some stuff as root (like
installing a service to run your server for X)?

> Are there disadvantages to running to port commands as root?

No, but there are disadvantages to running it as an ordinary user.
You can run plenty of commands without sudo (port search, port info,
port list, port livecheck, ...)
[In theory also stuff like "port configure" or build, even though you
are then exposed to the same security risk if you build as regular
user and it doesn't help you either as you won't be able to install
such port without sudo permissions anyway.]

> If I want to revert, what should I chown to that user? How should ownership 
> in /opt be?

root:admin

If you want to install as ordinary user, you would probably want to
put the package manager somewhere inside your HOME dir, and you'll
have to compile everything from source. (I'm actually not sure what
happens if you try to install as regular user under default prefix,
but I suspect you need to install MacPorts from source and explicitly
say that, and then binary packages also get disabled, but please don't
hold my word for that.)

Some users posted recipes to avoid having to type the password for the
"port" command.

Mojca

What am I forgetting?

[Gerben Wierda]

I have my own cloud git directory tree
I cd to $thattree/net/unbound
I edit the Portfile (startupitem), set revision to 1 (there was no revision)
I run sudo port install unbound
It is not built and installed as nothing has changed (but there has)

What am I forgetting?

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: What am I forgetting?

[Gerben Wierda]

port edit

> On 13 Aug 2019, at 01:24, Gerben Wierda  wrote:
> 
> I have my own cloud git directory tree
> I cd to $thattree/net/unbound
> I edit the Portfile (startupitem), set revision to 1 (there was no revision)
> I run sudo port install unbound
> It is not built and installed as nothing has changed (but there has)
> 
> What am I forgetting?
> 
> Gerben Wierda
> Chess and the Art of Enterprise Architecture 
> Mastering ArchiMate 
> Architecture for Real Enterprises 
>  at 
> InfoWorld
> On Slippery Ice  at EAPJ
> 

Re: What am I forgetting?

[Andrew Udvare]

> On 2019-08-12, at 19:24, Gerben Wierda  wrote:
> 
> I run sudo port install unbound

I think you need to run `port upgrade unbound`. `install` will not upgrade 
packages.

If that does not work, try going into the directory of the Portfile and run 
`port -f upgrade` (no package name argument).

Re: What am I forgetting?

[Mojca Miklavec]

On Tue, 13 Aug 2019 at 01:24, Gerben Wierda  wrote:
>
> I have my own cloud git directory tree
> I cd to $thattree/net/unbound
> I edit the Portfile (startupitem), set revision to 1 (there was no revision)
> I run sudo port install unbound
> It is not built and installed as nothing has changed (but there has)
>
> What am I forgetting?

Did you add your local git checkout to configuration as your local
repository with higher preference?
https://guide.macports.org/chunked/development.local-repositories.html
Check this with
port dir unbound
If not, "sudo port install" or "sudo port upgrade" (without port name)
or "sudo port install subport=unbound" should take the port from the
current dir, but "sudo port install unbound" will probably take the
one that's configured globally and returned by "port dir unbound".

Mojca

Re: nm issue with gimp on 10.5

[Kenneth F. Cunningham]

> On Aug 9, 2019, at 06:32, Riccardo Mottola wrote:
> 
> > I am re-building current GIMP on 10.5 (I have a couple of local patches to 
> > adapt it, last time they gave me a nice working app).
> > 
> > Buld fails for me with:
> > 
> > 
> > .0 -lintl -Wl,-framework -Wl,CoreFoundation -lbabl-0.1   -ljpeg
> > libtool: link: /usr/bin/nm -p  .libs/gimpmodule.o .libs/pygimp-item.o 
> > .libs/pygimp-display.o .libs/pygimp-drawable.o .libs/pygimp-image.o 
> > .libs/pygimp-parasite.o .libs/pygimp-pdb.o .libs/pygimp-tile.o 
> > .libs/pygimp-vectors.o   |  | /opt/local/bin/gsed 's/.* //' | sort | uniq > 
> > .libs/gimp.exp
> > ../../libtool: eval: line 1734: syntax error near unexpected token `|'
> > ../../libtool: eval: line 1734: `/usr/bin/nm -p .libs/gimpmodule.o 
> > .libs/pygimp-item.o .libs/pygimp-display.o .libs/pygimp-drawable.o 
> > .libs/pygimp-image.o .libs/pygimp-parasite.o .libs/pygimp-pdb.o 
> > .libs/pygimp-tile.o .libs/pygimp-vectors.o   |  | /opt/local/bin/gsed 's/.* 
> > //' | sort | uniq > .libs/gimp.exp'
> > make[4]: *** [gimp.la] Error 1
> > 
> > 
> > I have already seen this issue months ago, perhaps in another port, I don't 
> > remember where, the nm version used is too old and using the MacPorts one 
> > should fix it.
> > 
> > How do I accomplish this? = tried setting NM on the command line but it 
> > doesn't ork.
> > 
> > I guess the portfile needs a hack... and, in case, can it be done for 
> > everybody in the official portfile?
> 
> Well the obvious problem in the above output is the two pipes next to each 
> other: "|  |". That's what's causing the system error, and it wouldn't matter 
> what version of nm you're using. There's obviously supposed to be some other 
> program being called between those pipes, a program which perhaps is not 
> being found on your system. I don't know what that program is; you'd have to 
> read the build system files and see if you can find the variable that's 
> between those two pipes and from that variable name figure out what program 
> it's meant to be.
This is a rather weird error, but it indeed is caused by a too-old version of 
NM. Forcing a newer NM does fix it.

Before pounding on me about it, I didn't figure this out, so don't blame me for 
the seeming inconsistencies of it.  Somewhere back in the ancient MacPorts 
tickets archives, Jeremy sorted out that when the version of NM was too old it 
caused this odd error. So feel free to ask him why this presents itself this 
way.

Ken

Re: I'm already using Homebrew for a couple of things, Is it problematic to use Homebrew and MacPorts side by side?

[Kenneth F. Cunningham]

> On Aug 9, 2019, at 18:50, Andrew Udvare wrote:
> 
> > I can see one way: alias port or the Homebrew command to fix PATH to remove 
> > either because this is the main point of conflict. And you have to make 
> > sure you don't install other conflicting commands. So something that is 
> > installed with MacPorts may also need PATH to be fixed.
> 
> MacPorts ignores the PATH while building ports. Yet build problems can still 
> appear if you have Homebrew (or Fink) installed to their default locations 
> (or other software installed to a common location like /usr/local) while 
> building something with MacPorts.

Compilers like clang are prebuilt to search first in /usr/local for include 
files and libraries, and then after that in /usr (or -isysroot).

SO -- if you have things installed in /usr/local then those headers and 
libraries will be found automatically and, helpfully, USED.

THIS is why people love HomeBrew so much -- things seem to  "just work" because 
they are installed (or symlinked) into /usr/local. 

However, this is also why things break cryptically without being able to figure 
out what the heck is going on. Because headers in /usr/local are being used 
instead of the ones you thought would be used.

IF you are very very clever, and can keep track of all this, you can use 
multiple different systems together successfully. 

Otherwise, you are doomed to never knowing what the H*LL is going on with your 
failed builds.

Best,

K