problem with selfupdate

[pnewell@…]

I am getting an error that I do not understand how to fix or get around. I looked in the existing issues and found one that involved rsync, but the error message was totally different. I do want to acknowledge that I am new to MacPorts and may be missing "the obvious" as it isn't obvious to me

Here is the output from my attempt to selfupdate:

+++ START +++

yzma:~ paul$ port -v selfupdate
--->  Updating MacPorts base sources using rsync
receiving file list ... done
rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/.base.tar.uTJd0g" failed: Permission denied (13)
inflate returned -3 (140 bytes)
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-42/rsync/token.c(419) [receiver=2.6.9]
rsync: connection unexpectedly closed (31 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-42/rsync/io.c(452) [generator=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/release/tarballs/base.tar /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
Exit code: 12
Error: Error synchronizing MacPorts sources: command execution failed
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing MacPorts sources: command execution failed
yzma:~ paul$

+++ END +++

This has worked in the past and, from my newbie POV, it sure looks like my system can't connect with your update given some issue with rsync on my/your/both ends

Thanks for help, Paul

[larryv (Lawrence Velázquez)]

Did you intend to run sudo port selfupdate instead of port selfupdate?

rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/.base.tar.uTJd0g" failed: Permission denied (13)

[pnewell@…]

Replying to larryv@…:

Did you intend to run sudo port selfupdate instead of port selfupdate?

rsync: mkstemp "/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/.base.tar.uTJd0g" failed: Permission denied (13)

Larryv:

First, I hope this is the correct way to reply by adding a comment at the end.

Second, you are absolutely right. My bad.

I had typed "port help" and the message I got was "[...] by running 'port selfupdate'". Neither this message or anything in the error output indicated permissions issue. I should have figured this one out on my own, but the error message led me down the wrong analysis path.

I added the sudo and it worked like a champ. I did notice that the next step "port upgrade outdated" does give me an "insufficient privledges" message if I don't preface the command with sudo.

I am now "selfupdated-ed" and I suspect I will remember the 'sudo' thanks to my mistake in thinking it was a possible problem ("duh!" moments have good memory retention)

Thanks for your help, Paul

[larryv (Lawrence Velázquez)]

Replying to pnewell@…:

I added the sudo and it worked like a champ. I did notice that the next step "port upgrade outdated" does give me an "insufficient privledges" message if I don't preface the command with sudo.

I am now "selfupdated-ed" and I suspect I will remember the 'sudo' thanks to my mistake in thinking it was a possible problem ("duh!" moments have good memory retention)

The documentation often fails to note when superuser privileges may be necessary. Generally speaking, commands that make changes require root:

• sudo port selfupdate / sudo port sync
• sudo port install foo / sudo port uninstall foo
• sudo port activate foo / sudo port deactivate foo
• sudo port upgrade foo
• sudo port setrequested foo / sudo port unsetrequested foo
• sudo port select --set foo foo-x.y
• etc.

Commands that are purely informational don’t need root:

• port info foo / port variants foo
• port contents foo
• port deps foo / port dependents foo
• port installed
• port echo foo\* / port list foo\*
• etc.

Some commands that write files default to using a local directory in the absence of superuser privileges (~/.macports on my machine):

• port fetch foo
• port configure foo
• port build foo
• etc.

And of course, if you have a non-root MacPorts installation, you’re aware of what you’re doing and proceed at your own peril.

[pnewell@…]

Replying to larryv@…:

Replying to pnewell@…:

I added the sudo and it worked like a champ. I did notice that the next step "port upgrade outdated" does give me an "insufficient privledges" message if I don't preface the command with sudo.

I am now "selfupdated-ed" and I suspect I will remember the 'sudo' thanks to my mistake in thinking it was a possible problem ("duh!" moments have good memory retention)

The documentation often fails to note when superuser privileges may be necessary. Generally speaking, commands that make changes require root:

• sudo port selfupdate / sudo port sync
• sudo port install foo / sudo port uninstall foo
• sudo port activate foo / sudo port deactivate foo
• sudo port upgrade foo
• sudo port setrequested foo / sudo port unsetrequested foo
• sudo port select --set foo foo-x.y
• etc.

Commands that are purely informational don’t need root:

• port info foo / port variants foo
• port contents foo
• port deps foo / port dependents foo
• port installed
• port echo foo\* / port list foo\*
• etc.

Some commands that write files default to using a local directory in the absence of superuser privileges (~/.macports on my machine):

• port fetch foo
• port configure foo
• port build foo
• etc.

And of course, if you have a non-root MacPorts installation, you’re aware of what you’re doing and proceed at your own peril.

Larryv:

Thanks for the extra information. Yes, this is a non-root install. I must admit I kinda wish there had been a way (or at least the documentation telling me there was) to install as root for all users (ala Fedora/yum). I've been living with (and burned by) "at my own peril" long enough that I just take it as part of the price of usage.

I'm going to have to read up on that "write files to a local directory" as I need to better understand what you are saying.

That being said, I haven't had any problems with MacPorts except for my own "duh!" moments and I never argue when things are working (and well I might add)

Paul