CC’ing the proper chain of command. I don’t really feel like speaking for the
entire project in private discussion.
> On May 30, 2016, at 12:32, Ian Boardman <isb0...@gmail.com> 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 <http://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 “Linux based system”. It’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
can’t exclude the possibility that 99.9% of people who try Fink can’t get
downloading via apt-get to work and move on without saying anything, of course,
but that doesn’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 I’ve seen within the past
few years (I haven’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 aren’t always reported in people’s
error messages which can derail things:
1) Root method. We’ve had problems with some operations (usually build rather
than download) when folks have acquired root access by means other than the
built-in “sudo” from the system, since these aren’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 perl’s other than the system
version. However, if running “apt-get” by itself has the same problem, this
can be excluded.
3) Third party tools. Some packagers don’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 haven’t actually checked the list archives to confirm this.
4) Environment variables—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 Fink’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? I’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
<http://superuser.com/questions/120760/what-port-needs-to-be-open-for-debian-to-get-updates>
I’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.
I’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 aren’t the greatest—I got any number of confusing errors when using
tools of our vintage on Debian.
It’s also possible that something might be happening on the binary distribution
server, too. I don’t have access to that machine so I can’t really do anything
like checking connections, lookups, and the like.
—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
fink-core@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core
