On Mon, Nov 24, 2014 at 3:37 AM, René J.V. rjvber...@gmail.com wrote:
They'd done better by providing some kind of profile (mechanism) allowing
to disable ntp or reduce its polling frequency when on battery ...
Maybe it's possible to come up with something like that ourselves?
openntpd would
Yesterday, a port -d selfupdate revealed that 'rsync.macports.org' was down.
It remained down for many hours. Despite mirroring, that's evidently an
Achilles' Heel in the default configuration's mechanism. I found a way around
it, and it wasn't obvious, requiring temporary modifications to both
Thanks!
--
Eneko Gotzon Ares
Donostia
Tf 943 273 431
On Mon, Nov 24, 2014 at 1:46 AM, Lawrence Velázquez lar...@macports.org
wrote:
___
macports-users mailing list
macports-users@lists.macosforge.org
Does this fix still allow port selfupdate to work once rsync.macports.org
is up again? Or do you need to reverse the changes?
On Mon, Nov 24, 2014 at 8:52 AM, Dan Johnson rdj...@gmail.com wrote:
Yesterday, a port -d selfupdate revealed that 'rsync.macports.org' was
down. It remained down for
You will be using the mirror until you revert your changes. I would restore the
default configuration so you don't get caught mistakenly thinking that
'rsync.macports.org http://rsync.macports.org/' is down when it's your mirror
that went down!
-^-rdj-^-
On Nov 24, 2014, at 9:07 AM, Carlo
On Nov 23, 2014, at 4:28 PM, Mark Brethen wrote:
It occurred to me to comment out the default rsync and make the mirror
default. I think this was the culprit. Will it be easy to migrate to the main
site once its up again?
Yes. And it is up again.
See this:
http://rdj999.blogspot.com/2014/11/eek-macports-is-down.html
http://rdj999.blogspot.com/2014/11/eek-macports-is-down.html
I found that after making a mirror the default, 'port -d selfupdate' restored
'rsync.macports.org' as the default, so I had to re-edit 'sources.conf' to
On Nov 23, 2014, at 10:46 AM, Carlo Tambuatco wrote:
Running port version 2.3.2 on Yosemite 10.10.1
The output of the command:
sudo port -v selfupdate
is:
--- Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Operation timed out (60)
You might not consider it a fault depending on how long the main site is
down. It might save you the trouble of having to revert it back later.
On Mon, Nov 24, 2014 at 9:23 AM, Dan Johnson rdj...@gmail.com wrote:
See this:
http://rdj999.blogspot.com/2014/11/eek-macports-is-down.html
I found
Perhaps, but the first thing I usually do before installing or upgrading
anything is a 'selfupdate', which would succeed, using the mirror. The next
command - 'port install' or whatever - would then time out, because it would
have reverted to using the failed server.
Let's call it a misfeature
On Nov 24, 2014, at 8:23 AM, Dan Johnson wrote:
See this:
http://rdj999.blogspot.com/2014/11/eek-macports-is-down.html
I found that after making a mirror the default, 'port -d selfupdate' restored
'rsync.macports.org' as the default, so I had to re-edit 'sources.conf' to
undo
But I specified [nosync], so it should have ignored that one. Perhaps
'selfupdate' would not have added ,default in that case, but it's unexpected
behavior regardless.
The bug would lie in not properly implementing if another wasn't already
default, which it was.
Thank you for tracking that
On Nov 24, 2014, at 5:28 AM, Brandon Allbery allber...@gmail.com wrote:
openntpd would be a good start;
openntpd looks OK, but the last time I checked, there was no one working on the
portable version anymore.
ntpd's fanatical attempt to maintain microsecond clock accuracy is overkill
for
Is there any reason to have both services running? Can't you just unload the
pacemaker plist and let ntpd handle things like the big boy it is on othe
OSes?
This may be of use.
https://discussions.apple.com/thread/5604114
Oh wow:
This eventually led me to notice the timestamps on the
On Nov 24, 2014, at 11:11 AM, Michael keybou...@gmail.com wrote:
Frankly, I don't understand how the drift file can be changed by ntpd while
the timestamp remains constant. I'd be very interested to hear if anyone else
can confirm this observation.
On Mon, Nov 24, 2014 at 11:29 AM, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 24, 2014, at 11:11 AM, Michael keybou...@gmail.com wrote:
Frankly, I don't understand how the drift file can be changed by ntpd
while the timestamp remains constant. I'd be very interested to hear if
anyone
Oops, forgot to hit reply-all on this. Possible fix as follows:
On Nov 24, 2014, at 11:47 AM, Richard L. Hamilton rlha...@smart.net wrote:
If it’s not critical that the call complete super-fast, an msync() call
(returns faster with MS_ASYNC if you don’t need to know exactly when it
On Mon, 24 Nov 2014, Brandon Allbery wrote:
http://prod.lists.apple.com/archives/darwin-kernel/2014/Nov/msg00015.html
Ooh. That's especially fun given that pacemaker checks the mod time on
ntp.drift... no wonder things get confused.
And is completely broken, from a computer-forensics
On Mon, Nov 24, 2014 at 12:09 PM, Dave Horsfall d...@horsfall.org wrote:
On Mon, 24 Nov 2014, Brandon Allbery wrote:
http://prod.lists.apple.com/archives/darwin-kernel/2014/Nov/msg00015.html
Ooh. That's especially fun given that pacemaker checks the mod time on
ntp.drift... no wonder
On Monday November 24 2014 08:11:43 Michael wrote:
Oh wow:
This eventually led me to notice the timestamps on the drift file were never
changing. Enter this command in your terminal window to read the timestamp:
ls -la /var/db/ntp.drift
Wow indeed: I don't even have that file!
R.
Running ` sudo port upgrade outdated` on Yosemite, I get this error:
$ more
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/main.logversion:1:msg:archivefetch
--- Computing dependencies for
On Nov 24, 2014, at 3:31 PM, Chris M. Balz christopherb...@yahoo.com wrote:
:debug:fetch fetch phase started at Mon Nov 24 12:04:40 PST 2014
:notice:fetch --- Fetching distfiles for llvm-gcc42
:debug:fetch Executing proc-pre-org.macports.fetch-fetch-0
:error:fetch llvm-gcc42 is not supported
On Nov 24, 2014, at 9:08 AM, Dan Johnson rdj...@gmail.com wrote:
You will be using the mirror until you revert your changes. I would restore
the default configuration so you don't get caught mistakenly thinking that
'rsync.macports.org' is down when it's your mirror that went down!
There's
On Mavericks, I had the gnome-desktop package running; that is the only
possible dependency I know of. How would I keep gnome-desktop (or the
equivalent) working, but not be stopped by this error?
On Monday, November 24, 2014 12:49 PM, Lawrence Velázquez
lar...@macports.org wrote:
On Mon, 24 Nov 2014, Lawrence Velázquez wrote:
There's no particular reason to stick with the primary MacPorts
servers, if you find a mirror that works better for you. I'm not aware
of problems with any of the mirrors. If you're not in North America, you
might even benefit from switching
On Nov 24, 2014, at 4:02 PM, Chris M. Balz christopherb...@yahoo.com wrote:
On Mavericks, I had the gnome-desktop package running; that is the only
possible dependency I know of. How would I keep gnome-desktop (or the
equivalent) working, but not be stopped by this error?
I doubt that
Your advice worked: After removing a couple more ports as per the console log,
all is well and I can now run programs such as Epiphany, etc.
On Monday, November 24, 2014 1:24 PM, Lawrence Velázquez
lar...@macports.org wrote:
On Nov 24, 2014, at 4:02 PM, Chris M. Balz
On 25/11/2014, at 10:11 AM, Clemens Lang wrote:
- On 24 Nov, 2014, at 22:17, Dave Horsfall d...@horsfall.org wrote:
A minor problem with FreeBSD is that should an ISP-assigned DNS server
report an error, said ISP helpfully redirects you elsewhere, but luckily
FreeBSD handles this stupidity
On Nov 24, 2014, at 3:17 PM, Dave Horsfall wrote:
On Mon, 24 Nov 2014, Lawrence Velázquez wrote:
There's no particular reason to stick with the primary MacPorts
servers, if you find a mirror that works better for you. I'm not aware
of problems with any of the mirrors. If you're not in
29 matches
Mail list logo
