FWIW, I believe I've seen this once -- it was on a colleague's system and they ended up removing and re-installing fink to resolve it. I couldn't get any more information; they were impatient, and it wasn't a system I had access to.
m On Mon, May 30, 2016 at 02:09:33PM -0700, Alexander Hansen wrote: > CCa**ing the proper chain of command. I dona**t really feel like speaking > for the entire project in private discussion. > > On May 30, 2016, at 12:32, Ian Boardman <[email protected]> wrote: > Dear Alexander, > I have no network problem reaching fink project servers from my Mac > via my Comcast ISP. I have no problem manually running curl (for > example) on bindist.finkproject.org to download binary packages. I can > only conclude from everything you've suggested and everything I've tried > and examined that there is something fundamentally flawed in the apt-get > package we have. It does not produce error messages either on the > terminal nor in any log files that will help diagnose this problem. I > could guess there is a configuration error somewhere or an inaccessible > parameter that needs to change or a buried failure in communicating with > Mac OS system network functions that never happens on other Linux based > systems. > > Bit of pedantry here: OS X is not a a**Linux based systema**. Ita**s > barely a BSD-based system, in spite of how it was initially marketed. > > But there is definitely something very wrong that shouldn't be happening > without error reporting. I admit to lacking the skill to dig in further > but I'm convinced this is not some weirdness with my MacBook on my > Comcast network, and I can't believe I would be the only one with this > problem. I honestly feel this deserves more attention from those who > have the skill. > Thanks for all you and your comrades do to make Fink available to free > loaders like myself. > Best regards, > Ian Boardman > > > How is it "fundamentally flawed?" It works for most everybody, and has > for more than a decade, as far as we know based on the lack of bug > reports. I cana**t exclude the possibility that 99.9% of people who try > Fink cana**t get downloading via apt-get to work and move on without > saying anything, of course, but that doesna**t seem likely. There was a > message today (which might have prompted your own message) from somebody > who experienced the same problem, but you two are the only folks to report > such issue that Ia**ve seen within the past few years (I havena**t checked > my logs to see whether there has been such a report further back in the > past). > There are a few things that I know of which arena**t always reported in > peoplea**s error messages which can derail things: > 1) Root method. Wea**ve had problems with some operations (usually build > rather than download) when folks have acquired root access by means other > than the built-in a**sudoa** from the system, since these arena**t as well > tested. > 2) Messing with the system tools. apt-get lockwait is a perl script and > in principle _might_ not work properly against perla**s other than the > system version. However, if running a**apt-geta** by itself has the same > problem, this can be excluded. > 3) Third party tools. Some packagers dona**t necessarily encapsulate > everything nicely in an app bundle and will install libraries in > system-visible locations without necessarily mentioning that fact up > front. I believe folks have also reported some network-related problems > due to third-party tools in the past, but I havena**t actually checked the > list archives to confirm this. > 4) Environment variablesa**related to 3). Some third-party packagers > also will have you set environment variables to run their apps, and not > always appropriately. A well-known issue is using DYLD_LIBRARY_PATH, > which actually overrides the normal linker lookups. That can cause > Fink-built executables to look for libraries in non-Fink locations. > Alternatively, one can give another location precedence over Finka**s > tree. > So, for apt-get, the relevant items are: > $ otool -L /sw/bin/apt-get > /sw/bin/apt-get: > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility > version 150.0.0, current version 1152.0.0) > /sw/lib/libapt-pkg.3.2.dylib (compatibility version 3.2.0, current > version 3.2.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1213.0.0) > $ otool -L /sw/lib/libapt-pkg.3.2.dylib > /sw/lib/libapt-pkg.3.2.dylib: > /sw/lib/libapt-pkg.3.2.dylib (compatibility version 3.2.0, current > version 3.2.0) > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility > version 150.0.0, current version 1152.0.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1213.0.0) > > and if you have a *_LIBRARY_PATH variable set in your shell that points to > a third-party libc++.1.dylib, that could potentially cause apt-get not to > function properly. > 5) System tool settings. Firewall? Ia**m honestly not sure on that. > 6) ISP/local network settings. apt uses ports 53 and 80 for DNS and > download. > > http://superuser.com/questions/120760/what-port-needs-to-be-open-for-debian-to-get-updates > Ia**m speculating that it's possible that a firewall or router might > notrecognize apt-get as a legitimate user of that port (also applicable to > #5, or a third-party firewall from #3). If you can use apt-get from a > location with a different ISP or at least a different network, that would > help narrow the issue down. > Ia**m not sure about whether more verbose diagnostics could be turned on > in our apt-get build or not, but my guess is that it would take a lot of > additional hacking of the source code to do that. At least in that era, > the Debian toolset seemed to me to assume that nothing would ever go > wrong, and the diagnostics arena**t the greatesta**I got any number of > confusing errors when using tools of our vintage on Debian. > Ita**s also possible that something might be happening on the binary > distribution server, too. I dona**t have access to that machine so I > cana**t really do anything like checking connections, lookups, and the > like. > a**akh > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _______________________________________________ > fink-core mailing list > [email protected] > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core -- Matt Billenstein [email protected] http://www.vazor.com/ ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ fink-core mailing list [email protected] List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
